MENU

Azure BatchのHBv2/HC/NP-Series EOL対応：HPC・GPUワークロードの移行選択肢

Azure

Azure BatchでHBv2、HC-Series、NP-Seriesの古いVMファミリーを使っているHPC・GPU系ワークロードは、2027年5月31日までに移行計画を具体化すべき段階に入りました。2026年4月16日時点のAzure Updatesでは、Azure BatchプールにおけるこれらのVMサポート終了がリマインドされており、単なる告知確認ではなく、プール構成、クォータ、価格、アプリケーション互換性をまとめて見直す必要があります。(Microsoft Azure)

結論から言うと、HBv2/HCを使うMPI・CAE・シミュレーション系のHPCワークロードは、HBv5、HBv4、HX、HBv3などの現行HPC向けVMを候補にします。NP-Seriesを使うFPGAアクセラレーション系ワークロードは、単純なVMサイズ変更では済まないケースが多く、NDv2、NCads_H100_v5、NCasT4_v3などのGPU VM候補と、アプリケーション実装の変更コストを同時に比較するのが現実的です。(Microsoft Learn)

目次

Azure BatchのEOL reminderで何が変わるのか

今回のポイントは、Azure Batchそのものが終了する話ではありません。対象は、Azure Batchプールで利用している特定の古いVMファミリーです。

影響を受ける主なVMファミリーは次の3つです。

対象VMファミリー主な用途移行時に見るべき観点
HBv2-seriesCFD、有限要素解析、気象、エネルギー研究などのメモリ帯域幅重視HPCメモリ帯域幅、MPIスケーリング、InfiniBand、ジョブ実行時間
HC-SeriesAVX-512やIntel MKLに依存する計算系HPC、化学計算、構造解析Intel依存、ライブラリ互換性、コアあたり性能、MPI通信
NP-SeriesFPGAアクセラレーション、推論、動画処理、リアルタイム処理FPGA依存コード、ビットストリーム、GPU移植可否、再設計コスト

特に注意したいのは、VMの世代交代は「同等スペックの後継SKUに置き換えるだけ」ではないという点です。HPCでは、CPUコア数よりもメモリ帯域幅やノード間通信性能が支配的になることがあります。GPU/FPGA系では、アクセラレータの種類が変わるだけで、ビルド環境、ドライバー、ライブラリ、性能特性が大きく変わります。

まず確認すべきは「どのBatchプールが対象か」

移行検討の最初の作業は、現在のAzure Batchアカウントにあるプールを棚卸しすることです。グローバルに複数リージョンでBatchを運用している場合、リージョンごとに利用可能なVMサイズ、クォータ、価格、容量状況が異なります。

Azure Batchでは、リージョンでサポートされるVMサイズをCLIやPowerShell、Batch Management APIで確認できます。Microsoft Learnでも、BatchプールではAzureで利用可能なVMサイズの多くを利用でき、リージョンごとの対応SKUはaz batch location list-skusなどで確認できると説明されています。(Microsoft Learn)

az batch location list-skus --location <azure-region> -o table

対象プールの棚卸しでは、少なくとも次の情報を一覧化します。

確認項目見る理由
Batchアカウント名、リージョン移行先SKUの可用性とクォータがリージョン依存のため
プールID、vmSizeHBv2、HC、NP-Seriesの利用有無を判定するため
dedicated/Spotノード数コスト比較と容量確保の前提になるため
OSイメージ、node agent SKUVMだけでなくイメージ側のEOLも影響するため
startTask、application packages、container設定新プールで再現が必要なため
VNet、サブネット、NSG、マウント設定MPI通信、データ配置、セキュリティに影響するため
autoscale formula、taskSlotsPerNodeVMサイズ変更後に過剰・過小スケールしやすいため

Azure Resource Manager側でBatchプールが取得できる環境なら、次のように候補を抽出できます。

az resource list \
  --resource-type Microsoft.Batch/batchAccounts/pools \
  --query "[?contains(properties.vmSize, 'HB') || contains(properties.vmSize, 'HC') || contains(properties.vmSize, 'NP')].{id:id, vmSize:properties.vmSize}" \
  -o table

実行環境によって取得できるプロパティ名が異なる場合は、まずJSONで出力してproperties.vmSizeの位置を確認してください。

az resource list \
  --resource-type Microsoft.Batch/batchAccounts/pools \
  -o json

HBv2/HC-Seriesの移行先はワークロード特性で選ぶ

HBv2やHC-Seriesからの移行では、単純に「新しいHPC VMを選ぶ」のではなく、ジョブのボトルネックで分類するのが重要です。

