Azure Cobalt 200 Arm-based Virtual Machinesは、Azure VMでArmベースの選択肢を広げる重要なプレビューです。結論から言うと、Dpsv7、Dplsv7、Epsv7に加え、高メモリ向けのMpsv4、ローカルストレージ密度を重視したLpsv5が加わり、Linuxベースのクラウドネイティブワークロード、Web/API、キャッシュ、データ処理、AKSのArm64ノード検証に向いています。
ただし、すぐに本番VMを置き換える発表ではありません。Azure Updates上の「In development」は、選定された顧客向けの非本番・テスト用途という位置付けであり、公開範囲・リージョン・仕様が変わる可能性があります。管理者や開発者は、まずArm64対応、リージョン、クォータ、OSイメージ、コンテナイメージ、監視・セキュリティエージェント、IaCのSKU指定を確認するのが現実的です。(Microsoft Azure)
Azure Cobalt 200 Arm-based Virtual Machinesとは
Azure Cobalt 200 Arm-based Virtual Machinesは、Microsoftが発表した第2世代ArmベースCPU「Azure Cobalt 200」を利用する新しいAzure VM群です。Microsoftは、Cobalt 200 VMをLinuxベースのagentic AI、スケールアウト、クラウドネイティブ用途向けの早期アクセスプレビューとして説明しており、Cobalt 100世代と比べた性能向上も示しています。(Microsoft Azure)
今回の対象は、主に以下の5系統です。
| VMシリーズ | 位置付け | 主な用途 |
|---|---|---|
| Dplsv7 / Dpldsv7 | 汎用・低メモリ寄り | マイクロサービス、小規模DB、キャッシュ、ゲームサーバーなど |
| Dpsv7 / Dpdsv7 | 汎用 | Webサーバー、アプリケーションサーバー、小〜中規模DB、キャッシュなど |
| Epsv7 / Epdsv7 | メモリ最適化 | 大規模リレーショナルDB、NoSQL、RedisやMemcached、リアルタイム分析など |
| Mpsv4 / Mpdsv4 | 高メモリ最適化 | 大規模インメモリDB、ERP、大規模キャッシュ、メモリ集約型分析など |
| Lpsv5 | 高密度ローカルストレージ | データ前処理、ステージング、ローカルストレージを必要とするDB、ビッグデータ、検索・インデックス用途など |
Microsoftの公式ブログでは、Dplsv7/Dpldsv7、Dpsv7/Dpdsv7、Epsv7/Epdsv7は最大128 vCPU、Mpsv4/Mpdsv4は最大84 vCPU、Lpsv5は最大128 vCPUと説明されています。Lpsv5は全サイズでローカルNVMeストレージを持ち、最大23TBのローカルNVMe構成が示されています。(Microsoft Azure)
何が変わるのか
ArmベースVMの用途が「汎用・メモリ最適化」から広がる
Cobalt 100世代では、主にDplsv6、Dpsv6、Epsv6などの汎用・メモリ最適化系が中心でした。Microsoft Learnでも、Cobalt 100ベースVMはスケールアウト、クラウドネイティブLinuxワークロード、データ分析、Web/API、オープンソースDB、キャッシュなどを対象にしていたことが説明されています。(Microsoft Learn)
Cobalt 200では、従来の汎用・メモリ最適化に加えて、Mpsv4の高メモリ系、Lpsv5の高密度ローカルストレージ系が加わります。これにより、ArmベースVMの検討対象が「Webサーバーや軽量なマイクロサービス」だけでなく、キャッシュ基盤、分析基盤、検索基盤、ローカルNVMeを使う一時処理基盤まで広がります。
CPU、ストレージ、ネットワークの性能向上が示されている
Microsoftは、Cobalt 200 VMについて、Cobalt 100世代と比べて最大50%のCPU性能向上、NVMe利用時のリモートストレージIOPS最大20%向上、リモートストレージスループット最大10%向上、ネットワーク帯域最大15%向上を説明しています。ただし、いずれも「最大」であり、実際の効果はワークロードによって変わります。(Microsoft Azure)
実務では、公式値をそのまま移行判断に使うのではなく、自社のアプリケーションで以下を測る必要があります。
| 評価項目 | 見るべき指標 | 判断のポイント |
|---|---|---|
| Web/API | p95・p99レイテンシ、RPS、CPU使用率 | 同じリクエスト量でCPU余力が増えるか |
| DB・キャッシュ | IOPS、スループット、待機時間、メモリ使用量 | CPUではなくI/Oやメモリがボトルネックになっていないか |
| バッチ・データ処理 | 処理時間、読み書き量、一時領域使用量 | Lpsv5のローカルNVMeが効く処理か |
| AKS | Pod起動時間、ノード使用率、再スケジュール時間 | Arm64ノードへ安全に分散できるか |
| コスト | 1リクエストあたりのコスト、1ジョブあたりのコスト | 単価ではなく処理量あたりで比較する |
Azure Boost、メモリ暗号化、ローカルNVMeの扱いが重要になる
Cobalt 200 VMではAzure Boost統合により、リモートストレージやネットワーク性能の改善が説明されています。また、Cobalt 200ではメモリ暗号化が既定で有効になるとされています。これはセキュリティの底上げとして有益ですが、アプリケーション側の認証、Key Vault、ディスク暗号化、ネットワーク制御が不要になるわけではありません。(Microsoft Azure)
注意したいのはローカルNVMeです。ローカルストレージは高速ですが、永続データの保存先として扱うべきではありません。Azureのローカル一時ストレージは、キャッシュ、バッファ、一時ファイルのように失われても復旧できる用途に向き、VMの割り当て解除や削除で失われると説明されています。(Microsoft Learn)
たとえば、Lpsv5を検索インデックスや一時的なETL処理に使うのは検討しやすい一方、唯一のDB保存先として使うのは危険です。永続データはManaged Disk、データベースのレプリケーション、バックアップ、別リージョンへの保護設計と組み合わせて考える必要があります。
対象者と影響範囲
Azure VM管理者
Azure VMを直接管理している場合、最初に確認すべきなのは「既存VMをそのままリサイズできるか」ではありません。Azure VMのサイズ変更は、実行中VMの再起動を伴う破壊的な操作として扱うべきであり、場合によってはVMの割り当て解除が必要になります。特にステートフルなワークロードでは、単純なサイズ変更ではなく、別VMまたは別VMSSへの段階的移行を前提にした方が安全です。(Microsoft Learn)
管理者が確認すべき項目は次の通りです。
| 確認項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| リージョン | 対象リージョンにSKUがあるか | 日本リージョンで使える前提で設計してしまう |
| クォータ | Arm系VMファミリのvCPU上限 | SKUは見えるが作成時にクォータで失敗する |
| OSイメージ | Arm64対応のLinuxイメージか | x64用カスタムイメージを流用しようとする |
| 拡張機能 | 監視、EDR、バックアップ、構成管理エージェント | Arm64版が未提供、または制限付き |
| ディスク | ローカルNVMeとManaged Diskの役割分担 | 一時領域に永続データを置く |
| IaC | Bicep、ARM Template、TerraformのSKU指定 | SKU名を固定しすぎてリージョン展開に失敗する |
AKS管理者
AKSで利用する場合は、Arm64ノードプールを既存クラスタに追加して検証する流れが現実的です。Microsoft Learnでは、AKSにArm64 VMを追加でき、IntelとArmのアーキテクチャを同一クラスタ内で混在させられると説明されています。一方で、WindowsノードプールではArm64 VMはサポートされず、既存ノードプールをArm64 VMへ更新することもできません。(Microsoft Learn)
つまり、既存のx86ノードプールをその場でArm化するのではなく、新しいArm64ノードプールを追加し、ラベル、taint、nodeSelector、affinityを使って対象Podだけを段階的に移す設計が必要です。
AKSでは、次のような切り分けが有効です。
| ワークロード | Arm64移行の進め方 |
|---|---|
| ステートレスAPI | Arm64ノードプールに一部Podをカナリア配置 |
| バッチ処理 | ジョブ単位でArm64ノードへ振り分け、処理時間と失敗率を比較 |
| キャッシュ | レプリカ構成を前提に一部ノードで検証 |
| DB系Pod | ストレージ、バックアップ、復旧手順を検証してから限定的に実施 |
| Windowsコンテナ | 今回のArm64ノード検証対象から外す |
また、AKSの複数ノードプールでは、作成後にノードプールのVMサイズを変更できない制限があります。サイズ選定を誤るとノードプールの作り直しが必要になるため、検証用ノードプールは小さく始め、メトリックを見て作り直せる前提で設計すると安全です。(Microsoft Learn)
開発者・アプリケーション担当者
開発者にとって最も大きい確認点は、アプリケーションがArm64で正しく動くかです。Java、.NET、Python、Rust、C++などの主要な開発言語ではArmネイティブ対応が進んでいますが、アプリケーション全体が自動的にArm64対応になるわけではありません。Microsoftは、主要な開発プラットフォームや言語でArmネイティブ版が提供され、AKSやコンテナイメージのArm対応も広がっていると説明しています。(Microsoft Azure)
特に次の依存関係は見落とされやすいポイントです。
| 領域 | 確認例 |
|---|---|
| Python | arm64対応wheelがあるか、ネイティブ拡張をソースビルドできるか |
| Node.js | npmパッケージにネイティブバイナリ依存がないか |
| Java | JNI、暗号化ライブラリ、圧縮ライブラリがarm64対応か |
| .NET | Runtime Identifier、ネイティブAOT、外部DLL依存を確認 |
| Go / Rust | CGO、外部Cライブラリ、ビルドターゲットを確認 |
| コンテナ | linux/arm64イメージを提供しているか |
| 監視 | APMエージェント、ログ収集、メトリック収集のArm64対応 |
「コンテナが起動した」だけでは移行完了とは言えません。暗号化処理、圧縮処理、画像処理、PDF生成、データベースドライバ、機械学習ライブラリなど、CPUアーキテクチャ依存のある処理を重点的にテストしてください。
利用可能リージョンと日本リージョンでの注意点
Microsoftの公式ブログでは、Cobalt 200 Arm-based VMのプレビュー提供リージョンとして、West US3、East US2、Central US、Sweden Central、East US、West US2、Spain Central、Indonesia Centralが挙げられています。追加リージョンは今後発表予定とされていますが、このリストにはJapan EastやJapan Westは含まれていません。(Microsoft Azure)
日本の組織が検証する場合は、次の点に注意が必要です。
| 条件 | 判断 |
|---|---|
| 個人情報や機密データを扱う | 日本リージョン外に出せない場合は、本番データを使わない |
| レイテンシが重要 | 日本から遠いリージョンでの結果を本番性能として扱わない |
| DRやBCP要件がある | プレビュー対象リージョンだけで可用性設計を確定しない |
| 社内規定でプレビュー利用に制限がある | 非本番・検証用途に限定し、承認を取る |
| 将来的に日本リージョンで使いたい | IaCでリージョンとSKUをパラメータ化しておく |
現時点では、「日本リージョンの本番ワークロードをすぐ移す」よりも、「Arm64対応の検証、ベンチマーク、コンテナイメージ整備、IaC修正を先に進める」段階と考えるのが妥当です。
管理者が確認すべき設定項目
SKUとリージョンを確認する
プレビューアクセスが有効になったら、まず対象リージョンでSKUが見えるか確認します。SKU名や提供範囲はプレビュー中に変わる可能性があるため、IaCに固定値を埋め込む前にCLIで確認するのが安全です。
az vm list-skus \
--location eastus2 \
--resource-type virtualMachines \
--all \
--query "[?contains(name, 'ps_v7') || contains(name, 'pls_v7') || contains(name, 'ps_v4') || contains(name, 'ps_v5')].{name:name, zones:locationInfo[0].zones, restrictions:restrictions}" \
-o tableSKUが表示されない場合は、主に次の可能性があります。
| 状況 | 考えられる原因 |
|---|---|
| SKUが出てこない | プレビューアクセスが未承認、対象リージョン外、CLI/API側の反映前 |
| SKUは出るが作成できない | クォータ不足、サブスクリプション制限、リージョン制限 |
| 一部サイズだけ使えない | ゾーン制限、容量制限、プレビュー提供範囲の違い |
| IaCだけ失敗する | APIバージョン、SKU名、イメージ、ゾーン指定の不整合 |
クォータと容量を確認する
新しいVMシリーズでは、既存のD/E/M/L系クォータとは別に制限が見えることがあります。検証前に、対象リージョンのvCPU使用状況を確認します。
az vm list-usage \
--location eastus2 \
-o table本番移行を見据える場合は、検証環境で1台作れたかどうかでは不十分です。VM Scale Sets、AKSノードプール、ゾーン分散、ローリング更新時の一時的な増加分まで含めて必要vCPUを見積もってください。
OSイメージとカスタムイメージを確認する
Arm64 VMでは、x64向けのOSイメージやカスタムイメージをそのまま使えません。Marketplaceイメージを使う場合はArm64対応のLinuxイメージを選び、カスタムイメージを使う場合はビルドパイプラインから見直します。
確認すべき項目は次の通りです。
| 項目 | 確認内容 |
|---|---|
| OS | Arm64対応のLinuxディストリビューションか |
| ブート方式 | Gen2前提の構成に対応しているか |
| パッケージ | arm64リポジトリから取得できるか |
| カーネルモジュール | 独自ドライバやセキュリティ製品が対応しているか |
| 初期化処理 | cloud-init、拡張機能、構成管理がarm64で動くか |
| ゴールデンイメージ | x64前提のスクリプトやバイナリを含んでいないか |
コンテナイメージをArm64対応にする
AKSやコンテナベースのアプリケーションでは、マルチアーキテクチャ対応が重要です。linux/amd64だけのイメージでは、Arm64ノード上で動かない、または意図しないエミュレーションに依存する可能性があります。
確認例は以下です。
docker manifest inspect <image-name>:<tag>CI/CDでは、少なくとも次の2つを分けて管理してください。
| 種類 | 用途 |
|---|---|
linux/amd64 | 既存x86環境向け |
linux/arm64 | Cobalt 200やArm64 AKSノード向け |
実務では、タグ名だけで判断せず、デプロイ時に実際のノードアーキテクチャとイメージアーキテクチャが一致しているかを確認します。
kubectl get nodes -o wide
kubectl describe node <node-name> | grep -i architectureIaCのSKU指定を見直す
Bicep、ARM Template、TerraformなどでVMサイズを固定している場合、Cobalt 200検証用にパラメータ化しておくと安全です。
避けたい書き方は、環境ごとにSKU名を直接ベタ書きすることです。代わりに、以下のように環境別パラメータで切り替えられる形にします。
| パラメータ | 例 |
|---|---|
location | eastus2、westus3など |
vmSize | Standard_D...形式のSKU |
imageArchitecture | Arm64相当の選定条件 |
useLocalNvme | ローカルNVMeを前提にするか |
workloadProfile | web、cache、batch、searchなど |
プレビュー中は、SKU名、サイズ、リージョン、制限が変更される可能性があります。TerraformのplanやBicepのwhat-ifだけで安心せず、実際の作成、再デプロイ、削除、スケール、ロールバックまで確認しておくべきです。
移行・検証の進め方
まず移行候補を絞る
最初の候補は、ステートレスで水平スケールしやすいLinuxワークロードです。Web/API、キュー処理、バッチ、キャッシュ、検索インデックス生成、CIランナーなどは検証しやすい領域です。
一方で、以下のワークロードは慎重に扱います。
| ワークロード | 慎重にすべき理由 |
|---|---|
| 商用ソフトウェア | Arm64版のライセンス・サポート条件が不明な場合がある |
| 独自ドライバ依存 | x64カーネルモジュールを流用できない |
| Windows Server前提 | 今回の主対象はLinuxベースのArm VM |
| 単一構成のDB | ローカルディスクや停止時の影響が大きい |
| 低レイテンシ本番系 | プレビューリージョンが日本から遠い可能性がある |
検証環境を本番と分離する
In development / Private Preview相当の機能は、検証専用のサブスクリプションまたはリソースグループで扱うのが安全です。タグ、予算アラート、権限、ネットワーク境界を本番と分けてください。
推奨する検証単位は次の通りです。
| フェーズ | 目的 | 成果物 |
|---|---|---|
| 互換性確認 | 起動・ビルド・テストが通るか | Arm64対応リスト |
| 小規模性能検証 | 同一条件でx86/Cobalt 100と比較 | ベンチマーク結果 |
| 運用検証 | 監視、ログ、バックアップ、パッチ適用 | 運用手順 |
| 障害検証 | 再起動、再作成、ノード障害、ロールバック | 復旧手順 |
| 限定カナリア | 一部トラフィックで実測 | 移行可否判断 |
比較基準を決めてからベンチマークする
Cobalt 200の公式説明には大きな性能向上が示されていますが、ワークロードごとの差があります。検証では「速くなったか」ではなく、「何がどれだけ改善したら採用するか」を先に決めてください。
たとえば、次のような基準です。
| 採用基準 | 例 |
|---|---|
| 性能 | p95レイテンシが10%以上改善、または同等性能でCPU使用率が下がる |
| コスト | 1,000リクエストあたりのコストが下がる |
| 安定性 | 24〜72時間の連続負荷でエラー率が増えない |
| 運用性 | 監視、ログ、脆弱性管理、バックアップが既存運用に乗る |
| 可搬性 | x86環境へ即時ロールバックできる |
「CPU性能は上がったが、アプリのボトルネックは外部DBだった」という結果はよくあります。その場合、VM単体の性能ではなく、システム全体のボトルネックを再評価する必要があります。
展開時の注意点
本番置換ではなくブルーグリーンまたはカナリアで進める
既存VMを直接リサイズする移行は、再起動や割り当て解除の影響を受けやすく、切り戻しも複雑になります。特にx86からArm64への移行では、別環境を作って段階的にトラフィックを流す方が安全です。
おすすめは次の流れです。
| 手順 | 内容 |
|---|---|
| 新環境作成 | Cobalt 200 VMまたはArm64ノードプールを別に作る |
| 同一構成化 | OS、ミドルウェア、設定、シークレット、監視を揃える |
| テスト流量投入 | 内部トラフィックまたは一部ユーザーだけ流す |
| メトリック比較 | レイテンシ、エラー率、CPU、メモリ、I/Oを比較 |
| 段階拡大 | 5%、25%、50%のように増やす |
| ロールバック | DNS、Load Balancer、Ingress、スケール設定で戻す |
ローカルNVMeを「速い永続ディスク」と誤解しない
Lpsv5やd付きサイズのローカルNVMeは魅力的ですが、永続化が必要なデータの唯一の保存先には向きません。ローカル一時ストレージは、失われても再生成できるデータに使うべきです。(Microsoft Learn)
向いている用途は以下です。
| 向いている | 向いていない |
|---|---|
| キャッシュ | 唯一のDBデータ |
| 一時ファイル | 監査ログの唯一の保存先 |
| ETLの中間データ | バックアップなしの検索インデックス |
| 再生成可能なインデックス | 顧客データの原本 |
| ビルド・テストの作業領域 | 復旧不能なセッション情報 |
セキュリティ製品と監視エージェントのArm64対応を確認する
VMが起動してアプリが動いても、監視やセキュリティが抜け落ちると本番運用には進めません。以下は必ず確認してください。
| 項目 | 確認ポイント |
|---|---|
| Microsoft Defender系 | 対象OS・アーキテクチャ・拡張機能の対応 |
| Azure Monitor Agent | インストール、ログ収集、メトリック収集 |
| APM | arm64対応パッケージ、サンプリング、トレース |
| 脆弱性管理 | スキャンエージェントやSBOM生成 |
| バックアップ | VM単位で必要か、アプリ側で保護するか |
| パッチ管理 | OS更新、再起動、カーネル更新の流れ |
Cobalt 200のメモリ暗号化は有益な基盤機能ですが、アプリケーションや運用のセキュリティ設計を代替するものではありません。通信の暗号化、秘密情報管理、IDベースのアクセス制御、ログ監査は従来通り必要です。
すぐに確認すべきチェックリスト
| チェック | 確認内容 |
|---|---|
| プレビュー利用条件 | 自社・自チームでIn development / Private Previewを使えるか |
| リージョン | 対象リージョンが社内規定、データ所在地、レイテンシ要件に合うか |
| SKU | Dpsv7、Dplsv7、Epsv7、Mpsv4、Lpsv5のどれが用途に合うか |
| クォータ | 検証台数だけでなく、スケール時のvCPUを確保できるか |
| OS | Arm64対応Linuxイメージを使えるか |
| アプリ | ネイティブ依存、ライブラリ、コンテナがarm64対応か |
| AKS | 既存ノードプール更新ではなく、新規Arm64ノードプール追加で設計しているか |
| ストレージ | ローカルNVMeに永続データを置かない設計か |
| 監視 | ログ、メトリック、APM、アラートが取れるか |
| ロールバック | x86または既存VMへ戻す手順があるか |
| IaC | SKU、リージョン、イメージをパラメータ化しているか |
| コスト | VM単価ではなく、処理量あたりのコストで比較する準備があるか |
どのシリーズを選ぶべきか
迷った場合は、既存ワークロードのボトルネックから選びます。シリーズ名だけで選ぶのではなく、CPU、メモリ、I/O、ローカルストレージのどれが効くかを確認してください。
| 状況 | 候補 | 理由 |
|---|---|---|
| Web/API、一般的なLinuxサーバー | Dpsv7 | CPUとメモリのバランスが取りやすい |
| メモリ消費が小さい大量のマイクロサービス | Dplsv7 | メモリ比率を抑えたスケールアウトに向く |
| Redis、Memcached、分析、DB | Epsv7 | メモリ比率が高く、キャッシュやDBに向く |
| 大規模インメモリ処理、ERP、巨大キャッシュ | Mpsv4 | 高メモリ比率が必要な処理向け |
| ローカルNVMeを使うデータ前処理・検索 | Lpsv5 | 高密度ローカルストレージを活用しやすい |
実務では、最初から大きいサイズを選ばず、小さめのサイズでアプリ互換性を確認し、その後にCPU・メモリ・I/Oのメトリックを見てサイズを上げる方が失敗しにくくなります。
現時点でのおすすめアクション
Azure Cobalt 200 Arm-based Virtual Machinesは、将来的にAzure上のArmワークロードを広げる有力な選択肢です。特に、Linuxベースのスケールアウトアプリ、AKS、キャッシュ、データ処理、検索基盤では、早めにArm64対応を進めておく価値があります。
一方で、現時点ではIn development / Private Preview相当の扱いであり、本番移行を急ぐ段階ではありません。まずは次の順序で進めるのが安全です。
- 対象ワークロードをステートレスなLinuxアプリから選ぶ
- Arm64対応のOS、依存ライブラリ、コンテナイメージを確認する
- 対象リージョンとクォータを確認する
- IaCのSKU・リージョン・イメージ指定をパラメータ化する
- Cobalt 100または既存x86環境と同じ条件でベンチマークする
- AKSでは新規Arm64ノードプールを追加し、カナリアで検証する
- ローカルNVMeは一時データ専用として設計する
- 監視、セキュリティ、バックアップ、ロールバック手順まで確認する
この発表の本質は、「新しいVMサイズが増えた」ことだけではありません。Azure上でArm64を前提にした設計、ビルド、運用を現実的に検証するタイミングが来たことです。まずは本番移行ではなく、Arm64対応の棚卸しと小規模な検証環境の構築から始めるのが、最もリスクの低い進め方です。
コメント