サービスの最小インスタンス数を設定する

このページでは、デフォルトの Cloud Run 自動スケーリング動作を使用して最小インスタンスを構成し、サービスでアイドル状態のインスタンスを有効にする方法について説明します。サービスを手動でスケーリングするには、手動スケーリングをご覧ください。

サービスの自動スケーリングの動作をより細かく制御する必要がある場合は、インスタンスの最小数を設定すると、コンテナの起動時間を短縮し、サービスのレイテンシを短縮できます。Cloud Run サービスの場合、Cloud Run はデフォルトで受信リクエストの数に基づいてインスタンス数のスケーリングを行います。

ただし、サービスでレイテンシの短縮が必要であり、特にアクティブインスタンスがない状態からスケーリングする場合は、ウォーム状態を維持し、いつでもリクエストを処理できるコンテナインスタンスの最小数を指定することで、このデフォルトの動作を変更できます。この最適化の詳細については、全般的な開発のヒントをご覧ください。

Cloud Run は、リクエストを処理していないインスタンス（アイドル状態）を削除します。最小インスタンス数を設定すると、リクエストを処理していなくても、Cloud Run は少なくとも最小のインスタンス数を維持します。min-instances を超えるアクティブなインスタンスは、リクエストを受信していない場合にアイドル状態になる可能性があります。

たとえば、min-instances が 10 で、アクティブなインスタンスの数が 0 の場合、アイドル状態のインスタンスの数は 10 です。アクティブなインスタンスの数が 6 まで増えると、アイドル状態のインスタンスの数は 4 に減ります。

サービスが最近トラフィックを処理していない場合、最小インスタンス数として 1 以上の値を指定しても、アクティブインスタンスの指標ではアクティブなインスタンスがないと示される場合があるので注意してください。

最小インスタンスはいつでも再起動できます。

課金

最小インスタンスの機能を使用して実行を継続しているインスタンスは、課金の対象となります。

次の図は、サービスまたはリビジョンの最小インスタンス数を構成した場合に、インスタンスのライフサイクルでどのように課金されるのかを示しています。

Google Cloud コンソールで Cloud Run Admin API を呼び出す。 — **図 1.** 3 つのリクエストを受信して処理するインスタンスの例。

構成された課金設定に応じて、サービスは次のように課金されます。

リクエストベースの課金: インスタンスがアイドル状態でリクエストの処理を待機しているときは、低額の料金で課金されます。最小インスタンス数が 0 に設定されている場合、インスタンスがアイドル状態のときは課金されません。
インスタンスベースの課金: インスタンスのライフサイクル全体に対してデフォルトの料金が課金されます。起動からシャットダウンまでの時間が課金対象となり、インスタンスがリクエストを処理している時間だけでなくアイドル状態の時間も含まれます。つまり、最小インスタンス数が 0 に設定されていても、デフォルトのレートで課金されます。このオプションは、リクエスト以外で CPU が必要な場合に適しています。最小インスタンス数が 0 に設定されている場合でも、デフォルトの料金が課金されます。

これらの請求額は予測可能であるため、確約利用割引の購入をおすすめします。

サービスレベルとリビジョンレベルで最小インスタンス数を適用する

最小インスタンス数は、サービスレベルまたはリビジョンレベルで構成できます。最小インスタンス数はサービスレベルで適用し、サービスレベルとリビジョンレベルの最小インスタンス数を組み合わせる方法は避けることをおすすめします。サービスレベルとリビジョンレベルの両方のスケーリング設定を構成した場合の動作については、こちらをご覧ください。

リビジョンレベルで最小インスタンス数を適用すると、リビジョンのデプロイ時に設定が有効になります。この機能をサービスレベルで適用すると、新しいリビジョンをデプロイしなくても設定が有効になります。

リビジョンと最小インスタンス数

サービスレベルで最小インスタンス数が設定されている場合、トラフィックを処理するすべてのリビジョンに、トラフィック分割に比例して受信リクエストが分散されます。

リビジョンレベルで最小インスタンス数が設定されている場合、リビジョンがトラフィック分割で参照されるか、リビジョンにトラフィックタグが割り当てられていると、最小数のインスタンスが開始されます。つまり、インスタンスはリクエストの処理時だけでなく、受信リクエストの待機時にも課金されます。

タグ付きリビジョンとサービスレベルの最小インスタンス数

タグが割り当てられたリビジョンが開始されると、インスタンスがトラフィック分割の一部である場合、そのインスタンスはサービスレベルの最小インスタンス数の対象としてカウントされます。

最小インスタンス数を使用したリクエストのルーティング

最小インスタンス数を設定すると、Cloud Run は、受信リクエストをプロビジョニングされたすべてのインスタンスに均等に分散します。特にリクエストベースの課金を使用している場合や、アイドル状態のホットスペアインスタンスを維持する場合は、この動作を理解しておくことが費用を管理するうえで重要です。費用を最小限に抑えるには、最小インスタンス数を通常のトラフィックを処理するために必要なインスタンス数に設定します。

必要なロール

Cloud Run サービスの構成とデプロイに必要な権限を取得するには、次の IAM ロールを付与するよう管理者に依頼してください。

Cloud Run サービスに対する Cloud Run デベロッパー（roles/run.developer）
サービス ID に対するサービスアカウントユーザー（roles/iam.serviceAccountUser）

Cloud Run に関連付けられている IAM ロールと権限のリストについては、Cloud Run IAM ロールと Cloud Run IAM 権限をご覧ください。Cloud Run サービスがGoogle Cloud APIs（Cloud クライアントライブラリなど）と連携している場合は、サービス ID の構成ガイドをご覧ください。ロールの付与の詳細については、デプロイ権限とアクセスの管理をご覧ください。

サービスレベルの最小インスタンス数を構成する

デフォルトでは、コンテナインスタンスではサービスレベルの最小インスタンス数が無効になっており、0 に設定されています。このデフォルトの数は、Google Cloud コンソール、Google Cloud CLI、または YAML ファイルを使用して変更できます。

コンソール

Google Cloud コンソールで Cloud Run に移動します。

[Cloud Run] に移動
新しいサービスを構成する場合は、メニューから [サービス] を選択し、[コンテナをデプロイ] をクリックして [サービスの作成] フォームを表示します。[サービスのスケーリング] フォームを見つけます。
既存のサービスを構成する場合は、サービスをクリックして詳細パネルを表示し、詳細パネルの右上にある [サービスレベルのスケーリング設定を編集] をクリックします。
[インスタンスの最小数] フィールドに、ウォームアップ状態を維持し、リクエストを受信できるコンテナインスタンスの数を指定します。
新しいサービスの場合は [作成]、既存のサービスの場合は [デプロイ] をクリックします。

gcloud

次のコマンドを使用して、特定のサービスのインスタンスの最小数を更新します。

gcloud run services update SERVICE --min MIN-VALUE

次のように置き換えます。

SERVICE: サービスの名前。
MIN-VALUE: ウォーム状態を維持し、リクエストを受信できるコンテナインスタンスの数。インスタンスの最小数の設定を消去するには、default を指定します。

または、デプロイ中に次のコマンドを使用してインスタンスの最小数を設定することもできます。

gcloud run deploy --image IMAGE_URL --min MIN-VALUE

次のように置き換えます。

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 の形式です。
MIN-VALUE: ウォーム状態を維持し、リクエストを受信できるコンテナインスタンスの数。インスタンスの最小数の設定を消去するには、default を指定します。

YAML

構成を変更すると、新しいリビジョンが作成されます。明示的に更新しない限り、以降のリビジョンでも、この構成が自動的に設定されます。

新しいサービスを作成する場合は、この手順をスキップします。既存のサービスを更新する場合は、その YAML 構成をダウンロードします。
```
gcloud run services describe SERVICE --format export > service.yaml
```
run.googleapis.com/minScale 属性を更新します。
```
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
  annotations:
    run.googleapis.com/minScale: 'MIN_INSTANCE'
```
次のように置き換えます。
- SERVICE: Cloud Run サービスの名前
- MIN-INSTANCE: ウォーム状態を維持し、リクエストを受信できるインスタンスの数。
次のコマンドを使用して、サービスを作成または更新します。
```
gcloud run services replace service.yaml
```

クライアントライブラリ

サービスのサービスレベルの最小インスタンスをコードから更新するには:

REST API

特定のサービスでサービスレベルの最小インスタンスを更新するには、PATCH HTTP リクエストを Cloud Run Admin API の service エンドポイントに送信します。

curl の使用例を次に示します。

curl -H "Content-Type: application/json" \
-H "Authorization: Bearer ACCESS_TOKEN" \
-X PATCH \
-d '{ "scaling": { "minInstanceCount": MIN-VALUE }}' \
https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services/SERVICE?update_mask=scaling.minInstanceCount

次のように置き換えます。

ACCESS_TOKEN: サービスを更新する IAM 権限を持つアカウントの有効なアクセストークン。たとえば、gcloud にログインしている場合は、gcloud auth print-access-token を使用してアクセストークンを取得できます。Cloud Run コンテナインスタンスから、コンテナインスタンスメタデータサーバーを使用してアクセストークンを取得できます。
MIN-VALUE: ウォーム状態を維持し、リクエストを受信できるコンテナインスタンスの数。
SERVICE: サービスの名前。
REGION: サービスの Google Cloud リージョン。
PROJECT-ID: Google Cloud プロジェクト ID。

サービスレベルの最小インスタンス数を表示する

Cloud Run サービスの現在のサービスレベルの最小インスタンス数の設定を表示するには:

コンソール

Google Cloud コンソールで Cloud Run に移動します。

Cloud Run に移動
目的のサービスをクリックして、[サービスの詳細] パネルを開きます。
現在の設定は、サービスの詳細パネルの右上にある [スケーリング] の横に表示されます。

gcloud

次のコマンドを使用します。
```
gcloud run services describe SERVICE
```
返された構成で、[スケーリング: 自動（最小: MIN_VALUE、最大: MAX_VALUE）] の値を見つけます。

リビジョンレベルの最小インスタンス数を構成する

構成を変更すると、新しいリビジョンが作成されます。明示的に更新しない限り、以降のリビジョンでも、この構成が自動的に設定されます。

デフォルトでは 0 が設定され、コンテナインスタンスの min-instances は無効になっています。このデフォルトを変更するには、新しいサービスを作成するとき、または新しいリビジョンをデプロイするときに、 Google Cloud コンソール、Google Cloud CLI、または YAML ファイルを使用します。

コンソール

Google Cloud コンソールで Cloud Run に移動します。

Cloud Run に移動
メニューから [サービス] を選択し、[コンテナをデプロイ] をクリックして新しいサービスを構成します。既存のサービスを構成する場合は、サービスをクリックし、[新しいリビジョンの編集とデプロイ] をクリックします。
新しいサービスを構成する場合は、最初のサービス設定のページに入力してから、[コンテナ、ボリューム、ネットワーキング、セキュリティ] をクリックしてサービス構成ページを開きます。
[コンテナ] タブをクリックします。
- [インスタンスの最小数] フィールドに、ウォームアップ状態を維持し、リクエストを受信できるコンテナインスタンスの数を指定します。
[作成] または [デプロイ] をクリックします。

gcloud

次のコマンドを使用して、指定したサービスの min-instance を更新できます。

gcloud run services update SERVICE --min-instances MIN-VALUE

次のように置き換えます。

SERVICE: サービスの名前。
MIN-VALUE: ウォーム状態を維持し、リクエストを受信できるコンテナインスタンスの数。インスタンスの最小数の設定を消去するには、default を指定します。

デプロイ中に次のコマンドを使用して min-instance を設定することもできます。

gcloud run deploy --image IMAGE_URL --min-instances MIN-VALUE

次のように置き換えます。

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 の形式です。
MIN-VALUE: ウォーム状態を維持し、リクエストを受信できるコンテナインスタンスの数。インスタンスの最小数の設定を消去するには、default を指定します。

YAML

新しいサービスを作成する場合は、この手順をスキップします。既存のサービスを更新する場合は、その YAML 構成をダウンロードします。
```
gcloud run services describe SERVICE --format export > service.yaml
```
autoscaling.knative.dev/minScale: 属性を更新します。
```
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: SERVICE
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: 'MIN-INSTANCE'
      name: REVISION
```
次のように置き換えます。
- SERVICE: Cloud Run サービスの名前
- MIN-INSTANCE: ウォーム状態を維持し、リクエストを受信できるインスタンスの数。
- REVISION は、新しいリビジョン名に置き換えるか、削除します（存在する場合）。新しいリビジョン名を指定する場合は、次の条件を満たす必要があります。
  - SERVICE- で始まる
  - 小文字、数字、- のみが使用されている
  - 末尾が - ではない
  - 63 文字以内である
次のコマンドを使用して、サービスを作成または更新します。
```
gcloud run services replace service.yaml
```

Terraform

Terraform 構成を適用または削除する方法については、基本的な Terraform コマンドをご覧ください。