MicrosoftのHBv2移行ガイダンスでは、HBv2の後継候補としてHBv5、HBv4、HX、HBv3が挙げられています。HBv2は120個のAMD EPYC 7V12コア、CPUコアあたり4GBメモリ、最大350GB/sのメモリ帯域幅を持つHPC向けVMとして説明されています。(Microsoft Learn)

HC-Seriesについても、Microsoftは2027年5月31日の提供終了を示し、移行先としてHBv5、HBv4、HX、HBv3などのHPC最適化SKUを案内しています。HCはIntel Xeon Platinum 8168、CPUコアあたり8GBメモリ、100Gb/s Mellanox EDR InfiniBandを備えるVMとして説明されています。(Microsoft Learn)

ワークロード特性移行候補判断基準
メモリ帯域幅が支配的HBv5、HBv4、HBv3CFD、構造解析、気象、分子動力学など。コア数よりもメモリ帯域幅と実行時間で比較する
メモリ容量・レイテンシが支配的HX、HBv5、HBv3EDA、巨大モデル、メモリ容量を多く使う解析。ノードあたりメモリ量を確認する
MPI通信が重いHX、HBv5、HBv4InfiniBand、RDMA、MPIライブラリ、ノード間スケーリングを必ず検証する
Intel MKLやXeon認定に依存Ddsv6/Edsv6、Ddsv5/Edsv5、Ddsv4/Edsv4なども候補ISV認定、AVX-512依存、Intel固有最適化の有無を確認する
レンダリングや金融計算など計算バウンドHX、HBv4、HBv3コアあたり性能、並列効率、ライセンス課金単位も比較する

HPCでは「1時間あたりのVM単価」だけで判断すると失敗します。たとえば、旧VMより時間単価が高くても、ジョブ実行時間が半分になれば総コストは下がる可能性があります。比較時は次の式で見ると実務に近くなります。

ジョブ単価 = VM時間単価 × ノード数 × 実行時間 × 再実行率 + ストレージ/転送/ライセンス関連コスト

特にCAEや商用ソルバーでは、VMコストよりライセンス消費のほうが支配的になることがあります。その場合は、「同じライセンス数で何本のジョブを完了できるか」をKPIにしたほうが正確です。

NP-Seriesは「GPU VMへサイズ変更」ではなく再設計として扱う

NP-Seriesは、一般的なGPU VMではなく、FPGAアクセラレーション向けに導入されたVMです。MicrosoftのNP-Series移行ガイダンスでは、Intel Xeon 8171M CPUとAMD Xilinx Alveo U250 FPGAを搭載し、機械学習推論、動画トランスコーディング、データベース検索・分析などの高速化を想定したVMとして説明されています。移行候補としてはNDv2、NCads_H100_v5、NCasT4_v3が挙げられています。(Microsoft Learn)

ただし、FPGAからGPUへの移行は、ほとんどの場合でアプリケーション側の変更を伴います。

現在のNP-Series利用パターン移行時の考え方
FPGAビットストリームに強く依存GPU VMへの単純移行は難しい。アルゴリズム再実装、ライブラリ変更、検証期間を見積もる
推論処理をFPGAで高速化NCasT4_v3、NCads_H100_v5などで推論レイテンシとスループットを比較する
バッチ推論・学習寄りNCads_H100_v5やND系を候補にし、GPUメモリ、フレームワーク対応、コストを比較する
動画処理・トランスコードGPUエンコード/デコード対応、コンテナイメージ、ライブラリ互換性を確認する
低レイテンシの専用処理GPU化で遅延が増える可能性があるため、CPU最適化や別アーキテクチャも含めて比較する

NP-Series移行でありがちな失敗は、クラウドインフラ担当が「推奨GPU VMに変えればよい」と判断し、アプリケーション担当の移植工数を後から認識するパターンです。FPGA固有の処理を使っている場合は、移行計画にコード変更、性能検証、精度検証、運用監視の再設計を含めてください。

Azure Batchプールの移行方式は2つある

Azure Batchプールの移行は、大きく分けて「既存プールを更新する」方法と「新しいプールを作って切り替える」方法があります。

Microsoft Learnでは、Batchプール作成時にVMサイズやイメージなどを指定し、状況によって一部プロパティを更新できると説明されています。Management PlaneのPool Update APIでは、API version 2024-07-01以降を使うこと、PATCHでは指定したプロパティのみ更新されること、また多くのプロパティ更新ではプールのノード数をゼロにする必要があることが示されています。vmSize更新のREST例も掲載されています。(Microsoft Learn)

