容量バッファを使用すると、クラスタ内のアクティブまたはスタンバイの容量バッファの階層を事前に宣言できるため、Google Kubernetes Engine（GKE）ワークロードの Pod の起動レイテンシを短縮できます。予備容量を事前に宣言することで、費用対効果の高い方法でワークロードを迅速に起動できます。
このドキュメントでは、容量バッファの仕組みについて説明します。容量バッファを有効にして使用する方法については、容量バッファを構成するをご覧ください。
容量バッファを使用する場合
容量バッファは、起動レイテンシの影響を受けやすく、迅速なスケーリングが必要なアプリケーションに使用します。トラフィックが急増した場合、アクティブ バッファは、低レイテンシのスケーリング用に事前にプロビジョニングされた容量を提供します。トラフィックが継続的に増加している場合、スタンバイ バッファは、事前プロビジョニングよりも手頃な費用で Pod のスケジューリングを提供します。
容量バッファには次の利点があります。
- スケーリング レイテンシの最小化: アクティブ バッファは実行中のノードを提供し、 レイテンシを最小限に抑えます。スタンバイ バッファは迅速に再開され、アクティブ バッファよりも低コストで、新しいノードよりも迅速に容量を利用できます。
- 費用対効果の高いオーバー プロビジョニング: 容量バッファは セーフティ ネットの維持に役立ちます。大規模なワークロードの場合、このアプローチは、クラスタの成長に伴ってアイドル状態の容量が直線的に増加する可能性がある他のオーバー プロビジョニング方法（HorizontalPodAutoscaler（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 バッファ シミュレータを使用してワークロードのスケーリング動作のシミュレーションを実行し、バッファサイズ設定ルールを微調整してパフォーマンス目標を達成します。
要件と制限事項
容量バッファには次の要件と制限があります。
- 容量バッファは、アクティブ バッファの場合はバージョン 1.35.2-gke.1842000 以降、スタンバイ バッファの場合はバージョン 1.36.0-gke.2253000 以降を実行している GKE クラスタで使用できます。
- 容量バッファは、特定のハードウェアを選択する Standard ノードプールと Autopilot node pools that select specific hardwareに node-based billing modelを使用するワークロードのみをサポートします。容量バッファは、 Pod ベースの課金モデルを使用するワークロードをサポートしていません。
- Standard クラスタでは、 ノード自動プロビジョニングを有効にすることをおすすめします。ノード自動プロビジョニングにより、クラスタ オートスケーラーは CapacityBuffer のリソース リクエストに基づいて新しいノードプールを作成できます。ノード自動プロビジョニングを有効にしない場合、クラスタ オートスケーラーは既存のノードプールのみをスケールアップします。
- アクティブ容量バッファとスタンバイ容量バッファの両方が Compute Engine の割り当てにカウントされます。
- CapacityBuffer 構成の依存関係（PodTemplate など）がカスタム ComputeClass を選択する場合、依存関係では、プロビジョニングされたノードでスケジューリングするために必要な toleration、ノードセレクタ、ランタイム クラス（GKE Sandbox の要件など）を定義する必要があります。手順については、 カスタム ComputeClass のドキュメントをご覧ください。
スタンバイ バッファには、次の追加の制限があります。
- ノード自動プロビジョニングが有効になっている Standard クラスタでサポートされています。
- バージョン 1.36.0-gke.2853000 以降を実行している Autopilot クラスタでサポートされています。
- GPU または TPU が接続されたノードはサポートされていません。
- ローカル SSD は対象外です。
- Confidential Google Kubernetes Engine ノードはサポートされていません。
- Compute Engine の一時停止と再開のオペレーションに関連する制限事項を理解しておく必要があります。
主な制限事項は次のとおりです。
- 顧客指定の暗号鍵（CSEK）で保護されたディスクを持つノードはサポートされていません。
- 208 GB を超えるメモリを持つノードは対象外です。
- ベアメタル インスタンスはサポートされていません。
- ノード OS は ACPI S3 スリープ信号をサポートしている必要があります。
- 一時停止プロセスの長さはメモリサイズに比例します。
- 再開は、再開に必要な基盤となるリソースの取得可能性によって異なります。
次のステップ
- 容量バッファを実装する方法については、容量バッファを構成するをご覧ください。