コンテナ インスタンスの自動スケーリング

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

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

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

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

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

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

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

スケーリングの保証

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

トラフィックの急増

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

デプロイ

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

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

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

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

アイドル状態のインスタンスを永続的に使用可能にするには、min-instance の設定を使用します。

次のステップ