🚀 Wave Autoscale 3.2.0: GPU 対応オートスケーリングと OpenShift サポート
著者: Hwansoo Kim (opens in a new tab)
Date: 2026年4月29日
TL;DR: Wave Autoscale 3.2.0 は、3.x シリーズで残されていた 2 つのコスト・カバレッジのギャップを解消します。GPU ワークロードには NVIDIA DCGM (opens in a new tab) メトリクス収集、コスト追跡、無駄検出、Web Console の専用 GPU ビューを備えた完全な最適化スタックが用意されます。そして OpenShift は、ファーストクラスのデプロイ対象になりました。DeploymentConfig が Kubernetes Deployment、Argo Rollouts と並んで認識されるワークロードタイプとして加わり、Helm チャートは Red Hat 認定パイプライン経由で配布されます。
🛤️ ワークロードとノードを越えて GPU と OpenShift へ
Wave Autoscale 3.0 はワークロードレベルのインテリジェンスを提供しました。ML 駆動オートスケーリングのための Autopilot、自動ライトサイジングのための Smart Sizing、ストレージ最適化のための PV 管理です。Wave Autoscale 3.1 ではそのインテリジェンスをノード層まで広げ、Amazon EKS の Karpenter (opens in a new tab) を制御できるようにしました。
私たちが最も多くの会話を交わすお客様にとって、依然として 2 つのギャップが残っていました。
1 つ目は GPU です。 GPU インスタンスは、AI 中心のクラスターでは最も高価な項目であり、同時に最も過剰割り当てされやすい資源でもあります。標準的な Kubernetes メトリクス（CPU、メモリ、ポッド数）からは GPU 使用率について何もわかりません。トレーニングや推論のワークロードを運用するチームは、月次請求の最大項目について、ほとんど目隠しの状態で運用を続けていたのです。
2 つ目は OpenShift です。 Wave Autoscale のエンタープライズのお客様の多くは、規制環境やオンプレ環境で Red Hat OpenShift (opens in a new tab) を運用されています。OpenShift の DeploymentConfig は Deployment や Rollout と並ぶファーストクラスのワークロードオブジェクトですが、Wave Autoscale はこれまで後者の 2 つしか認識していませんでした。そのため DC ベースのサービスは Autopilot や Smart Sizing から見えない領域にあり、まさにそれらの機能を最も必要としているワークロードが対象外になっていました。
Wave Autoscale 3.2.0 はこの 2 つのギャップをまとめて解消します。
🎯 GPU 対応オートスケーリング: コストの死角を埋める
GPU はコスト最適化の観点で CPU と異なる性質を持ちます。CPU 使用率は意味の明確な単一の数値です。一方 GPU 使用率は少なくとも 3 つの数値（SM（ストリーミングマルチプロセッサ）アクティビティ、メモリ使用率、メモリ帯域）であり、これらは連動しません。あるポッドが 80GB の GPU メモリを保持したままほぼ計算をしていないこともあれば、メモリの一部だけで SM アクティビティ 100% を使い切ることもあります。標準のクラスター監視ではどちらも見えません。
NVIDIA の答えは Data Center GPU Manager (DCGM) exporter (opens in a new tab) です。GPU ごとのメトリクスをドライバから直接取得する Prometheus 形式のコレクターで、多くのプラットフォームチームはすでに名前を知っているか、Prometheus でスクレイプ済みのはずです。難しいのはメトリクスを集めることではなく、それをオートスケーリング、サイジング、FinOps の意思決定に変えることです。
Wave Autoscale 3.2.0 が提供するもの:
- Wave Agent での DCGM 収集. Agent は既存の CPU・メモリ・ネットワークメトリクスと並行して DCGM exporter のエンドポイントをスクレイプし、同じ経路で内部の分析ストアに書き込みます。
- GPU コスト追跡タスク. GPU が割り当てられたすべてのポッドはノードのインスタンスタイプとオンデマンド／スポットの価格にマッピングされ、ワークロード別、ネームスペース別、クラスター別の GPU コストビューに集計されます。
- 無駄検出. スケジュールされたタスクが、割り当て済みだがアイドルな GPU を浮かび上がらせます。A100 や H100 を丸ごと予約しているのに、設定された時間窓のあいだ SM アクティビティが閾値を下回り続けるポッドを検出します。GPU FinOps において最もアクションにつながる単一のシグナルです。
- Web Console の GPU リソースビュー. コンソールの新しいビューでは、ノードごとの GPU インベントリ、ポッドごとの GPU 消費、無駄検出の結果が表示され、基となる DCGM の時系列までドリルダウンできます。
GPU スタックは Wave Autoscale の他の領域と同じプリミティブの上に構築されています。Agent が収集し、分析層が保存し、タスクが生のメトリクスを推奨に変換します。DCGM exporter がすでに動作していれば、アップグレードによって自動的に取り込まれます。
🟥 OpenShift サポート: お客様の運用環境にきちんと届く
Red Hat OpenShift は、規制業種およびオンプレ環境で最も普及している Kubernetes ディストリビューションです。OpenShift 固有のワークロードオブジェクトである DeploymentConfig（DC）は Deployment よりも歴史が古く、Red Hat が OCP 4.14 で deprecated に指定 (opens in a new tab) して移行を推奨している現在も、本番環境で広く利用されています。その移行が普遍的になるまで（現状ではまだそうではありません）、DC をサポートすることが OpenShift 環境を扱うための前提条件になります。
DC は単に「名前の違う Deployment」ではありません。ライフサイクルモデルそのものが異なります。
| 項目 | Kubernetes Deployment | OpenShift DeploymentConfig |
|---|---|---|
| ロールアウトの主体 | Deployment コントローラー | リビジョンごとに短命な *-deploy deployer ポッド |
| 下位の replica オブジェクト | ReplicaSet | ReplicationController |
| 戦略 | RollingUpdate、Recreate | Rolling、Recreate、Custom |
| ライフサイクルフック | なし | pre、mid、post フック |
| ロールアウト中の scale | 比例スケーリング | 制限あり |
最も扱いにくいのが deployer ポッドです。新しいリビジョンが作られるたびに <dc>-<revision>-deploy という名前の使い捨てのポッドが生成されてロールアウトを進め、終わると Completed (0/1) の状態で終了します。素朴なワークロード追跡の視点では、これらのポッドは「死に続ける本物のワークロードポッド」のように見えます。実際にはワークロードではなくロールアウトの仕組みです。これをワークロードとして扱うと使用率データが歪み、Smart Sizing が混乱します。
Wave Autoscale 3.2.0 が扱う部分:
- DeploymentConfig をファーストクラスのワークロードタイプとして認識. Kubernetes Deployment、Argo Rollouts と並んで deployment 一覧と詳細ビューに表示されます。
- Deployer ポッドのフィルタリング.
*-deployポッドはopenshift.io/deployer-pod-for.nameラベルと名前のサフィックスで識別され、使用率集計や Pod Placement ビューから除外されます。 - Autopilot と Smart Sizing の連携. DC ワークロードも、他のワークロードタイプと同じオートスケーリング・ライトサイジング推奨フローを通ります。
- S3 で配布される Red Hat 認定 Helm チャート. OpenShift 用 Helm チャートは GitHub Actions パイプライン (opens in a new tab)を通じて Red Hat のチャート認定を通過したのち S3 へアップロードされます。ビルドは deprecated な offline-token フローではなく、service account を使って Red Hat Hybrid Cloud Console に認証します。
EKS、ROSA、オンプレの OpenShift が混在するプラットフォームでも、これからは 1 つの Wave Autoscale コントロールプレーンですべて管理できます。
📐 Smart Sizing: 2 つのモードを明確に
Smart Sizing は Wave Autoscale 3.0 から提供している機能ですが、その挙動はコンソール上で必ずしも明確ではありませんでした。最初は通常 scale out しないワークロードである StatefulSet と DaemonSet を対象にし、その後 HPA も Wave Autopilot も持たない Deployment まで広げました。Autopilot が動作する Deployment では水平スケーリングが組み合わさるためサイジングの式が変わるので、2 つ目の経路も追加しました。
3.2.0 の Web Console は、この 2 つの運用モードを明示的に表示します。
- Static Smart Sizing: scale しない、または Autopilot を使わないワークロード向け。観測された過去の使用量（P99 付近）と安全マージンに基づいて推奨を計算します。
- Autopilot Smart Sizing: Autopilot が水平スケーリングを担うワークロード向け。生の需要ではなく replica あたりの定常状態に対して推奨を計算するため、2 つのシステムが整合的に組み合わさります。
両モードとも同じ recommendations の出力先に書き込みますが、コンソールではどちらの経路が生成した推奨かをラベルで示します。デバッグと信頼性の両面で有用です。
📈 予測（Forecast）と Wave Agent のアップデート
小さいながら運用上意味のある 2 つの変更です。
- Forecast の地平線（horizon）デフォルトを 30 日から 7 日へ短縮. 30 日の地平線は、予測モデルを新規導入したときに保守的に設定した値でした。実務では実際にチームが行動に移すのは 7 日予測であり、より長い地平線は無視されるノイズを生んでいました。
WA_CLUSTER_STATUS_FORECAST_HORIZON_DAYS環境変数で引き続き上書きできます。 - Wave Agent テレメトリの改善. 3.1.0 の gRPC パイプライン作業に続き、3.2.0 では Agent 内部のタスクスケジューラの信頼性と可観測性を段階的に改善しています。
🔭 次に取り組むこと
3.2.0 は、3.x シリーズで進めてきたプラットフォーム広範囲化の作業の締めくくりです。GPU と OpenShift がファーストクラスとして加わったことで、フォーカスは再び深さに戻ります。広がったワークロード領域に対して Autopilot と Smart Sizing の推奨品質を高め、GPU やストレージの無駄検出をより鋭くし、観測結果と推奨のあいだのフィードバックループをより緊密にしていきます。
GPU を本番環境で運用していてワークロードごとの使用率とコストの可視性が不足していたり、OpenShift のワークロードを既存のオートスケーリングスタックの外に置いていたりするのであれば、3.2.0 へのアップグレードはまさに今です。環境にどんな変化が起きるかを一緒に見ていきたい方は、お問い合わせ (opens in a new tab)ください。