2. Cloud Runとは

Cloud Run は「コンテナを渡すと、HTTPS の URL を返してくれる」フルマネージドなコンテナ実行基盤です。

  • サーバー(VM・クラスタ)の管理は不要
  • リクエストに応じて 0台から自動でスケールし、使った分だけ課金
  • デプロイの単位は普通のコンテナイメージ。ランタイムの縛りなし

4つの実行モデル

同じコンテナイメージから分岐する実行モデル

Cloud Run には現在、ワークロードの形に合わせた4つの実行モデルがあります。

今日のハンズオンの主役は Service ですが、この4分類を頭に入れておくと「Cloud Run は HTTP リクエストを受けるだけのもの」という思い込みをせずに済みます。

実行モデル 向いているもの AWSでいうと
Service HTTPリクエスト / イベント駆動 ECS on Fargate + ALB(1コマンドで立てるなら ECS Express Mode), Lambda + ALB
Job 実行して終わるバッチ処理 ECS RunTask, AWS Batch
Worker pool 常駐してキューをpullし続ける処理(2026年4月GA) SQSをポーリングするECS常駐ワーカー
Instance 1台であることに意味があるシングルトン常駐(2026年8月時点で Preview) 常時起動の Fargate タスク1個 / 小型EC2

Kafka コンシューマや Pub/Sub の pull 型ワーカーのような「リクエスト起点でない常駐処理」も、Worker pool の登場で Cloud Run に乗るようになりました。

同じイメージ・同じ開発体験のまま実行モデルだけ選び替えられるのが、このプラットフォームの設計の一貫性です。

選び分けの軸は3つだけです。(1) リクエストが来るか (2) 処理に終わりがあるか (3) コンテナインスタンスが1台か複数か。

迷いやすいのは Worker pool と Instance の境目で、ここは「N台に分散したいのか」「1台であることに意味があるのか」で分かれます。キューを複数台で食べたいなら Worker pool、状態を持つプロセスを1つだけ動かし続けたいなら Instance です。

Instance は 2026年8月時点で Preview です。gcloud beta run instances から使えますが、us-central1 / us-east1 / europe-west1 は対象外です。今日のハンズオンでは扱いません。

Cloud Run Service

このハンズオンでは、4つの実行モデルのうち Service を中心に扱います。

Cloud Run Serviceを学習するにあたり、まずは以下の3つの要素を押さえると良いでしょう。

  • Service
    • URL を持つ論理単位。ECS でいう「サービス+ALB+ターゲットグループ」を1つにしたもの
  • リビジョン
    • デプロイのたびに作られる不変のスナップショット(イメージ+環境変数+CPU/メモリ設定のセット)
    • 過去のリビジョンは残り続けるため、ロールバックなどが容易
  • トラフィック分割
    • どのリビジョンに何%流すかを制御
    • ロールバックもカナリアもこの仕組みの上に乗っている

「リビジョンが不変で、トラフィックを好きに振り分けられる」

Docker のイメージと同じ「不変のスナップショットを積み重ねる」という考え方が、プラットフォームの機能にまで貫かれています(後述の章で実際に手を動かしながら体感します)。

ここが Cloud Run の設計の美しさでもあります。

料金感

課金モデルは2種類から選びます(Service 作成後も切替可)。

  • request-based billing(デフォルト): リクエスト処理中を中心に CPU・メモリが課金され、スケールtoゼロ時はインスタンス課金がなくなる。起動・終了処理や min-instances のアイドル時間など例外はある
  • instance-based billing: インスタンス起動中は常時課金。単価はrequest-basedより安く、常時処理があるワークロード向け

無料枠も課金モデルごとにあります(2026年8月時点。単価・無料枠は改定されるので公式の料金ページが正)。

  • request-based: 月あたり vCPU 18万秒 / メモリ 36万GiB秒 / リクエスト200万件
  • instance-based: 月あたり vCPU 24万秒 / メモリ 45万GiB秒

