Cloud RunとGKEの使い分けまとめ

Cloud RunとGKEはどちらもコンテナを動かすサービスなので、「複数サービスに分けるならGKE」「マイクロサービスならKubernetes」といった規模やアーキテクチャの基準で選び分けようとしがちです。ところがこの基準は間違いのもとで、それっぽい選択肢を出されたときに誤答します。

この記事では、『GKE概要まとめ』までで見たKubernetesの前提を踏まえ、Cloud RunとGKEの本当の分かれ目を整理します。結論を先に言うと、分かれ目は「マイクロサービスかどうか」ではなく「Kubernetesの運用モデルが必要かどうか」です。

前提: Cloud Runでもマイクロサービスは作れる

まず誤解を解きます。マイクロサービスはKubernetesでしか作れないものではありません。『マイクロサービスの概要まとめ』で見たとおり、マイクロサービスはアプリケーションを独立したサービスに分ける設計の話で、実行基盤とは別レイヤーだからです。

Cloud Runは、コンテナを渡すだけで動かせるサーバーレスなコンテナ実行環境です。サービスごとにコンテナを用意して別々のCloud Runサービスとしてデプロイし、API通信や非同期メッセージングで連携させれば、Cloud Runだけでマイクロサービスは成立します。

つまり「サービスを複数に分けている＝Kubernetesが要る」ではありません。分割はどちらでもできます。分かれ目は別のところにあります。

違いはKubernetesの運用モデルが必要かどうか

Cloud RunとGKEの本当の分かれ目は、Kubernetesの制御モデルを自分で握る必要があるかどうかです。

GKEはKubernetesなので、『Kubernetesのデプロイ概要まとめ』で見たような、Podの配置・スケール・ネットワークの細かな制御を、Kubernetesのリソースを通じて自分で宣言できます。その代わり、Kubernetesという仕組み自体を理解し、運用する前提があります。

Cloud Runは、その制御モデルを表に出しません。コンテナと「同時実行数」「最大インスタンス数」といった少数の設定を渡せば、スケールも含めてプラットフォームが面倒を見ます。Podやクラスタという概念は登場しません。

観点	Cloud Run	GKE
実行の考え方	コンテナを渡すと動く	Kubernetes上でコンテナを運用する
スケール	リクエストに応じて自動。ゼロまで縮小できる	HPAやCluster Autoscalerを構成して制御
制御できる範囲	少数の設定に絞られる	Kubernetesのリソースで細かく制御できる
運用の前提	Kubernetesの知識は不要	Kubernetesの理解と運用が前提
向く方向	運用を任せて手離れを良くしたい	制御モデルを握って作り込みたい

同じコンテナを動かすにしても、「制御モデルを握るか、任せるか」で立ち位置が正反対です。これが規模ではなく判断の軸になります。

Cloud RunとGKEのメリット・デメリット

Cloud RunとGKEは、どちらが上位という関係ではありません。運用を任せて速く動かすCloud Runと、Kubernetesの制御を使って作り込むGKEの違いとして捉えると整理しやすくなります。

• Cloud Run
  • メリット
    • コンテナを渡すだけで動き、サーバーやKubernetesを管理しなくてよい
    • アクセスがないときはゼロまで縮小できる
    • 少ない設定で素早くサービスを公開できる
  • デメリット
    • Pod配置やクラスタ構成のようなKubernetesの細かな制御はできない
    • Kubernetesのエコシステムを前提にした構成には向かない
• GKE
  • メリット
    • Kubernetesのリソースを使って、配置・スケール・ネットワークを細かく制御できる
    • Service Meshや各種コントローラなど、Kubernetesの周辺エコシステムを使いやすい
    • 多数の常時稼働サービスをクラスタとしてまとめて運用しやすい
  • デメリット
    • Kubernetesの理解と運用が前提になる
    • Cloud Runより管理する概念が増える

Cloud Runが向くケース

次のような場合は、Kubernetesの運用モデルを持ち込む必要がなく、Cloud Runが向きます。

• HTTPリクエストやイベントに応じて動くサービスで、細かな配置制御が要らない
• アクセスがないときはゼロまで縮小し、コストを抑えたい
• Kubernetesの運用に人手をかけたくない
• サービスを素早く立ち上げ、手離れよく運用したい

「Kubernetesでしかできないこと」を必要としていないなら、Cloud Runで十分、というのが基本の判断です。

GKEが向くケース

次のような、Kubernetesの制御モデルそのものが必要な場合はGKEが向きます。

• Podの配置やスケールを細かく制御したい（ノードの指定、GPU利用など）
• Kubernetesのエコシステム（後述のService Meshや各種コントローラ）を活用したい
• 常時稼働する多数のサービスを、クラスタとして一元的に運用したい
• すでにKubernetesで作られたシステムがあり、それを前提に動かす

言い換えると、GKEを選ぶ理由は「Kubernetesが要るから」であって、「マイクロサービスだから」ではありません。

判断の早見表

要件からの判断を早見表にすると以下です。

要件・状況	向く選択肢
コンテナを動かしたいが、Kubernetesの制御は要らない	Cloud Run
アクセスがないときゼロまで縮小してコストを抑えたい	Cloud Run
Podの配置やスケールを細かく制御したい	GKE
Kubernetesのエコシステムを活用したい	GKE
既存のKubernetes資産を前提に運用する	GKE

迷ったときの目安は「Kubernetesならではの制御を挙げられないならCloud Runで十分」です。

まとめ

Cloud RunとGKEは、規模やアーキテクチャではなく、Kubernetesの運用モデルが必要かどうかで選び分けます。要点は以下です。

• マイクロサービスは実行基盤の話ではなく、Cloud Runでも作れる。分割の有無は判断軸にならない
• 本当の分かれ目は、Kubernetesの制御モデルを自分で握る必要があるかどうか
• Cloud Runはコンテナを渡すと動き、制御を任せる。Kubernetesの知識は不要
• GKEはKubernetesの制御を細かく握れるが、Kubernetesの理解と運用が前提
• 迷ったら、Kubernetesならではの制御を挙げられないならCloud Runで十分

参考

• Cloud Run overview | Google Cloud
• GKE overview | Google Cloud
• Choosing a compute option | Google Cloud