VMware ワークロードの移行戦略 - MGN と EVS を使い分ける段階的アプローチ

VMware ワークロードを AWS へ移行する際の MGN (Application Migration Service) と EVS の使い分け、段階的移行計画の立て方、移行後の最適化を解説します。

VMware 移行の 3 つのアプローチ

VMware ワークロードを AWS へ移行する方法は大きく 3 つに分類されます。第一のリフト & シフトは、Amazon EVS を使って VMware 環境をそのまま AWS 上に移設する方法です。アプリケーションの変更は不要ですが、VMware ライセンスは引き続き必要です。第二のリプラットフォームは、AWS MGN (Application Migration Service) を使って VMware VM を EC2 インスタンスに変換する方法です。VMware ライセンスから解放されますが、OS やミドルウェアの互換性検証が必要です。第三のリファクタリングは、アプリケーションをコンテナ化して ECSEKS で稼働させる方法です。最もクラウドネイティブな形態ですが、アプリケーションの改修工数が大きくなります。

移行アセスメントと計画策定

移行に先立ち、AWS Migration Hub で既存環境のインベントリを収集し、ワークロード間の依存関係をマッピングします。Migration Evaluator (旧 TSO Logic) を使えば、現在のオンプレミス環境の利用状況データから AWS 上での最適な構成とコスト試算を算出できます。アセスメントの結果に基づいて、各ワークロードを EVS、MGN、リファクタリングのいずれで移行するかを判定します。判定基準として、VMware 固有の機能 (vMotion、DRS、HA) への依存度が高いワークロードは EVS、標準的な Linux/Windows サーバーは MGN、マイクロサービス化が見込めるアプリケーションはリファクタリングを選択します。

MGN による EC2 移行の実践

AWS MGN は、ソースサーバーにエージェントをインストールし、ブロックレベルの継続的レプリケーションで AWS 上にレプリカを作成します。レプリケーション中もソースサーバーは稼働し続けるため、業務への影響はありません。テスト起動でレプリカの動作を検証し、問題がなければカットオーバーを実行して本番切り替えを行います。カットオーバー時のダウンタイムは、最終差分の同期時間のみ (通常数分から数十分) です。 MGN はエージェントが VMware Tools と共存できるため、 vSphere 環境のサーバーにそのままインストールできます。移行後は EC2 インスタンスとして稼働するため、 Auto Scaling や ALB との統合など AWS ネイティブの機能を活用できます。 移行プロジェクトの知見を広げたい場合はAmazon の専門書も活用できます。

移行コストの考慮

MGN の利用料金は無料で、レプリケーション用のステージングエリア (EC2 + EBS) のコストのみ発生します。EVS は専用ホスト (i4i.metal) の料金が主要なコスト要因で、最小 3 ホスト構成で月額約 15,000 ドル以上です。移行方式の選択はコストに大きく影響するため、MGN による EC2 移行 (低コスト、アプリ変更必要) と EVS による VMware 環境移設 (高コスト、変更不要) のトレードオフを慎重に評価します。Migration Evaluator で現行環境のコスト分析を行い、移行後の TCO を試算してから方式を決定します。

まとめ - 段階的移行の推奨戦略

VMware ワークロードの AWS 移行は、単一のアプローチではなく、ワークロードの特性に応じて EVS と MGN を使い分ける段階的戦略が有効です。まず開発・テスト環境を MGN で EC2 に移行してクラウド運用のノウハウを蓄積し、本番環境は EVS でリフト & シフトした後に順次 EC2 へ転換します。移行後は Compute Optimizer でインスタンスサイズを最適化し、Savings Plans でコストを削減します。VMware ライセンスからの段階的な脱却により、長期的な運用コストの削減を実現できます。