Terraform 構成の google_cloud_run_v2_service リソースに次の内容を追加します。

resource "google_cloud_run_v2_service" "default" {
  name     = "cloudrun-service-min-instances"
  location = "us-central1"

  deletion_protection = false # set to "true" in production

  template {
    containers {
      image = "us-docker.pkg.dev/cloudrun/container/hello"
    }
    scaling {
      # Min instances
      min_instance_count = 1
    }
  }
}

前の google_cloud_run_v2_service リソースは、template.scaling の下にある 1 のインスタンスの最小数を指定します。1 は、実際のインスタンスの最小数に置き換えます。

リビジョンレベルの最小インスタンス数を表示する

Cloud Run サービスの現在のリビジョンレベルの最小インスタンス数の設定を表示するには:

コンソール

Google Cloud コンソールで Cloud Run に移動します。

Cloud Run に移動
目的のサービスをクリックして、[サービスの詳細] パネルを開きます。
[変更内容] タブをクリックします。
右側の詳細パネルの [コンテナ] タブに、[リビジョンの最小インスタンス数] の設定が表示されます。

gcloud

次のコマンドを使用します。
```
gcloud run services describe SERVICE
```
返された構成で、[最小インスタンス数:] の値を見つけます。

例

以降のセクションでは、最小インスタンス数を構成した場合のサービスの動作について説明します。

サービスレベルとリビジョンレベルの両方の最小インスタンス数または最大インスタンス数を使用する

次の表は、サービスレベルの最小インスタンス数と、リビジョンレベルの最小インスタンス数または最大インスタンス数を組み合わせた場合の動作を示しています。

構成設定	動作
サービスレベルの最小インスタンス数とリビジョンレベルの最小インスタンス数の両方が設定されています。	リビジョンの有効な値は、リビジョンレベルの最小インスタンス数とサービスレベルの最小インスタンス数のうち、大きい方の値です。
サービスレベルの最小インスタンス数とリビジョンレベルの最大インスタンス数の両方が設定されています。	リビジョンの有効な値は、リビジョンレベルの最大インスタンス数とサービスレベルの最小インスタンス数のうち小さい方の値です。これは、リビジョンレベルの最大インスタンス数が原因で、サービスレベルの最小インスタンス数に構成されているインスタンス数の上限に達していない場合についても該当します。

構成設定

動作

サービスレベルの最小インスタンス数とリビジョンレベルの最小インスタンス数の両方が設定されています。

リビジョンの有効な値は、リビジョンレベルの最小インスタンス数とサービスレベルの最小インスタンス数のうち、大きい方の値です。

サービスレベルの最小インスタンス数とリビジョンレベルの最大インスタンス数の両方が設定されています。

リビジョンの有効な値は、リビジョンレベルの最大インスタンス数とサービスレベルの最小インスタンス数のうち小さい方の値です。

これは、リビジョンレベルの最大インスタンス数が原因で、サービスレベルの最小インスタンス数に構成されているインスタンス数の上限に達していない場合についても該当します。

トラフィック分割でサービスレベルの最小インスタンス数を使用する

トラフィック分割を使用する場合、サービスレベルの最小インスタンス数は、トラフィック分割の比率に基づいてリビジョン間で分割されます。たとえば、サービスレベルの最小インスタンス数が 10 の場合、50 対 50 のトラフィック分割により、各リビジョンにサービスレベルの最小インスタンス数 5 が割り当てられます。

次の表に、構成シナリオの例を示します。

