Cloud Run とは

Cloud Run は、Google のスケーラブルなインフラストラクチャ上でコンテナを直接実行できるマネージド コンピューティング プラットフォームです。

コンテナ イメージをビルドできるものであれば、任意のプログラミング言語で記述されたコードを Cloud Run にデプロイできます。コンテナ イメージのビルドは任意です。Go、Node.js、Python、Java、.NET Core、Ruby、またはサポートされるフレームワークを使用している場合は、使用している言語のベスト プラクティスに従って、コンテナをビルドするソースベースのデプロイ オプションを使用できます。

Google では、 Google Cloud上の他のサービスと連携できるように Cloud Run を構築しているため、さまざまな機能を備えたアプリケーションを構築できます。

つまり、Cloud Run を使用すると、Cloud Run サービスの運用、構成、スケーリングに必要な時間がほとんどなくなるため、デベロッパーはコードの作成に時間を費やすことができます。クラスタの作成やインフラストラクチャの管理をすることなく Cloud Run で生産性を向上できます。

サービス、ジョブ、ワーカープール: コードを実行する 3 つの方法

Cloud Run では、コードはサービス、ジョブ、ワーカープールとして実行できます。これらのリソースタイプはすべて同じ環境で動作し、 Google Cloud上の他のサービスと同じ統合を使用できます。

次の表に、各 Cloud Run リソースタイプで提供されるオプションの概要を示します。

リソース 説明
サービス 一意の安定したエンドポイントに送信された HTTP リクエストに応答します。さまざまな主要指標に基づいて自動スケーリングされる、ステートレスなエフェメラル インスタンスを使用し、イベントと関数にも応答します。
ジョブ 手動またはスケジュールに基づいて実行され、完了まで実行されるリクエストベースでない並列化可能なタスクを処理します。
ワーカープール pull ベースのワークロード（Kafka コンシューマー、Pub/Sub pull キュー、RabbitMQ コンシューマーなど）のようなリクエストベースでないワークロードを処理します。

Cloud Run サービス

Cloud Run サービスでは、信頼性の高い HTTPS エンドポイントを実行するために必要なインフラストラクチャが提供されます。コードが TCP ポートでリッスンし、HTTP リクエストを処理することを確認するのは、お客様の責任となります。

次の図は、HTTPS エンドポイントを使用してクライアントからのウェブ リクエストとイベントを処理するために、複数のコンテナ インスタンスを実行している Cloud Run サービスを示しています。

Cloud Run サービスはコンテナを実行し、ウェブ リクエストとイベントを処理します。

標準サービスには次の機能が含まれます。

すべてのサービス用の一意の HTTPS エンドポイント
すべての Cloud Run サービスには、*.run.app ドメインの一意のサブドメインに HTTPS エンドポイントが用意されています。また、カスタム ドメインを構成することもできます。Cloud Run が TLS を管理し、WebSocket、HTTP/2（エンドツーエンド）、gRPC（エンドツーエンド）をサポートします。
高速なリクエスト ベースの自動スケーリング
Cloud Run は、すべての受信リクエストを処理するために迅速にスケールアウトします。また、課金設定がインスタンスベースの課金に設定されている場合は、リクエスト以外の CPU 使用率の増加に対応するために迅速にスケールアウトします。サービスは、インスタンスを 1,000 個まで迅速にスケールアウトできます。割り当ての増加をリクエストした場合は、さらにスケールアウトが可能です。需要が減ると、Cloud Run はアイドル状態のコンテナを削除します。コストやダウンストリーム システムの過負荷が懸念される場合は、インスタンスの最大数を制限できます。
オプションの手動スケーリング
デフォルトでは、Cloud Run はより多くのトラフィックを処理するため、より多くのインスタンスに自動的にスケーリングしますが、手動スケーリングを使用してスケーリング動作を制御することで、この動作をオーバーライドできます。
組み込みのトラフィック管理

新しいリビジョンのデプロイのリスクを軽減するため、Cloud Run は、受信トラフィックの最新のリビジョンへのルーティング、前のリビジョンへのロールバック、トラフィックの複数のリビジョンへの同時分割など、段階的なロールアウトの実行をサポートしています。

たとえば、リクエストの 1% を新しいリビジョンに送信し、テレメトリーをモニタリングしながらその割合を増やします。

一般公開サービスと限定公開サービス

Cloud Run サービスには、インターネットから到達できます。また、次の方法でアクセスを制限できます。

