Cloud Runは2019年4月のGoogle Cloud Nextで発表され、同年11月にGA（一般提供）となったサーバレスコンテナ実行基盤である。コンテナイメージを渡せばGoogle側がHTTPSのエンドポイントを生やし、リクエスト量に応じて0からインスタンスを自動立ち上げ・自動停止する。基盤にはオープンソースのKnativeを採用しており、Cloud Runで動くアプリは原則として他のKubernetes＋Knative環境でも動かせる「ロックインの薄さ」が強調されてきた。本記事ではCloud Runの設計思想、サービスとジョブの違い、そしてApp EngineやCloud Functionsとの棲み分けまでを整理する。
この記事の目次
- Knativeを土台にしたサーバレス設計
- ServiceとJob、二つの実行モデル
- 課金とコールドスタートのチューニング
- App EngineやFunctionsとの棲み分け
- まとめ
Knativeを土台にしたサーバレス設計
Cloud Runのデータプレーンは、Kubernetes向けのサーバレス基盤として2018年から開発されてきたOSS「Knative」のServingコンポーネントをベースにしている。Knativeはルーティング、スケール、リビジョン管理を抽象化したCRD（カスタムリソース）を提供し、HTTPリクエストの有無に応じてPod数を0〜Nの間で自動調整する仕組みを持つ。Cloud RunはこのKnativeのAPI互換を維持しているため、開発者はYAMLマニフェストをそのままKnative on GKEへ移植することもできる。
コンテナ実行時はGoogleが社内向けに開発したサンドボックス「gVisor」上でユーザーコンテナが走る。gVisorはユーザー空間でLinuxシステムコールをエミュレートし、ホストカーネルへのアクセスを遮断することで、マルチテナント環境でも強い分離を確保している。ソースコードからCloud Buildを経由してビルド・デプロイまでをワンコマンドで回せる体験もCloud Runの大きな魅力で、Dockerfileすら書かずに済むケースも多い。
ServiceとJob、二つの実行モデル
Cloud Runには大きく分けて「Service」と「Job」の2つのリソース種別がある。ServiceはHTTPS（あるいはgRPC、WebSocket）を受けるエンドポイントを生やし、リクエストに応じてインスタンスを0〜上限値の間で自動スケールする。デプロイのたびに「リビジョン」が積み上がり、トラフィック分割や即時ロールバックが可能になっている点もKnative由来の特徴だ。
一方のJobは2022年に追加された機能で、リクエスト駆動ではなく「処理を一回走らせて終わる」バッチ実行用に設計されている。Cloud SchedulerやEventarcと組み合わせれば、夜間バッチや定期データ取り込みをサーバレスに回せる。並列タスクインデックスを指定して同じコンテナを多数同時起動する機能もあり、軽量なデータ処理基盤として小規模Dataflowの代替に使われることも増えている。
課金とコールドスタートのチューニング
Cloud Runの課金は基本的に「リクエストを処理している間のCPU秒、メモリ秒、ネットワーク量」をミリ秒単位で精算する従量モデルである。アクセスがなければ0スケールしてインスタンスが落ち、課金もほぼゼロになる点はサーバレスの王道だ。一方で常時稼働させたいワークロードには「インスタンスベース課金」が別途用意され、KafkaコンシューマやWebSocket常時接続といったケースに対応する。
コールドスタート対策としては「min-instances」を1以上に固定する、起動の重い依存ライブラリを減らす、ベースイメージを軽量化するといった工夫が定番である。1インスタンスが同時に処理できるリクエスト数（concurrency）を上げると、コンテナ起動回数を減らせるためレイテンシが改善するが、メモリ競合に注意が必要だ。「CPU Always Allocated」を有効にすると、リクエストがない時間帯もバックグラウンドジョブを走らせられるため、軽量なワーカ用途にもフィットする。
App EngineやFunctionsとの棲み分け
GCPのサーバレス系サービスはCloud Runのほかに、App EngineとCloud Functionsが並走しており、新規開発者は選択に迷うことが多い。App Engineは2008年から続く老舗PaaSで、特定の言語ランタイム上にコードを上げて動かす、より「縛りのある」モデルだ。Cloud Functionsは2017年登場のFaaSで、関数単位でデプロイし、Pub/SubメッセージやStorageのオブジェクト生成イベントをトリガに動かす。
Cloud Runは「コンテナイメージを渡せばよい」という最も自由度の高い選択肢で、近年はCloud Functions（第2世代）の実体もCloud Runとして実装されている。「言語制約を受けたくない」「コンテナで動かしたい」「将来Kubernetesに引っ越すかもしれない」という条件があるならCloud Runを起点に考え、明確に関数単位で十分ならFunctions、伝統的PaaSが心地よければApp Engineを選ぶ、という棲み分けが現実的である。
まとめ
Cloud Runは2019年にKnativeを土台として登場したサーバレスコンテナ基盤であり、現在ではFunctionsの第2世代の実装基盤としても使われるGoogle Cloudサーバレスの中核に位置している。ServiceとJobの両モード、柔軟な課金、コンテナ任意の自由度、そしてKnative互換による移植性が組み合わさり、Kubernetesの運用負担を避けたい組織の有力な落とし所となっている。「とりあえずDockerfileがあるなら、まずCloud Runへ」と言える手軽さは、サーバレス選定の起点として覚えておきたい。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント