Azure Dl/D/E v7 Virtual Machinesは、Azure仮想マシンの汎用・メモリ最適化ワークロード向けに追加された新しいv7世代のVMシリーズです。結論から言うと、既存のD/E系VMをすぐ置き換える必須対応ではありませんが、CPU性能、ネットワーク、リモートストレージ性能を重視する環境では、移行候補として早めに検証する価値があります。
今回の一般提供では、Intel® Xeon® 6（Granite Rapids）ベースのDlsv7、Dsv7、Esv7系VMが本番利用可能な段階に進みました。MicrosoftはAzure Updates上で「Launched」を本番利用可能な完全リリースとして説明しており、今回の更新では前世代のIntelベースv6 VMと比べて最大20％の一般コンピュート性能向上が示されています。(マイクロソフト Azure)
ただし、管理者が最初に確認すべきなのは「性能が上がるか」だけではありません。リージョンごとのSKU提供状況、vCPUクォータ、ローカル一時ディスクの有無、既存VMのリサイズ可否、ストレージ上限、予約・コストの影響まで見ないと、移行時に停止時間や構成不一致が発生しやすくなります。
Azure Dl/D/E v7 Virtual MachinesのGAで何が変わったのか
Azure Dl/D/E v7 Virtual Machinesは、Azure VMのDファミリーおよびEファミリーに属する新世代の仮想マシンです。主な対象は、Webアプリケーション、業務アプリケーション、仮想デスクトップ、データベース、分析基盤、インメモリキャッシュなどです。
今回のポイントは、単なる「新しいサイズ名の追加」ではなく、CPU、メモリ帯域、ネットワーク、リモートストレージの上限が引き上げられたことです。Dsv7はIntel Xeon 6 6973PCを採用し、最大372 vCPU、最大1,488 GiBメモリに対応します。Dlsv7は最大248 vCPU、最大496 GiBメモリの低メモリ寄り構成、Esv7は最大372 vCPU、最大2,832 GiBメモリのメモリ最適化構成です。(Microsoft Learn)
| 観点 | 変更点 | 実務上の意味 |
|---|---|---|
| 提供状態 | GA、一般提供 | プレビューではなく本番利用の候補にできる |
| CPU | Intel Xeon 6 6973PC、Granite Rapids世代 | CPU負荷の高い業務アプリや分析処理で検証価値がある |
| 対象シリーズ | Dlsv7、Dsv7、Esv7と、それぞれのローカルディスク付き派生 | 用途に応じて低メモリ、汎用、メモリ最適化を選べる |
| 性能 | 前世代Intel v6比で最大20％の一般コンピュート性能向上 | 既存v6環境の性能改善・統合候補になる |
| 注意点 | リージョン、クォータ、容量、サイズ提供状況に依存 | GAでも全環境で即時利用できるとは限らない |
重要なのは、既存VMが自動的にv7へ切り替わるわけではない点です。利用するには、新規作成、リサイズ、VM Scale Setsのサイズ変更、または移行用VMの作成が必要になります。
Dlsv7・Dsv7・Esv7の違いと選び方
Azure Dl/D/E v7 Virtual Machinesを検討するときは、「最新世代だから大きいサイズを選ぶ」のではなく、現在のボトルネックから逆算するのが基本です。
Dlsv7はメモリ使用量が少ない汎用ワークロード向け
Dlsv7は、Dsv7よりメモリを抑えた構成です。Webサーバー、APIサーバー、小〜中規模のアプリケーションサーバー、軽量なバッチ処理など、CPUは必要だがメモリ使用量が大きくない環境に向いています。
Dlsv7はローカル一時ディスクを持たないため、Dドライブや一時ディスクに依存しない構成で使うのが前提です。Microsoft Learnでは、Dlsv7は最大248 vCPU、496 GiBメモリ、ネットワーク最大150,000 Mbps、リモートストレージ最大397,000 IOPSとして説明されています。(Microsoft Learn)
Dsv7はバランス重視の標準候補
Dsv7は、CPUとメモリのバランスを重視する汎用VMです。ECサイト、Webアプリ、デスクトップ仮想化、アプリケーションサーバー、一般的な業務システムの移行先として検討しやすいシリーズです。
Dsv7は最大372 vCPU、1,488 GiBメモリ、ネットワーク最大200,000 Mbps、リモートストレージ最大500,000 IOPSに対応します。一方で、Dsv7自体にはローカル一時ディスクがありません。(Microsoft Learn)
Esv7はデータベース・分析・インメモリ処理向け
Esv7は、メモリ最適化ワークロード向けです。SQL Server、NoSQLデータベース、データウェアハウス、BI、Redisなどのインメモリキャッシュ、分析エンジンのように、CPUよりもメモリ容量やメモリ帯域が効きやすい環境で候補になります。
Esv7は最大372 vCPU、2,832 GiBメモリに対応し、Premium SSD v2またはUltra Disk利用時のリモートストレージ性能は最大800,000 IOPS、20,000 MBps、ネットワークは最大400,000 Mbpsとされています。(Microsoft Learn)
ローカル一時ディスクが必要なら「d」付きシリーズを検討する
Dsv7、Dlsv7、Esv7は、基本的にローカル一時ディスクなしの構成です。ローカルNVMe一時ディスクを使いたい場合は、Ddsv7、Dldsv7、Edsv7のような「d」付き派生を検討します。
たとえばDdsv7は最大3,520 GiBのローカルストレージ、最大9,600,000 IOPSのローカルディスク性能を持ちます。Edsv7はメモリ最適化構成にローカルストレージを組み合わせた派生で、最大7,040 GiBのローカルストレージに対応します。(Microsoft Learn)
| シリーズ | 主な用途 | 選定の目安 | 注意点 |
|---|---|---|---|
| Dlsv7 | 軽量Web、API、小規模アプリ、軽めのバッチ | メモリよりCPU単価を重視したい | ローカル一時ディスクなし |
| Dsv7 | 一般的な業務アプリ、Web、VDI、アプリサーバー | CPU・メモリのバランスを取りたい | 大型サイズはクォータ確認が必須 |
| Esv7 | DB、BI、分析、インメモリキャッシュ | メモリ容量・帯域がボトルネック | コア課金ライセンスの影響を確認 |
| Ddsv7 / Dldsv7 / Edsv7 | 一時領域、高速スクラッチ、ローカルNVMe活用 | ローカル一時ディスクが必要 | 一時ディスクは永続データ保存先にしない |
影響を受ける利用者とシステム
今回の更新で直接確認すべきなのは、Azure VMを使っている管理者、インフラ担当者、開発チーム、SRE、コスト管理担当者です。特に次の環境では検討優先度が高くなります。
- Dv6、Dsv6、Dlsv6、Esv6など前世代のIntel系VMを使っている
- CPU使用率が高く、スケールアウトやサイズアップを検討している
- Premium SSD v2、Ultra Disk、複数データディスクの性能を引き出したい
- データベースや分析基盤でメモリ不足、I/O待ち、ネットワーク帯域が課題になっている
- VM Scale SetsやAzure Virtual Desktopでセッション密度・ノード集約を見直したい
- SQL Serverなど、VMサイズ変更がライセンスやコストに直結するワークロードを運用している
一方で、CPU負荷が低いVM、Bシリーズのようなバースト型で足りているVM、ローカル一時ディスクに強く依存する古いWindows構成、アプリ側がシングルスレッドで頭打ちになっている環境では、v7へ変更しても期待ほどの効果が出ない場合があります。
管理者が最初に確認すべき項目
Azure Dl/D/E v7 Virtual Machinesを導入する前に、次の順番で確認すると失敗を減らせます。
| 確認項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| リージョン | 利用リージョンで対象SKUが提供されているか | GAでも全リージョン・全サイズで使えるとは限らない |
| クォータ | Total Regional vCPUsとD/EファミリーのvCPU枠 | クォータ不足でデプロイやリサイズが失敗する |
| 容量 | 希望ゾーン・サイズに実容量があるか | クォータがあってもAzure側容量不足で失敗することがある |
| ローカル一時ディスク | 既存VMがDドライブ、swap、scratchに依存していないか | Dsv7/Dlsv7/Esv7はローカル一時ディスクなし |
| ストレージ | Premium SSD v2、Ultra Disk、ディスク本数、IOPS上限 | VM上限とディスク側上限の両方を見ないと性能が出ない |
| ネットワーク | NIC数、帯域、MANA対応、OS・ドライバー | 公称上限がそのままアプリ性能になるとは限らない |
| コスト | VM単価、ディスク課金、予約、Savings Plan、ライセンス | サイズ変更で課金メーターやライセンス条件が変わる |
vCPUクォータは、サブスクリプションとリージョン単位で「リージョン全体のvCPU」と「VMファミリー別vCPU」の2階層で管理されます。Microsoft Learnでは、どちらかを超えるとVMデプロイが許可されないと説明されています。また、クォータと実容量は別物であり、クォータが足りていても対象リージョンやゾーンに容量がなければデプロイに失敗する可能性があります。(Microsoft Learn)
確認には、Azure CLIで次のように実行できます。japaneastは利用リージョンに置き換えてください。
az vm list-usage --location japaneast -o table対象SKUの提供状況を確認する場合は、次のようにVM SKUを絞り込むと候補を把握しやすくなります。
az vm list-skus \
--location japaneast \
--resource-type virtualMachines \
--query "[?contains(name, '_v7')].{name:name, zones:locationInfo[0].zones, restrictions:restrictions}" \
-o table移行・リサイズ時の実務手順
既存VMをv7世代へ移行する場合は、いきなり本番VMをリサイズするのではなく、段階的に進めるのが安全です。
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 現状把握 | CPU、メモリ、ディスクIOPS、スループット、ネットワーク、P95/P99レイテンシを取得 | 何を改善したいかを明確にする |
| 候補選定 | Dlsv7、Dsv7、Esv7、d付き派生から選ぶ | メモリ比率、一時ディスク要否、ストレージ上限で決める |
| 制約確認 | リージョン、ゾーン、クォータ、容量、予約適用を確認 | デプロイ可能性とコストを事前に見る |
| 検証環境作成 | スナップショットやイメージから検証VMを作る | 本番に近い負荷で比較する |
| 性能比較 | 旧VMと新VMで同じ条件のベンチマークを取る | 平均値ではなくピーク時と尾部レイテンシを見る |
| 移行計画 | 停止時間、ロールバック、DNS/LB切替、バックアップを決める | 失敗時に元へ戻せるかを確認 |
| 本番展開 | 小さい範囲から段階的に切り替える | VMSSならローリング更新や新規プール方式を検討 |
Azure VMのサイズ変更はポータル、PowerShell、CLI、Terraformから実行できます。Microsoft Learnでは、実行中のVMで希望サイズが表示されない場合、停止すると選択可能なサイズが増えることがあると説明されています。また、可用性セット内のVMでは、希望サイズが現在のハードウェアクラスターで利用できない場合、可用性セット内のすべてのVMを割り当て解除してリサイズする必要がある場合があります。(Microsoft Learn)
単体VMのサイズ変更例は次のとおりです。
az vm resize \
--resource-group rg-prod \
--name vm-app-01 \
--size Standard_D16s_v7ただし、停止や再起動が発生し得るため、業務時間外のメンテナンス枠、アプリケーション停止手順、バックアップ、監視アラート抑制、ロールバック用の旧サイズ確認までセットで準備してください。
ローカル一時ディスクなしの落とし穴
v7移行で特に注意したいのが、ローカル一時ディスクです。
Dsv7、Dlsv7、Esv7のような「dなし」シリーズは、ローカル一時ディスクを持ちません。Microsoft Learnでは、ローカル一時ディスクなしのVMでは従来のDドライブのような小さなローカルディスクが存在しないと説明しています。永続データにはStandard HDD、Premium SSD、Ultra Diskなどのリモートストレージを使う必要があります。(Microsoft Learn)
特にWindows VMでは、ページファイルやアプリの一時ファイルがDドライブ前提になっていると、リサイズや起動後の動作に問題が出ることがあります。Microsoft Learnでは、ローカル一時ディスクあり・なしのWindows VM間のリサイズには制約があり、ローカル一時ディスクにページファイルやswapがあるイメージはディスクレスサイズで動作しない可能性があると説明されています。(Microsoft Learn)
確認すべき典型例は次のとおりです。
- WindowsのページファイルがDドライブに固定されている
- バッチ処理が一時ファイルをDドライブへ出力している
- Linuxのswapや一時ディレクトリがローカルディスク前提になっている
- アプリログ、アップロード一時領域、ETLの中間ファイルを一時ディスクに置いている
- カスタムイメージや起動スクリプトが特定のディスク名を前提にしている
このような場合は、Dsv7へ直接移るのではなく、Ddsv7やEdsv7などのローカルディスク付き派生を検討するか、一時領域を管理ディスク、Azure Files、Blob Storage、アプリケーション側の設定に移す必要があります。
ストレージとネットワークは「VM上限」と「構成上限」を分けて見る
v7世代では、ストレージとネットワークの上限が大きくなっています。ただし、公称値は「最大サイズ」「適切なディスク種別」「十分なディスク本数」「対応リージョン」「OS・ドライバー・アプリ側の処理能力」がそろった場合に近づく値です。
たとえばEsv7は、Premium SSD v2またはUltra Diskで最大800,000 IOPS、20,000 MBps、ネットワーク最大400,000 Mbpsとされています。一方、Dsv7はリモートストレージ最大500,000 IOPS、16,000 MBps、ネットワーク最大200,000 Mbpsです。Dlsv7は最大397,000 IOPS、13,145 MBps、ネットワーク最大150,000 Mbpsです。(Microsoft Learn)
性能検証では、次のメトリックを必ず旧VMと新VMで比較してください。
| メトリック | 見る理由 |
|---|---|
| CPU使用率、CPU Ready相当の待ち | CPU性能向上がアプリに効いているかを見る |
| メモリ使用量、ページング、GC時間 | メモリ不足やランタイム側の詰まりを確認する |
| ディスクIOPS、スループット、待機時間 | VM上限ではなく実ディスク構成のボトルネックを見つける |
| ネットワーク送受信、再送、接続数 | NICやアプリ側の制限を確認する |
| P95/P99レイテンシ | 平均値では見えない利用者体感の悪化を防ぐ |
| アプリ別KPI | 注文処理数、検索時間、ジョブ完了時間など実業務に紐づける |
「VMを大きくしたのに速くならない」ケースの多くは、アプリケーションがCPUではなくディスク待ち、DBロック、外部API待ち、メモリ不足、ライセンス制限で詰まっている場合です。v7移行は万能な高速化策ではなく、ボトルネックを特定したうえで使う選択肢と考えるべきです。
開発者が確認すべきポイント
開発者側では、インフラチームから「v7へ移行する」と言われたときに、アプリの動作確認だけで終わらせないことが重要です。
Intel Xeon 6世代では、Intel AVX-512やIntel Advanced Matrix Extensionsなどの機能が説明されています。Dsv7、Dlsv7、Esv7の各ドキュメントでも、これらのCPU機能が記載されています。(Microsoft Learn)
ただし、アプリケーションが自動的にそれらを活用するとは限りません。以下のような確認が必要です。
- Java、.NET、Python、Node.jsなどのランタイムバージョンが古すぎないか
- 数値計算、画像処理、暗号化、圧縮、AI推論ライブラリがCPU機能を利用できるか
- コンテナイメージやOSイメージがv7世代の環境で問題なく起動するか
- アプリのスレッド数、接続プール数、DBプール数が新しいVMサイズに見合っているか
- 負荷試験でCPUだけでなく、DB、キャッシュ、外部サービスまで含めて計測しているか
たとえば、VMだけをD16s_v7へ変更しても、アプリの接続プール上限が10のままなら、処理並列度は増えません。VMサイズ変更に合わせて、アプリ設定、オートスケール条件、キュー処理数、DB接続上限を見直す必要があります。
料金・予約・ライセンスで確認すべきこと
Azure Dl/D/E v7 Virtual Machinesへの移行では、性能だけでなくコストも再評価が必要です。新しいVMへ変更すると、VMサイズ、vCPU数、メモリ、ディスク、ネットワーク、ライセンスの組み合わせが変わります。
特に注意すべきなのは、SQL Server、Oracle、商用ミドルウェアなど、コア数やインスタンス数に応じてライセンス費用が変わる製品です。Esv7のように大きなメモリを持つVMへ集約すると、インフラ費用は効率化できても、ソフトウェアライセンス費用が増える可能性があります。
確認すべき項目は次のとおりです。
- 現在のReserved VM InstancesやSavings Planが新しいサイズに適用されるか
- Azure Hybrid Benefitを使っている場合、OSやSQL Serverの適用条件に問題がないか
- サイズアップでvCPU数が増え、商用ソフトウェアのライセンス費用が増えないか
- ローカル一時ディスクなしへ移ることで、追加の管理ディスク費用が発生しないか
- Premium SSD v2やUltra Diskを使う場合、ディスク性能設定に応じた費用を見積もっているか
- VMを集約した場合、障害時の影響範囲が広がりすぎないか
コスト削減を狙うなら、単純なサイズアップではなく「同等性能をより少ないVM数で出せるか」「過剰メモリのVMをDlsv7へ寄せられるか」「ピーク時間だけVMSSで増減できるか」を検討すると効果が出やすくなります。
よくある失敗と回避策
| 失敗例 | 原因 | 回避策 |
|---|---|---|
| GAなので全リージョンで使えると思い込む | SKU提供、ゾーン、容量は地域差がある | 事前にaz vm list-skusとポータルで確認する |
| クォータ申請を忘れる | D/EファミリーvCPU枠が足りない | 検証前にTotal Regional vCPUsとファミリー別vCPUを確認する |
| Dドライブ前提のWindows VMをDsv7へ移す | ローカル一時ディスクなしを見落とす | ページファイル、一時領域、スクリプトを確認する |
| 20％性能向上をそのまま期待する | ワークロード依存で効果が変わる | 実アプリの負荷試験でP95/P99まで測る |
| 大型サイズを選べばよいと考える | ライセンス費、可用性、障害影響が増える | スケールアップとスケールアウトを比較する |
| ストレージ性能が出ない | ディスク本数やディスク種別が不足 | VM上限とディスク側上限を両方確認する |
| 可用性セット内で一部VMだけリサイズする | ハードウェアクラスター制約がある | 必要に応じて可用性セット全体の停止計画を立てる |
なお、Microsoft Learnの一部v7サイズ表では、248 vCPUや372 vCPUなど一部大型サイズについて「まもなく一般提供」とする注記が見られます。シリーズ全体がGAとして発表されていても、利用したい最大サイズが実際に選択できるかは、リージョンとタイミングごとに確認してください。(Microsoft Learn)
まず実施すべきチェックリスト
Azure Dl/D/E v7 Virtual Machinesを検討する場合、最初のアクションは次の5つです。
| 優先度 | 実施内容 | 目的 |
|---|---|---|
| 高 | 既存D/E系VMのCPU、メモリ、I/O、ネットワーク使用率を一覧化 | 移行候補を絞る |
| 高 | 対象リージョンでDlsv7、Dsv7、Esv7、d付き派生の提供状況を確認 | 使えるSKUを把握する |
| 高 | vCPUクォータと容量制約を確認 | デプロイ失敗を防ぐ |
| 中 | ローカル一時ディスク依存を調査 | 移行後の起動不具合を防ぐ |
| 中 | 検証VMで実アプリの負荷試験を行う | 期待効果とコストを判断する |
今回のGAは、Azure VMを使う企業にとって「すぐ全VMを置き換えるべき更新」ではなく、「性能・集約・コストを見直すための新しい選択肢」です。特にD/E系の前世代VMでCPU、メモリ、ディスクI/O、ネットワークのいずれかがボトルネックになっている環境では、Dlsv7、Dsv7、Esv7を候補に入れる価値があります。
一方で、移行の成否はVMサイズそのものより、事前確認の質で決まります。まずは対象ワークロードを棚卸しし、リージョン、クォータ、ローカル一時ディスク、ストレージ、ライセンス、性能指標を確認してください。そのうえで小さな検証環境から始め、旧VMとの比較結果をもとに、本番展開の可否を判断するのが最も安全です。
コメント