Firebase Hosting や Cloud CDN などのコンテンツ配信ネットワーク（CDN）を使用して Cloud Run サービスを起動することで、クライアントに近いエッジ ロケーションからキャッシュ可能なアセットを提供できます。

ゼロおよび最小インスタンスへのスケーリング

デフォルトでは、インスタンスベースの課金が設定されている場合、Cloud Run は、すべての受信リクエストを処理するため、またはリクエスト以外の CPU 使用率の増加に対応するために、インスタンスを自動的に追加または削除します。

サービスに対する受信リクエストがない場合は、最後に残ったインスタンスまで削除されます。この動作は一般にゼロにスケーリングと呼ばれています。その後、リクエストが届いたときにアクティブなインスタンスがない場合、Cloud Run は新しいインスタンスを作成します。コンテナでリクエストの処理の準備ができるまでの時間によっては、最初のリクエストのレスポンス時間が長くなります。

この動作を変更するには、次のいずれかの方法を使用します。

  • サービスがゼロ インスタンスにスケーリングされないように、最小数のインスタンスをアクティブにするように Cloud Run を構成する
  • 手動スケーリングを使用して、スケーリングをより細かく制御する

サービスの従量課金制

インスタンスに割り当てられた CPU とメモリは 100 ミリ秒の粒度で課金されます。そのため、ゼロへのスケーリングは、経済的な理由で魅力的な設定となります。最小インスタンス数を構成していない場合、サービスが使用されていなければ料金は発生しません。十分な無料枠が用意されています。詳細については、料金をご覧ください。

有効にできる課金設定は次の 2 つです。

リクエスト ベース
インスタンスがリクエストを処理していない場合、課金は発生しません。リクエストごとの料金が発生します。
インスタンス ベース
インスタンスの全期間に対して課金されます。リクエストごとの料金は発生しません。

十分な無料枠が用意されています。詳細については、料金をご覧ください。また、サービスに対してリクエスト ベースまたはインスタンス ベースの課金を有効にする方法については、課金設定をご覧ください。

使い捨てのコンテナ ファイルシステム

Cloud Run のインスタンスは使い捨てです。すべてのコンテナにはメモリ内に書き込み可能なファイル システム オーバーレイがあり、コンテナがシャットダウンした場合、これらは保持されません。Cloud Run は、スケールインなどの際に、インスタンスへのリクエスト送信を停止してシャットダウンするタイミングを決定します。

Cloud Run でインスタンスがシャットダウンされる際に警告を受け取るには、アプリケーションで SIGTERM シグナルをトラップします。これにより、ローカル バッファをフラッシュして、外部データをローカル データストアに保持できます。

ファイルを永続的に保持するには、Cloud Storage と統合するか、ネットワーク ファイル システム（NFS）をマウントします。

Cloud Run サービスを使用するタイミング

Cloud Run サービスは、リクエスト、イベント、関数を処理するコードに最適です。たとえば、次のような場合があります。

ウェブサイトとウェブ アプリケーション
お好みのスタックを使ってウェブアプリを構築し、SQL データベースにアクセスして動的な HTML ページをレンダリングします。
API とマイクロサービス
HTTP または gRPC で通信する REST API、GraphQL API、プライベート マイクロサービスを構築できます。
ストリーミング データ処理
Cloud Run サービスは、Pub/Sub push サブスクリプションからメッセージを受け取り、Eventarc からイベントを受信できます。
非同期ワークロード
Cloud Run 関数は、Pub/Sub トピックのメッセージ、Cloud Storage バケットの変更、Firebase イベントなどの非同期イベントに応答できます。
AI 推論
GPU が構成されているかどうかにかかわらず、Cloud Run サービスは、推論モデルやモデル トレーニングなどの AI ワークロードをホストできます。

Cloud Run ジョブ

コードが動作後に停止する場合（スクリプトを使用する場合など）、Cloud Run ジョブを使用してコードを実行できます。コマンドラインから Google Cloud CLI を使用してジョブを実行するか、定期的なジョブをスケジュールするか、ワークフローの一部として実行できます。

配列ジョブでより迅速にジョブを実行する

ジョブは、コードを実行するために 1 つのインスタンスを開始します。これは、スクリプトまたはツールを実行する一般的な方法です。

ただし、独立した同一のインスタンスを複数並行して開始する配列ジョブを使用することもできます。配列ジョブは、複数の独立したタスクに分割できるジョブを迅速に処理します。

次の図は、4 つのインスタンスが独立したタスクを並行して処理できる場合、7 つのタスクを含むジョブを順番に実行するよりも、同じジョブを並行して実行するほうが時間がかかることを示しています。

