容量バッファを使用すると、クラスタでアクティブまたはスタンバイの容量バッファの階層を事前に宣言できるため、Google Kubernetes Engine（GKE）ワークロードの Pod 起動レイテンシを短縮できます。事前に予備容量を宣言することで、費用対効果の高い方法でワークロードの起動を高速化できます。
このドキュメントでは、容量バッファの仕組みについて説明します。容量バッファを有効にして使用する方法については、容量バッファを構成するをご覧ください。
容量バッファを使用する場合
起動レイテンシの影響を受けやすく、迅速なスケーリングが必要なアプリケーションには、容量バッファを使用します。トラフィックが急増した場合、アクティブ バッファは、低レイテンシ スケーリング用に設計された事前プロビジョニング済みの容量を提供します。トラフィックが継続的に増加している場合、スタンバイ バッファを使用すると、事前プロビジョニングよりも低コストで Pod をスケジュールできます。
容量バッファには次の利点があります。
- スケーリング レイテンシを最小限に抑える: アクティブ バッファは実行中のノードを提供し、レイテンシを最小限に抑えます。スタンバイ バッファは迅速に再開され、アクティブ バッファよりも低コストで、新しいノードよりも迅速に容量を利用できます。
- 費用対効果の高いオーバー プロビジョニング: 容量バッファは、セーフティ ネットの維持に役立ちます。大規模なワークロードの場合、このアプローチは、クラスタの拡大に伴ってアイドル容量が線形に増加する Horizontal Pod Autoscaler（HPA）の使用率目標を下げるなどの他のオーバー プロビジョニング方法よりも費用対効果が高くなります。
- ワークロードの要件を満たす: 容量バッファの構成を完全に制御できます。オプションには、カスタム DaemonSet を組み込んでイメージをプリロードする、起動時間を調整する、ニーズに合わせてバッファサイズを制御するなどがあります。
AI エージェント、AI 推論、セールイベント中の小売アプリケーション、プレーヤー アクティビティのピーク時のゲームサーバーなど、迅速なスケールアップを必要とするレイテンシの影響を受けやすいワークロードには、容量バッファをおすすめします。
容量バッファの仕組み
Kubernetes CapacityBuffer カスタム リソースを使用して予備容量のバッファを定義し、容量バッファを実装します。GKE クラスタ オートスケーラーは、CapacityBuffer リソースをモニタリングし、保留中の需要として扱うことで、予備容量を確保します。クラスタにバッファで定義されたリソース リクエストを満たすのに十分な容量がない場合、クラスタ オートスケーラーは追加のノードをプロビジョニングします。
優先度の高いワークロードがスケールアップすると、GKE はバッファ内の使用可能な容量にワークロードをすぐにスケジューリングします。この即時スケジューリングは、バッファに予約されているレプリカ数またはリソース量に適用され、ノード プロビジョニングに関連する一般的な遅延を回避します。ワークロードがバッファ単位を使用すると、クラスタ オートスケーラーはバッファを補充するために新しいノードをプロビジョニングします。
容量バッファ戦略
レイテンシと費用の要件に基づいて、さまざまなプロビジョニング戦略を使用して容量バッファを構成できます。
アクティブ バッファ
アクティブ バッファは、予約済み容量に収まるワークロードの低レイテンシ スケーリング用に実行中のノードを提供します。ノードはすでに実行されているため、スケールアップ イベント中に Pod を要求する際のレイテンシを最小限に抑えることができます。
スタンバイ バッファ
スタンバイ バッファは、一時停止されたノードを提供します。スタンバイ戦略はアクティブ戦略よりも費用対効果が高いですが、ワークロードを受け入れる前にノードを再開する際に短い遅延が発生します。
費用と料金
容量バッファの課金は、バッファの種類によって異なります。
- アクティブ バッファ: GKE がアクティブ バッファ容量として維持する実行中の VM に対して、標準の GKE コンピューティング料金が課金されます。Autopilot では、実行中の Pod に標準の Pod ベースの課金レートが適用されます。
- スタンバイ バッファ: VM インスタンスが一時停止している間は、コンピューティング費用（CPU またはメモリ）は発生しません。ストレージ料金（VM ブートディスクなど）と、静的外部 IP アドレスなどの関連リソースの費用がわずかに発生します。GKE がワークロードをホストするためにスタンバイ VM を再開すると、標準コンピューティングまたは Pod ベースの課金レートが適用されます。
CapacityBuffer CRD
容量バッファを構成するには、CapacityBuffer CustomResourceDefinition（CRD）を作成します。容量バッファは、さまざまな条件を満たすように構成できます。
- 固定レプリカ: 参照される Pod テンプレートのリソース リクエストに基づいて作成するバッファ Pod の固定数を指定します。この構成は、既知のサイズのバッファを作成する最も簡単な方法です。
- リソース上限: バッファが予約する CPU とメモリの合計量を指定します。コントローラは、参照される Pod テンプレートのリソース リクエストに基づいて、作成するバッファ Pod の数を計算します。
- 割合ベース: スケール サブリソース（Deployment、StatefulSet、ReplicaSet、Job など）を定義する既存のスケーラブル オブジェクトの割合としてバッファサイズを定義します。バッファサイズは、参照ワークロードのスケールに合わせて動的に調整されます。容量バッファの割合は、Kubernetes のスケール サブリソースを実装するオブジェクトでのみサポートされます。
詳細については、CapacityBuffer CRD リファレンス ドキュメントをご覧ください。
ベスト プラクティス
容量バッファを構成する際に費用対効果と応答性を最適化するには、次の推奨事項を使用します。
- 費用対効果の高いスタンバイ優先戦略を使用する: ワークロードで約 30 秒のスケールアップの遅延を許容できる場合は、スタンバイ バッファを優先します。この戦略では、アクティブな VM の全費用を発生させることなく、新しい VM のコールドノードの起動を回避できます。
- レイテンシの影響を受けやすいワークロードにアクティブ バッファを使用する: Pod スケジューリング時間を可能な限り短くする必要がある場合に、ノードの再開時間を許容できないワークロードにアクティブ バッファを使用します。
- ハイブリッド戦略を使用してパフォーマンスと費用をバランスさせる: 小さなアクティブ バッファと大きなスタンバイ バッファを組み合わせて、費用対効果の高い設定にします。GKE は、スタンバイ バッファからノードを再開して（約 30 秒）、アクティブ バッファの補充を優先します。その間、新しいノードがバックグラウンドでプロビジョニングされ、スタンバイ バッファが補充されます。この設定では、アクティブ容量で初期の急増を吸収し、低コストのスタンバイ容量を使用して持続的な増加に対応します。
- 初期バースト用にアクティブ バッファのサイズを設定する: スタンバイ バッファ ノードが再開する前に発生すると想定される、初期のレプリカの急増をカバーするようにアクティブ バッファのサイズを定義します。
- 持続的な負荷に対応するスタンバイ バッファのサイズを設定する: 想定される負荷の増加を十分にカバーできるサイズのスタンバイ バッファを定義し、コールドスタート時でもバックグラウンドでバッファが補充されるようにします。十分なサイズのスタンバイ バッファがあれば、Pod のスケジューリングにおける最大レイテンシを、ノードの再開にかかる時間（約 30 秒）まで短縮できます。容量バッファが使用され始め、補充されると、新しいバッファノードは一時停止する前にアクティブ状態に移行します。この戦略により、負荷が長期間続く間、アクティブな容量を増やすことができます。
- バッファ シミュレータを使用する: さまざまなアクティブ バッファとスタンバイ バッファのサイズを試して、特定のワークロードに最適な結果を得ます。https://github.com/gke-labs/buffers-simulator にあるオープンソースの GKE バッファ シミュレータを使用して、ワークロードのスケーリング動作のシミュレーションを実行し、バッファ サイズ設定ルールをファインチューニングして、パフォーマンス目標を達成します。
- ワークロードをゼロからスケーリングする際のコールド スタート レイテンシを短縮する: HPA を使用してゼロとの間でスケーリングする（
minReplicas: 0）ワークロードを容量バッファとペア設定します。需要が増加し、ワークロードがゼロからスケールアップすると、GKE は新しいコンピューティング ノードのプロビジョニングを待つのではなく、事前にウォームアップされたバッファ ノードに Pod をすぐにスケジュールします。
要件と制限事項
容量バッファには、次の要件と制限事項があります。
- 容量バッファは、アクティブ バッファの場合はバージョン 1.35.2-gke.1842000 以降、スタンバイ バッファの場合はバージョン 1.36.0-gke.2253000 以降を実行している GKE クラスタで使用できます。
- 容量バッファは、Standard ノードプールと 特定のハードウェアを選択する Autopilot ノードプールに ノードベースの課金モデルを使用するワークロードのみをサポートします。容量バッファは、Pod ベースの課金モデルを使用するワークロードをサポートしていません。
- Standard クラスタでは、ノード自動プロビジョニングを有効にすることをおすすめします。ノード自動プロビジョニングにより、クラスタ オートスケーラーは CapacityBuffer のリソース リクエストに基づいて新しいノードプールを作成できます。ノード自動プロビジョニングを有効にしない場合、クラスタ オートスケーラーは既存のノードプールのみをスケールアップします。
- アクティブ容量バッファとスタンバイ容量バッファの両方が Compute Engine の割り当てにカウントされます。
- CapacityBuffer 構成の依存関係（PodTemplate など）でカスタム ComputeClass を選択する場合は、プロビジョニングされたノードでスケジュールするために必要なすべての容認、ノードセレクタ、ランタイム クラス（GKE Sandbox の要件など）を依存関係で定義する必要があります。手順については、カスタム ComputeClass のドキュメントをご覧ください。
スタンバイ バッファには、次の追加の制限があります。
- これらは、ノード自動プロビジョニングが有効になっている Standard クラスタでサポートされています。
- これらは、バージョン 1.36.0-gke.2853000 以降を実行している Autopilot クラスタでサポートされています。
- GPU または TPU がアタッチされたノードはサポートされていません。
- ローカル SSD は対象外です。
- Confidential Google Kubernetes Engine Node はサポートされていません。
- Compute Engine の一時停止と再開のオペレーションに関連する制限事項を理解しておく必要があります。主な制限事項は次のとおりです。
- 顧客指定の暗号鍵（CSEK）で保護されたディスクを持つノードはサポートされていません。
- メモリが 208 GB を超えるノードは対象外です。
- ベアメタル インスタンスはサポートされていません。
- ノード OS が ACPI S3 スリープ信号をサポートしている必要があります。
- 一時停止プロセスの長さはメモリサイズに比例します。
- 再開は、再開に必要な基盤となるリソースの取得可能性によって異なります。
次のステップ
- 容量バッファを実装する方法については、容量バッファを構成するをご覧ください。