Azure Migrate

解決する課題

オンプレミスや他クラウドにある資産を Azure へ移すとき、何があるか・何をどう移すか・移したら幾らかかるかを、ばらばらのツールで把握せず1か所で進めたい場面で使います。

• 物理/仮想サーバーやデータベースがどれだけあるか把握できていないため、まず棚卸し（検出）したい
• 移行先の VM サイズ・コスト・互換性を、推測ではなく実測の使用率に基づいて評価したい
• サーバー・データベース・Web アプリといった複数種類の移行を1つの進捗ダッシュボードで管理したい
• 個別の移行ツールを別々に運用せず、検出から移行までを同じプロジェクトで完結させたい
• 移行前に依存関係を可視化し、まとめて動かすべきサーバー群（移行ウェーブ）を見極めたい

主要概念と用語

• Azure Migrate プロジェクト: 検出・評価・移行の状態を集約する入れ物。すべての作業はこのプロジェクト単位で管理される
• Azure Migrate アプライアンス: オンプレ環境に配置する軽量な仮想/物理アプライアンス。サーバーを検出し、構成と使用率（パフォーマンス）データを Azure へ送る
• 検出（Discovery）: アプライアンスが環境内のサーバー・データベース・Web アプリを見つけ、インベントリ化する工程
• 評価（Assessment）: 検出したサーバーについて、Azure 適合性・推奨 VM サイズ・月額コストの見積もりを算出する工程。推奨は「実測のパフォーマンス基準」か「オンプレ構成基準」で行える
• 依存関係マッピング（Dependency analysis）: サーバー間の通信を可視化し、一緒に移行すべきグループを把握する機能
• 移行ツール（Migration tools）: 実際の移行を担う機能。サーバーのレプリケーションと切り替え、データベース移行、Web アプリ移行などを提供する
• エージェントレス / エージェントベース: 検出・移行の方式。多くのシナリオはエージェントレスで進められるが、物理サーバーなど一部はエージェントを使う

仕様・制限・クォータ

• 1つのプロジェクトでサーバー・データベース・Web アプリなど複数のワークロード種別を扱える。サーバー移行は VMware・Hyper-V・物理/他クラウドの VM に対応する
• 検出はアプライアンスを起点に行う。アプライアンスは管理対象環境にアクセスでき、Azure へアウトバウンドで通信できる必要がある
• 評価の推奨は、実測のパフォーマンスデータ（一定期間の使用率を収集）に基づくものと、オンプレの割り当て構成に基づくものを選べる。前者の方がサイズとコストを最適化しやすい
• データベース移行は Azure Database Migration Service（DMS）系の機能と連携し、SQL などをマネージドな移行先へ移す。Web アプリは App Service への移行を支援する
• 検出・評価できるサーバー台数や、1アプライアンスあたりの収集規模には上限がある。大規模環境では複数アプライアンスへの分割を検討する。具体的な上限値は変動するため公式ドキュメントで確認する

内部の仕組み

オンプレ環境に配置した Azure Migrate アプライアンスが、vCenter や Hyper-V、物理サーバーへ接続してインベントリと使用率を継続的に収集し、アウトバウンド HTTPS で Azure 側のプロジェクトへメタデータを送ります。集まったデータをもとに、評価エンジンが各サーバーの Azure 適合性・推奨サイズ・概算コストを算出します。

実際のサーバー移行では、対象 VM のディスクを Azure へ継続的にレプリケーションします。本番を動かしたまま差分を同期し続け、準備が整った時点で短い停止で**切り替え（カットオーバー）**して Azure 上の VM を本稼働させる、という流れです。これにより停止時間を最小化できます。

• アプライアンスが集める実測データが、サイズとコスト見積もりの精度を左右する
• 移行はレプリケーション主体で、テスト移行により本番切り替え前に動作検証できる
• 評価と移行は疎結合で、評価せずに移行することも、評価だけ繰り返すこともできる

設計パターン / ベストプラクティス

• 十分な収集期間を取る: 評価は数日〜数週間の実測使用率に基づくとサイズ最適化が効く。繁忙期を含む期間で取ると過小評価を避けられる
• 依存関係でウェーブ化: 依存関係マッピングで密に通信するサーバー群を1つの移行ウェーブにまとめ、半端に分断しない
• テスト移行を必ず実施: 本番切り替え前にテスト移行で隔離ネットワーク上の動作を確認し、想定外を潰す
• 段階的カットオーバー: 重要度の低いウェーブから移行して手順を磨き、本番クリティカルなものは後半に回す
• 移行後の最適化: 移行直後は評価どおりのサイズで動かし、Azure 上の実測でさらに右サイズ化やリザーブド購入を検討する

