GKE Active Buffer:ノードプロビジョニング遅延を解消

現代のクラウドネイティブシステムはスケールすることを前提に設計されていますが、その「スケールの速さ」こそが、ユーザーにシームレスな体験を届けられるか、待たされる不満を与えてしまうかの分かれ目になります。フラッシュセールが始まったECサイト、プレイヤーが一気に流入するゲームプラットフォーム、突如として大量のリクエストを処理するAI推論サービス——いずれの場合も、ハードウェアが追いつくまでの数分を待つ余裕はなく、インフラには秒単位の応答が求められます。

GKEは以前から、Cluster AutoscalerやHorizontal Pod Autoscaler(HPA)といった強力なツールを提供し、こうした変動に対応してきました。しかし、どれほど最適化されたクラスターであっても、ある根本的な課題によって長らく足を引っ張られてきました。それが、ノードプロビジョニング遅延です。

ワークロードが拡大するにつれて、待ち時間は次のような複数の要因によって積み重なっていきます。

ノードの初期化: クラスターへの参加とDaemonSetの起動。
イメージのプル: 数ギガバイト規模のコンテナイメージのダウンロード。
アプリのウォームアップ: アプリケーションの状態の初期化や、AIモデルのGPUメモリへのロード。

大規模なワークロードでは、こうした遅延によりPodが数分間Pending状態のままとなり、SLO未達やユーザー体験の低下につながることがあります。

従来の回避策と、その限界

これまでGKEユーザーは、スケールアウト遅延に対処するために、2つの不完全な手法に頼ってきました。

HPAターゲットを下げてオーバープロビジョニングする方法: HPAの使用率しきい値を保守的に設定し、クラスターに常に余裕を持たせるアプローチです。難点は、ワークロードの増加に比例してコストが膨らむこと。常に80%ではなく60%の使用率で稼働させるクラスターは、大規模なデプロイメントでは20〜30%ほどコストが上振れする可能性があります。

Balloon Pod(バルーンPod): 低優先度のプレースホルダーPodを配置してノード容量を確保し、本来のワークロードが到着したタイミングで退避させる手法です。対象ワークロードがスケールアップすると、GKEは優先度の低いプレースホルダーPodを退避させ、その場所に新しいレプリカをスケジュールします。効果はあるものの、PriorityClassの慎重な設定と継続的なチューニングが欠かせません。トラフィックパターンの変化に伴ってしきい値がずれていくと、保護機能は気づかぬうちに劣化していきます。

どちらの方法にも、より根深い共通の課題があります。本番トラフィックの変化に追随して効果を保ち続けるには、運用面で常に手をかける必要があるという点です。

GKE Capacity Bufferの登場

2026年4月1日、GoogleはGKE Active Bufferのプレビュー提供を発表しました。これは、Kubernetes OSSのCapacityBuffer APIをGKEネイティブに実装したものです。

複雑なPriorityClassやプレースホルダーデプロイメントを管理する代わりに、ユーザーはCapacityBufferカスタムリソースで要件を定義します。これにより、GKE Cluster Autoscalerは常にウォーム状態で未使用の容量をセーフティネットとして維持するようになります。

Active Bufferの仕組み

GKE Cluster Autoscalerは、CapacityBufferを保留中の需要として扱います。実在しない仮想Podを使って容量を予約し、Autoscalerがそれを保留中の需要として追跡することで、事前にノードがプロビジョニングされる仕組みです。対象ワークロードがスケールアップすると、GKEは利用可能なバッファ容量上で即座にスケジューリングを行うため、ノードプロビジョニング遅延は発生しません。

その後、バッファは再びPending状態に戻り、Autoscalerがバックグラウンドで代替バッファをプロビジョニングします。

柔軟なバッファリング戦略

Active Bufferでは、維持する余剰容量の指定方法を3通りから選べます。

1. 固定レプリカ数

もっともシンプルなオプションです。ワークロードの規模に関係なく、一定数のバッファユニットを維持します。

apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: fixed-replica-buffer
  namespace: my-app
spec:
  podTemplateRef:
    name: buffer-unit-template
  replicas: 3

この設定は、「このサイズのPodを3つ分、常にすぐ使える状態で確保しておく」とGKEに指示するものです。

2. パーセンテージベース

既存のワークロードに比例してバッファがスケールします。本番デプロイメントが拡大すれば、バッファも自動的に拡大するため、手動調整は不要です。

apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: percentage-buffer
  namespace: my-app
spec:
  scalableRef:
    apiGroup: apps
    kind: Deployment
    name: my-production-deployment
  percentage: 20

デプロイメントが50レプリカから100レプリカにスケールすれば、バッファも10ユニットから20ユニットへ自動的に調整されます。

3. リソース上限

バッファが消費できる総コンピューティングリソースに上限を設けることで、コストを予測可能に保てます。GKEは、PodTemplateのリソースリクエストと指定された上限をもとに、維持すべきバッファPod数を算出します。

apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: resource-limit-buffer
  namespace: my-app
spec:
  podTemplateRef:
    name: buffer-unit-template
  limits:
    cpu: "20"
    memory: "20Gi"

Active Bufferが向いているのは?

Active Bufferは、急速なスケールアップを必要とする、レイテンシに敏感なワークロードに最適です。

