Cloud Run を徹底解説!

記事タイトルとURLをコピーする

G-gen の佐々木です。当記事では Google Cloud (旧称 GCP) のサーバレスなコンテナサービスである Cloud Run を解説します。

Cloud Run

Cloud Run とは

Cloud Run は、任意のプログラミング言語でコードを記述し、実行環境のコンテナイメージを Google Cloud にデプロイするだけで、クラスタの作成や管理をすることなくアプリケーションを実行することができるサービスです。

Cloud Run は、Kubernetes 上にサーバレスなコンピューティング基盤を構築できるオープンソースソフトウェアの Knative がベースとなっています。コンテナはフルマネージドな Kubernetes 環境で実行されます。

コンテナを実行するインスタンスは 負荷に応じて自動的にスケールアウト し、処理をしていないときは インスタンス数が 0 までスケールイン します。

アプリケーションをコンテナイメージ単位でデプロイできることから実行環境の柔軟性が高く、ユースケースは多岐に渡ります。

公式ドキュメントにいくつかのユースケースが紹介されているのでご一読ください。

Cloud Run の基本

2 つの利用方法

Cloud Run には Cloud Run サービスCloud Run ジョブ (2022 年 7 月現在、プレビュー版) の 2 つの利用形態があります。

Google Cloud プロダクトとして「 Cloud Run 」があり、その中のリソースとして「Cloud Run サービス」と「Cloud Run ジョブ」が作成できるイメージです。

当記事では現在一般提供 (GA) されている「 Cloud Run サービス」としての利用方法をご紹介します。

Cloud Run サービスでは、コンテナイメージをデプロイするだけで、コンテナの実行環境(コンテナインスタンス)とリクエストを受信する HTTPS エンドポイントが提供されます。

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 になるまでスケールインします。

最小インスタンス数を 1 以上 にすることにより、コンテナインスタンスのウォーム状態 (いつでも呼び出し可能な状態) を維持し、リクエストをすぐに処理することが可能になります。

その場合は、コンテナがアイドル状態で常に起動していることになるため、課金が発生します。ただし最小インスタンス数でアイドルしている間は、リクエスト処理をしているときよりも安い単価で起動し続けることが可能です ( 料金表 ) 。

CPU・メモリ

サービスのデプロイ時に Cloud Run のコンテナインスタンス 1 つに割り当てる 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 サービス

リクエストを定常的に受信するようなサービスであれば、CPU を常に割り当てる Cloud Run サービス として構成することも可能です(参考)。

CPU を常に割り当てることで、リクエストがないときでも、短期のバックグラウンドタスクや非同期処理タスクをコンテナインスタンス上で実行することができます。

その代わり、起動しているコンテナインスタンスの CPU・メモリ割り当ての料金が常に課金されてしまうので、ユースケースによって使い分けると良いでしょう。

ただし「CPU を常に割り当てる」を設定すると、料金単価は通常よりも安価なものが適用されます (料金表) 。

サービス連携 (トリガー)

Cloud Run サービスでは、クライアントからの HTTPS リクエスト経由の呼び出しのほか、gRPC や WebSocket を使用した通信や、他の Google Cloud サービスからの呼び出しをサポートしています。

Google Cloud のサービスからの呼び出しは、Pub/Sub、Cloud Scheduler、Cloud Tasks、Eventarc、Workflows などが利用できます。

ネットワークアクセスの制限

Cloud Run サービスに対する接続

デフォルトの設定では、ネットワークレベルでは任意のアクセス元から Cloud Run サービスにアクセスすることが可能です。