サンプルのユースケース	構成の例	結果
リビジョンレベルの設定なし	サービスレベルの最小インスタンス数: 10 リビジョン A の最小インスタンス数: 0 リビジョン B の最小インスタンス数: 0 トラフィック分割: 60 対 40	リビジョン A は、トラフィック分割に比例してサービスレベルの最小インスタンス数から 6 つのインスタンスを受け取ります。リビジョン B は、トラフィック分割に比例してサービスレベルの最小インスタンス数から 4 つのインスタンスを受け取ります。
リビジョンレベルの最小インスタンス数が原因で、サービスレベルの最小インスタンス数よりも多くのインスタンスを受け取る	サービスレベルの最小インスタンス数: 10 リビジョン A の最小インスタンス数: 6 リビジョン B の最小インスタンス数: 0 トラフィック分割: 50 対 50	リビジョン A は、リビジョンレベルの最小インスタンス数から 6 個のインスタンスを受け取ります。リビジョン B は、トラフィック分割に比例して、サービスレベルの最小インスタンス数から 5 つのインスタンスを受け取ります。これはサービスレベルの最小インスタンス数を超えており、想定内の動作です。
リビジョンレベルの最大インスタンス数が原因で、受け取るインスタンス数がサービスレベルの最小インスタンス数を下回っています。	サービスレベルの最小インスタンス数: 10 リビジョン A の最小インスタンス数: 0 リビジョン A の最大インスタンス数: 3 リビジョン B の最小インスタンス数: 0 トラフィック分割: 50 対 50	リビジョン A は、トラフィック分割によってサービスレベルの最小インスタンス数から 3 つのインスタンスを受け取りますが、リビジョンレベルの最大インスタンス数に制限されます。リビジョン B は、トラフィック分割に比例してサービスレベルの最小インスタンス数から 5 つのインスタンスを受け取ります。この場合、リビジョン A のリビジョンレベルでの最大インスタンス数が原因で、2 つのサービスレベルインスタンスが失われ、8 つのサービスレベルインスタンスが存在することになります。
サービスレベルの最小インスタンス数がトラフィック分割のリビジョン数より大きく、トラフィック分割に比例してインスタンス数が分割されます。	サービスレベルの最小インスタンス数: 3 リビジョン A の最小インスタンス数: 0 リビジョン B の最小インスタンス数: 0 リビジョン B はサービス構成トラフィックセクションの先頭にあるトラフィック分割: 50 対 50	リビジョン A の最小インスタンス数は 1 に、リビジョン B の最小インスタンス数は 2 になります。サービスのインスタンス数は 3 です。

必要な最小インスタンス数を特定する

最小インスタンス数を通常のトラフィックに必要な数よりも高く設定した場合、多くのインスタンスが少しだけアクティブになり、それぞれが少数のリクエストを処理する可能性があります。たとえば、サービスのピーク時の負荷として通常は 200 個のインスタンスが必要な場合に、最小インスタンス数を 600 に構成すると、受信リクエストは 600 個のインスタンスすべてに分散されます。この場合、約 200 個のインスタンスが非常にアクティブになり、残りの 400 個が完全にアイドル状態になるわけではなく、600 個のインスタンスの多くがある程度アクティブになり、それぞれが小規模なトラフィックを処理します。

費用を最小限に抑える（少ないインスタンスで使用率を高める）には、最小インスタンス数を通常のトラフィック処理に必要な実際のインスタンス数とほぼ一致する値に設定します。

また、構成済みの最小インスタンス数を超えるインスタンスが自動スケーリングによってプロビジョニングされた場合、Cloud Run はまず、構成された最小インスタンスに優先的に受信リクエストをルーティングし、それで処理できないリクエストを自動スケーリングされたインスタンスに送信します。リクエストベースの課金では、構成された最小インスタンスへの優先ルーティングにより、自動スケーリングされたインスタンスに優先して構成済みの最小インスタンスが使用されるため、コストが削減されます。ただしトラフィック量によっては、優先ルーティングにより、構成された最小インスタンスの利用率が自動スケーリングされたインスタンスよりも高くなる場合があるので注意してください。

サービスの最小インスタンス数を設定する コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

課金

サービスレベルとリビジョン レベルで最小インスタンス数を適用する

リビジョンと最小インスタンス数

タグ付きリビジョンとサービスレベルの最小インスタンス数

最小インスタンス数を使用したリクエストのルーティング

必要なロール

サービスレベルの最小インスタンス数を構成する

コンソール

gcloud

YAML

クライアント ライブラリ

REST API

サービスレベルの最小インスタンス数を表示する

コンソール

gcloud

リビジョン レベルの最小インスタンス数を構成する

コンソール

gcloud

YAML

Terraform

リビジョン レベルの最小インスタンス数を表示する

コンソール

gcloud

例

サービスレベルとリビジョン レベルの両方の最小インスタンス数または最大インスタンス数を使用する

トラフィック分割でサービスレベルの最小インスタンス数を使用する

必要な最小インスタンス数を特定する

サービスの最小インスタンス数を設定する

サービスレベルとリビジョンレベルで最小インスタンス数を適用する

クライアントライブラリ

リビジョンレベルの最小インスタンス数を構成する

リビジョンレベルの最小インスタンス数を表示する

サービスレベルとリビジョンレベルの両方の最小インスタンス数または最大インスタンス数を使用する