G-gen の佐々木です。当記事では Google Cloud (旧称 GCP) のサーバーレスなコンテナサービスである Cloud Run を解説します。
Cloud Run とは
Cloud Run は、任意のプログラミング言語でコードを記述してコンテナイメージ化すれば、コンテナイメージを Google Cloud にデプロイするだけでアプリケーションを実行することができる Google Cloud のフルマネージドサービスです。クラスタの作成やインフラの管理は全く必要ありません。
コンテナを実行するインスタンスは負荷に応じて自動的にスケールアウトし、処理をしていないときはインスタンス数を 0 までスケールインさせることができす。
アプリケーションをコンテナイメージからデプロイできるため実行環境の柔軟性が高く、ユースケースは多岐に渡ります。
ウェブサイトやモバイルバックエンドなど、公式ドキュメントにいくつかのユースケースが紹介されているのでご一読ください。
なお Cloud Run は、Kubernetes 上にサーバーレスなコンピューティング基盤を構築できるオープンソースソフトウェアの Knative がベースとなっています。
Cloud Run の基本
2 つの利用方法
Cloud Run には Cloud Run サービスと Cloud Run ジョブの 2 つの利用形態があります。それぞれ Cloud Run (services)、Cloud Run (jobs) と表記されることもあります。
Google Cloud プロダクトとして「Cloud Run」があり、その中のリソースとして「Cloud Run サービス (services)」と「Cloud Run ジョブ (jobs)」が作成できるイメージです。
当記事では主に「Cloud Run サービス」にフォーカスして解説しています。
Cloud Run サービス (services)
Cloud Run サービスでは、コンテナイメージをデプロイするだけで、コンテナの実行環境（コンテナインスタンス）とリクエストを受信する HTTPS エンドポイントが提供されます。
リクエストを受けてレスポンスを返す、ウェブサイトや API バックエンドなどのユースケースに用いられます。
- 参考 : リソースモデル
Cloud Run ジョブ (jobs)
Cloud Run ジョブでは、コンテナインスタンスを使用して、ユーザーが作成したコードを HTTP リクエスト起点ではない ジョブ として実行することができます。
ジョブは任意のタイミングで実行することができ、コンテナインスタンスを複数組み合わせて実行することにより、60 分以上のジョブ実行や並列処理を実現できます（参考）。
Cloud Run が提供するサーバーレスなコンテナ実行環境を使用した、リソース効率の高いバッチ処理を行いたい場合には選択肢となってくるでしょう。
Cloud Run ジョブの詳細については以下の記事で解説しています。
動的スケーリング
Cloud Run サービスは、HTTPS エンドポイントで受信したリクエストを迅速に処理するために、コンテナインスタンスを自動でスケールアウトします。
コンテナインスタンスはデフォルトで最大 1000 までスケールアウトでき、リクエストのないときはインスタンス数が 0 になるまでスケールインします。
サービスの冗長性
Cloud Run サービスは特定のリージョンに作成され、冗長性とフェイルオーバーのため、リージョン内の複数のゾーンに自動的に複製されます。
Cloud Run は「リージョナルサービス」です。つまり、利用リージョンは選択できますが、その中のゾーンは選択しません。逆に言うと、利用者はゾーンを意識する必要がなく、適切に負荷分散されますし、ゾーン障害も自動的に対応されます。
デプロイ
デプロイ元のコンテナイメージ
Cloud Run にデプロイするコンテナイメージは、Google Cloud のマネージドなコンテナレジストリである Container Registry もしくは Artifact Registry に格納されているものを使用します。
他のプロジェクトにあるコンテナイメージを使用することもできます。
サーバーレス CI / CD プラットフォームである Cloud Build を使用することで、Git リポジトリへの push をトリガーとして、Cloud Run への継続的なデプロイを実現することも可能です（参考）。
コンテナの要件
Cloud Run で実行することができるコンテナにはいくつかの要件があります。
要件の詳細については 公式ドキュメント もご一読ください。
- コンテナイメージ内の実行可能ファイルは、Linux 64 ビット用にコンパイルする必要がある。
- リクエストの送信先ポート（デフォルトのポートは 8080 ）で 0.0.0.0 のリクエストをリッスンする必要がある。
- リクエストを受信してからリクエストのタイムアウト設定で指定された時間内に、レスポンスを返す必要がある。
トラフィック移行とロールバック
サービスをデプロイもしくは構成を変更すると、新しい リビジョン (版) が作成されます。
新しいリビジョンを作成した際に、既存のリビジョンに対する全てのトラフィックを即座に移行するか、段階的に移行するかを選択することができます。
また、複数のリビジョンでトラフィックを分割したり、古いリビジョンにロールバックしたりできます（参考）。
構成
エンドポイント
デフォルトでは、Cloud Run サービスには *.run.app ドメインの一意のサブドメインがサービスの HTTPS エンドポイントとして提供されます。
グローバル外部 HTTPS ロードバランサ または Firebase Hosting を利用することで、カスタムドメインを設定することもできます（参考）。
コンテナインスタンスの最大・最小数
動的スケーリングの最大・最小インスタンス数をあらかじめ設定することができます。
最大インスタンス数はデフォルトが 100、上限は 1000 で 上限の引き上げ も可能となっています。
最小インスタンス数はデフォルトで 0 となっており、リクエストがないときはインスタンス数が 0 になるまでスケールインします。
インスタンス数が 0 の状態で Cloud Run サービスに対するリクエストがあった場合、インスタンスを起動する時間ぶん、処理の遅延が発生します（コールドスタート）。
そこで、最小インスタンス数を 1 以上 にすることにより、コンテナインスタンスのウォーム状態 (いつでも呼び出し可能な状態) を維持し、リクエストをすぐに処理することが可能になります。
最小インスタンス数が 1 以上の場合、指定した数のコンテナインスタンスがアイドル状態で常に起動しており、リクエストを処理していないときでも、アイドル状態のインスタンスの料金が発生します。
アイドル状態のインスタンスの料金は、実際にリクエスト処理をしているときの料金よりも安く設定されています ( 料金表 ) 。
Startup CPU boost
ゼロスケールからのコンテナ起動や、リクエスト数が上昇してスケールアップする際のコンテナ起動を高速化するために Startup CPU boost 機能が存在します。
以下の記事で詳細に解説しています。
CPU・メモリ
サービスのデプロイ時に Cloud Run のコンテナインスタンス 1 つに割り当てる CPU の数とメモリ容量の上限を設定できます。デプロイ後も変更が可能です。
CPU の数に応じて、割り当てることができるメモリ容量の幅が決まります。
- 参考 : CPU 制限
- 参考 : メモリ上限を構成する
| CPU（個） | メモリ容量 |
|---|---|
| 1 未満（最小 0.08） | 128 MiB ~ 512 MiB（CPU 数が 0.08 の場合） |
| 1 | 128 MiB ~ 4 GiB |
| 2 | 128 Mib ~ 8 Gib |
| 4 | 2 GiB ~ 16 GiB |
| 6 | 4 GiB ~ 24 GiB |
| 8 | 4 GiB ~ 32 GiB |
リクエストのタイムアウト
Cloud Run サービスのエンドポイントで受信したリクエストの処理に使用できる時間を設定できます。
デフォルトは 300秒 で、1~3600秒 の範囲で設定することができます。
コンテナインスタンスあたりの同時リクエスト最大数
1つのコンテナインスタンスが処理できる同時リクエストの数を設定できます。
デフォルトは 80 で、1~1000 の範囲で設定することができます。
CPU を常に割り当てる Cloud Run サービス
Cloud Run では、CPU を常に割り当てる Cloud Run サービス として構成することで、リクエストがない場合でもコンテナインスタンスに CPU を割り当て、短期のバックグラウンドタスクや非同期処理タスクを実行することができます。
通常、Cloud Run サービスはリクエストを処理しているときに CPU が割り当てられ、割り当て時間に応じて料金が発生しますが、CPU を常に割り当てる場合はコンテナインスタンスの起動から終了まで CPU が割り当てられ、そのライフサイクル全体で料金が発生します。
ただし、料金単価は通常よりも安価なものが適用されます (料金表) 。
「CPU を常に割り当てる」設定にすべきか否かの選択は、Recomender を参考にすることができます。
Recommender は Cloud Run サービスの過去 1 ヶ月間のトラフィック受信状況から、料金が安くなる場合に「CPU を常に割り当てる」設定にするように推奨してくれます。
- 参考 : CPU の割り当て（サービス）
- 参考 : Recommender による最適化
コンテナ実行環境 (世代)
Cloud Run のコンテナ実行環境として、第 1 世代 と 第 2 世代 が選択できます。
デフォルトの設定では、Cloud Run サービスには第 1 世代の実行環境が使用されるようになっています。
世代ごとの特徴とユースケースは以下の通りです。
- 参考 : 実行環境について
| 世代 | 特徴 | ユースケース |
|---|---|---|
| 第 1 世代 | ・高速なコールドスタート | ・Cloud Run サービスに対するバーストトラフィックが予測される場合。 ・アプリケーションがコールドスタートの影響を受けやすい場合。 ・Cloud Run サービスに対する定常的なトラフィックがなく、コンテナインスタンスの数が頻繁にゼロまでスケールインする場合。 ・512 MiB 未満のメモリを使用したい場合（第 2 世代は最低 512 MiB）。 |
| 第 2 世代 | ・ネットワークファイルシステムのサポート ・Linux との完全な互換性（すべてのシステムコール、名前空間、cgroup が利用可能） ・CPU とネットワークパフォーマンスの高速化 |
・アプリケーションからネットワークファイルシステムを使用する場合。 ・Cloud Run サービスに対する定常的なトラフィックがあり、コールドスタートが多少遅くても許容できる場合。 ・CPU やネットワークに高いパフォーマンスが求められるワークロードの場合。 ・第 1 世代ではサポートされていない OS のシステムコールを使用する場合（参考）。 ・Linux の cgroup 機能を使用したい場合。 |
サービス連携 (トリガー)
Cloud Run サービスでは、クライアントからの HTTPS リクエスト経由の呼び出しのほか、gRPC や WebSocket を使用した通信や、他の Google Cloud サービスからの呼び出しをサポートしています。
Google Cloud のサービスからの呼び出しは、Pub/Sub、Cloud Scheduler、Cloud Tasks、Eventarc、Workflows などが利用できます。
- 参考 : HTTPS リクエストによる呼び出し
- 参考 : Pub/Sub の push によるトリガー
ネットワークアクセスの制限
Cloud Run サービスに対する接続
デフォルトの設定では、ネットワークレベルでは任意のアクセス元から Cloud Run サービスにアクセスすることが可能です。
上り（内向き）設定 を変えることで、ネットワークアクセス元について 3 段階の制限をかけることが可能です。
| 設定名 | 許可するアクセス元 |
|---|---|
| 内部 (Internal) | ・ 内部アプリケーションロードバランサ ・ VPC Service Controls 境界内のリソース ・ 同一プロジェクトの VPC ・ Eventarc, Pub/Sub, Workflows |
| 内部 (Internal) と Cloud Load Balancing | ・ 内部 (Internal) で許可されているもの ・ 外部アプリケーションロードバランサ |
| すべて (All) | すべて |
なお Google Cloud で「上り」「内向き」「Ingress」という言葉が出てきた場合は、サービスの外部や Google Cloud の外部を「下」「外」とみなすので、サービスの方向 (Google Cloud の方向) に入る方向のトラフィックが「上り」「内向き」「Ingress」となります。対義語はそれぞれ「下り」「外向き」「Egress」です。
Cloud Run サービスから VPC ネットワークへの接続
GKE のクラスタ等とは異なり、Cloud Run サービスは VPC ネットワークの外に作成されるため、デフォルトでは VPC 内のリソースに Private IP (内部 IP) でアクセスすることができません。
サーバーレス VPC アクセス もしくは Direct VPC Egress 機能を使用することにより、Private IP を使用して VPC リソース接続することができます。
サーバーレス VPC アクセスと Direct VPC Egress については、以下の記事で解説しています。
認証
非公開サービスの認証
アプリケーションのレベルでは、Cloud Run サービスはデフォルトで非公開としてデプロイされます。
非公開のサービスでは、リクエスト時に IAM の認証情報を使用することでサービスを呼び出します。つまり IAM 認証情報を持っていない人 / プログラムからのリクエストは受け付けません。
他の Google Cloud サービスから Cloud Run サービスを呼び出す場合は Cloud Run 起動元（roles/run.invoker） ロール、もしくは同等の権限をもつカスタムロールが付与されたサービスアカウントによる認証が必要です。
Workload Identity 連携 を用いることで、OpenID Connect（OIDC）もしくは SAML 2.0 をサポートする外部 ID プロバイダを使用した認証も可能となっています。
- 参考 : 認証の概要
公開アクセスの許可
デプロイしたサービスが公開 API やウェブサイトの場合は 公開アクセスを許可 します。
コンソールや CLI から allUser メンバータイプ に対して Cloud Run 起動元（roles/run.invoker） ロールを割り当てるだけで、未認証のサービス呼び出しを許可することができます。
- 参考 : 公開（未認証）アクセスを許可する
ユーザー認証
サービスに対して、許可されたエンドユーザーのみにアクセスを制限する場合、Identity Platformを使用します。
Identity Platform は独立した Google Cloud プロダクトであり、Cloud Run とは別プロダクトです。
Identity Platform では、メールアドレスとパスワード、電話番号、Google、Facebook、GitHubなどのソーシャルプロバイダや、カスタム認証メカニズムを用いたユーザー認証が可能となっています。
- 参考 : Identity Platform
料金
料金体系
Cloud Run では リクエストの処理中のみ CPU を割り当てる 場合と、CPU を常に割り当てる 場合で、別々の料金体系が適用されます。
- 参考 : Cloud Run の料金
リクエストの処理中のみ CPU を割り当てる Cloud Run サービス
コンテナインスタンスがリクエストを処理している間に割り当てられた CPU とメモリの利用時間について 100 ミリ秒 の粒度で課金されます。
最小インスタンス数を 1 以上にしている場合のみ、アイドル状態のインスタンスに対しても料金が発生します。
また、デプロイした Cloud Run サービスに対するリクエスト数について 100 万リクエスト 単位で課金されます。
| CPU | メモリ | リクエスト | |
|---|---|---|---|
| 無料枠 | 毎月最初の 180,000 vCPU 秒 | 毎月最初の 360,000 GiB 秒 | 毎月 200 万リクエスト |
| 通常料金 | $0.00002400 / vCPU 秒 アイドル状態の場合 $0.00000250 / vCPU 秒 (最小インスタンス数が1以上のとき) |
$0.00000250 / GiB 秒 アイドル状態の場合 $0.00000250 / GiB 秒 (最小インスタンス数が1以上のとき) |
$0.40 / 100 万リクエスト |
| 確約利用割引 | $0.00001992 / vCPU 秒 | $0.000002075 / GiB 秒 | CUD $0.332 / 100 万リクエスト |
※上記は2023年4月現在、東京リージョンのもの
vCPU 秒：vCPU が 1 つのインスタンスを 1 秒間 実行すること。
GiB 秒：メモリ容量が 1 ギビバイトのインスタンスを 1 秒間 実行すること。
アイドル状態：最小インスタンス数でウォーム状態を維持している場合。
CPU を常に割り当てる Cloud Run サービス
CPU を常に割り当てる場合、リクエスト単位の課金はなく、CPU とメモリの利用時間についての課金のみとなっています。
コンテナインスタンスの起動から終了までの間、リソースの利用料金が発生します。
常時リソースが割り当てられている分、単価は安くなっています。
| CPU | メモリ | |
|---|---|---|
| 無料枠 | 毎月最初の 240,000 vCPU 秒 | 毎月最初の 450,000 GiB 秒 |
| 通常料金 | $0.00001800 / vCPU 秒 | $0.00000200 / GiB 秒 |
| 確約利用割引 | $0.00001494 | $0.00000166 |
※上記は2023年4月現在、東京リージョンのもの
他サービスとの比較
Compute プロダクトの考え方
Google Cloud が提供する各種 Compute プロダクト (プログラムが動作するためのプラットフォームを提供するプロダクト。 Compute Engine, GKE, Cloud Run 等) は、 構築の柔軟性 と 運用負荷 に差があります。
例として Compute Engine は仮想サーバーのサービスのため、 OS やミドルウェアなどを好きにカスタマイズできます。それは柔軟性が高い代わりに運用負荷が高いことを意味します。
どこまでの柔軟性が必要か、運用負荷をどれだけ抑えたいか、などの観点で適切なサービスを選択することが重要です。
Cloud Run は柔軟性と運用負荷において、Compute プロダクト内でも 中間の位置 にあります。
コンピュート系サービスの選択方法については以下の記事でも論じています。当記事では Cloud Run を軸として説明しますが、以下の記事もぜひご参照ください。
Cloud Run と Compute Engine の違い
Compute Engine (GCE) は Google Cloud の VPC 内に仮想マシンを構築することができる IaaS プロダクトです。
Compute プロダクトの中で最高の柔軟性があり、他のプロダクトにデプロイできるものは GCE にデプロイすることも可能です。
その代わり GCE では、仮想マシンの OS から上にあるものはすべてユーザーが構築・管理する必要があります。
また Cloud Run のようなサーバーレスアーキテクチャではないため、仮想マシンの実行中は何も処理をしていなくても課金され続けます。
Compute Engine については以下の記事も参考にしてください。
Cloud Run と Google Kubernetes Engine の違い
Google Cloud の代表的なコンテナサービスである Google Kubernetes Engine (GKE) では、コンテナをデプロイする Kubernetes クラスタをユーザーが管理しなければなりませんが、フルマネージドの Cloud Run と比較して、OS、CPU、GPU、ディスク、メモリ、ネットワークなどの柔軟な構成が可能となっています。
また GKE には、Kubernetes クラスタの管理の大部分を Google Cloud に任せることのできる Autopilot モードがあります。
Cloud Run と GKE では、主に以下のような点が異なります。
- リクエストがないとき GKE は 0 までスケールインできない。 Cloud Run ではできる
- GKE は複雑な構成が可能 (マイクロサービス) 。 Cloud Run でデプロイできるのは 1 つのコンテナイメージのみ
- GKE は VPC 内で動作するため、VPC 内 のリソースとの直接接続が容易。Cloud Run では VPC 内のリソースと通信するためにはサーバーレス VPC アクセスなどの設定が必要
Cloud Run と GKE はどちらもコンテナ実行環境を提供するサービスですが GKE は「高度なコンテナオーケストレーションを実現できるサービス」、 Cloud Run は「コンテナをサーバーレスで容易に実行することができるサービス」という位置づけです。
GKE については以下の記事も参考にしてください。
Cloud Run と App Engine の違い
Cloud Run と コンセプトが似ているサービスとして Google App Engine (GAE) があります。
GAE は、コードと構成ファイルをデプロイするだけで、アプリケーションを容易に実行できるサービスとなっています。
スタンダード環境の GAE では開発言語の制限がありますが、 Cloud Run 同様、リクエストがないときにインスタンスが 0 までスケールインします。
GAE と Cloud Run の主な違いは以下の点となります。
- GAE ではデプロイに必要なのはコードと構成ファイルのみであり、Cloud Run よりも実行環境の柔軟性が劣る代わりに、容易にアプリケーションを実行することができる。
- GAE では Identity Aware Proxy (IAP) による認証がサポートされている。Cloud Run でも IAP を使用することができるが、Serverless NEG に紐づける必要があり、そのフロントエンドとして使用するロードバランサ分の料金がかかる。
また、フレキシブル環境の GAE のみのデメリットとして、VM ベースの実行環境のためスケーリングが遅い、0 までスケールインできないなどがあります。
GAE との比較では、デプロイの容易さで GAE、環境の柔軟性で Cloud Run が優れています。
GAE については以下の記事も参考にしてください。
Cloud Run と Cloud Functions の違い
サーバーレスコンピューティングを提供する Google Cloud サービスの代表として Cloud Run の他に Cloud Functions があります。
Cloud Functions はソースコードだけを用意すればデプロイすることができることが、 Cloud Run との最も大きな違いです。
コードのみで容易にデプロイでき単純な処理をさせるのに向いているのが Cloud Functions 。実行環境の柔軟性が高く、長時間に渡る複雑な処理もさせることができるのが Cloud Run といえます。
Cloud Functions と Cloud Run の主な違いは以下のとおりです。
| 比較観点 | Cloud Run | Cloud Functions |
|---|---|---|
| デプロイするもの | コンテナイメージ | ソースコード |
| 開発言語 | 制限なし | 制限あり |
| 最長実行時間 | 60 分間 | (第2世代の場合) HTTP 関数で 60 分 イベントドリブン関数で 10 分 |
Cloud Functions については以下の記事も参考にしてください。
Cloud Run for Anthos
Anthos は Kubernetes によってインフラレイヤを抽象化することにより、Google Cloud 以外の各種クラウドプラットフォームやオンプレミス上でもコンテナアプリケーションを同じように構築・運用することができる Google Cloud のサービスです。
Anthos では「オンプレミス」「AWS」「Google Cloud」などの各プラットフォーム上に存在する Kubernetes クラスタを、Google Cloud Console の単一のインターフェースで管理することができます。
Cloud Run for Anthos は Anthos が提供するサービスの 1 つであり、Anthos クラスタに対して Google マネージドの Knative を構築することによって、Cloud Run によるサーバーレスなコンテナ実行を利用することができるようになります（参考）。
通常の Cloud Run では実現できない以下のようなユースケースに対応可能となります。
- サーバーレス VPC アクセスを使用しない VPC ネットワークへの接続
- 1 つのサービスで複数の種類のコンテナを実行
- GPU を利用したハイパフォーマンス処理の実行
佐々木 駿太 (記事一覧)
G-gen最北端、北海道在住のクラウドソリューション部エンジニア
2022年6月にG-genにジョイン。Google Cloud Partner Top Engineer 2024に選出。好きなGoogle CloudプロダクトはCloud Run。
趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。
Follow @sasashun0805