上り(内向き)設定 を変えることで、ネットワークアクセス元について 3 段階の制限をかけることが可能です。(参考

設定名 許可するアクセス元
内部 (Internal) ・ 内部 HTTP(S) ロードバランサ
・ VPC Service Controls 境界内のリソース
・ 同一プロジェクトの VPC
・ Eventarc, Pub/Sub, Workflows
内部 (Internal) と Cloud Load Balancing ・ 内部 (Internal) で許可されているもの
・ 外部 HTTP(S) ロードバランサ
すべて (All) すべて

Cloud Run サービスから VPC ネットワークへの接続

GKE のクラスタ等とは異なり、Cloud Run サービスは VPC ネットワークの外に作成されるため、デフォルトでは VPC 内のリソースにアクセスすることができません。

サーバレスVPCアクセス を使用することで、Cloud Run サービスを VPC ネットワークに直接接続できます。

認証

非公開サービスの認証

アプリケーションのレベルでは、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、Facebook、GitHubなどのソーシャルプロバイダや、カスタム認証メカニズムを用いたユーザー認証が可能となっています。

料金

Cloud Run では、リクエストの処理中のみ CPU を割り当てる 場合と、CPU を常に割り当てる 場合で料金体系が異なります(料金参考)。

リクエストの処理中のみ CPU を割り当てる Cloud Run サービス

コンテナインスタンスに割り当てられた CPU とメモリの利用時間について 100 ミリ秒 の粒度で課金されます。

インスタンスがアイドル状態のときは、リクエストの処理中よりも料金が多少安くなっています。

また、デプロイした Cloud Run サービスに対するリクエスト数について 100 万リクエスト 単位で課金されます。

CPU メモリ リクエスト
無料枠 毎月最初の 240,000 vCPU 秒 毎月最初の 360,000 GiB 秒 毎月 200 万リクエスト
通常料金 $0.00002400 / vCPU 秒

アイドル状態の場合 $0.00000250 / vCPU 秒
$0.00000250 / GiB 秒

アイドル状態の場合 $0.00000250 / GiB 秒
$0.40 / 100 万リクエスト
確約利用割引 $0.00001992 / vCPU 秒 $0.000002075 / GiB 秒 CUD $0.332 / 100 万リクエスト

※ 2022 年 7 月現在、東京リージョン

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

※ 2022 年 7 月現在、東京リージョン

他サービスとの簡単な比較

Google Cloud が提供する各種 Compute プロダクト (プログラムが動作するためのプラットフォームを提供するプロダクト。 Compute Engine, GKE, Cloud Run 等) は、 構築の柔軟性運用負荷 に差があります。

例として Compute Engine は仮想サーバーのサービスのため、 OS やミドルウェアなどを好きにカスタマイズできます。それは柔軟性が高い代わりに運用負荷が高いことを意味します。

どこまでの柔軟性が必要か、運用負荷をどれだけ抑えたいか、などの観点で適切なサービスを選択することが重要です。

Cloud Run は柔軟性と運用負荷において、Compute プロダクト内でも 中間の位置 にあります。

Google Cloud の Compute プロダクト比較

Google Compute Engine との主な違い

Google Compute Engine(GCE) は Google Cloud の VPC 内に仮想マシンを構築することができる IaaS プロダクトです。

Compute プロダクトの中で最高の柔軟性があり、他のプロダクトにデプロイできるものは GCE にデプロイすることも可能です。

その代わり GCE では、仮想マシンの OS から上にあるものはすべてユーザーが構築・管理する必要があります。

また、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 は「コンテナをサーバレスで容易に実行することができるサービス」という位置づけです。

Google 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 を使用する必要があり、そのぶんの料金がかかる( ※Cloud Run における IAP のサポートは 2022 年 7 月現在プレビュー中)。

また、フレキシブル環境の GAE のみのデメリットとして、VM ベースの実行環境のためスケーリングが遅い、0 までスケールインできないなどがあります。

GAE との比較では、デプロイの容易さで GAE、環境の柔軟性で Cloud Run が優れています。

また、IAP との連携のしやすさから、サービスのフロントエンドとしては GAE が扱いやすくなっています。

Cloud Functions との主な違い

Google Cloud 上でサーバレスコンピューティングを提供するサービスの代表としては Cloud Functions があります。

開発言語に制限がありますが、処理を行うときだけ Google Cloud のコンピューティングリソースを使用することができ、用途によって非常にコスト効率の高いサービスとなっています。

ともにサーバレスである Cloud Functions と Cloud Run の主な違いは以下の点となります。

  • デプロイに必要なものは Cloud Functions ではコードのみ、である一方 Cloud Run ではコンテナイメージ
  • Cloud Functions はデプロイが容易である代わりに実行環境に制限あり
  • Cloud Functions のリクエストタイムアウトは最大 9 分だが、Cloud Run では最大 60
  • Cloud Functions は 1 つのリクエストを 1 つのインスタンスで処理するが、Cloud Run は複数のリクエストを 1 つのインスタンスで処理

コードのみで容易にデプロイでき、単純な処理をさせるのに向いているのが Cloud Functions、実行環境の柔軟性が高く、複雑な処理もさせることができるのが Cloud Run といったところでしょう。

Cloud Run ジョブ(プレビュー)

Cloud Run ジョブでは、コンテナインスタンスを使用して、ユーザーが作成したコードを HTTP リクエスト起点ではない ジョブ として実行することができます。

ジョブは任意のタイミングで実行することができ、コンテナインスタンスを複数組み合わせて実行することにより、60 分以上のジョブ実行や並列処理を実現できます(参考)。

2022 年 7 月時点ではプレビューとなっている機能ですが、Cloud Run が提供するサーバレスなコンテナ実行環境を使用した、リソース効率の高いバッチ処理を行いたい場合には選択肢となってくるでしょう。

Cloud Run for Anthos

Anthos は Kubernetes によってインフラレイヤを抽象化することにより、Google Cloud 以外の各種クラウドプラットフォームやオンプレミス上でもコンテナアプリケーションを同じように構築・運用することができる Google Cloud のサービスです。

Anthos では、各プラットフォーム上に存在するクラスタを、Google Cloud Console の単一のインターフェースで管理することができます。

Cloud Run for Anthos は Anthos が提供するサービスの 1 つであり、Anthos クラスタに対して Google マネージドの Knative を構築することによって、Cloud Run によるサーバレスなコンテナ実行を利用することができるようになります。(参考

通常の Cloud Run では実現できない以下のようなユースケースに対応可能となります。

  • サーバレス VPC アクセスを使用しない VPC ネットワークへの接続
  • 1 つのサービスで複数の種類のコンテナを実行
  • GPU を利用したハイパフォーマンス処理の実行

佐々木 駿太(記事一覧)

クラウドソリューション部

2022年6月にG-genにジョイン。北海道在住。
Google Cloud認定4冠、AWS 5冠、Azure 3冠、Salesforce 1冠のクラウドネイティブなエンジニア。
Professional Cloud Architect、Professional Cloud Network Engineerなどを所持。
現在はコンテナと機械学習を中心に勉強中。