Kubernetessよりも先にCloud Runを先に考える理由

はじめに

Google Cloudにコンテナベースのアプリケーションをデプロイする際、GCE(Google Compute Engine), GKE（Google Kubernetes Engine）, Cloud Runなどが選択肢になります。このセクションではCloud Runの解説をする前準備として、どのようなワークロードでCloud Runを選ぶべきなのかについて述べます。
わたしは新しいアプリケーションをGoogle Cloudで動かすとき、まずCloud Runで足りるかを考えます。これは「GKEを使わない」という宗教ではありません。逆に、Kubernetes API、CRD、DaemonSet、StatefulSet、複雑なservice mesh、既存のKubernetes資産とシステムが密結合になっており切り離せない、cluster単位のplatform engineeringが必要ならGKEを使うべきです。OS、ディスク、固定IP/ポート、特殊なmiddleware、低レイヤ制御が必要ならGCEも自然な選択になります。Cloud Runで扱えないL4 Ingressを構築する場合も同様にGKE/GCEが選択肢となるでしょう。

ただし、多くの HTTP API、Web アプリ、Webhook、BFF、バッチ、キュー consumer、軽量な常駐 worker は、最初から GKE や GCE を必要としていません。必要なのは「コンテナを安全に動かす場所」「スケールする入口」「ログとメトリクス」「IAM とネットワーク」「デプロイとロールバック」です。Cloud Run はこの領域を、かなり少ない運用負荷で満たします。これまでk8sの運用に毎年数千万円の人員稼働コストを払っていたなら、それが数百万、極端な例ならほぼゼロにもなりえます。人員コストが無視できないエンタープライズでのインフラ運用においてはこのコストメリットは強力です。Cloud Runはk8sの廉価版、下位互換のような論調をたまに見かけますが、例えば性能をレイテンシ、スループット、コールドスタート時間に置いたとき、Cloud Runは「安いから性能が低い」ではありません。うまく使えば「安いのにk8sよりも性能が高い」にもなりえます。これをわからずにGKEを採用し、クラウドコストが性能に見合わない、さらに数千万円、数億円の人員コストも上乗せ、という踏んだり蹴ったりな状況になりかねません。

この記事の立場

この連載の立場は、Cloud Run first, not Run only です。Cloud Runで足りるものはCloud Runから考える。足りない理由が出たらGKEやGCEへ進みます。最初から「本番だからGKE」と置きません。この順番を変えるだけで、設計レビューの論点がかなり変わります。つまり問いの立て方が

• 本番だから、どのGKEクラスタに載せるか。

ではなく

• このワークロードは、Cloud Run Services / Jobs / Worker Poolsで足りない理由があるか。

にシフトします。この問いに答えたうえでGKEを選ぶなら、それは筋の良い選定になりえます。逆に答えられないなら、それは検討が足りないと言わざるを得ません。

Cloud RunはGKEの下位互換ではない

Cloud Runは雑に言えば「GoogleがKubernetesクラスタの運用をもろもろ肩代わりしてくれて、抽象化レイヤだけ利用できる」サービスです（厳密には後述のとおりGKEではなくBorgです）。これは公式ドキュメントでも言及されています。

Cloud Run は、Google が週に何十億ものコンテナをデプロイし、Gmail や YouTube などの世界最大のサイトをホストしている環境と同じ環境の Borg 上で動作します。

雑に言えば、Cloud Run は「Google が Kubernetes 的なクラスタ運用を引き受け、利用者にはコンテナ実行の抽象化だけを見せる」サービスです。より正確には、Cloud Run fully managedは GKE の上に載っているのではなく、Google 内部の Borg 上で動いています。Kubernetes はBorg の運用経験から生まれた系譜にあるため、Cloud Run は「GKEの下位互換」ではなく、むしろ Google 内部基盤の抽象化を直接使う選択肢だと言えます。Cloud Runの価値は、次のような運用対象を減らせることです。

• クラスタのバージョンアップ(GKE)
• ノードプールのリソース管理・バージョンアップ(GKE)
• OSバージョンの管理・バージョンアップ(GCE)
• アドオンの互換性確認(GKE)
• CRD、廃止APIの追跡と改修(GKE)
• ワークロードとクラスターの障害原因切り分け(GKE)
• ingress controllerやautoscaler周辺の運用(GKE)
• 小さなサービスごとの基盤テンプレート維持(GKE)