個人開発や社内ツールなら実質無料で運用できることが多く、「とりあえず公開しておく」が気軽にできます。

AWSでいうと何?

App Runner・Fargate・Lambda のどれかに対応付けたくなりますが、どれとも微妙に違います。

App Runner は新規顧客への提供を終了していますが(※3)、「あの手軽なやつ」として頭に残っている人が多いので、比較の材料としては表に残しておきます。

この「微妙に違う」がそのまま Cloud Run の魅力なので、表で整理してみましょう(2026年8月時点)。

Lambda(標準) ECS on Fargate + ALB App Runner ※3 Cloud Run
デプロイ単位 関数 / イメージ イメージ イメージ / ソース イメージ / ソース
実行モデル 1リクエスト=1実行環境 ※1 常駐 常駐 1インスタンスで複数リクエストを並行処理(既定80・最大1000)
スケールtoゼロ ○ × ×(最低1台のメモリ課金) ○
課金 リクエスト処理時間 常時(起動時間) プロビジョンドメモリ(常時)+処理中のvCPU リクエスト単位 / 常時 を選択可 ※2
実行時間上限 15分 なし 120秒(リクエストあたり) 60分(リクエストあたり)
HTTPS URL ○(Function URLs) 要 ALB + ACM ○ ○(自動発行)
WebSocket / gRPC / HTTP2 苦手(要別サービス) ○(要ALB/NLB設定) 実質不可(120秒上限) ○
VPC 内で動く 内で動く 外(接続可) 外(接続可)

※1 2025年11月に登場した Lambda Managed Instances では、1つの実行環境で複数リクエストの並行処理が可能になりました。「普通のWebサーバー+インスタンス内並行処理」という Cloud Run が以前から持つモデルへ、AWS 側も歩み寄ってきた、と見ると両クラウドの設計思想の変化が見えて面白いところです。

※2 正式には request-based billing(リクエスト処理中を中心に課金)と instance-based billing(インスタンス起動中は常時課金)の2モデルから選びます。詳細は後述。

※3 App Runner は新規顧客への提供を終了しており、AWS は ECS Express Mode への移行を案内しています(AWS App Runner availability change)。Express Mode は1回の API 呼び出しで ECS クラスタ・サービス・ALB・ACM証明書などをまとめて作り、HTTPS URL を返す仕組みで、実体は「ECS on Fargate + ALB」です(1章の注記)。この表で App Runner の列を残しているのは、その仕様が今も有効という意味ではなく、「Cloud Run ≒ App Runner」という対応付けのどこがずれているかを見るためです。 現在の AWS 側の比較対象としては、左隣の「ECS on Fargate + ALB」を見てください。

押さえておきたいポイントは3つです。

  1. Lambda の手軽さ × コンテナの自由度。 スケールtoゼロ・従量課金でありながら、中身はただのWebサーバー。Lambda 特有のハンドラ関数やランタイム制約がなく、手元で docker run できるものがそのまま動きます。
  2. 1インスタンスが複数リクエストを同時に捌く。 標準の Lambda は1リクエスト1環境なのでインスタンス数が爆発しがちですが、Cloud Run は「並行数(concurrency)」の分だけ1台で受けます。Webサーバーの常識がそのまま通用します。
  3. VPCが前提にない。 AWS では最初に VPC を作りますが、Cloud Run はデフォルトで VPC の外。DB接続などで必要になったときだけ VPC に「つなぎに行く」発想です。

まとめ

  • Cloud Run = コンテナを渡すと HTTPS URL が返ってくる。Lambda の運用感覚 × コンテナの自由度
  • 実行モデルは「Service・Job・Worker pool・Instance」の4つ(Instance は Preview)。今日の主役は Service で、概念は「Service・リビジョン・トラフィック分割」の3つだけ。AWS 側で ECS・ELB・CloudWatch・IAM・Application Auto Scaling に散っていた設定が、この3つと数個のつまみに集まっている
  • 座学はここまで。ここからは全部手を動かします

results matching ""

    No results matching ""