方式A：既存プールをゼロノードにしてvmSizeを更新する

この方式は、テスト環境や停止時間を確保できるバッチ基盤で有効です。

項目内容
向いているケースプールIDを維持したい、ジョブ投入側の変更を最小化したい
前提対応API/SDKを使えること、プールをゼロノードにできること
メリットプール名や一部設定を維持しやすい
注意点停止時間が発生する。SDKやIaCの対応状況を確認する必要がある

実施イメージは次の流れです。

手順作業
1対象プールへの新規ジョブ投入を止める
2実行中タスクを完了させる、または再実行可能な状態にする
3プールを0ノードへ縮退する
4Management Plane APIまたは対応SDKでvmSizeを更新する
5少数ノードで起動し、startTask、ドライバー、MPI、マウントを確認する
6段階的にスケールアウトし、本番ジョブを再開する

方式B：新しいプールを作り、ジョブを段階的に切り替える

本番環境では、こちらのほうが安全です。既存プールを残したまま、新しいVMファミリーで別プールを作り、検証済みジョブから順に切り替えます。

項目内容
向いているケース本番停止を避けたい、複数ワークロードを段階移行したい
前提ジョブ投入側でpoolIdを切り替えられること
メリットロールバックしやすい。旧VMと新VMの実測比較ができる
注意点一時的に旧プールと新プールの両方のクォータ・コストが必要

新プール作成時は、VMサイズだけでなく次の設定をコピーまたは再設計します。

設定見落としやすいポイント
OSイメージ古いMarketplaceイメージやNode Agent SKUのEOLも確認する
startTaskドライバー、MPI、ライセンス設定、環境変数の差異を確認する
application packagesバージョン固定されている場合、新OSで動かないことがある
container imageCUDA、ROCm、MPI、glibcなどの互換性を確認する
VNet/NSGノード間通信、ストレージアクセス、名前解決を確認する
Managed IdentityStorage、Key Vault、Container Registryへの権限を再確認する
autoscale formulaVMサイズ変更でタスク密度が変わるため、そのまま流用しない
taskSlotsPerNode新VMのコア数・メモリに合わせて再設計する

クォータと容量は早めに申請する

移行プロジェクトで遅れやすいのがクォータです。Azure BatchのBatch service modeでは、専用ノードに対してVMシリーズごとのコアクォータとBatchアカウント全体のコアクォータが適用されます。一方、SpotノードはBatchアカウント全体のSpotコアクォータで管理されます。user subscription modeでは、Batchのコアクォータではなくサブスクリプション側のリージョン別・シリーズ別クォータが使われます。(Microsoft Learn)

移行先VMを決める前に、次の観点でクォータを確認してください。

確認項目判断基準
リージョン現在のリージョンで移行先SKUが利用できるか
VMファミリー別クォータHBv5、HX、GPU系など必要なシリーズのコア数が足りるか
DedicatedとSpotの比率本番SLAに必要な最低Dedicatedノード数を確保できるか
ピーク時容量月末処理、研究締切、繁忙期に必要なノード数を満たせるか
複数Batchアカウントアカウント単位の上限にぶつからないか

クォータ申請では、「旧VMと同じコア数」ではなく、移行後の実測ベンチマークを想定した必要ノード数で申請するのが理想です。性能改善で必要ノード数が減ることもあれば、メモリやGPUメモリの制約で逆にノード数が増えることもあります。

Spot VMを使うならHPCジョブの性質を分ける

価格比較ではSpot VMも候補になります。Azure Batchでは、Dedicated VMとSpot VMを同じプール内で組み合わせることができ、タスクが中断された場合には再キューされる仕組みがあります。ただし、Spot VMにはSLAや可用性保証がなく、いつでも割り当て解除される可能性があります。(Microsoft Learn)

Spotに向いているのは、短時間で再実行しやすい多数の独立タスクです。

ワークロードSpot適性理由
画像変換、レンダリングのフレーム単位処理高いタスク単位で再実行しやすい
大量の独立したパラメータ探索高い失敗タスクだけ再実行できる
バッチ推論中〜高チェックポイントや再投入設計があれば有効
長時間MPIジョブ低い1ノードの中断でジョブ全体が失敗しやすい
ライセンス費が高いCAEジョブ低〜中再実行でライセンス時間を浪費する可能性がある
FPGA/GPUの長時間専有処理中チェックポイント設計次第

