GKEがカスタムメトリクスにネイティブ対応:CPU・メモリを超える賢いオートスケーリング

Kubernetesのオートスケーリングは通常、Horizontal Pod Autoscaler(HPA)を利用します。HPAはデフォルトでCPUやメモリといったリソース使用率に基づいてworkloadsをスケールします。多くのケースで有効に機能しますが、アプリケーションが実際に受けている負荷を必ずしも反映できるわけではありません。

たとえば、次のようなケースです。

• Web APIに大量のリクエストが集中していても、CPU使用率は高くない場合があります。
• キュー処理サービスは、バックログが増えるほど多くのワーカーが必要になります。
• AI推論workloadsは、CPUよりもGPU使用率に依存する傾向があります。
• ストリーミングサービスは、秒間リクエスト数に応じたスケーリングが求められます。

こうしたシナリオでは、インフラ指標ではなくアプリケーションレベルのメトリクスに基づくスケーリングが必要です。

Kubernetesはカスタムメトリクスによるオートスケーリングをサポートしていますが、従来は次のような追加コンポーネントを実装する必要がありました。

• Prometheusアダプタ — PrometheusメトリクスをKubernetes Metrics APIに橋渡しする別途のデプロイメント
• カスタムメトリクスパイプライン — アプリケーションとHPAの間に挟まる取り込み・保存・クエリの各レイヤー
• 複雑なIAMおよびサービスアカウント設定 — 特にGKEのようなマネージド環境で必須

出典:Gemini Nano Banana Pro

これらのコンポーネントは運用負荷が高く、チームはKubernetesバージョン間でのアダプタ互換性の管理、マルチホップなメトリクスパイプラインのデバッグ、インフラレイヤー由来のレイテンシへの対処に追われていました。この煩雑さが導入の足かせとなり、結局CPUベースのスケーリングに戻ってしまうチームも少なくありませんでした。

GKEはカスタムメトリクスを公開するためのネイティブ統合を提供するようになり、アプリケーションがオートスケーリングシステムにメトリクスを渡す手順が大幅に簡素化されました。外部アダプタや監視システムを経由する必要はなく、Podから直接カスタムメトリクスを収集してHPAに供給できます。

これによりオートスケーリングシステムは、リクエストスループットやリソース使用率といった実際のアプリケーション挙動に応じて反応できるようになります。アプリケーションメトリクスをスケーリング戦略に組み込むハードルが大きく下がりました。

出典:Gemini Nano Banana Pro

この新機能は、AutoscalingMetricというリソースを通じて動作します。

このリソースで定義する内容は次のとおりです。

• どのPodがメトリクスを公開するか(ラベルセレクタで指定)
• メトリクスエンドポイントの場所(ポートとパス)
• 収集する具体的なメトリクス
• メトリクスをオートスケーリングシステムへエクスポートする方法

定義が完了すると、GKEはこれらのメトリクスを収集し、ロードバランサーやオートスケーラーといったコンポーネントから利用できるようにします。

主な要件は以下のとおりです。

• メトリクスをHTTPエンドポイントで公開していること
• フォーマットがPrometheus標準に準拠していること
• サポート対象はgaugeメトリクスのみ
• クラスターあたり最大20種類のメトリクスを公開可能

Gaugeとその他のメトリクスタイプの違い: gaugeは任意の時点で増減し得る値を表します(例:現在のキュー長 = 45)。一方、counterは増加のみで(例:処理済みリクエスト総数 = 10,432)、オートスケーリングのターゲットとして直接利用するには適しません。アプリケーションがcounterしか公開していない場合は、本機能で利用する前にgauge(例:算出されたリクエストレート)を別途導出する必要があります。

メトリクスが登録されると、GKEはその値を継続的に読み取り、スケーリングロジックに反映します。

一通り完結した例で具体的に見ていきましょう。

シナリオ: バックグラウンドワーカーサービスがキューからジョブを処理しています。CPU使用率ではなく、現在のキュー長に応じてワーカーPodの数をスケールしたいケースです。

ステップ1:アプリケーションからメトリクスを公開する

Prometheus形式のgaugeメトリクスを/metricsエンドポイントで公開するアプリケーションをデプロイします。

# HELP job_queue_length Current number of jobs waiting in the queue
# TYPE job_queue_length gauge
job_queue_length 45

ここではメトリクスがhttp://worker-service:9090/metricsで取得できるものとします。

ステップ2:AutoscalingMetricリソースを作成する

GKEにメトリクスの取得先とエクスポート方法を伝えるAutoscalingMetricリソースを定義します。

apiVersion: autoscaling.gke.io/v1beta1
kind: AutoscalingMetric
metadata:
  name: worker-queue-metric
  namespace: default
spec:
  selector:
    matchLabels:
      app: job-worker #The label name and value matching the Pods
  endpoints:
  - port: 9090 #The metrics port number
    path: /metrics #The path to the metric
    metrics:
    - gauge:
      name: job_queue_length #The name of the metric that you are exposing.
      prometheusMetricName: job_queue_length #optional: The Prometheus metric name as exposed by the Pod.

適用すれば、メトリクスがオートスケーリングシステムから利用できるようになります。

続いて、このカスタムメトリクスを利用するHPAを作成します。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: worker-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: job-worker
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: autoscaling.gke.io|worker-queue-metric|queue_utilization
      target:
        type: AverageValue
        averageValue: 20

この設定の意味は次のとおりです。

• Podあたりの平均キューサイズが20ジョブを超えると、システムはスケールアップします。
• キューが減ると、システムはスケールダウンします。

本機能には、いくつもの大きな利点があります。

• アプリケーションを意識したスケーリング: インフラの代理指標ではなく、実際の需要に即してスケーリングを判断できます。
• 運用の複雑さを軽減: 外部アダプタや煩雑なメトリクスパイプラインが不要になります。
• パフォーマンス向上: アプリケーションがより的確にスケールし、workloadsの急増にも素早く応答できます。
• リソース利用効率の向上: 実需要に沿ってスケーリングされるため、インフラコストを抑えられます。
• 柔軟なオートスケーリング戦略: キュー長、アクティブセッション、保留中のレンダリングなど、アプリケーションが公開する任意のgaugeメトリクスを軸にポリシーを設計できます。