Azure BatchでAv2、F、Fs、Fsv2、G、Gs、Lsv2シリーズを使用している場合は、2028年11月15日までに対応するVMシリーズへ移行する必要があります。
2026年6月11日に公開された公式情報によると、廃止後は対象VMを使った新規プールを作成できず、既存プールもスケールアウトできません。プールが強制的にゼロノードへ縮小され、残ったVMが停止・割り当て解除される可能性もあります。今すぐ停止する変更ではありませんが、ゼロノードで待機しているプールや自動スケール環境も影響を受けるため、早めの棚卸しと移行テストが必要です。(Microsoft Developer)
まず確認すべき変更点と期限
今回のAzure BatchにおけるVMシリーズ廃止を整理すると、次のとおりです。
| 項目 | 内容 |
|---|---|
| 公式情報の公開日 | 2026年6月11日 |
| 廃止日 | 2028年11月15日 |
| 対象VMシリーズ | Av2、F、Fs、Fsv2、G、Gs、Lsv2 |
| 期限まで | 既存プールは継続利用できるが、移行が推奨される |
| 期限後 | 新規プール作成不可、既存プールのスケールアウト不可 |
| 既存ノード | 強制的なゼロノード化や、停止・割り当て解除の可能性がある |
| 必要な対応 | 対象プールの特定、代替VMの選定、動作・性能・料金テスト、移行 |
特に注意したいのは、現在ノードが動いているプールだけが対象ではない点です。自動スケールによって普段はゼロノードになっているプールでも、設定されているvmSizeが対象シリーズなら移行が必要です。廃止日以降にジョブを投入しても、必要なノードを追加できず、処理を開始できない可能性があります。(Microsoft Azure)
影響を受けるユーザーと環境
次のいずれかに該当する場合は、Azure Batchプールの確認が必要です。
- 対象シリーズを指定したプールを現在運用している
- ジョブ実行時だけノード数を増やす自動スケール構成を使用している
- 夜間処理や月次処理など、普段はゼロノードのプールがある
- ARMテンプレート、Bicep、Terraform、SDK、スクリプトに対象VMサイズを記述している
- 開発・検証・災害対策用として停止中のプールを残している
- 新規環境のひな型や構築手順書に古いVMサイズが残っている
既存プールだけでなく、Infrastructure as Codeや運用スクリプトに残っているvmSizeも修正対象です。プールを削除済みでも、廃止後に同じテンプレートから再作成しようとすると失敗します。
Azure Advisorにも、対象シリーズからの移行を促すAzure Batch向け信頼性推奨事項が追加されています。ただし、Advisorの表示だけに頼らず、すべてのBatchアカウントとプールを直接確認するのが確実です。(Microsoft Learn)
対象のBatchプールを確認する方法
Azureポータルで確認する
Azureポータルでは、次の順序で確認します。
- 対象の「Batch アカウント」を開く
- プール一覧を表示する
- 各プールを開き、VMサイズを確認する
- Pool ID、リージョン、VMサイズ、ノード数、自動スケールの有無を記録する
- 開発・検証・本番など、環境ごとに移行優先度を付ける
複数のサブスクリプションやリージョンを利用している場合は、Batchアカウント単位で確認してください。停止中やゼロノードのプールも除外しないことが重要です。
Azure CLIで一覧を取得する
プール数が多い場合は、Azure CLIでvmSizeを一覧にすると確認しやすくなります。
az batch account login \
--name <BATCH_ACCOUNT> \
--resource-group <RESOURCE_GROUP>
az batch pool list \
--query "[].{Pool:id,VMSize:vmSize,State:state,AllocationState:allocationState}" \
--output table認証方法は、Batchアカウントのプール割り当てモードや認証設定に合わせて調整してください。
移行候補のVMサイズが対象リージョンのAzure Batchで利用できるかは、次のコマンドで確認できます。
az batch location list-skus \
--location japaneast \
--output tableAzure Batchで利用可能なVMサイズはリージョンごとに異なります。Microsoftも、サポート終了が近いSKUを避け、az batch location list-skusなどで利用可能なSKUを確認するよう案内しています。(Microsoft Learn)
なお、「Aで始まるVMをすべて対象」「Fで始まるVMをすべて対象」と判定するのは適切ではありません。今回の対象は指定されたシリーズと世代です。VMサイズの文字列だけで機械的に判定せず、シリーズ名まで確認してください。
代替VMシリーズの選び方
Microsoftが示している主な移行候補は次のとおりです。
| 廃止対象 | 主な移行候補 | 選定時のポイント |
|---|---|---|
| Av2 | Dsv5、Ddsv5、Dasv5、Dadsv5 | CPUとメモリのバランス、ローカル一時ディスクの必要性 |
| F、Fs、Fsv2 | Dlsv6、Dldsv6、Falsv6、Dsv5、Ddsv5 | CPU性能、メモリ比率、並列実行数 |
| G、Gs | Lsv3、Lasv3、Easv5、Edsv5 | 大容量メモリとローカルストレージのどちらを重視するか |
| Lsv2 | Lsv3、Lasv3 | ローカルNVMeの容量、IOPS、スループット |
これらは移行先の候補であり、すべてのワークロードに対する一対一の置き換えを保証するものではありません。Microsoftの公式情報でも、用途に応じてDsv5、Lsv3、Dlsv6、Falsv6などへの移行が案内されています。(Microsoft Azure)
vCPU数だけで選ばない
旧VMと同じvCPU数の新VMを選んでも、処理時間や料金が同じになるとは限りません。最低限、次の項目を比較します。
- vCPU数とメモリ容量
- CPUとメモリの比率
- ディスクIOPSとスループット
- ネットワーク帯域
- ローカル一時ディスクやNVMeの有無
- Intel系とAMD系の違い
- 使用するOSイメージと世代
- 1ノードあたりの同時タスク数
- 対象リージョンでの提供状況とクォータ
- DedicatedノードとSpotノードの利用条件
特にLsv2やローカル一時ディスクを活用している処理では注意が必要です。一時ディスク上のデータはノードの割り当て解除などで失われるため、入力データの再配置、チェックポイント、処理結果の外部保存まで含めて設計を見直してください。VMサイズの選定では、アプリケーションのメモリ使用量やマルチスレッド特性、リージョンのクォータも考慮する必要があります。(Microsoft Learn)
Azure Batchプールを移行する2つの方法
公式情報では、既存プールのVMサイズを更新する方法と、新しいプールを作成する方法が案内されています。
| 移行方法 | 適している環境 | メリット | 注意点 |
|---|---|---|---|
| 既存プールをゼロノードにして更新 | 停止時間を確保でき、Pool IDを維持したい環境 | ジョブやスクリプトのPool ID変更を減らせる | 更新中は処理不可。事前にすべてのノードをゼロにする必要がある |
| 新しいプールを作成して切り替え | 本番環境、停止時間を抑えたい環境 | 並行テストと切り戻しが容易 | Pool IDやジョブスケジュールの切り替えが必要。移行中は追加コストとクォータを消費する |
既存プールのVMサイズを更新する
既存プールのVMサイズは、Batch Management Plane APIの2024-07-01以降を利用して更新できます。vmSizeを変更する場合は、プールの合計ノード数をゼロにしておく必要があります。Microsoftは、プールプロパティの更新方法としてManagement PlaneのPool - Updateを推奨しています。(Microsoft Learn)
実務上は次の順序で進めます。
- 実行中のジョブとタスクを確認する
- 処理結果、ログ、チェックポイントを外部ストレージへ保存する
- 自動スケールや定期実行を一時停止する
- DedicatedノードとSpotノードを両方ともゼロにする
- Management Plane APIまたは対応SDKで
vmSizeを更新する - 少数のノードを割り当て、Start Taskとアプリケーションの起動を確認する
- 代表的なジョブで性能と結果を検証する
- 問題がなければ自動スケールと定期実行を再開する
ノードをゼロにする際は、実行中タスクを完了させるのか、再キューするのかを事前に決めてください。再実行によって二重登録や二重課金が発生する処理では、タスクの冪等性も確認が必要です。
新しいプールを作成して切り替える
本番環境では、旧プールを残したまま新しいVMシリーズのプールを作成する方法が安全です。
- 既存プールの設定をエクスポートする
- 移行候補のVMサイズで新しいプールを作成する
- OSイメージ、Start Task、アプリケーション、ネットワーク、IDを再現する
- 本番に近いデータ量でテストジョブを実行する
- 処理時間、エラー率、出力結果、料金を比較する
- ジョブやJob Scheduleの参照先を新しいPool IDへ変更する
- 一定期間監視した後、旧プールを削除する
新しいプール方式では、旧環境へ戻しやすいことが大きな利点です。一方、移行期間中は新旧両方のノードを割り当てる可能性があるため、VMクォータと予算に余裕を持たせてください。
移行時に再確認すべき設定
VMサイズだけを変更し、周辺設定を確認しないと、ノードは起動してもタスクが正常に動かないことがあります。
| 確認項目 | 主なチェック内容 |
|---|---|
| OSイメージ | 新しいVMシリーズで利用可能か、第2世代イメージが必要か |
| Node Agent SKU | 選択したOSイメージと組み合わせが一致しているか |
| Start Task | アプリのインストール、環境変数、終了コードが正常か |
| アプリケーションパッケージ | バージョンや参照先が正しいか |
| 仮想ネットワーク | サブネットのIP数、NSG、DNS、プライベート接続 |
| マネージドID | Storage、Key Vaultなどへの権限が維持されているか |
| ディスク | 一時ディスク、データディスク、マウント先の違い |
| 自動スケール | 新しいvCPU数や処理速度に合わせて式を調整したか |
| Task Slots | 1ノードあたりの同時実行数が適切か |
| クォータ | 新シリーズのvCPUクォータを確保できているか |
| 監視 | ノード割り当てエラー、Start Task失敗、タスク失敗を検知できるか |
VMシリーズによって利用できるイメージや機能が異なる場合があります。移行前に、サポート対象のVM SKUとイメージの組み合わせを確認してください。(Microsoft Learn)
移行による料金への影響
Azure Batch自体に追加のサービス利用料はありません。ただし、プールで使用するVM、OSディスク、データディスク、Storage、ネットワーク転送、ロードバランサー、ソフトウェアライセンスなどには料金が発生します。移行先のVMサイズが変われば、時間単価だけでなく周辺リソースの料金も変わる可能性があります。(Microsoft Learn)
移行前後の費用は、次の考え方で比較すると判断しやすくなります。
1ジョブあたりの概算費用
= VM単価 × ノード数 × 稼働時間
+ OS・データディスク
+ 入出力データの保存費用
+ ネットワーク転送
+ ソフトウェアライセンス時間単価が高いVMでも、処理時間が短くなれば1ジョブあたりの費用が下がることがあります。そのため、VMの時間単価だけでなく、同じデータを処理するまでの総費用を比較してください。
また、次の費用も見落としやすいポイントです。
- 新旧プールを並行稼働する期間の追加料金
- ローカルディスクからManaged DiskやStorageへ変更する場合の料金
- 新しいVMシリーズに合わせたクォータ増加
- 予約やSavings Planの適用状況
- Spotノードが削除された場合の再実行コスト
Spot VMはコストを抑えられる一方、容量不足などによって割り当て解除される可能性があります。再実行できない処理では、チェックポイントやDedicatedノードとの併用を検討してください。
よくある疑問
2028年11月15日までは何もしなくてもよいですか
期限までは既存プールを利用できますが、直前の対応は避けるべきです。移行先VMのリージョン対応、クォータ、OSイメージ、処理性能を確認するには時間がかかります。
古いVMシリーズでは追加容量を確保しにくくなる場合もあるため、廃止日前でもスケールアウトに失敗するリスクがあります。少なくとも本番移行の数カ月前には、性能試験と移行リハーサルを完了させてください。(Microsoft Learn)
現在ゼロノードのプールなら影響しませんか
影響します。プールにノードが存在しなくても、設定されたvmSizeが対象シリーズなら、廃止後にスケールアウトできません。
夜間処理や月次処理など、普段はゼロノードのプールほど問題の発見が遅れやすいため、優先的に確認してください。
既存プールのVMサイズだけ変更できますか
可能です。ただし、Management Plane APIのバージョン2024-07-01以降を使用し、プールをゼロノードにする必要があります。停止時間を確保できない場合や、切り戻しを容易にしたい場合は、新しいプールを作成する方法が適しています。(Microsoft Learn)
同じvCPU数のVMへ変更すれば十分ですか
十分とは限りません。メモリ容量、CPU世代、ディスク性能、ネットワーク帯域、ローカルストレージの有無が異なるためです。
本番移行前に、実際の入力データと同程度のテストデータを使い、処理時間、エラー率、メモリ使用量、ディスク使用量、1ジョブあたりの料金を比較してください。
期限までに進める対応
最初に行うべきことは、すべてのBatchアカウントからプールとvmSizeを一覧化することです。そのうえで、次の順序で進めます。
- Av2、F、Fs、Fsv2、G、Gs、Lsv2を使用するプールを特定する
- IaC、SDK、スクリプト、運用手順書の古いVMサイズも検索する
- 対象リージョンで利用可能な代替VMとクォータを確認する
- 代表的なジョブで性能、互換性、料金を比較する
- 既存プール更新か、新規プール移行かを決める
- ジョブ、スケジュール、自動スケールを含めて移行リハーサルを行う
- 2028年11月15日より十分前に本番移行を完了する
- 旧VMサイズが設定やテンプレートに残っていないことを確認する
今回の変更は、単にVM名を置き換えるだけでは対応できません。リージョン、クォータ、ディスク、イメージ、性能、料金を一つの移行単位として検証することが、ジョブ停止や想定外のコストを防ぐポイントです。
コメント