GKE スタンバイ バッファの概要: 予算を抑えながらノードの起動時間を短縮

※この投稿は米国時間 2026 年 6 月 2 日に、Google Cloud blog に投稿されたものの抄訳です。

アプリケーション オーナーやプラットフォーム エンジニアは、長い間、難しい選択を迫られてきました。それは、オーバー プロビジョニングに過剰な費用をかけて迅速な起動を保証するか、費用を最小限に抑える代わりに起動に時間がかかる「コールド スタート」に耐えるか、という選択です。

このたび、この問題を解決するソリューションとして、Google Kubernetes Engine スタンバイ バッファの提供を開始いたします。これは、今年初めにリリースした GKE アクティブ バッファを基盤としています。GKE アクティブ バッファは、Kubernetes CapacityBuffers API のネイティブ バージョンであり、すぐに利用できる容量を簡単にプロビジョニングすることでトラフィックの急増に対処できるほか、新しい Pod の起動にかかるレイテンシをほぼゼロにすることができます。しかし、アクティブ バッファには、パフォーマンスと費用のトレードオフが生じるという課題が依然として存在していました。新しい GKE スタンバイ バッファは、GKE クラスタ用に低コストの一時停止された容量バッファを維持することで、この課題を解決します。GKE スタンバイ バッファを利用すると、費用オーバーヘッドを 1 桁台前半という無視できるレベルに抑えつつ、ワークロードのスケジューリングをほぼ即座に実現できます。これは、汎用ワークロード、エージェント型ワークロード、その中間的なものなど、あらゆる種類のワークロードに有用です。

問題: 高いコストとレイテンシ

従来、標準的な Kubernetes による自動スケーリングは効果的ではありましたが、処理速度が遅いという課題がありました。トラフィックの急増やバッチジョブが発生すると、クラスタのオートスケーラーが新しいノードをプロビジョニングする必要があるため、Pod は保留状態になります。この遅延を防ぐには、HorizontalPodAutoscaler（HPA）のしきい値を下げる、あるいは、Balloon Pod で管理するといった、費用のかかる煩雑な回避策に頼るしかありませんでした。

• Balloon Pod の管理は運用が複雑であり、正しく機能させるには、優先度クラスやリソース リクエストを手動で構成し、継続的にメンテナンスする必要がある。

• HPA のしきい値を下げると、ノードプールのサイズに比例して空き（無駄な）スペースが増加する。

GKE のアクティブ バッファとスタンバイ バッファの両方を利用すると、容量を宣言的に定義できるようになるため、こうした煩雑で運用上の負担が大きい回避策は不要になります。

さらに、GKE スタンバイ バッファでは、ノードの状態がディスクに保存されるためインフラストラクチャ費用を削減できます。これにより、コンピューティングとメモリの費用を削減して、永続ディスクと IP アドレスの費用のみを維持できます。また、アクティブ バッファと組み合わせることで、オーバー プロビジョニングと同等のパフォーマンスを実現しながら、非常に手頃な価格で、ほぼ瞬時の Pod スケジューリングが可能になります。

アクティブ バッファとスタンバイ バッファの連携

すべての GKE キャパシティ バッファは、YouTube などのプラットフォームにおける動画ストリーミングと同様の原理で動作します。GKE は、差し迫った需要に先立って利用可能な容量をプロアクティブにプロビジョニングおよび管理することで（動画コンテンツの事前ダウンロードのように）、必要なときにリソースを確実に利用できるようにします。

今回のリリースにより、この 2 種類のキャパシティ バッファを連携できるようになりました。

• アクティブ バッファ: クラスタ オートスケーラーが、既存のクラスタ ノード上で事前定義された数の Pod に対応する十分な容量を確保し、必要に応じて追加のノードをプロビジョニングします。レイテンシの影響を受けやすいワークロードの容量を確保する場合は、このすぐに使用できるバッファを選択します。

