移行（DMS / MGN）

このページで押さえる論点

• 移行サービスの全体像（DB・サーバー・ファイルでサービスが分かれる）
• AWS DMS のしくみ（レプリケーションインスタンス・エンドポイント・タスク）
• 停止時間を短くする: 全ロード＋CDC
• 同種間移行と異種間移行（DMS Schema Conversion・AWS SCT）
• AWS Application Migration Service（MGN）: サーバーのリホスト
• 要件から移行サービスを選ぶ

移行サービスの全体像

何を移すかによって、使うサービスが分かれます。SAA-C03 の試験ガイドでも、移行のサービスとして DMS・Application Migration Service のほか、DataSync・Snow Family・Transfer Family が挙げられています。後の 3 つはファイルやオブジェクトのデータ移行用で、別ページ（データ移行）で扱います。

移行の進め方には、次のような種類があります。MGN の公式ドキュメントでも、まずリホストで AWS へ移し、その後にリプラットフォームやリファクタリングで作り変えていく進め方が紹介されています。

• リホスト（lift and shift）: 作りを変えずに、そのまま AWS の EC2 へ移す。いちばん速く移せる。MGN の担当
• リプラットフォーム: 少しだけ変えて移す。例: 自前で管理していた MySQL を、DMS で RDS for MySQL に移す
• リファクタリング: クラウド向けに作り直す。例: エンジンを変えて Aurora へ、処理を Lambda へ

AWS DMS のしくみ

AWS DMS は、リレーショナルデータベース・データウェアハウス・NoSQL データベースなどのデータを、AWS へ（またはクラウドとオンプレミスの間で）移すサービスです。AWS 上のレプリケーションインスタンス（コピー作業をするサーバー）でレプリケーションのソフトウェアが動き、移行元から読んだデータを移行先へ書き込みます。

DMS は、移行先にテーブルと主キーがなければ自動で作ります。ただし作るのはデータを入れるための最小限の定義なので、エンジンの違う移行でスキーマ（テーブル定義や、ビュー・ストアドプロシージャなどのデータベースのオブジェクト）をきちんと変換したい場合は、次に説明する DMS Schema Conversion や AWS SCT を使います。

停止時間を短くする: 全ロード＋CDC

DMS のタスクには 3 つの移行方式があります。試験で「ダウンタイム（停止時間）を最小にしたい」とあれば、全ロード＋CDC が答えです。

CDC（Change Data Capture: 変更データキャプチャ）は、移行元のデータベースで起きた変更（追加・更新・削除）を拾って、移行先に次々と反映する仕組みです。移行中も移行元のデータベースは普段どおり使えるので、アプリを止めるのは最後の切り替えのときだけで済みます。下の図で流れを確かめてみましょう。

同種間移行と異種間移行

移行元と移行先のデータベースエンジンが同じか違うかで、手順が変わります。試験ガイドにも「異種間移行、同種間移行」という言葉が出てきます。

DMS Schema Conversion は DMS の機能で、移行元のスキーマを評価して移行の難しさを示し、移行先エンジンの形式へ自動で変換します。AWS SCT（Schema Conversion Tool）は、自分の PC にダウンロードして使う、同じ目的のツールです。どちらも「スキーマの変換」の担当で、データそのものを運ぶのは DMS です。

商用データベースのライセンス費用を減らすために、Oracle や SQL Server から Aurora（MySQL・PostgreSQL 互換）へ移す、というのが試験の定番シナリオです。この場合は異種間移行なので、スキーマ変換と DMS の 2 つがセットで答えになります。

AWS Application Migration Service（MGN）

AWS Application Migration Service（MGN） は、物理サーバー・仮想マシン・他のクラウドのサーバーを、作りを変えずに AWS へ移す（リホストする）ためのサービスです。現在の公式ドキュメントでは「AWS Transform MGN」という名前になっていますが、試験ガイドでは「AWS Application Migration Service」と書かれています。

• ブロック単位の継続的なレプリケーション: 移行元サーバーのディスクを、ファイル単位ではなくブロック（ディスクの区画）単位でコピーし続けます。サーバーは動かしたままで構いません。
• AWS で起動できる形に変換: コピーしたサーバーを EC2 で起動できるように変換するので、OS やアプリの互換性の問題を気にせず、多数のサーバーを移せます。
• 停止時間が短い: 切り替え（カットオーバー）のときだけ止めればよく、公式ドキュメントでは「通常数分の切り替え時間」とされています。
• テストしてから切り替え: 本番の切り替えの前に、テスト用のインスタンスを起動して動作を確かめられます。
• 大量のサーバーをまとめて扱う: サーバーをアプリケーション単位、さらにウェーブ（移行する順番のまとまり）単位でまとめ、起動や切り替えを一括で行えます。

DMS が「データベースの中のデータ」を移すのに対して、MGN は「サーバー丸ごと」を移します。データベースが入ったサーバーを MGN で丸ごと EC2 に移すこともできますが、その場合、移行後もデータベースの運用（パッチ当てやバックアップ）は自分で行うことになります。「マネージドなデータベース（RDS など）へ移したい」なら DMS を選びます。

要件から移行サービスを選ぶ

下のフローチャートで、何を移すかから使うサービスを選ぶ練習をしてみましょう。

問題文のキーワード → 選ぶべき答え

引っかけポイント

• 「DMS だけで Oracle のストアドプロシージャなども含めて PostgreSQL 用に変換できる」→ ✕。DMS はデータを運ぶ担当。エンジンの違うスキーマの変換は DMS Schema Conversion や AWS SCT
• 「AWS SCT でデータも移行先に移す」→ ✕（試験の定番の分担では）。SCT はスキーマ変換、データの移行は DMS
• 「停止時間を最小にしたいので全ロードを選ぶ」→ ✕。全ロードだけではコピー中の変更を移せない。全ロード＋CDC を選ぶ
• 「サーバーを丸ごと移すのに DMS を使う」→ ✕。DMS はデータベースのデータの移行。サーバーのリホストは MGN
• 「MGN でサーバーを移せば、DB の運用も AWS が行う」→ ✕。MGN は EC2 に移すので、DB の運用は自分で行う。マネージドな RDS に移すなら DMS
• 「DMS で移行している間は、移行元 DB を読み取り専用にしなければならない」→ ✕。CDC を使えば移行元は普段どおり使え、止めるのは最後の切り替えのときだけ

まとめ: SAA 試験で押さえるポイント

• データベースのデータは DMS、サーバー丸ごとは MGN、ファイルやオブジェクトは DataSync など
• DMS はレプリケーションインスタンスがソースエンドポイントから読み、ターゲットエンドポイントへ書く
• 停止時間を最小にするなら 全ロード＋CDC。移行元を使い続けながら変更を反映し、最後に切り替える
• エンジンが違う異種間移行は、DMS Schema Conversion（または AWS SCT）でスキーマ変換 → DMS でデータ移行。同種間ならスキーマ変換は不要
• MGN はブロック単位の継続的なレプリケーションで、物理・仮想・他クラウドのサーバーを EC2 へリホスト。テスト起動のあと、通常数分の切り替えで移せる
• リホストで早く移し、その後にリプラットフォーム・リファクタリングで作り変えていく進め方もある