AI推論サービス — コールドスタートのレイテンシが、そのままユーザー体験の低下やSLO未達につながる領域。
セールイベント中のリテールアプリケーション — フラッシュセール、限定販売、季節的なスパイクなど、トラフィックが数秒で急増するケース。
金融サービス — 市場の開場・閉場、日次バッチ処理など。
ゲームプラットフォーム — プレイヤーアクティビティのピーク、新作タイトルのリリース。
リアルタイムAPI — エンドユーザーレイテンシが契約で定められているサービス全般。

一方、バッチ処理ジョブや、起動レイテンシの影響を受けにくいワークロードには、Active Bufferは推奨されません。

プロ仕様の構成:Active Buffer + カスタムComputeClass

Active Bufferは、GKEのComputeClassesと組み合わせることで、さらに真価を発揮します。ComputeClassは、優先順位付けされたノード構成のセットを記述するKubernetesカスタムリソースです。

GKEがオートスケールで新しいノードをプロビジョニングする際は、ComputeClassで定義された優先順位ルールに従い、優先するハードウェアが利用できなければ次の選択肢にフォールバックします。

ComputeClassとCapacity Bufferを組み合わせれば、ウォーム状態の容量がワークロードに必要な特定のハードウェア上に確保されます。単に空いているノードに置かれるわけではありません。これは特にGPU/TPU推論ワークロードで価値を発揮します。AIサービングアプリケーションは特定のアクセラレータ構成を必要とすることが多く、nvidia-l4 GPUを要するワークロードに対して、標準CPUノード上の汎用Capacity Bufferでは役に立たないからです。

以下の例では、L4 GPUノードを3台事前にウォーム状態で確保し、オンデマンドを優先しつつ、利用できない場合はSpotにフォールバックします。

# L4 GPUを優先し、Spot VMにフォールバックするComputeClass
apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: inference-compute
spec:
  nodePoolAutoCreation:
    enabled: true
  priorities:
  - gpu:
      type: nvidia-l4
      count: 1
    spot: false
  - gpu:
      type: nvidia-l4
      count: 1
    spot: true
  - machineFamily: n4
    minCores: 16
  whenUnsatisfiable: DoNotScaleUp
---
# バッファPod用にComputeClassを要求するPodTemplate
apiVersion: v1
kind: PodTemplate
metadata:
  name: inference-buffer-template
  namespace: inference-ns
template:
  metadata:
    labels:
      cloud.google.com/compute-class: inference-compute
  spec:
    terminationGracePeriodSeconds: 0
    nodeSelector:
      cloud.google.com/compute-class: inference-compute
    tolerations:
    - key: cloud.google.com/compute-class
      operator: Equal
      value: inference-compute
      effect: NoSchedule
    containers:
    - name: buffer-container
      image: registry.k8s.io/pause:3.9
      resources:
        requests:
          cpu: "4"
          memory: "16Gi"
---
# 推論対応の事前ウォームノードを3台維持するCapacityBuffer
apiVersion: autoscaling.x-k8s.io/v1beta1
kind: CapacityBuffer
metadata:
  name: inference-buffer
  namespace: inference-ns
spec:
  podTemplateRef:
    name: inference-buffer-template
  replicas: 3

さらに踏み込むなら: Capacity Bufferはノードプロビジョニング遅延を解消しますが、イメージのプル時間までは考慮されません。サブ秒レベルのレイテンシを目指すなら、Active BufferとImage Streamingの併用がおすすめです。

要件と前提条件

Active Bufferを有効化する前に、次の点を確認してください。

GKEバージョン: クラスターバージョン1.35.2-gke.1842000以降が必要です。
課金モデル: ノードベース課金のワークロードでのみサポートされます(PodベースのAutopilot Pod単位課金には非対応)。
ノード自動プロビジョニング: 推奨(必須ではありません)。有効にすると、バッファを補充する際にAutoscalerが新しいノードプールを作成できるようになります。無効の場合、Autoscalerは既存のノードプールのスケールアップしか行えません。
提供ステータス: 現在プレビュー段階で、Pre-GA Offerings Termsが適用されます。

コストに関する考慮事項

Active Bufferはスケーリング遅延を解消する一方で、アイドル状態のVMを稼働させ続けるため、実費が発生します。ただし、広範なオーバープロビジョニングに比べれば格段に効率的です。クラスター全体を無駄に60%の使用率で稼働させるのではなく、アクティブなノードを80〜90%まで引き上げつつ、必要最小限で目的を絞ったセーフティ用のバッファを維持できます。

バッファ容量にSpot VMを使えば、コストをさらに抑えられます。Spot VMはオンデマンドインスタンスよりも大幅に安価なため、ワークロードがプリエンプションリスクを許容できるなら、バッファのオーバーヘッドは最小限に抑えられます。

まとめ

Active Bufferは、サブ秒スケーリングの実現に向けた大きな一歩です。Balloon Podの運用上の複雑さを、シンプルで宣言的なCapacityBufferカスタムリソースに置き換えることで、GKEはプラットフォームエンジニアに、レイテンシに敏感なワークロード向けのウォーム容量を確保するための、ネイティブで保守しやすい手段を提供します。

設定例やベストプラクティスについては、GKE Capacity Buffer How-toガイドをご覧ください。