コンテナ インスタンスの自動スケーリングについて

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

Cloud Run では、リビジョンのスケーリングが自動的に行われます。すべての受信リクエストまたはイベントを処理できるように、必要なコンテナ インスタンスの数が調整されます。リビジョンがトラフィックを受信しない場合、デフォルトでは、コンテナ インスタンスの数がゼロにスケールインされます。このデフォルトは必要に応じて変更できます。インスタンスをアイドル状態のままにすることも、最小インスタンスの設定を使用してウォームアップを指定することもできます。

受信リクエストまたはイベントのレートに加えて、スケジュールされるインスタンスの数は以下の影響を受けます。

コンテナ インスタンスの最大数について

コスト管理や、サービスで使用される他のリソースとの互換性を高めるために、必要に応じて起動できるコンテナ インスタンスの総数を制限できます。たとえば、Cloud Run サービスは、一定の数の同時オープン接続しか処理できないデータベースとやり取りする場合があります。

コンテナ インスタンスの最大数の設定で説明されているように、コンテナ インスタンスの最大数の設定を使用して、同時に起動できるインスタンスの合計数を制限できます。

最大インスタンス数の超過

通常の状況では、受信トラフィックの負荷を処理するために、新しいインスタンスを作成して、リビジョンをスケールアウトします。ただし、最大インスタンス数の上限を設定すると、トラフィック負荷を処理できるインスタンスが不足することがあります。その場合、受信リクエストは最大 10 秒間キューに入る場合があります。この時間枠内に、インスタンスがリクエストの処理が完了すると、キューに入れられたリクエストを処理できるようになります。この時間枠内で使用可能になるインスタンスがない場合、リクエストは失敗し、429 エラーコードが表示されます。

スケーリングの保証

インスタンスの最大数の上限はリビジョンごとの上限になります。上限を高く設定しても、リビジョンが指定した数のコンテナ インスタンスにスケールアウトされるわけではありません。これは、このリビジョンのコンテナ インスタンスの数が最大数を超えないことのみを意味しています。

最大インスタンス数の超過

トラフィックの急増やシステム メンテナンスなどの一部のケースでは、Cloud Run が短期間に最大インスタンス数を超えるコンテナ インスタンスを作成することがあります。既存のインスタンスを置き換える場合や、処理中のリクエストの処理が完了するまでの猶予期間を設ける場合に、最大インスタンス数の設定を超えて新しいインスタンスが開始されることがあります。

通常の運用では、週に数回、最大インスタンス数の上限を超えることがあります。通常、この猶予期間は最長 15 分、またはリクエスト タイムアウトの設定で指定された値まで継続します。これらの余分なインスタンスは、アイドル状態になってから 15 分以内に破棄されます。

通常、多くの置換が必要な場合、更新は数分または数時間にわたって分散しますが、各置換の猶予期間には余分なインスタンスが存在します。通常、最大インスタンス値を超えるインスタンス数は、構成されている最大インスタンス数の上限の 2 倍未満になりますが、トラフィックが突然急増した場合は、それをはるかに上回る可能性があります。

負荷テストでは、最大インスタンス数の設定を超えるインスタンスが発生します。これは、持続的な負荷パターンがみられる既存ワークロードの容量を確保するために、トラフィックが急増する場所が変更される可能性があるためです。

サービスがこの一時的な動作を許容できない場合は、安全性を確保するため、サービスが許容できるインスタンス値よりも少ない最大インスタンス値を設定することをおすすめします。

トラフィック分割

インスタンスの最大数の上限は各リビジョンの上限であるため、サービスが複数のリビジョン間でトラフィックを分割すると、サービスのインスタンス数の合計が、リビジョンごとのインスタンスの最大数を超えることがあります。これは、インスタンス数の指標で確認できます。

デプロイ

新しいリビジョンをデプロイしてすべてのトラフィックを処理する場合、Cloud Run は、以前に 100% のトラフィックを処理していたリビジョンから新しいリビジョンに、トラフィックを段階的に移行します。インスタンスの最大数の上限はリビジョンごとの上限であるため、デプロイ時に、サービスの合計インスタンス数がリビジョンごとのインスタンスの最大数を超えることがあります。これは、インスタンス数の指標で確認できます。

インスタンスをアイドル状態にしてコールド スタートを最小限に抑える

Cloud Run は、すべてのリクエストを処理した後、すぐにはインスタンスをシャットダウンしません。コールド スタートの影響を最小限に抑えるために、Cloud Run は一部のインスタンスを最大で 15 分間アイドル状態にすることがあります。このようなインスタンスは、トラフィックが急増した場合にすぐリクエストを処理できます。

たとえば、コンテナ インスタンスがリクエストの処理を完了した場合、別のリクエストを処理する必要がある場合に備えて、一定期間アイドル状態のままになることがあります。アイドル状態のコンテナ インスタンスは、オープン データベース接続などのリソースを残すことがあります。CPU を常に割り当てるように明示的に構成しない限り、リクエストの処理時にのみ CPU が割り当てられます。

アイドル状態のインスタンスを永続的に使用可能にするには、min-instance の設定を使用します。この機能を使用すると、サービスがリクエストを処理していない場合でもコストが発生することに注意してください。

次のステップ