• スタンバイ バッファ: ノードは事前にプロビジョニングされ、Kubernetes DaemonSet などの必要なコンポーネントで完全に初期化されます。イメージをプリロードする時間が確保されますが、その後は一時停止されます。その間、基盤となるコンピューティング容量は解放されて費用が節約されます。需要が急増すると、これらのノードは新しいノードを作成するよりも 2～3 倍速く再開され、コールド スタートと常時利用可能な容量とのギャップを埋めます。

アクティブ バッファは、スタンバイ バッファが再開されるまでの初期の需要急増をカバーします。システムは、スタンバイ バッファからアクティブ バッファへの補充を優先します。スタンバイ バッファは負荷の増加に対応し、ノードのコールド スタートによる遅延を防ぎます。スタンバイ バッファが補充されると、まず構成可能な時間だけアクティブ状態になり、その後一時停止されます。これにより、トラフィック負荷が持続している間、アクティブな容量が増加します。

初期ベンチマーク

Google のテストでは、スタンバイ バッファを使用することで、完全なオーバー プロビジョニングと比較して最大 90% の費用削減を実現しつつ、Agent Sandbox のスケジュール設定のレイテンシを 1 秒未満に抑えることができました。

ビジネスニーズに合わせて最適化

多くの企業は、業務を合理化しながらリソース消費を最適化するという絶え間ないプレッシャーにさらされています。Google は、散発的に急増するワークロードの管理には、よりスマートなツールが必要であることを認識し、スタンバイ バッファを早急に提供できるよう取り組んできました。エージェント、バッチジョブ、CI/CD パイプライン、ゲームサーバー、急激に変動するワークロードなどの実行に、GKE のキャパシティ バッファを使用することで、パフォーマンスと費用のバランスを動的に調整できるほか、トラフィックの急増に対する「保険」を、高額な保険料を支払うことなく定義できます。GKE スタンバイ バッファを使用すると、以下のことが可能になります。

1. コールド スタートの回避: スタンバイ バッファによって一時停止されたノードは、新しいノードをプロビジョニングする場合に比べて 2～3 倍速く再開されるため、トラフィックの急増時や持続的な負荷の下での Pod スケジューリング レイテンシが短縮されます。

2. 費用削減: スタンバイ バッファでは基盤となる VM が一時停止状態になるため、アクティブ容量に比べて大幅に低コストです。コンピューティング時間全体ではなく、ストレージと IP アドレスの費用を支払うことになります。

3. 宣言型コントロールの実現: 複雑な Balloon Pod による回避策を、シンプルでネイティブな宣言型 CapacityBuffers API に置き換えます。必要な容量を明示的に指定するだけで、残りの処理は GKE に任せることができます。

- Unico、チーフ アーキテクト、Pedro Spagiari 氏

使ってみる

パフォーマンス向上と費用削減に向けて踏み出しましょう。

• まず、クラスタに CapacityBuffer リソースを定義し、目標とするバッファサイズを指定します。

• 持続的な負荷に対する Pod スケジューリング レイテンシを短縮し、予測不可能な即時の容量ニーズに対応できるよう、スタンバイ バッファとアクティブ バッファのバランスを取ります。

例として、カスタム ComputeClass を使用しながら Deployment のバッファを構成する方法を見てみましょう。

基本設定

まず、基本設定として Namespace を作成します。

次に、カスタム ComputeClass を作成します（省略可）。

バッファユニットのサイズを定義する

PodTemplate をバッファユニットのサイズの基準として使用できます。また、特定の Deployment や scale subResource を定義する任意のオブジェクトに対してバッファを作成することもできます。

バッファを作成する

最後に、PodTemplate を参照して  CapacityBuffer オブジェクトを作成します。ここでは、50 個の CPU と 50 GB の RAM のスタンバイ バッファを作成します。

（省略可）アクティブ バッファの例: 5 個の CPU と 5 GB の RAM

最後に、上記のオブジェクトをクラスタに適用します。これで設定は完了です。

