Cloud Run サービスでのインスタンスの自動スケーリングについて

Cloud Run では、各リビジョンが、すべての受信リクエスト、イベント、CPU 使用率を処理するために必要なインスタンス数に自動的にスケーリングされます。

リビジョンがトラフィックを受信しない場合、デフォルトでは、インスタンスの数がゼロにスケールインされます。このデフォルトは必要に応じて変更できます。インスタンスをアイドル状態のままにすることも、最小インスタンスの設定を使用してウォームアップを指定することもできます。リクエスト以外で CPU を使用する場合は、最小インスタンス数を 1 に設定する必要があります。

受信リクエスト、イベント、CPU 使用率のレートに加えて、スケジュールされるインスタンスの数は次の要因の影響を受けます。

Cloud Run のオートスケーラーは 5 秒ごとにこれらを評価します。

CPU の常時割り当てと自動スケーリング

Cloud Run サービスを構成して CPU を常に割り当てる場合は、ゼロに向けた、およびゼロからのスケーリングの動作に注意する必要があります。

CPU は常にゼロからスケーリングされて割り当てられます。ゼロからのスケーリングはリクエストによってのみトリガーされるため、リクエストを処理していないサービスはゼロからスケーリングできません。これらのワークロードでは、最小インスタンス数を 0 より大きい値に設定するか、ゼロにスケーリングした後に処理を再開するように設計に「ウェイクアップ リクエスト」を追加します。

CPU は割り当てられる際に常にゼロにスケーリングされます。CPU 使用率が 0% のインスタンスは存在しないため、すべての CPU 使用率を確認してもゼロにスケーリングされることはありません。つまり、1 から 0 へスケーリングすることは、インスタンスがリクエストを処理しているかどうかを確認することによってのみ決定できます。

最大インスタンス数について

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

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

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

通常の状況では、受信トラフィックの負荷を処理するために、新しいインスタンスを作成して、リビジョンをスケールアウトします。ただし、最大インスタンス数の上限を設定すると、トラフィック負荷を処理できるインスタンスが不足することがあります。その場合、受信リクエストは次のようにキューに入れられます（保留状態になります）。

  • スケールアウト中など、新しいインスタンスが起動されると、少なくともこのサービスのコンテナ インスタンスの平均起動時間の間はリクエストが保留されます。これには、ゼロからのスケーリングなど、リクエストでスケールアウトが開始されるタイミングも含まれます。
  • 起動時間が 10 秒未満の場合、リクエストは最大で 10 秒間保留されます。
  • 起動プロセスにインスタンスがなく、リクエストがスケールアウトを開始しない場合、リクエストは最大で 10 秒間保留されます。

この時間枠内に、インスタンスがリクエストの処理が完了すると、キューに入れられた保留中のリクエストを処理できるようになります。この時間枠内で使用可能になるインスタンスがない場合、リクエストは失敗し、429 エラーコードが表示されます。

スケーリングの保証

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

トラフィックの急増による最大インスタンス数の超過

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

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

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

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

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

トラフィック分割

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

デプロイメント

新しいリビジョンをデプロイしてすべてのトラフィックを処理する場合、Cloud Run は新しいリビジョンに十分なインスタンスを起動してから、トラフィックを転送します。これにより、特に大量のトラフィックを処理するときに、新しいリビジョンのデプロイがリクエストのレイテンシに与える影響を軽減できます。インスタンスの最大数の上限はリビジョンごとの上限であるため、デプロイ時に、サービスの合計インスタンス数がリビジョンごとのインスタンスの最大数を超えることがあります。これは、インスタンス数の指標で確認できます。

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

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

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

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

自動スケーリングと保留中のリクエスト

  • スケールアウト中など、新しいインスタンスが起動されると、少なくともこのサービスのコンテナ インスタンスの平均起動時間の間はリクエストが保留されます。これには、ゼロからのスケーリングなど、リクエストでスケールアウトが開始されるタイミングも含まれます。
  • 起動時間が 10 秒未満の場合、リクエストは最大で 10 秒間保留されます。
  • 起動プロセスにインスタンスがなく、リクエストがスケールアウトを開始しない場合、リクエストは最大で 10 秒間保留されます。

自動スケーリングがバッキング サービスに与える影響

インスタンスの数が自動的に増加すると、Cloud Run サービスのバッキング サービスで制限に達する場合があります。たとえば、Cloud SQL には API 割り当て上限があります。これらのバッキング サービスに十分な割り当てがあり、Cloud Run サービスのすべてのインスタンスからの接続を処理できることを確認してください。バッキング サービスが過負荷状態にならないように、インスタンスの最大数を設定することを検討してください。

自動スケーリングと Pub/Sub

push サブスクリプションを使用して、Cloud Run の Pub/Sub トピックからのメッセージを利用することをおすすめします。push されたメッセージは、コンテナによって HTTP リクエストと同様に受信されるため、同じ自動スケーリングの動作がトリガーされます。

次のステップ