配列ジョブでより迅速に並列処理可能なジョブを実行する

たとえば、Cloud Storage 内の 1,000 枚の画像のサイズを変更して切り抜く場合、連続して処理する方が、多くのインスタンスで同時に処理する場合より時間がかかります。同時に処理する方法では、Cloud Run は自動スケーリングを使用して管理します。

Cloud Run ジョブを使用するタイミング

Cloud Run ジョブは、作業（ジョブ）を実行します。作業の完了後に終了するコードを実行する場合に適しています。いくつか例を挙げましょう。

スクリプトまたはツール
スクリプトを実行して、データベースの移行などの運用タスクを行います。
配列ジョブ
Cloud Storage バケット内のすべてのファイルに高度な並列処理を行います。
スケジュールされたジョブ
請求書の作成や送信を定期的に行います。また、データベース クエリの結果を XML 形式で保存し、数時間ごとにファイルをアップロードします。
AI ワークロード
GPU が構成されているかどうかにかかわらず、Cloud Run ジョブは、バッチ推論、モデルのファインチューニング、モデル トレーニングなどの AI ワークロードをホストできます。

Google Cloud の統合

Cloud Run は Google Cloudの幅広いエコシステムと統合されているため、フル機能のアプリケーションをビルドできます。

統合には次のようなものがあります。

データ ストレージ
Cloud Run は、Cloud SQL（マネージド MySQL、PostgreSQL、SQL Server）、Memorystore（マネージド Redis および Memcached）、Firestore、Spanner、Cloud Storage などと統合されます。完全なリストについては、データ ストレージをご覧ください。
ロギングとエラー報告
Cloud Logging はコンテナログを自動的に取り込みます。ログに例外がある場合は、Error Reporting によって集約され、通知されます。サポートされている言語は、Go、Java、Node.js、PHP、Python、Ruby、.NET です。
サービス ID
すべての Cloud Run リビジョンはサービス アカウントにリンクされます。 Google Cloud クライアント ライブラリは、このサービス アカウントを透過的に使用して Google Cloud API で認証を行います。
継続的デリバリー
ソースコードを GitHub、Bitbucket、Cloud Source Repositories のいずれかに保存する場合は、新しい commit を自動的にデプロイするように Cloud Run を構成できます。
プライベート ネットワーク
Cloud Run インスタンスは、サーバーレス VPC アクセス コネクタを介して Virtual Private Cloud ネットワーク内のリソースにアクセスできます。これは、サービスが Google Kubernetes Engine や Memorystore などの Compute Engine に基づく Compute Engine 仮想マシンまたはプロダクトに接続する方法です。
Google Cloud API
サービスのコードは、 Google Cloud APIs で透過的に認証を行います。たとえば、Cloud Vision API、Speech-to-Text API、AutoML Natural Language API、Cloud Translation API などの AI や機械学習の API で使用します。
バックグラウンド タスク
ウェブ リクエストを返した直後またはすぐ後に実行されるコードのスケジュールを設定する場合、Cloud Run と Cloud Tasks を連携させると、スケーラブルで信頼性の高い非同期実行が可能になります。

Cloud Run と連携する Google Cloud サービスの一覧については、 Google Cloud サービスへの接続をご覧ください。

コードをコンテナ イメージにパッケージ化する

サービス、ジョブ、またはワーカープールを Cloud Run にデプロイできるようにするには、コンテナ イメージにパッケージ化する必要があります。コンテナについてよく知らない方のために、概念について簡単に紹介します。

コンテナ イメージのビルド

図に示すように、ソースコード、アセット、ライブラリの依存関係を使用してコンテナ イメージをビルドします。コンテナ イメージは、サービスの実行に必要なものがすべて含まれるパッケージです。これには、ビルド アーティファクト、アセット、システム パッケージ、ランタイム（オプション）が含まれます。コンテナ化アプリケーションは本質的に移植可能となり、コンテナを実行できるあらゆる場所で実行できます。ビルド アーティファクトの例としては、コンパイル済みバイナリやスクリプト ファイルなどがあります。ランタイムの例としては、Node.js JavaScript ランタイムや Java 仮想マシン（JVM）などがあります。

上級者は、Cloud Run がコードの実行に負担をかけないという事実に着目しています。Cloud Run では任意のバイナリを実行できます。

アプリケーションの利便性を高めたい場合や、アプリケーションをコンテナ化して Google に委任したい場合は、Cloud Run とオープンソースの Google Cloud の Buildpack を統合することで、ソースベースのデプロイを行うことができます。

次のステップ