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

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

スケジュールされるインスタンス数は、以下の影響を受けます。

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

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

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

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

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

スケーリングの保証

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

トラフィックの急増

トラフィックの急増などの場合、Cloud Run によって短期間に、指定された最大インスタンス値よりもわずかに多くコンテナ インスタンスが作成される場合があります。サービスがこの一時的な動作を許容できない場合は、安全マージンを考慮して、サービスが許容できるインスタンス値よりも少ない最大インスタンス値を設定することをおすすめします。

デプロイ

新しいリビジョンをデプロイすると、Cloud Run は古いリビジョンから新しいリビジョンにトラフィックを段階的に移行します。リビジョンごとにインスタンス数の上限が設定されているため、デプロイ後には、指定した上限を一時的に超える場合があります。

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

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

たとえば、コンテナ インスタンスがリクエストの処理を完了した場合、別のリクエストを処理する必要がある場合に備えて、一定期間アイドル状態のままになることがあります。アイドル状態のコンテナ インスタンスは、オープン データベース接続などのリソースを残すことがあります。ただし、Cloud Run では CPU を使用できません

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

次のステップ