AWS Transform MGNによるサーバー移行を理解する

この単元で学ぶこと

• MGNのリホストとブロック複製を説明する
• テスト起動と本番切替の違いを説明する
• 依存関係・同期状態・移行後運用を確認する

本文解説

1. MGNの位置付け MGNは物理・仮想・クラウドのサーバーをAWSへ移す用途です。旧名AWS Application Migration Serviceに対し、現行公式はAWS Transform MGNと案内しています。既存アプリを大きく変えず移すリホストを中心に考えます。Transformという名前だけで全アプリが自動的に再設計されると読み替えず、MGNの機能範囲を見ます。

2. 初期複製と継続変更 MGNはサーバーのブロック単位のデータを複製し、変更を継続してAWS側へ反映します。最初に必要なデータを同期した後も、元のサーバーで更新が続けば追従が必要です。複製状態や遅れ、未転送分を確認します。通信が届くことと、変更が追い付いて起動可能な状態になったことは別です。

3. 起動条件を用意する 移行先でのインスタンス、ネットワーク、ストレージ、許可等の起動設定を準備します。複製・起動・起動後処理の設定を用途に合わせて管理します。元で動いたOSや機能が全て無条件に対応するとはせず、サポート条件を確認します。古いライセンスや固定IPに依存した構成も検討が必要です。

4. テスト起動 本番を切り替える前にAWS上でテスト用インスタンスを起動し、接続、アプリ、データ、依存サービスを確認します。テスト起動後も元からステージング領域への複製は続きますが、起動済みテストインスタンスへ最新変更を自動で常時反映するものとは区別します。テストの時点と、その後の元側の変更を整理します。

5. 依存関係を試す Webサーバーだけ起動しても、DB、認証サーバー、外部API等に届かなければ業務は動きません。複数サーバーが相互依存するなら一緒にテストし、移行のまとまりを決めます。例えば固定のオンプレミスIPを参照する設定が残っていれば、切替後の接続先や経路を変える必要があります。OSの起動成功だけで合格としません。

6. 切替と完了 必要な試験を終え、更新の反映を確認し、元の業務書込みや利用者接続を制御して本番側へ切り替えます。停止時間を短くする支援はありますが、全アプリの停止ゼロを保証するわけではありません。MGNで切替を完了させると元サーバーの複製は停止するため、いつ完了とするかを業務の確認と合わせて判断します。

7. データ変換との境界 MGNでDBを載せたサーバーを移すことと、そのDBを異なるエンジンへ変えることは別です。異種DBの行移行や構造変換にはDMSやSchema Conversion/SCT等を比較します。共有ファイル群だけを移すならDataSync等を比較します。対象と変化の大きさから分け、名前が移行サービスであるという理由だけで同じ機能としません。

8. 移行後も運用する 移したインスタンスには、OSやアプリの更新、バックアップ、アクセス制御、監視等が必要です。テストインスタンスや複製に使う資源の料金と後片付けも確認します。使用しなくなった元環境をいつ廃止するかは、業務の合格、必要な保持、戻し方を確認して決めます。移行と運用改善は段階を分けて進められます。

図解

重要ポイント

• リホストは自動的なDB変換やアプリ再設計ではない。
• テスト起動と本番切替、ステージングへの複製を分ける。
• 起動しただけでなく依存先と業務の動作を確認する。

間違えやすい点

• テストインスタンスへ常に最新の元データが入ると考える。
• 切替完了後も元サーバーの複製が同じまま永久に続くと考える。

用語解説

ブロック単位の複製

サーバーのストレージのデータをブロック単位で複製する方式。

ステージング領域

移行元からの複製データを受け取り、起動の準備に使う領域。

テスト起動

本番切替前にAWS上で起動して動作を確かめる工程。

切替完了

本番への移行の完了を確定する段階。MGNの複製停止の扱いも確認する。

関連教材

• Snow Familyの概念と現在の転送手段を理解する
• AWS DMSを理解する
• データ・サーバー移行と接続の違いと使い分け
• データ・サーバー移行とAWSへの接続の全体像
• データ・サーバー移行と接続のシナリオ判断