複数のクラスタを所有している組織では毎日のようにこれらの作業が発生し、調査・改修計画策定・検証・チーム間調整・承認プロセスを通して本番環境への変更適用をされていると思います。重要な仕事ですが、もっと重要なのは「これらの運用作業は顧客に対して価値を生まない、非生産的な活動である」ということです。Cloud Runで済むワークロードをCloud Runへ寄せれば、上記の作業の多くをGoogleがマネージドで面倒を見ますからユーザは考える必要がなくなります。その代わりにアプリケーションの新機能開発、SLI/SLO改善など顧客にダイレクトに価値をデリバリーできるタスクへコストを集中させることができます。

Cloud Run firstは、考えることが減るという意味ではない

Cloud Runに載せれば何も考えなくてよいということではありません。むしろ、Cloud Runはアプリケーション側の設計が露出するため、GKEとは異なり、CloudRunならではの設計の腕が求められます。

• ステートレスにできているか
• リトライされても壊れないか
• リクエスト外でCPUを使う必要がないか
• コンカレンシーを上げても接続先が耐えるか
• コールドスタートをどこまで許容するか
• min instances とCPU allocationを混同していないか
• Direct VPC egressを「VPC内VM化」と誤解していないか
• Worker Poolsを固定VMとして扱っていないか
• default URL、IAM、IAPを分けて考えているか

GKEやGCEの低レイヤ運用を増やす前に、アプリケーションとして解くべき問題を明確にする必要があります。

この連載で扱う範囲

この連載ではCloud RunをHTTP servicesだけの実行環境として扱いません。Runファミリーには様々な用途に合わせて使用できるリソースが用意されています。

種類	主な用途	先に見る失敗モード
Cloud Run Services	HTTP API、Webhook、BFF、管理画面	ingress、IAM、CPU idle、concurrency
Cloud Run Jobs	batch、cron、運用タスク、移行処理	retry、checkpoint、冪等性
Worker Pools	pull worker、consumer、bot、runner	二重起動、ローテーション、重複副作用
Cloud Run Functions	薄いevent glue	アプリケーション化しすぎること

GKEが必要な条件

Cloud Run firstと言っても、GKEが必要な条件は明確にあります。

• L4 Ingressが必要
• 小さなCPUリクエストのワークロードを大量に使用する
• Cloud Runで対応していないGPU・リージョンを使用する
• Kubernetes APIを前提にしたplatformを作っている
• CRD/operator/controllerが中心にある
• DaemonSetやnode localな機能が必要
• StatefulSetやvolume設計が主役
• pod間networkingやservice meshを細かく制御したい 注2
• 既存Kubernetes資産が大きく、移行コストが高い

注2：2026/4時点ではCloud Service Mesh for Cloud Runがプレビュー公開されているため、Istioほどではありませんが、RunでもService Meshを使用できるようになりました。

こういう場合にCloud Runへ無理やり寄せると、別の複雑さを作ることになってしまいます。ただ、多くのWeb APIや小さなworkerには、ここまでの理由がないことも多いです。そのとき、GKEをアンチパターンで採用する事故が起こりえます。

希少性はどこにあるか

Cloud Runの入門記事は多くあります。しかし、実務で必要なのは「Cloud Runをどう使うか」だけではなく、Cloud Runを選ぶことでどの運用責任を捨て、代わりにどのアプリケーション設計責任を持つのかを理解することです。Cloud Runはしばしば「簡単なコンテナ実行環境」として紹介されます。しかし実務では、Cloud Runを採用するかどうかはplatform ownershipの設計です。

判断チェックリスト

Cloud Run firstを設計レビューに持ち込むなら、最初に次を見るとよいでしょう。

• L4 Ingressが必要か
• 大規模なGPU処理が必要か
• Kubernetes APIが必要か
• Pod、Node、Clusterを直接制御する必要があるか
• CRD、operator、DaemonSet、StatefulSetが中心か
• Web/API/batch/workerとしてworkloadを分解できるか
• request外CPU、常駐処理、retry、二重起動を設計できるか
• Cloud Runで足りない理由を1文で言えるか
• GKEを選ぶ場合、減らせない運用責任をチームが持てるか

参考

• https://docs.cloud.google.com/run/docs/overview/what-is-cloud-run
• https://docs.cloud.google.com/architecture/select-managed-container-runtime-environment
• https://cloud.google.com/run/pricing
• https://docs.cloud.google.com/run/docs/securing/security

まとめ

Cloud Runを先に考えるのは、GKEを避けたいからではありません。本当に必要な場所でGKEを使うために、GKEでなくてもよいworkloadを先に見分けるための順番がCloud Run firstです。この連載では、その順番を実務で使える判断軸に分解していきます。