容量バッファを使用すると、クラスタ内のアクティブまたはスタンバイの容量バッファの階層を事前に宣言することで、Google Kubernetes Engine（GKE）ワークロードの Pod 起動レイテンシを短縮できます。予備容量を事前に宣言することで、費用対効果の高い方法でワークロードの起動を高速化できます。
このドキュメントでは、容量バッファの仕組みについて説明します。容量バッファを有効にして使用する方法については、容量バッファを構成するをご覧ください。
容量バッファを使用する状況
起動レイテンシの影響を受けやすく、迅速にスケーリングする必要があるアプリケーションには、容量バッファを使用します。トラフィックが急増した場合、アクティブ バッファは、低レイテンシのスケーリング用に設計された事前プロビジョニングされた容量を提供します。トラフィックが継続的に増加している場合、スタンバイ バッファを使用すると、事前プロビジョニングよりも手頃な費用で Pod のスケジューリングを行うことができます。
容量バッファには次の利点があります。
- スケーリング レイテンシを最小限に抑える: アクティブ バッファは実行中のノードを提供するため、レイテンシを最小限に抑えることができます。スタンバイ バッファは迅速に再開されるため、新しいノードよりも早く容量を確保できます。また、アクティブ バッファよりも低コストです。
- 費用対効果の高いオーバープロビジョニング: 容量バッファは、セーフティ ネットの維持に役立ちます。大規模なワークロードの場合、このアプローチは、HorizontalPodAutoscaler（HPA）の使用率目標を下げるなど、他のオーバープロビジョニング方法よりも費用対効果が高くなることがよくあります。これにより、クラスタの成長に合わせてアイドル容量を線形に増やすことができます。
- ワークロードの要件を満たす: 容量バッファの構成を完全に制御できます。オプションには、カスタム DaemonSet を組み込んでイメージをプリロードする、起動時間をチューニングする、ニーズに合わせてバッファサイズを制御するなどがあります。
AI エージェント、AI 推論、セール イベント中の小売アプリケーション、プレーヤー アクティビティのピーク時のゲームサーバーなど、迅速なスケールアップが必要なレイテンシの影響を受けやすいワークロードには、容量バッファをおすすめします。
容量バッファの仕組み
Kubernetes の CapacityBuffer カスタム リソースを使用して、予備容量のバッファを定義することで、容量バッファを実装します。GKE クラスタ オートスケーラーは、CapacityBuffer リソースをモニタリングし、保留中の需要として扱って、予備容量を確保します。バッファで定義されたリソース リクエストを満たすのに十分な容量がクラスタにない場合、クラスタ オートスケーラーは追加のノードをプロビジョニングします。
ワークロードがスケールアップされると、GKE は次の優先順位で使用可能な容量に保留中の Pod をスケジュールします。
- アクティブ バッファでノードを実行する
- まだ一時停止されていないスタンバイ バッファで実行中のノード
- スタンバイ バッファ内の停止中のノード
- 新しくプロビジョニングされたノード
保留中の Pod をできるだけ早くスケジュールするため、GKE は新しいノードをプロビジョニングする前に、使用可能なバッファ容量を使用します。この優先度は、カスタム ComputeClass の優先度の高いルールが新しいノードをプロビジョニングする場合でも適用されます。
バッファ容量は、scalableRef フィールドで参照されているワークロードに制限されません。スケジューリング制約（ノードセレクタ、容認、リソース リクエストなど）がバッファノードの構成と一致する保留中の Pod は、その容量を要求できます。特定のワークロードの容量バッファを予約するには、ワークロードと容量バッファの両方に一致する toleration とノードセレクタ（またはノード アフィニティ）を追加して、ワークロードの分離を構成します。
ワークロードがアクティブ バッファの容量を消費すると、クラスタ オートスケーラーは、互換性のあるスタンバイ バッファ（存在する場合）からノードを再開するか、新しいノードをプロビジョニングして、アクティブ バッファを補充します。ワークロードまたはアクティブ バッファがスタンバイ バッファからノードを消費すると、クラスタ オートスケーラーは新しいノードをプロビジョニングして一時停止することで、スタンバイ バッファを補充します。ワークロードがスケールダウンし、ノードの使用率が低下すると、クラスタ オートスケーラーは、スケールダウン安定化ウィンドウの後に、余分な実行中のノードをスタンバイ バッファに再一時停止するのではなく、削除します。スタンバイ バッファを補充するために、GKE は新しいノードを個別にプロビジョニングして一時停止します。
容量バッファ戦略
レイテンシと費用の要件に基づいて、さまざまなプロビジョニング戦略を使用して容量バッファを構成できます。
Active Buffer
アクティブ バッファは、予約された容量に収まるワークロードの低レイテンシ スケーリングのために、実行中のノードを提供します。ノードはすでに実行されているため、スケールアップ イベント中に Pod を要求する際のレイテンシは最小限に抑えられます。
スタンバイ バッファ
スタンバイ バッファは、一時停止されたノードを提供します。スタンバイ戦略はアクティブ戦略よりも費用対効果が高くなりますが、ワークロードを受け入れる前にノードを再開する際に短い遅延が発生します。
費用と料金
容量バッファは、Standard ノードプールと特定のハードウェアを選択する Autopilot ワークロードに適用される標準のノードベースのコンピューティング費用に加えて、追加料金なしで提供されます。容量バッファは、Pod ベースの課金モデルをサポートしていません。
基盤となるノードの課金は、バッファタイプによって異なります。
- アクティブ バッファ: GKE がアクティブ バッファ容量として維持する実行中の VM に対して、標準のノードベースのコンピューティング料金が課金されます。
- スタンバイ バッファ: VM インスタンスが一時停止している間は、コンピューティング費用（CPU またはメモリ）は発生しません。少額のストレージ料金（VM ブートディスクや保存されたメモリ状態など）と、静的外部 IP アドレスなどの関連リソースの費用が発生します。GKE がスタンバイ VM を再開してワークロードをホストすると、標準のノードベースのコンピューティング料金が適用されます。詳細については、一時停止されたインスタンスの料金をご覧ください。
CapacityBuffer CRD
容量バッファを構成するには、CapacityBuffer CustomResourceDefinition（CRD）を作成します。容量バッファは、さまざまな条件を満たすように構成できます。
- 固定レプリカ: 参照される Pod テンプレートのリソース リクエストに基づいて作成するバッファ Pod の固定数を指定します。この構成は、既知のサイズのバッファを作成する最も簡単な方法です。
- リソース上限: バッファが予約する CPU とメモリの合計量を指定します。コントローラは、参照される Pod テンプレートのリソース リクエストに基づいて、作成するバッファ Pod の数を計算します。
- 割合ベース: バッファサイズを、スケール サブリソースを定義する既存のスケーラブル オブジェクト（Deployment、StatefulSet、ReplicaSet、Job など）の割合として定義します。バッファサイズは、参照ワークロードのスケーリングに応じて動的に調整されます。割合ベースの容量バッファは、Kubernetes のスケール サブリソースを実装するオブジェクトでのみサポートされます。
これらのオプションを組み合わせることもできます。たとえば、replicas と percentage の両方を設定して、GKE が大きい方の値を最小値として使用するようにし、limits を上限として設定します。
詳細については、CapacityBuffer CRD のリファレンス ドキュメントをご覧ください。
ベスト プラクティス
容量バッファを構成する際に費用対効果と応答性を最適化するには、次の推奨事項を参考にしてください。
- 費用を最適化するスタンバイ優先戦略を使用する: ワークロードが約 30 秒の短いスケールアップ遅延を許容できる場合は、スタンバイ バッファを優先します。この戦略では、アクティブな VM の全費用を負担することなく、新しい VM のコールド ノード起動を回避できます。
- レイテンシの影響を受けやすいワークロードにアクティブ バッファを使用する: Pod のスケジューリング時間を可能な限り短くする必要がある場合に、ノードの再開時間を許容できないワークロードにアクティブ バッファを使用します。
- ハイブリッド戦略を使用してパフォーマンスと費用のバランスを取る: 小さいアクティブ バッファと大きいスタンバイ バッファを組み合わせて、費用対効果の高い設定を実現します。GKE は、スタンバイ バッファからノードを再開することでアクティブ バッファの補充を優先します（約 30 秒かかります）。一方、新しいノードはバックグラウンドでプロビジョニングされ、スタンバイ バッファをバックフィルします。この設定により、アクティブな容量で初期の急増を吸収し、低コストのスタンバイ容量を使用して持続的な成長に対応します。
- 初期バーストに合わせてアクティブ バッファのサイズを設定する: スタンバイ バッファのノードが再開する前に発生すると想定される、初期のレプリカの急増をカバーするように、アクティブ バッファのサイズを定義します。
- 持続的な負荷に対応するスタンバイ バッファのサイズを設定する: 想定される負荷の増加を十分にカバーできるサイズのスタンバイ バッファを定義し、コールドスタート時でもバックグラウンドでバッファが補充されるようにします。十分なサイズのスタンバイ バッファがあれば、Pod のスケジューリングにおける最大レイテンシを、ノードの再開にかかる時間（約 30 秒）まで短縮できます。容量バッファが使用され始め、補充されると、新しいバッファノードは一時停止する前にアクティブ状態に移行します。これにより、負荷が長期間続く間、アクティブな容量を増やすことができます。
- バッファ シミュレータを使用する: さまざまなアクティブ バッファサイズとスタンバイ バッファサイズを試して、特定のワークロードに最適な結果を得ます。https://github.com/gke-labs/buffers-simulator でオープンソースの GKE バッファ シミュレータを使用して、ワークロードのスケーリング動作のシミュレーションを実行し、バッファサイズ ルールを微調整してパフォーマンス目標を達成します。
- ワークロードをゼロからスケーリングする際のコールド スタート レイテンシを短縮する: HPA を使用してゼロにスケールダウンし、ゼロからスケールアップするワークロード（
minReplicas: 0）を容量バッファと組み合わせます。需要が増加し、ワークロードがゼロからスケールアップすると、GKE は新しいコンピューティング ノードのプロビジョニングを待つことなく、事前にウォームアップされたバッファノードに Pod をすぐにスケジュールします。 - Standard クラスタの
optimize-utilization自動スケーリング プロファイルを検討する: 容量バッファはすでに予備のヘッドルームを維持しているため、optimize-utilization自動スケーリング プロファイル（--autoscaling-profile=optimize-utilization）を構成して、需要が減少した後にクラスタ オートスケーラーが使用率の低いノードをより迅速にスケールダウンするようにできます。このプロファイルでは、Pod がノードにさらに密にパッキングされるため、有効にする前に、より密なビンパッキングがワークロードの可用性要件に適合するかどうかを評価してください。
バッファサイズを計算する
アクティブ バッファとスタンバイ バッファを組み合わせると、トラフィックの急増を吸収するために必要なバッファ レプリカ（シミュレートされたバッファ Pod）の数を推定できます。この見積もりは、1 秒あたりの Pod の予想スケールアップ率、スタンバイ ノードの再開レイテンシ、コールドノードの作成レイテンシを使用して計算します。これらのレイテンシは、VM マシンシリーズとノード構成によって異なります。たとえば、スタンバイ ノードの再開レイテンシは通常 30 ～ 35 秒で、新しいノードの作成レイテンシは通常 60 ～ 120 秒です（マシンシリーズによって異なります）。クラスタの実際のレイテンシを測定するには、起動レイテンシの指標をモニタリングするをご覧ください。
スタンバイ ノードの再開中に作成された Pod をカバーするアクティブ バッファサイズを計算します。
\[ \text{Active buffer replicas} = \text{Expected scale-up rate} \times \text{Standby node resume latency} \]
新しいコールドノードのプロビジョニングが完了するまでに作成される残りの Pod をカバーするスタンバイ バッファサイズを計算します。
\[ \text{Standby buffer replicas} = (\text{Expected scale-up rate} \times \text{Cold node creation latency}) - \text{Active buffer replicas} \]
たとえば、ワークロードが 1 秒あたり 2 Pod でスケールアップし、スタンバイ ノードの再開に 30 秒、新しいコールドノードのプロビジョニングに 90 秒かかる場合、次のようになります。
- アクティブ バッファには、スパイクの最初の 30 秒を吸収するために \( 2 \times 30 = 60 \) 個のレプリカが必要です。
- クラスタ オートスケーラーがバックグラウンドで新しいコールドノードをプロビジョニングしてバッファを補充する間、残りの 60 秒をカバーするために、スタンバイ バッファには \( (2 \times 90) - 60 = 120 \) レプリカが必要です。スパイクが同じレートで 90 秒を超えて続く場合、これらの補充されたノードは、待機時間なしで受信 Pod を処理する準備が整います。
ワークロードのスケーリング パターンに対してこれらの見積もりをテストするには、GKE バッファ シミュレーターを使用してシミュレーションを実行します。
要件と制限事項
容量バッファには、次の要件と制限があります。
- 容量バッファは、アクティブ バッファの場合はバージョン 1.35.2-gke.1842000 以降、スタンバイ バッファの場合はバージョン 1.36.0-gke.2253000 を実行している GKE クラスタで使用できます。
- 容量バッファは、Standard ノードプールと特定のハードウェアを選択する Autopilot ノードプールにノードベースの課金モデルを使用するワークロードのみをサポートします。容量バッファは、Pod ベースの課金モデルを使用するワークロードをサポートしていません。
- Standard クラスタでは、ノードプールの自動作成を有効にすることをおすすめします。ノードプールの自動作成により、クラスタ オートスケーラーは CapacityBuffer のリソース リクエストに基づいて新しいノードプールを作成できます。ノードプールの自動作成を有効にしない場合、クラスタ オートスケーラーは既存のノードプールのみをスケールアップします。
- アクティブな容量バッファとスタンバイ容量バッファでは、割り当ての消費方法が異なります。
- アクティブなバッファでノードを実行すると、vCPU、メモリ、ディスク、IP アドレスの Compute Engine の割り当てにカウントされます。
- スタンバイ バッファ内の一時停止中のノードは、一時停止中は Compute Engine の vCPU またはメモリの割り当てにカウントされません。ただし、IP アドレスの割り当てとディスクの割り当て（一時停止された VM のメモリの保存に使用される
Persistent disk standard (GB)の割り当てを含む）は引き続き消費されます。 - Kubernetes では、アクティブなスタンバイ バッファ ユニットと一時停止中のスタンバイ バッファ ユニットの両方が、バッファ Pod が実行されているかのように、Namespace の Kubernetes リソース割り当てにカウントされます。
- CapacityBuffer 構成の依存関係（PodTemplate など）でカスタム ComputeClass を選択する場合、依存関係では、プロビジョニングされたノードでスケジュールするために必要な toleration、ノードセレクタ、ランタイム クラス（GKE Sandbox の要件など）を定義する必要があります。手順については、カスタム ComputeClass のドキュメントをご覧ください。
スタンバイ バッファには、次の追加の制限があります。
- ノードプールの自動作成が有効になっている Standard クラスタでサポートされています。
- バージョン 1.36.0-gke.2853000 以降を実行している Autopilot クラスタでサポートされています。
- GPU または TPU がアタッチされたノードはサポートされていません。
- ローカル SSD はサポートされていません。
- スタンバイ バッファは、ノードのストレージに顧客管理の暗号鍵（CMEK）をサポートしていますが、ノードのメモリは、一時停止中に Google-owned and Google-managed encryption keys を使用して暗号化されます。
- Confidential Google Kubernetes Engine Node はサポートされていません。
- スタンバイ バッファは、GKE の Container-Optimized OS と Ubuntu ノードイメージのみをサポートします。Windows Server ノードはサポートされていません。カスタム ノード オペレーティング システムを使用する場合は、OS が Compute Engine の一時停止と再開のオペレーションをサポートしていることを確認する必要があります。
- Compute Engine の一時停止と再開オペレーションに関連する制限事項を理解しておく必要があります。主な制限事項は次のとおりです。
- 顧客指定の暗号鍵（CSEK）で保護されたディスクを持つノードはサポートされていません。
- 208 GB を超えるメモリを備えたノードはサポートされていません。
- ベアメタル インスタンスはサポートされていません。
- ノード OS は ACPI S3 スリープ信号をサポートしている必要があります。
- 一時停止プロセスの長さはメモリサイズに比例します。
次のステップ
- 容量バッファを実装する方法については、容量バッファを構成するをご覧ください。