バッファによって予約されたスペースでスケジュールできる既存および将来の Deployment は、Pod スケジューリング レイテンシの短縮によるメリットを享受できます。

バッファをテストする

以下の方法でバッファのステータスを確認できます。Kubernetes では、一時停止されたノードは  Suspended という条件で識別できます。

以下のような出力が表示されるので、スタンバイ バッファが一時停止されるまで待ちます。

バッファをテストするには、Deployment を作成してスケールします。

この Deployment を 2 つのレプリカにスケーリングすると、それらはアクティブバッファに割り当てられ、即座にスケジューリングされます。その後、アクティブ バッファは、スタンバイ バッファからすぐに補充されます。同時に、スタンバイ バッファは新しいノードのプロビジョニングを開始します。

この Deployment をさらに 50 個のレプリカにスケールすると、ノードが再開されたときに、すべてのレプリカがスタンバイ バッファにスケジュールされます。スタンバイ バッファを補充するためにプロビジョニングされた新しいノードは、短時間だけアクティブ バッファとして機能し、一時的にスタンバイ能力を増強します。したがって、この間に、この Deployment を 100 個のレプリカにさらにスケールすると、新しいレプリカが即座にスケジューリングされるメリットをより実感できるかもしれません。

GKE スタンバイ バッファのベスト プラクティス

GKE スタンバイバッファを使用する際は、以下の点を考慮してください。

1. 想定される負荷の増加を十分にカバーできるサイズのスタンバイ バッファを定義し、コールドスタート時でもバックグラウンドでバッファが補充されるようにします。十分なサイズのスタンバイ バッファがあれば、Pod のスケジューリングにおける最大レイテンシを、ノードの再開にかかる時間（約 30 秒）まで短縮できます。

2. バッファが使用され始め、補充されると、新しいバッファノードは一時停止する前に、まずアクティブ状態になります。これにより、負荷が長期間続く間、アクティブな容量を増やすことができます。

3. アプリケーションで可能な限り低い Pod スケジューリング レイテンシが必要な場合は、スタンバイ バッファのノードが再開できるまでに発生すると想定される、初期のトラフィック急増をカバーするのに十分なアクティブ バッファ サイズを定義します。システムは、スタンバイ バッファを消費することでアクティブ バッファの補充を優先します。十分なサイズのアクティブ バッファとスタンバイ バッファを確保することで、オーバー プロビジョニングに比べて大幅な低コストを実現できるほか、Pod スケジューリング レイテンシも短縮できます。

4. ワークロードに適した結果が得られるまで、さまざまなバッファサイズを試すことを推奨します。

参考までに、パフォーマンス目標を達成するために必要なバッファサイズを見積もることができるシミュレータをご用意しました。https://github.com/gke-labs/buffers-simulator から入手してご利用ください。

まとめ

GKE のアクティブ バッファとスタンバイ バッファは、ウォーム状態とスタンバイ状態のキャパシティ バッファを維持することで、低レイテンシかつ費用対効果の高いワークロード スケーリングを実現するネイティブなソリューションです。低速なノードのコールドスタートを回避することで、パフォーマンスが重要なアプリケーションにおいて突発的なトラフィックの急増に対処できるようになります。また、Balloon Pod のような複雑な手動の回避策を、シンプルで宣言的な API に置き換えることができるほか、固定、割合ベース、またはリソース上限ベースのバッファリング戦略によって、ピーク時のオーバー プロビジョニングを行うことなく、費用対効果の高い方法で厳格なサービスレベル目標を維持できます。

スタンバイ バッファは、バージョン 1.36.0-gke.2253000 以降を実行している GKE クラスタで利用できます。バッファの使用を開始するには、こちらのドキュメントをご覧ください。

- Google Kubernetes Engine、プロダクト マネージャー、Eyal Yablonka

- Google Kubernetes Engine、スタッフ ソフトウェア エンジニア、Konrad Kurdej