Cloud Run では、リビジョンのスケーリングが自動的に行われます。すべての受信リクエストまたはイベントを処理できるように、必要なコンテナ インスタンスの数が調整されます。リビジョンがトラフィックを受信しない場合、デフォルトでは、コンテナ インスタンスの数がゼロにスケールインされます。このデフォルトは必要に応じて変更できます。インスタンスをアイドル状態のままにすることも、最小インスタンスの設定を使用してウォームアップを指定することもできます。
受信リクエストまたはイベントのレートに加えて、スケジュールされるインスタンスの数は以下の影響を受けます。
- リクエストまたはイベントを処理中の既存インスタンスの CPU 使用率（スケジュールされたインスタンスを CPU 使用率 60% に維持するためのターゲティング）。
- 最大同時実行数の設定
- コンテナ インスタンスの最大数の設定
- コンテナ インスタンスの最小数の設定
コンテナ インスタンスの最大数について
コスト管理や、サービスで使用される他のリソースとの互換性を高めるために、必要に応じて起動できるコンテナ インスタンスの総数を制限できます。たとえば、Cloud Run サービスは、一定の数の同時オープン接続しか処理できないデータベースとやり取りする場合があります。
コンテナ インスタンスの最大数の設定で説明されているように、コンテナ インスタンスの最大数の設定を使用して、同時に起動できるインスタンスの合計数を制限できます。
最大インスタンス数の超過
通常の状況では、受信トラフィックの負荷を処理するために、新しいインスタンスを作成して、リビジョンをスケールアウトします。ただし、最大インスタンス数の上限を設定すると、トラフィック負荷を処理できるインスタンスが不足することがあります。その場合、受信リクエストは最大 10 秒間キューに入る場合があります。この時間枠内に、インスタンスがリクエストの処理が完了すると、キューに入れられたリクエストを処理できるようになります。この時間枠内で使用可能になるインスタンスがない場合、リクエストは失敗し、429 エラーコードが表示されます。
スケーリングの保証
インスタンスの最大数の上限はリビジョンごとの上限になります。上限を高く設定しても、リビジョンが指定した数のコンテナ インスタンスにスケールアウトされるわけではありません。これは、このリビジョンのコンテナ インスタンスの数が最大数を超えないことのみを意味しています。
最大インスタンス数の超過
トラフィックの急増やシステム メンテナンスなどの一部のケースでは、Cloud Run が短期間に最大インスタンス数を超えるコンテナ インスタンスを作成することがあります。既存のインスタンスを置き換える場合や、処理中のリクエストの処理が完了するまでの猶予期間を設ける場合に、最大インスタンス数の設定を超えて新しいインスタンスが開始されることがあります。
通常の運用では、週に数回、最大インスタンス数の上限を超えることがあります。通常、この猶予期間は最長 15 分、またはリクエスト タイムアウトの設定で指定された値まで継続します。これらの余分なインスタンスは、アイドル状態になってから 15 分以内に破棄されます。
通常、多くの置換が必要な場合、更新は数分または数時間にわたって分散しますが、各置換の猶予期間には余分なインスタンスが存在します。通常、最大インスタンス値を超えるインスタンス数は、構成されている最大インスタンス数の上限の 2 倍未満になりますが、トラフィックが突然急増した場合は、それをはるかに上回る可能性があります。
負荷テストでは、最大インスタンス数の設定を超えるインスタンスが発生します。これは、持続的な負荷パターンがみられる既存ワークロードの容量を確保するために、トラフィックが急増する場所が変更される可能性があるためです。
サービスがこの一時的な動作を許容できない場合は、安全性を確保するため、サービスが許容できるインスタンス値よりも少ない最大インスタンス値を設定することをおすすめします。
トラフィック分割
インスタンスの最大数の上限は各リビジョンの上限であるため、サービスが複数のリビジョン間でトラフィックを分割すると、サービスのインスタンス数の合計が、リビジョンごとのインスタンスの最大数を超えることがあります。これは、インスタンス数の指標で確認できます。
デプロイ
新しいリビジョンをデプロイしてすべてのトラフィックを処理する場合、Cloud Run は、以前に 100% のトラフィックを処理していたリビジョンから新しいリビジョンに、トラフィックを段階的に移行します。インスタンスの最大数の上限はリビジョンごとの上限であるため、デプロイ時に、サービスの合計インスタンス数がリビジョンごとのインスタンスの最大数を超えることがあります。これは、インスタンス数の指標で確認できます。
インスタンスをアイドル状態にしてコールド スタートを最小限に抑える
Cloud Run は、すべてのリクエストを処理した後、すぐにはインスタンスをシャットダウンしません。コールド スタートの影響を最小限に抑えるために、Cloud Run は一部のインスタンスを最大で 15 分間アイドル状態にすることがあります。このようなインスタンスは、トラフィックが急増した場合にすぐリクエストを処理できます。
たとえば、コンテナ インスタンスがリクエストの処理を完了した場合、別のリクエストを処理する必要がある場合に備えて、一定期間アイドル状態のままになることがあります。アイドル状態のコンテナ インスタンスは、オープン データベース接続などのリソースを残すことがあります。CPU を常に割り当てるように明示的に構成しない限り、リクエストの処理時にのみ CPU が割り当てられます。
アイドル状態のインスタンスを永続的に使用可能にするには、min-instance の設定を使用します。この機能を使用すると、サービスがリクエストを処理していない場合でもコストが発生することに注意してください。
自動スケーリングがバッキング サービスに与える影響
コンテナ インスタンスの数が自動的に増加すると、Cloud Run サービスのバッキング サービスで制限に達する場合があります。たとえば、Cloud SQL には API 割り当て上限があります。これらのバッキング サービスに十分な割り当てがあり、Cloud Run サービスのすべてのインスタンスからの接続を処理できることを確認してください。バッキング サービスが過負荷状態にならないように、コンテナ インスタンスの最大数を設定することを検討してください。
次のステップ
- Cloud Run サービスの最大インスタンス数を管理するには、コンテナ インスタンスの最大数の設定をご覧ください。
- 各コンテナ インスタンスが処理する同時リクエストの最大数を管理するには、同時実行の設定をご覧ください。
- 同時実行の設定を最適化する方法については、同時実行を調整する際のヒントをご覧ください。
- アイドル状態のインスタンスを最小限にし、最初のリクエストのレイテンシまたはコールド スタートを最小限に抑える方法については、
min-instanceを使用してアイドル インスタンスを有効にするをご覧ください。