AWS MGN による大規模移行の計画と実行 - ウェーブ設計とカットオーバー自動化
数百台規模のサーバー移行をウェーブ設計で計画し、カットオーバーの自動化スクリプトと移行後の最適化手法を紹介します。
ウェーブ設計の考え方
大規模移行では全サーバーを一度に移行するのではなく、ウェーブ (移行バッチ) に分割して段階的に実行します。ウェーブの設計はアプリケーションの依存関係に基づきます。Web サーバー、アプリケーションサーバー、データベースサーバーが密結合しているアプリケーションは同一ウェーブに含め、同時にカットオーバーします。最初のウェーブは低リスクなアプリケーション (開発環境、社内ツール) で構成し、移行プロセスの検証と改善を行います。後続のウェーブで本番アプリケーションを移行し、最終ウェーブで最もクリティカルなシステムを移行する段階的アプローチが一般的です。Migration Hub のアプリケーショングルーピング機能を使い、サーバーをアプリケーション単位でまとめてウェーブに割り当てることで、依存関係の見落としを防ぎます。1 ウェーブあたりのサーバー台数は 10〜25 台が管理しやすく、同時カットオーバー時のトラブル対応も可能な範囲に収まります。
カットオーバーの自動化
MGN の起動後アクション (Post-launch actions) は、カットオーバー後の EC2 インスタンスに自動的にスクリプトを実行する機能です。Systems Manager Run Command と統合し、DNS レコードの更新、監視エージェントのインストール、アプリケーション設定の変更、ヘルスチェックの実行を自動化できます。アプリケーションテンプレートで移行先の EC2 設定 (インスタンスタイプ、サブネット、セキュリティグループ、IAM ロール、タグ) を標準化し、同じ役割のサーバーに一貫した構成を適用します。テスト起動とカットオーバーの両方で同じテンプレートが使用されるため、テスト環境と本番環境の構成差異を排除できます。起動後アクションの実行順序は優先度で制御し、DNS 更新を監視エージェントより先に実行するなど依存関係を考慮した順序付けが可能です。Systems Manager のドキュメント (SSM Document) を事前に作成しておけば、複雑なスクリプトも冪等に実行できます。
移行後の最適化
移行直後はオンプレミスと同じスペックの EC2 インスタンスで稼働させ、安定性を確認します。2-4 週間の運用データが蓄積された後、AWS Compute Optimizer の推奨に基づいてインスタンスタイプを適正化します。オンプレミスでは余裕を持ったスペックで運用していたサーバーが多く、適正化により 30-50% のコスト削減が期待できます。Graviton (Arm ベース) インスタンスへの移行も検討し、同等の性能で最大 40% のコスト削減を実現できます。移行後の最適化は一度で終わりではなく、定期的に Compute Optimizer の推奨を確認し、継続的にコストを最適化するプロセスを確立します。Savings Plans や Reserved Instances は移行完了後の安定期に適用し、移行中に長期コミットメントを結ぶのは避けます。 サーバー移行の基礎から応用まで、書籍 (Amazon)で体系的に学べます。
MGN の料金
MGN 自体の利用料金は無料です。コストはレプリケーション用の EC2 インスタンス (軽量な t3.small が自動作成)、EBS ボリューム (レプリケーションデータの保存)、テストインスタンスとカットオーバーインスタンスの EC2 料金で構成されます。レプリケーション中は継続的にコストが発生するため、移行期間を短縮することがコスト最適化の鍵です。テストインスタンスは検証完了後に速やかに終了し、カットオーバー後のソースサーバーのレプリケーションも停止します。データ転送料金として、ソースサーバーから AWS へのレプリケーション通信 (インバウンド) は無料ですが、ソースサーバーがオンプレミスの場合はインターネット回線や Direct Connect の帯域コストが発生する点に注意が必要です。
移行前の評価と他ツールとの使い分け
大規模移行の前段階として、Migration Hub の Discovery ツールまたは Application Discovery Service でオンプレミス環境のサーバー構成・依存関係・使用率を自動収集します。収集したデータを Migration Hub Strategy Recommendations に入力し、各サーバーの移行戦略 (Rehost / Replatform / Refactor) を判定します。MGN はリフト&シフト (Rehost) に最適化されたサービスで、OS やアプリケーションを変更せずブロックレベルでディスクを複製します。データベース移行には DMS (Database Migration Service) を併用し、アプリケーションサーバーは MGN、データベースは DMS という役割分担が一般的です。VMware 環境が多い場合は MGN の agentless レプリケーション (vCenter コネクタ) も選択肢になり、各サーバーにエージェントをインストールする手間を省けます。
カットオーバー時のリスク軽減策
カットオーバー時のダウンタイムを最小化するため、MGN の継続レプリケーションはブロックレベルの差分同期を行い、最終同期 (ファイナルシンク) は変更ブロックのみを転送します。実際のカットオーバー所要時間はサーバー 1 台あたり数分〜十数分で、ディスクサイズではなく差分データ量に依存します。カットオーバー失敗時のロールバック計画として、ソースサーバーを停止せず待機状態に置き、DNS の TTL を事前に短縮 (5 分以下) しておくことで、問題発生時に元のサーバーに即座に戻せる構成を取ります。テスト起動で全ウェーブの動作確認を事前に行い、テスト結果を承認してからカットオーバーに進む 2 段階プロセスが推奨されます。複数リージョンに移行する場合は、リージョン間のレイテンシがアプリケーション間通信に影響しないようウェーブの配置順序を設計します。
まとめ
大規模移行ではウェーブ設計による段階的な実行、起動後アクションによるカットオーバーの自動化、移行後の Compute Optimizer による最適化が成功の鍵です。MGN と Migration Hub の組み合わせで数百台規模の移行を一元管理し、リスクを最小化しながら効率的に移行を完了できます。事前の Discovery による評価とカットオーバー時のロールバック計画を組み合わせることで、移行プロジェクト全体のリスクを制御します。