容量バッファを使用すると、クラスタ内のアクティブまたはスタンバイの容量の階層を事前に宣言できるため、Google Kubernetes Engine（GKE）ワークロードの Pod の起動レイテンシを短縮できます。予備容量を事前に宣言することで、費用対効果の高い方法でワークロードを迅速に起動できます。
このドキュメントでは、容量バッファの仕組みについて説明します。容量バッファを有効にして使用する方法については、容量バッファを構成するをご覧ください。
容量バッファを使用する場合
起動レイテンシの影響を受けやすく、迅速なスケーリングが必要なアプリケーションには、容量バッファを使用します。トラフィックが急増した場合、アクティブ バッファは、低レイテンシのスケーリング用に事前プロビジョニングされた容量を提供します。トラフィックが継続的に増加する場合は、スタンバイ バッファを使用すると、事前プロビジョニングよりも低コストで Pod をスケジューリングできます。
容量バッファには次の利点があります。
- スケーリング レイテンシを最小限に抑える: アクティブ バッファは実行中の VM を提供するため、 レイテンシを最小限に抑えることができます。スタンバイ バッファは迅速に再開されるため、新しいノードよりも迅速に容量を利用できます。
- 費用対効果の高いオーバー プロビジョニング: 容量バッファを使用すると、 固定サイズのセーフティ ネットを維持できます。大規模なワークロードの場合、このアプローチは、クラスタの成長に伴って アイドル状態の容量が直線的に増加する他のオーバー プロビジョニング方法（HorizontalPodAutoscaler（HPA）の使用率の目標値を下げるなど）よりも 費用対効果が高くなります。
- ワークロードの要件を満たす: 容量バッファのサイズを完全に制御できます。カスタム DaemonSet やデータの組み込み、イメージのプリロードとワークロードの事前起動の制御など、ニーズに合わせて調整できます。
AI エージェント、AI 推論、セールイベント中の小売アプリケーション、プレーヤー アクティビティのピーク時のゲームサーバーなど、迅速なスケールアップが必要なレイテンシの影響を受けやすいワークロードには、容量バッファを使用することをおすすめします。
起動レイテンシの影響を受けないワークロード（バッチ処理ジョブなど）には、容量バッファを使用することをおすすめしません。このようなワークロードでは、リソースをオーバー プロビジョニングしてもメリットはありません。
容量バッファの仕組み
容量バッファを実装するには、Kubernetes CapacityBuffer カスタム リソースを使用して、予備容量のバッファを定義します。GKE クラスタ オートスケーラーは CapacityBuffer リソースをモニタリングし、保留中の需要として処理して、予備容量が使用可能であることを確認します。バッファで定義されたリソース リクエストを満たすのに十分な容量がクラスタにない場合、クラスタ オートスケーラーは追加のノードをプロビジョニングします。
優先度の高いワークロードがスケールアップすると、GKE はバッファ内の使用可能な容量にワークロードをすぐにスケジューリングします。この即時スケジューリングは、バッファに予約されているレプリカ数またはリソース量に適用され、ノードのプロビジョニングに伴う一般的な遅延を回避できます。ワークロードがバッファユニットを使用すると、クラスタ オートスケーラーはバッファを補充するために新しいノードをプロビジョニングします。
容量バッファの戦略
レイテンシと費用の要件に基づいて、さまざまなプロビジョニング戦略を使用して容量バッファを構成できます。
アクティブ バッファ
アクティブ バッファ は、予約済みの容量に収まるワークロードの低レイテンシ スケーリング用に実行中の VM を提供します。ノードはすでに準備が整っているため、スケールアップ イベント時の最初のバッファ消費のレイテンシを最小限に抑えることができます。
この戦略は、スケールアップ時間が最優先される重要なワークロードにおすすめします。
スタンバイ バッファ
スタンバイ バッファ は、一時停止された VM を提供します。スタンバイ戦略はアクティブ戦略よりも費用対効果が高くなりますが、ワークロードを受け入れる前に VM を再開する際に短い遅延が発生します。
この戦略は、スケーリングのわずかな遅延を許容して費用を最適化できるワークロードにおすすめします。
CapacityBuffer CRD
容量バッファを構成するには、CapacityBuffer CustomResourceDefinition（CRD）を作成します。さまざまな条件を満たすように容量バッファを構成できます。
- 固定レプリカ: バッファ Pod の固定数を指定します。この構成は、既知のサイズのバッファを作成する最も簡単な方法です。
- 割合ベース: スケール サブリソース（Deployment、 StatefulSet、ReplicaSet、Job など）を定義する既存の スケーラブル オブジェクトの割合としてバッファサイズを定義します。参照ワークロードがスケーリングされると、バッファサイズが動的に調整されます。Pod テンプレートにはレプリカ フィールドがないため、割合ベースのバッファを定義することはできません。
- リソース上限: バッファが予約する CPU とメモリの合計量を定義します。コントローラは、参照される Pod テンプレートのリソース リクエストに基づいて、作成するバッファ Pod の数を計算します。
詳細については、CapacityBuffer CRD のリファレンス ドキュメントをご覧ください。
要件と制限事項
容量バッファには次の要件と制限があります。
- 容量バッファは、アクティブ バッファの場合はバージョン 1.35.2-gke.1842000 以降、スタンバイ バッファの場合はバージョン 1.35.2-gke.1842002 以降を実行している GKE クラスタで使用できます。
- 容量バッファは、ノードベースの課金モデルを使用するワークロードのみをサポートします。容量バッファは、 Pod ベースの課金モデルを使用するワークロードをサポートしていません。
- クラスタでノード自動プロビジョニングを有効にすることをおすすめします。ノード自動プロビジョニングにより、クラスタ オートスケーラーは CapacityBuffer のリソース リクエストに基づいて新しいノードプールを作成できます。ノード自動プロビジョニングを有効にしない場合、クラスタ オートスケーラーは既存のノードプールのみをスケールアップします。
スタンバイ バッファには、次の追加の制限があります。
- Standard クラスタでのみサポートされます。
- GPU または TPU が接続された VM はサポートされていません。
- ローカル SSD は対象外です。
- 機密性の高い Google Kubernetes Engine ノード は対象外です。
- Compute Engine の一時停止と再開のオペレーションに関連する制限事項（メモリ上限など）を理解しておく必要があります。
次のステップ
- 容量バッファを実装する方法については、容量バッファを構成するをご覧ください。