このページでは、サービスを手動でスケーリングする方法について説明します。また、Cloud Scheduler ジョブと Cloud Run Admin API を使用してスケジュールに基づいてインスタンス数を変更する一般的なユースケースの手順も示します。
概要
デフォルトでは、Cloud Run はトラフィックと CPU 使用率に応じて、指定されたインスタンス数またはデフォルトの最大インスタンス数に自動的にスケールアウトします。ただし、ユースケースによっては、手動スケーリングを使用して特定の数のインスタンスを設定することが必要になる場合があります。
手動スケーリングでは、トラフィックや使用率に関係なく、再デプロイすることなく、特定のインスタンスの数を設定できます。これらにより、外部システムを使用して独自のスケーリング ロジックを記述できます。例については、スケジュールベースのスケーリングをご覧ください。
自動スケーリングと手動スケーリングの切り替え
スケーリング モードを切り替えると、次の表に示すように、インスタンス数とサービスレベルの最小インスタンス数と最大インスタンス数の設定に影響します。
| スケーリング スイッチの方向 | インスタンス数 | 最小インスタンス数と最大インスタンス数 |
|---|---|---|
| 自動から手動へ | モードを切り替えるコマンドでインスタンス数が指定されていない場合は、サービスレベルの最小インスタンス数の設定を継承します。 | 切り替え後、サービスレベルの最小インスタンス数と最大インスタンス数は設定解除されます。 |
| 手動から自動へ | 手動インスタンス数が設定されていない | サービスレベルの最小インスタンス数と最大インスタンス数の両方を指定するか、どちらも指定しない必要があります。（1 つだけ指定するとエラーが返されます）。モードを切り替えるコマンドでこれらのいずれも指定しない場合、サービスレベルの最小インスタンス数と最大インスタンス数は手動インスタンス数を継承します。 |
リビジョン レベルの最小値と最大値の設定と手動スケーリング
サービスを手動スケーリングに設定すると、リビジョン レベルの最小インスタンス数と最大インスタンス数の設定は無視されます。
手動スケーリングのトラフィック分割
次のリストは、手動スケーリングでトラフィックを分割するときにインスタンスが割り振られる方法を示しています。これには、トラフィック タグのみのリビジョンの動作も含まれます。
トラフィック分割中、各リビジョンには、サービスレベルの最小インスタンス数を使用したトラフィック分割と同様に、トラフィック分割に基づいてインスタンスが比例的に割り当てられます。
トラフィックを受信するリビジョン数が手動インスタンス数を超えると、一部のリビジョンにインスタンスが割り当てられません。これらのリビジョンに送信されたトラフィックは、リビジョンが無効になっている場合と同じエラーが発生します。
トラフィック分割でトラフィックを受信するすべてのリビジョンで、リビジョン レベルの最小インスタンス数と最大インスタンス数が無効になります。
リビジョンがトラフィック タグが原因でのみアクティブになっている場合:
- リビジョン レベルの最小インスタンス数が設定されている場合、指定された数のインスタンスが開始されますが、サービス手動インスタンスの合計数にはカウントされません。リビジョンは自動スケーリングされません。
- リビジョン レベルの最小インスタンス数が設定されていない場合、リビジョンはタグ URL に送信されたトラフィックに応じて最大 1 インスタンスにスケールアウトされます。
手動スケーリングを使用した課金の動作
手動スケーリングを使用する場合、請求の動作は最小インスタンス数機能を使用する場合の動作と同様です。
つまり、手動スケーリングとインスタンスベースの課金では、手動でスケーリングされたアイドル状態のインスタンスは、アクティブ インスタンスとして課金されます。
リクエスト ベースの課金で手動スケーリングを使用する場合、手動でスケーリングされたアイドル状態のインスタンスは、アイドル状態の最小インスタンス数として課金されます。課金の詳細については、料金ページをご覧ください。
必要なロール
Cloud Run サービスのデプロイに必要な権限を取得するには、次の IAM ロールを付与するよう管理者に依頼してください。
-
Cloud Run サービスに対する Cloud Run デベロッパー（
roles/run.developer） -
サービス ID に対するサービス アカウント ユーザー（
roles/iam.serviceAccountUser）ロール -
デプロイされたコンテナ イメージの Artifact Registry リポジトリに対する Artifact Registry 読み取り （
roles/artifactregistry.reader）（該当する場合）
Cloud Run に関連付けられている IAM ロールと権限のリストについては、Cloud Run IAM ロールと Cloud Run IAM 権限をご覧ください。Cloud Run サービスがGoogle Cloud API（Cloud クライアント ライブラリなど）と連携している場合は、サービス ID の構成ガイドをご覧ください。ロールの付与の詳細については、デプロイ権限とアクセスの管理をご覧ください。
スケーリングを構成する
スケーリング モードは、サービスを作成または更新するときに、Google Cloud コンソール、Google Cloud CLI、YAML ファイル、または API を使用して構成できます。
Console
Google Cloud コンソールで、Cloud Run に移動します。
新しいサービスを構成する場合は、[コンテナをデプロイ] をクリックし、[サービス] を選択して [サービスの作成] フォームを表示します。既存のサービスを構成する場合は、サービスをクリックして詳細パネルを表示し、詳細パネルの右上にある [スケーリング] の横にある鉛筆アイコンをクリックします。
新しいサービスの場合は [サービスのスケーリング] フォーム、既存のサービスの場合は [スケーリングの編集] フォームを見つけます。
[インスタンス数] フィールドに、サービスのコンテナ インスタンスの数を指定します。
新しいサービスの場合は [作成]、既存のサービスの場合は [保存] をクリックします。
gcloud
新しいサービスのスケーリングを指定する場合は、deploy コマンドを使用します。
gcloud beta run deploy SERVICE \ --scaling=INSTANCE_COUNT \ --image IMAGE_URL
次のように置き換えます。
- SERVICE は、実際のサービスの名前に置き換えます。
- INSTANCE_COUNT は、サービスのインスタンス数に置き換えます。これにより、サービスは手動スケーリングに設定されます。サービスを無効にするには、値を
0に指定します。デフォルトの Cloud Run 自動スケーリング動作を使用するには、値autoを指定します。 - 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です。
次の update コマンドを使用して、既存のサービスのスケーリングを指定します。
gcloud beta run services update SERVICE \ --scaling=INSTANCE_COUNT
YAML
新しいサービスを作成する場合は、この手順をスキップします。既存のサービスを更新する場合は、その YAML 構成をダウンロードします。
gcloud run services describe SERVICE --format export > service.yaml
scalingMode属性とmanualInstanceCount属性を更新します。apiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE annotations: run.googleapis.com/launch-stage: BETA run.googleapis.com/scalingMode: MODE run.googleapis.com/manualInstanceCount: INSTANCE_COUNT
次のように置き換えます。
- SERVICE は、Cloud Run サービスの名前に置き換えます。
- MODE は、手動スケーリングの場合は
manual、デフォルトの Cloud Run 自動スケーリング動作の場合はautomaticに置き換えます。 - INSTANCE_COUNT は、サービスに対して手動でスケーリングするインスタンスの数に置き換えます。サービスを無効にするには、値を
0に指定します。
次のコマンドを使用して、サービスを作成または更新します。
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 '{"launchStage":"BETA","scaling":{"manualInstanceCount":MANUAL_INSTANCE_COUNT }}' \ https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services/SERVICE?update_mask=launchStage,scaling.manualInstanceCount
次のように置き換えます。
- ACCESS_TOKEN は、サービスを更新する IAM 権限を持つアカウントの有効なアクセス トークンに置き換えます。たとえば、
gcloudにログインしている場合は、gcloud auth print-access-tokenを使用してアクセス トークンを取得できます。Cloud Run コンテナ インスタンスから、コンテナ インスタンス メタデータ サーバーを介してアクセス トークンを取得できます。 - MANUAL_INSTANCE_COUNT は、サービスのインスタンス数に置き換えます。これにより、サービスは手動スケーリングに設定されます。サービスを無効にするには、値を
0に指定します。 - SERVICE は、サービスの名前に置き換えます。
- REGION は、サービスがデプロイされているリージョンに置き換えます。 Google Cloud
- PROJECT_ID は、 Google Cloud プロジェクト ID に置き換えます。
サービスのスケーリング構成を表示する
Cloud Run サービスのスケーリング構成インスタンスを表示するには:
Console
Google Cloud コンソールで、Cloud Run に移動します。
目的のサービスをクリックして、[サービスの詳細] パネルを開きます。
現在のスケーリング設定は、サービスの詳細パネルの右上にある [スケーリング] ラベルの後に、鉛筆アイコンの横に表示されます。
gcloud
サービスの現在のスケーリング構成を表示するには、次のコマンドを使用します。
gcloud beta run services describe SERVICE
SERVICE は、実際のサービス名に置き換えます。
describe から返されたテキストの上部付近にある Scaling: Manual (Instances: ) フィールドを探します。
YAML
次のコマンドを使用して、サービスの YAML 構成をダウンロードします。
gcloud run services describe SERVICE --format export > service.yaml
スケーリング構成は scalingMode 属性と manualInstanceCount 属性に含まれます。
サービスの無効化
サービスを無効にしても、現在処理中のリクエストは完了できます。ただし、サービス URL に対するそれ以降のリクエストは失敗し、Service unavailable または Service disabled エラーが発生します。
トラフィック タグが原因でのみアクティブになっているサービス リビジョンへのリクエストは、リビジョンが無効になっていないため影響を受けません。
サービスを無効にするには、スケーリングをゼロに設定します。サービスは、Google Cloud コンソール、Google Cloud CLI、YAML ファイル、API を使用して無効にできます。
Console
Google Cloud コンソールで、Cloud Run に移動します。
無効にするサービスをクリックして詳細パネルを表示し、詳細パネルの右上にある [スケーリング] の横にある鉛筆アイコンをクリックします。
[スケーリングを編集] フォームを見つけて、[手動スケーリング] を選択します。
[インスタンス数] フィールドに値
0（ゼロ）を入力します。[保存] をクリックします。
gcloud
サービスを無効にするには、次のコマンドを使用してスケーリングを 0 に設定します。
gcloud beta run services update SERVICE --scaling=0
SERVICE は、実際のサービス名に置き換えます。
YAML
サービスの YAML 構成をダウンロードします。
gcloud run services describe SERVICE --format export > service.yaml
manualInstanceCount属性をゼロ（0）に設定します。apiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE annotations: run.googleapis.com/launch-stage: BETA run.googleapis.com/scalingMode: manual run.googleapis.com/manualInstanceCount: `0`
SERVICE は、Cloud Run サービスの名前に置き換えます。
次のコマンドを使用して、サービスを作成または更新します。
gcloud run services replace service.yaml
REST API
サービスを無効にするには、Cloud Run Admin API の service エンドポイントに PATCH HTTP リクエストを送信します。
curl の使用例を次に示します。
curl -H "Content-Type: application/json" \ -H "Authorization: Bearer ACCESS_TOKEN" \ -X PATCH \ -d '{"launchStage":"BETA","scaling":{"manualInstanceCount":0 }}' \ https://run.googleapis.com/v2/projects/PROJECT_ID/locations/REGION/services/SERVICE?update_mask=launchStage,scaling.manualInstanceCount
次のように置き換えます。
- ACCESS_TOKEN は、サービスを更新する IAM 権限を持つアカウントの有効なアクセス トークンに置き換えます。たとえば、
gcloudにログインしている場合は、gcloud auth print-access-tokenを使用してアクセス トークンを取得できます。Cloud Run コンテナ インスタンスから、コンテナ インスタンス メタデータ サーバーを介してアクセス トークンを取得できます。 - SERVICE は、サービスの名前に置き換えます。
- REGION は、サービスがデプロイされているリージョンに置き換えます。 Google Cloud
- PROJECT_ID は、 Google Cloud プロジェクト ID に置き換えます。
スケジュールベースのスケーリングの例
手動スケーリングの一般的なユースケースは、事前定義されたスケジュールに基づいてインスタンス数を変更することです。この例では、Cloud Scheduler を使用して 2 つのジョブをスケジュールします。各ジョブは Cloud Run Admin API を呼び出してインスタンス数をスケーリングします。最初のジョブは、営業時間中（月曜日～金曜日の午前 9 時～午後 5 時）に手動で 10 インスタンスにスケールアウトするようにサービスを設定します。2 番目のジョブは、営業時間外にサービスをゼロ インスタンスにスケールインするように設定します。
例に示すようにインスタンスをゼロに設定すると、サービスは無効になりますが、Cloud Scheduler ジョブは無効になりません。これらのジョブは引き続き実行され、スケジュールどおりにサービスを 10 インスタンスにリセット（および再有効化）します。
この例では、わかりやすくするために Cloud Run クイックスタートを使用していますが、任意のサービスを使用できます。
スケジュールベースの手動スケーリングを設定するには:
次のコマンドを使用してサービスをデプロイします。
gcloud beta run deploy SERVICE \ --image=us-docker.pkg.dev/cloudrun/container/hello \ --region=REGION \ --project PROJECT_ID
次の変数を置き換えます。
- REGION は、Cloud Run サービスがデプロイされているリージョンに置き換えます。
- SERVICE は、Cloud Run サービスの名前に置き換えます。
次のコマンドを使用して、10 インスタンスに手動でスケーリングするようにサービスを構成します。
gcloud beta run services update SERVICE \ --region=REGION \ --scaling=10
営業時間中にサービス インスタンスを手動で 10 インスタンスにスケールアウトする Cloud Scheduler ジョブを作成します。
gcloud scheduler jobs create http hello-start-instances \ --location=REGION \ --schedule="0 9 * * MON-FRI" \ --time-zone=America/Los_Angeles \ --uri=https://run.googleapis.com/v2/projects/PROJECT_ID/ locations/REGION/services/hello?update_mask=launchStage,scaling.manualInstanceCount \ --headers=Content-Type=application/json,X-HTTP-Method-Override=PATCH \ --http-method=PUT \ --message-body='{"launchStage":"BETA","scaling":{"manualInstanceCount":10}}' \ --oauth-service-account-email=PROJECT_NUMBER-compute@developer.gserviceaccount.com
このコマンドは、Cloud Run Admin API に HTTP 呼び出しを行う Cloud Scheduler ジョブを作成し、インスタンス数を
10に設定します。この例では、Cloud Scheduler ジョブに Compute Engine のデフォルトのサービス アカウントPROJECT_NUMBER-compute@developer.gserviceaccount.comを使用します。Cloud Run サービスを更新する権限を持つ任意のサービス アカウントを使用できます。営業時間外にサービス インスタンスを手動で 0 インスタンスにスケーリングし、サービスを無効にする Cloud Scheduler ジョブを作成します。
gcloud scheduler jobs create http hello-stop-instances \ --location=REGION \ --schedule="0 17 * * MON-FRI" \ --time-zone=America/Los_Angeles \ --uri=https://run.googleapis.com/v2/projects/PROJECT_ID/ locations/REGION/services/hello?update_mask=launchStage,scaling.manualInstanceCount \ --headers=Content-Type=application/json,X-HTTP-Method-Override=PATCH \ --http-method=PUT \ --message-body='{"launchStage":"BETA","scaling":{"manualInstanceCount":0}}' \ --oauth-service-account-email=PROJECT_NUMBER-compute@developer.gserviceaccount.com
このコマンドは、Cloud Run Admin API に HTTP 呼び出しを行い、手動スケーリング インスタンスをゼロに設定する Cloud Scheduler ジョブを作成します。これにより、サービスは事実上無効になりますが、Cloud Scheduler ジョブは無効になりません。Cloud Scheduler ジョブは引き続き実行され、スケジュールに従ってサービスを 10 インスタンスにリセット（および再び有効に）します。