独自の成長を促進: GKE のカスタム指標のネイティブ サポートを導入

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

プラットフォーム エンジニア、AI インフラストラクチャ リードおよび開発者が Kubernetes で実行されるワークロードの自動スケーリングについて考えるとき、その目標は単純です。必要なときに、必要な容量を、最適な料金で手に入れることです。

しかし、CPU とメモリに基づくスケーリングは比較的簡単ですが、キューの深さやアクティブなリクエストなどのアプリケーション シグナルに基づくスケーリングは簡単ではありません。従来、このようなスケーリングは、モニタリング、IAM、特定のエージェント構成など、さまざまな手順を複雑に組み合わせて実現していたため、運用上のオーバーヘッドが大きくなっていました。

この摩擦を解消するために、このたび、Google Kubernetes Engine（GKE）で実行される HorizontalPodAutoscaler（HPA）のカスタム指標がネイティブにサポートされるようになりました。これは、カスタム ワークロード シグナルをネイティブの GKE 機能へと高める新機能です。

現在の課題: カスタム指標に関わる「税金」

カスタム指標（アクティブなリクエスト、KV キャッシュ、ゲームサーバーのプレーヤー数など）に基づいてワークロードをスケールしようとしたことがある方なら、このアーキテクチャが非常に手間のかかるものであることをご存じでしょう。YAML を数行記述するだけでなく、複数の異種システムを連携させる必要があります。

現在、カスタム指標に基づいて HorizontalPodAutoscaler をスケールするには、複数のコンポーネントを構成する必要があります。

1. 指標をエクスポートする: まず、Pod が指標を Cloud Monitoring、Google マネージド Prometheus、または使用しているモニタリング システムに送信（エクスポート）するように構成します。

2. 「仲介役」を構成する: 次に、クラスタに custom-metrics-stackdriver-adapter または prometheus-adapter をインストールして管理し、Cloud Monitoring と HPA の間のトランスレータとして機能させます。これらのアダプタの構成は必ずしも簡単ではなく、保守は複雑でエラーが発生しやすくなります。

3. 難しい IAM に対応する: これは多くの場合、最大のハードルです。エクスポートした指標をアダプタが読み取れるようにするには、次の手順が必要です。

    ◦ クラスタで Workload Identity 連携を有効にする。

    ◦ Google Cloud IAM サービス アカウントを作成する。

    ◦ Kubernetes サービス アカウントを作成してアノテーションを付ける。

    ◦ IAM ポリシー バインディングを使用して 2 つのアカウントをバインドする。

    ◦ 特定の IAM ロールを付与する。

4. 運用リスクを管理する: 自動スケーリング ロジックを構成すると、そのロジックはオブザーバビリティ スタックが利用可能であることに依存するようになります。指標の取り込みが遅れたり、アダプタが失敗したりすると、スケーリングが中断されます。

つまり、本番環境が突然モニタリングに左右されるようになります。モニタリング システムは重要なインフラストラクチャの一部であり、本番環境の重要な要素ですが、モニタリング システムが失敗しても、通常は本番環境の稼働を継続できます。ただし、この構成では、自動スケーリング メカニズムがモニタリング システムに依存するようになります。モニタリング システムの読み取りまたはシステム自体が失敗すると、ワークロードは自動スケールできなくなります。これにより、スケーリング ロジックが外部のオブザーバビリティ スタックの可用性に結び付けられるという、固有の運用上のリスクが生じます。ほとんどの IT ベスト プラクティスでは、このような循環依存関係は推奨される構成ではありません。トラブルシューティングが複雑になり、サービスの全体的な復元力が低下するためです。

さらに、カスタム指標に基づいてスケールするように HPA を構成することは、これまで非常に煩雑で、エラーが発生しやすかったため、Kubernetes ユーザーはサードパーティ ソリューションを採用することがよくありました。サードパーティのソリューションとその複雑な設定の管理と同期は、GKE の更新またはアップグレード サイクルに合わせるのが難しい場合があります。

エージェントレス、ネイティブの自動スケーリング

GKE のカスタム指標のネイティブ サポートにより、「仲介役」が不要になり、自動スケーリングのフローが根本的に再設計されました。リアルタイムのカスタム指標に基づくワークロードのスケーリングは、メモリや CPU に基づくスケーリングと同じくらい簡単になり、モニタリング システム、アダプタ、サービス アカウント、IAM ロールに対する複雑な循環依存関係はなくなりました。

エージェント、アダプタ、複雑な IAM は不要: カスタム指標は Pod から直接取得され、HPA に配信されます。このエージェントレス アーキテクチャでは、カスタム指標アダプタを維持したり、複雑な Workload Identity バインディングを管理したりする必要がなくなります。

カスタム指標のネイティブ サポート:

AI 推論、金融サービス、小売、ゲームなど、要求の厳しいワークロードを実行する組織にとって、この更新は大きな変化をもたらします。

• 「仲介役」は不要: アダプタ、サイドカー、IAM ロール バインディングの複雑さを解消します。アプリケーションが指標を公開すると、GKE はその指標に基づいてスケールできます。

• レイテンシの短縮: 外部モニタリング システムへのラウンド トリップが不要になるため、HPA の反応が大幅に速くなります。これは、トラフィックの急増時に需要の高いサービスのパフォーマンスが低下するのを防ぐために重要です。

• 高い費用効率: 自動スケーリングの決定にのみ使用される指標の取り込み費用を支払う必要がなくなります。スケーリング イベントへのより正確かつ迅速な対応は、コンピューティング リソースの節約にもつながります。

• 信頼性の向上: スケーリング ロジックが外部のオブザーバビリティ スタックの稼働時間に依存しなくなり、クラスタ内で自己完結します。

新しいコントローラを使用すると、HPA がスケーリングに使用する指標を簡単に構成できるため、指標の収集を簡素化できます。

この構成を作成したら、AutoscalingMetric コントローラを使用して、定義したばかりの指標に HPA を設定するだけです。

これで完了です。GKE のカスタム指標のネイティブ サポートにより、任意のワークロードからゲージ指標を選択し、HPA のトリガー値として使用できます。この 2 つの簡単なステップで、上で説明した設定のプロセス全体が置き換えられます。

ぜひお試しください

GKE のカスタム指標のネイティブ サポートは、インテントベースの自動スケーリング に向けた取り組みの第一歩にすぎません。インテントベースの自動スケーリングでは、現在 SLO を定義するのと同様に、ワークロードに必要なパフォーマンスを簡単に定義できます。LLM の GPU 使用率の最適化、バースト性の高いバッチジョブの管理、高度にスケールするエージェント ワークロードや、その他のミッション クリティカルなサービスの実行の際に、GKE では CPU やメモリのリソース指標を使用するのではなく、実際のワークロード指標に基づいてスケーリング戦略をシンプルかつ効率的に実現できるようになりました。ネイティブのカスタム指標の使用を開始するには、ドキュメントをご覧ください。

- GKE、シニア プロダクト マネージャー、Valentin Hamburger

- ソフトウェア エンジニア、Nabil Dabouz