実行環境について

Cloud Run サービスでは、デフォルトで実行環境が指定されていません。つまり、Cloud Run は使用されている機能に基づいて実行環境を選択します。サービスの実行環境を指定しない場合、Cloud Run が第 1 世代または第 2 世代の環境を選択します。

Cloud Run ジョブは第 2 世代の実行環境のみ使用します。この動作をジョブで変更することはできません。

第 1 世代の実行環境は、コールド スタート時間が高速で、エミュレーションを行いますが、すべてのオペレーティング システム コールを実行できるわけではありません。当初は、これが Cloud Run のサービスで使用できる唯一の実行環境でした。

第 2 世代の実行環境では、システムコールのエミュレーションではなく、Linux の完全な互換性が実現されています。この実行環境では、以下のことが実現されています。

  • CPU パフォーマンスの高速化
  • ネットワーク パフォーマンスの高速化（特にパケットロスがある場合）
  • すべてのシステムコール、名前空間、cgroup のサポートを含む、Linux との完全な互換性
  • ネットワーク ファイル システムのサポート

第 2 世代の実行環境は、一般に持続的な負荷の下では迅速に動作しますが、ほとんどのサービスでは、第 1 世代よりもコールド スタート時間が長くなります。

新しいサービスまたはサービスの新しいリビジョンをデプロイするときに、Cloud Run サービスの実行環境を選択できます。実行環境を指定しない場合は、デフォルトで第 1 世代が使用されます。

実行環境の選択方法

次のいずれかに該当する場合は、第 1 世代を使用する必要があります。

  • Cloud Run サービスでトラフィックが急増しているため、多くのインスタンスにすばやくスケールアウトする必要があるか、コールド スタート時間の影響を受けやすい。
  • Cloud Run サービスに、ゼロからのスケールアウトを頻繁に発生させる頻度の低いトラフィックがある。
  • 512 MiB 未満のメモリを使用する。第 2 世代の実行環境では 512 MiB 以上のメモリが必要です。

Cloud Run サービスが以下のいずれかに該当する場合は、第 2 世代を使用してください。

  • サービスでネットワーク ファイル システムを使用する必要がある（これは第 2 世代でのみサポートされます）。
  • サービスのトラフィックはかなり安定しており、多少のコールド スタートは許容できる。
  • サービスに CPU 使用率が高いワークロードがある。
  • サービスで迅速なネットワーク パフォーマンスのメリットが得られる。
  • 実装されていないシステムコールのため、第 1 世代で実行すると問題のあるソフトウェアをサービスで使用する必要がある。
  • サービスで Linux cgroup 機能が必要。
  • このサービスでは、コンテナを保護するためにサードパーティのインフラストラクチャを利用しています。

第 2 世代の実行環境を使用する場合のベスト プラクティス

特に CPU オンデマンド課金モデルを使用している場合は、コンテナに SIGTERM ハンドラをインストールすることをおすすめします。

SIGTERM を処理すると、コンテナは終了前にログのフラッシュなど、必要なクリーンアップ タスクを行うことができます。コンテナが SIGTERM をキャッチしない場合でも、これらのタスクを実行するのに 10 秒かかります。この 10 秒は課金対象です。

コンテナが SIGTERM を処理するかどうかを確認する方法

コンテナに SIGTERM ハンドラがインストールされているかどうかを確認するには:

  1. Cloud Shell を起動します。Cloud Run を有効にするボタン「Cloud Shell をアクティブにする」は、表示しているドキュメント ページのヘッダーにあります。場合によっては、承認してプロビジョニングの完了を待つ必要があります。あるいは、スタンドアロン セッションを開始します。

  2. Cloud Shell を使用してコンテナをローカルで実行します。

    docker run IMAGE_URL

    IMAGE_URL は、コンテナ イメージへの参照（us-docker.pkg.dev/cloudrun/container/hello:latest など）に置き換えます。Artifact Registry を使用する場合は、リポジトリ REPO_NAME がすでに作成されている必要があります。URL の形式は LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG です。

  3. Cloud Shell で別のタブを開き、現在の Cloud Shell セッションで実行されているコンテナのリストを取得します。

    docker container ls

    コマンドから返されたコンテナ ID を特定する必要があります。

  4. コンテナ ID を使用して、コンテナに SIGTERM シグナルを送信する

    docker kill -s SIGTERM CONTAINER_ID

  5. docker run を呼び出したタブに戻り、コンテナが終了（停止）したかどうかを確認します。SIGTERM シグナルが原因でコンテナが終了している場合、コンテナは SIGTERM を処理しています。

SIGTERM の処理方法

コンテナが SIGTERM を処理していない場合、SIGTERM ハンドラを追加する最も簡単な方法は、サービスを tini でラップすることです。これを行うと、サービスがコンテナ初期化プロセスの役割を担う tini のサブプロセスとして実行されます。手順については、Docker の手順をご覧ください。

または、SIGTERM を直接処理するようにアプリケーションを変更することもできます。

次のステップ