HPC運用では、すべてをSpot化するよりも、最低限のDedicatedノードを確保し、余剰処理や再実行可能なジョブだけSpotに逃がす構成が現実的です。

移行前に必ず実施したいベンチマーク

VMファミリー移行では、カタログスペックより実アプリケーションの測定が重要です。特にHPC/GPUワークロードでは、CPU、メモリ、ネットワーク、I/O、ライブラリのどこが支配的かで結果が大きく変わります。

テスト項目合格基準の例
正常性テスト旧環境と同じ入力で同じ結果、または許容誤差内の結果になる
単一ノード性能旧VM比で実行時間、メモリ使用量、I/O時間を比較する
スケールアウト性能1、2、4、8、16ノードなどで並列効率を測る
MPI通信RDMA、InfiniBand、MPIライブラリ、ホストファイル生成を確認する
GPU/FPGA代替GPUメモリ、CUDA対応、推論レイテンシ、スループットを測る
データ配置Azure Storage、Azure NetApp Files、BlobFuse、NFSなどのI/Oを確認する
障害時挙動ノード割り当て失敗、Spot中断、タスク再実行を確認する
コスト1ジョブ完了あたりの総額で比較する

ベンチマークは、平均値だけでなくばらつきも見てください。HPCでは、数%の性能差よりも、ジョブによって実行時間が大きく揺れるほうが運用上の問題になります。

よくある失敗と回避策

失敗原因回避策
後継SKUを1つに決め打ちするワークロード特性を見ずにカタログだけで選ぶメモリ帯域幅、通信、GPU/FPGA依存で分類する
クォータ申請が遅れる移行先VMファミリーのコア枠を未確認検証開始前にリージョン別クォータを確認する
価格比較が時間単価だけ実行時間短縮や再実行率を考慮していないジョブ完了単価で比較する
MPIが新プールで遅いRDMA/InfiniBand設定、MPIライブラリ差分小規模からスケールテストし、通信設定を確認する
autoscaleが暴れる旧VM前提の式を流用taskSlotsPerNode、実行時間、待ちタスク数に合わせて再設計する
NP-Series移行を軽く見積もるFPGAからGPUへの実装差を無視アプリケーション担当を初期段階から入れる
旧OSイメージをそのまま使うVM移行だけに注目しているOS、Node Agent、ドライバー、コンテナも同時に更新する
本番切替で戻せない既存プールを直接変更した新旧プールを並行運用し、段階的にpoolIdを切り替える

いつまでに何をするべきか

2027年5月31日がサポート終了日であっても、実務上の締切はもっと前に設定すべきです。HPCやGPUワークロードは、クォータ、容量、検証、アプリケーション変更、ライセンス確認に時間がかかるためです。

時期実施内容
すぐHBv2、HC、NP-Seriesを使うBatchプールを棚卸しする
1〜2か月以内ワークロードをHPC、Intel依存、FPGA依存、GPU移行可能に分類する
検証フェーズHBv5、HBv4、HX、HBv3、GPU VMなどでベンチマークする
移行準備クォータ申請、IaC更新、ジョブ投入先切替、監視設定を準備する
本番移行新プールへ段階的に切り替え、旧プールをドレインする
完了後旧VMファミリーを使うテンプレート、スクリプト、ドキュメントを削除する

特にグローバル運用では、リージョンごとに同じSKUが同じ条件で使えるとは限りません。日本、米国、欧州など複数リージョンでBatchを使っている場合は、リージョン別に移行先を固定せず、利用可能SKU、クォータ、データ所在地、価格、ネットワーク遅延をセットで比較してください。

Azure Batch運用チームが次に取るべき行動

今回のAzure Batch EOL reminderは、単なるリタイア告知ではなく、HPC・GPU基盤の世代更新を始める合図です。まずは、HBv2、HC-Series、NP-Seriesを使っているBatchプールを洗い出し、ワークロード特性ごとに移行候補を分けてください。

HBv2/HC系のHPCワークロードは、HBv5、HBv4、HX、HBv3などを候補に、MPI性能とジョブ完了単価で比較します。NP-SeriesはFPGA依存の有無を最初に確認し、GPU VMへの移行が可能か、アプリケーション再設計が必要かを切り分けます。

最も安全な進め方は、新しいBatchプールを作成して小さく検証し、ジョブ単位で段階的に切り替えることです。EOL直前にVMサイズだけを変えるのではなく、クォータ、価格、OSイメージ、ドライバー、autoscale、監視まで含めて、2027年5月31日前に余裕を持って移行を完了させましょう。

Azure
GPU VM移行 EOL Azure Batch HPC

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次