運用・監視

• プロジェクトのダッシュボードで、検出済み台数・評価状況・移行（レプリケーション）の進捗をまとめて確認する
• アプライアンスの接続状態と収集の鮮度を監視する。データが古い場合はネットワーク・認証情報・アプライアンスの稼働を順に確認する
• 移行中はレプリケーションの健全性と差分の遅延を見て、切り替え可能なタイミングを判断する
• 切り替え後は Azure Monitor で移行先 VM やアプリの性能を観測し、評価との乖離があれば右サイズ化する

コスト

Azure Migrate のツール自体（検出・評価・移行のオーケストレーション）は基本的に追加料金なしで使えるのが特徴です。費用が発生するのは、移行先で稼働させる Azure リソース（VM・ストレージ・データベースなど）と、移行中のレプリケーションに伴うストレージ、一部のサードパーティ製移行ツールを併用する場合などです。つまり「評価して計画する」ところまではほぼ無償で、課金は移行で生まれた Azure 資産側に乗る、という考え方です。変動する単価は公式の料金ページで確認してください。

セキュリティ

• アプライアンスから Azure への通信はアウトバウンド HTTPS が基本で、インバウンドの口を開ける必要はない。閉域要件にはプライベートエンドポイントで対応できる
• オンプレ側の接続に使う認証情報は最小権限で用意し、アプライアンスに安全に保管する。検出に不要な高権限を与えない
• プロジェクトへのアクセスは Microsoft Entra ID + Azure RBAC で制御し、誰が評価・移行を実行できるかを統制する
• 移行されるディスクやデータは Azure 側で保存時暗号化され、必要に応じて Key Vault のキーで管理できる
• 移行先 VM やネットワークのセキュリティ設計（NSG・Firewall・Defender）は移行とは別に設計し、リフト後に無防備にならないようにする

Well-Architected の観点

• オペレーショナルエクセレンス（Operational Excellence）: 検出・評価・移行を1つのプロジェクトに集約し、進捗とコスト見積もりを一元的に把握できる。実測ベースの評価とテスト移行により、計画と実行を再現性のある手順に落とし込める
• 副次的にコスト最適化にも寄与する。実測使用率に基づく右サイズ化で、移行先の過大プロビジョニングを避けられる
• 一方で、移行先の信頼性・セキュリティ設計は Migrate の責務外であり、移行後に別途 Well-Architected の各柱で設計し直す前提を忘れないこと

試験で問われるポイント

関連サービス・比較

Azure Migrate は AWS で言えば、移行の進捗を集約する AWS Migration Hub と、サーバーをレプリケーションして移行する **AWS Application Migration Service（MGN）**を合わせたような位置づけです。検出・評価の「司令塔」と、実際にサーバーを動かす「移行実行」の両方を1つのプロジェクトで担います。

ハンズオン / CLI例

# リソースグループを作成
az group create --name migrate-rg --location japaneast

# Azure Migrate は主にポータルとアプライアンスで操作するが、
# 移行先となる Azure 側のリソース準備は CLI で進められる。

# 移行先の仮想ネットワークとサブネットを用意
az network vnet create \
  --resource-group migrate-rg \
  --name migrate-vnet \
  --address-prefix 10.20.0.0/16 \
  --subnet-name workload-subnet \
  --subnet-prefix 10.20.1.0/24

# レプリケーション/移行で使うストレージアカウントを作成
az storage account create \
  --resource-group migrate-rg \
  --name migratestg0627 \
  --location japaneast \
  --sku Standard_LRS

# プライベート接続を使う場合のプライベートエンドポイント用サブネットを追加
az network vnet subnet create \
  --resource-group migrate-rg \
  --vnet-name migrate-vnet \
  --name pe-subnet \
  --address-prefix 10.20.2.0/24

# 移行進捗の確認や検出・評価・実移行はポータルの
# Azure Migrate プロジェクトから実施する
# （アプライアンスの登録、評価作成、レプリケーション開始、カットオーバー）