インスタンスの最小数を設定すると、サービスのコンテナの起動時間を短縮し、サービスのレイテンシを短縮できます。このページでは、最小インスタンス数の設定を使用して、サービスでアイドル状態のインスタンスを有効にする方法について説明します。
Cloud Run サービスの場合、Cloud Run は受信リクエストの数に基づいてインスタンス数のスケーリングを行います。
ただし、サービスでレイテンシの短縮が必要であり、特にアクティブなインスタンスからスケーリングする場合は、ウォーム状態を維持し、いつでもリクエストを処理できるコンテナ インスタンスの最小数を指定することで、このデフォルトの動作を変更できます。この最適化の詳細については、全般的な開発のヒントをご覧ください。
Cloud Run は、リクエストを処理していないインスタンス(アイドル状態)を削除します。最小インスタンス数を設定すると、リクエストを処理していなくても、Cloud Run は少なくとも最小のインスタンス数を維持します。min-instances
を超えるアクティブなインスタンスは、リクエストを受信していない場合にアイドル状態になる可能性があります。
たとえば、min-instances
が 10
で、アクティブなインスタンスの数が 0
の場合、アイドル状態のインスタンスの数は 10
です。アクティブなインスタンスの数が 6
まで増えると、アイドル状態のインスタンスの数は 4
に減ります。
サービスが最近トラフィックを処理していない場合、最小インスタンスに 1 つ以上指定しても、アクティブ インスタンスの指標にアクティブなインスタンスがないことが示されることがあります。
サービスレベルとリビジョン レベルでの最小インスタンス数の適用
最小インスタンス数は、サービスレベルまたはリビジョンレベルで構成できます。最小インスタンス数はサービスレベルで適用し、サービスレベルとリビジョン レベルの最小インスタンス数を組み合わせることは避けることをおすすめします。
リビジョン レベルで最小インスタンス数を適用すると、リビジョンのデプロイ時に設定が有効になります。この機能をサービスレベルで適用すると、新しいリビジョンをデプロイしなくても設定が有効になります。
タグ付きリビジョンとサービスレベルの最小インスタンス数
タグ付きリビジョンは開始されますが、トラフィック分割の一部である場合にのみ、サービスレベルの最小インスタンス数にカウントされます。
課金
最小インスタンスの機能を使用して実行を継続しているインスタンスには、請求が発生します。これらの請求は予測可能であるため、確約利用割引の購入をおすすめします。
最小インスタンス数と常時割り当てられる CPU
リクエスト以外で CPU が必要な場合は、CPU が常に割り当てられるように構成できます。
最小インスタンスの再起動
最小インスタンスはいつでも再起動できます。
リビジョンと最小インスタンス数
サービスレベルで最小インスタンス数が設定されている場合、トラフィックを処理するすべてのリビジョンに、トラフィック分割に比例してインスタンスが分散されます。
リビジョン レベルで最小インスタンス数が設定されている場合、リビジョンがトラフィック分割で参照されるか(0% であっても)、リビジョンにトラフィック タグが割り当てられていると、最小インスタンスが開始されます。
必要なロール
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] に移動します。
新しいサービスを構成する場合は、[コンテナをデプロイ] をクリックし、[サービス] を選択して [サービスの作成] フォームを表示します。既存のサービスを構成する場合は、サービスをクリックして詳細パネルを表示し、詳細パネルの右上にある [最小インスタンス数] の横にある鉛筆アイコンをクリックします。
[サービスの自動スケーリング] フォームを見つけます。
- [インスタンスの最小数] フィールドに、ウォームアップ状態を維持し、リクエストを受信できるコンテナ インスタンスの数を指定します。
新しいサービスの場合は [作成]、既存のサービスの場合は [デプロイ] をクリックします。
gcloud
次のコマンドを使用して、特定のサービスの service-min-instances
を更新します。
gcloud run services update SERVICE --service-min-instances MIN-VALUE
次のように置き換えます。
- SERVICE: 実際のサービスの名前。
- MIN-VALUE: ウォーム状態を維持し、リクエストを受信できるコンテナ インスタンスの数。インスタンスの最小数の設定を消去するには、
default
を指定します。
また、デプロイ中に次のコマンドを使用して service-min-instances
を設定することもできます。
gcloud run deploy --image IMAGE_URL --service-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
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] に移動します。
目的のサービスをクリックして、[サービスの詳細] パネルを開きます。
現在の設定は、サービスの詳細パネルの右上の [最小インスタンス数] の横に表示されます。
gcloud
次のコマンドを使用します。
gcloud run services describe SERVICE
返された構成で、[サービスレベル最小インスタンス数:] の値を見つけます。
リビジョン レベルの最小インスタンス数の設定と更新
構成を変更すると、新しいリビジョンが作成されます。明示的に更新しない限り、以降のリビジョンでも、この構成が自動的に設定されます。
デフォルトでは 0
が設定され、コンテナ インスタンスの min-instances
は無効になっています。このデフォルトを変更するには、新しいサービスを作成する、または新しいリビジョンをデプロイする際に、Google Cloud コンソール、Google Cloud CLI、または YAML ファイルを使用します。
コンソール
Google Cloud コンソールで、[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 コマンドをご覧ください。
次の google_cloud_run_v2_service
リソースは、template.scaling
の下にある 1
のインスタンスの最小数を指定します。1
は、実際のインスタンスの最小数に置き換えます。
リビジョン レベルの最小インスタンス数の設定を表示する
Cloud Run サービスの現在のリビジョン レベルの最小インスタンス数の設定を表示するには:
コンソール
Google Cloud コンソールで、[Cloud Run] に移動します。
目的のサービスをクリックして、[サービスの詳細] ページを開きます。
[変更内容] タブをクリックします。
右側の詳細パネルの [コンテナ] タブに、リビジョン レベルの最小インスタンス数の設定が表示されます。
gcloud
次のコマンドを使用します。
gcloud run services describe SERVICE
返された構成で、リビジョン レベルの最小インスタンス数の設定を見つけます。
サービスレベルとリビジョン レベルの両方の最小インスタンス数または最大インスタンス数を使用する
次の表は、サービスレベルの最小インスタンス数と、リビジョン レベルの最小インスタンス数または最大インスタンス数を組み合わせた場合の動作を示しています。
構成設定 | 動作 |
---|---|
サービスレベルの最小インスタンス数とリビジョン レベルの最小インスタンス数の両方が設定されています。 | リビジョンの有効な値は、リビジョン レベルの最小インスタンス数とサービスレベルの最小インスタンス数のうち、大きい方の値です。 |
サービスレベルの最小インスタンス数とリビジョン レベルの最大インスタンス数の両方が設定されています。 | リビジョンの有効な値は、リビジョン レベルの最大インスタンス数とサービスレベルの最小インスタンス数のうち小さい方の値です。 これは、リビジョン レベルの最大インスタンス数が原因で、サービスレベルの最小インスタンス数に構成されているインスタンス数の上限に達していない場合についても該当します。 |
トラフィック分割でサービスレベルの最小インスタンス数を使用する
トラフィック分割を使用する場合、サービスレベルの最小インスタンス数は、トラフィック分割の比率に基づいてリビジョン間で分割されます。たとえば、サービスレベルの最小インスタンス数が 10 の場合、50 対 50 のトラフィック分割により、各リビジョンにサービスレベルの最小インスタンス数 5 が割り当てられます。
次の表に、構成シナリオの例を示します。
サンプルのユースケース | 構成の例 | 結果 |
---|---|---|
リビジョン レベルの設定なし | サービスレベルの最小インスタンス数: 10
|
リビジョン A は、トラフィック分割に比例してサービスレベルの最小インスタンス数から 6 つのインスタンスを受け取ります。リビジョン B は、トラフィック分割に比例してサービスレベルの最小インスタンス数から 4 つのインスタンスを受け取ります。 |
リビジョン レベルの最小インスタンス数が原因で、サービスレベルの最小インスタンス数よりも多くのインスタンスを受け取る | サービスレベルの最小インスタンス数: 10
|
リビジョン A は、リビジョン レベルの最小インスタンス数から 6 個のインスタンスを受け取ります。リビジョン B は、トラフィック分割に比例して、サービスレベルの最小インスタンス数から 5 つのインスタンスを受け取ります。これはサービスレベルの最小インスタンス数を超えており、想定内の動作です。 |
リビジョン レベルの最大インスタンス数が原因で、受け取るインスタンス数がサービスレベルの最小インスタンス数を下回っています。 | サービスレベルの最小インスタンス数: 10
|
リビジョン A は、トラフィック分割によってサービスレベルの最小インスタンス数から 3 つのインスタンスを受け取りますが、リビジョン レベルの最大インスタンス数に制限されます。 リビジョン B は、トラフィック分割に比例してサービスレベルの最小インスタンス数から 5 つのインスタンスを受け取ります。この場合、リビジョン A のリビジョン レベルでの最大インスタンス数が原因で、2 つのサービスレベル インスタンスが失われ、8 つのサービスレベル インスタンスが存在することになります。 |
サービスレベルの最小インスタンス数がトラフィック分割のリビジョン数より大きく、トラフィック分割に比例してインスタンス数が分割されます。 | サービスレベルの最小インスタンス数: 3
|
リビジョン A の最小インスタンス数は 1 に、リビジョン B の最小インスタンス数は 2 になります。サービスのインスタンス数は 3 です。 |