本文へスキップ
BecomeCoder

AWS SAP（ソリューションアーキテクト プロフェッショナル）コース　·　第10章　移行とモダナイゼーション、そして試験対策　·　レッスン56

サーバー・データベースの移行 ― MGN、DMS、SCT

導入

計画ができたら、いよいよ実際にサーバーとデータベースを移します。SAPでは、この移行を実行する専用サービス群の使い分けが頻出です。

説明

サーバーそのものの移行と、データベースの移行は別のサービスが担当します。

サービス対象やること
AWS Application Migration Service（MGN）サーバー（物理・仮想・他クラウド）継続的にレプリケーションし、最小限のダウンタイムでEC2へカットオーバー
AWS Database Migration Service（DMS）データベースソースDBからターゲットDBへデータを移行。継続的なレプリケーションで無停止移行も可能
AWS Schema Conversion Tool（SCT）データベースのスキーマ異種DB間（例: Oracle → Aurora PostgreSQL）でスキーマ・ストアドプロシージャを変換

MGN はサーバーの Rehost（リフト＆シフト）を実現する中核サービスです。稼働中のサーバーに軽量なエージェントを入れると、ブロックレベルで継続的にAWSへレプリケーションが行われ、準備ができたタイミングでEC2インスタンスとして起動（カットオーバー）します。レプリケーションは事前に完了しているため、カットオーバー時のダウンタイムを最小限に抑えられるのが特徴です。

flowchart LR
    S["オンプレサーバー"] -->|"継続的にブロックレプリケーション"| MGN["MGN"]
    MGN -->|"準備でき次第カットオーバー"| E["EC2インスタンス"]

データベースの移行は少し複雑です。移行元と移行先が同じエンジン（例: Oracle → RDS for Oracle）であれば、DMSだけでスキーマごと移行できます。しかし異なるエンジン間（例: Oracle → Aurora PostgreSQL）の移行では、テーブル定義・ビュー・ストアドプロシージャの方言（SQL構文の違い）を変換する必要があり、ここで SCT が活躍します。

flowchart TD
    Q{"移行元と移行先の<br/>DBエンジンは同じか？"}
    Q -->|"はい（同種移行）"| DMS1["DMSのみでデータ移行"]
    Q -->|"いいえ（異種移行）"| SCT["SCTでスキーマ変換"] --> DMS2["DMSでデータ移行"]

DMSは継続的レプリケーション（CDC: 変更データキャプチャ）にも対応しており、初回のフルロード後も更新差分を流し続けられます。これにより、旧DBを稼働させたまま新DBへ切り替え直前まで同期し続け、カットオーバー時のダウンタイムを数分程度に抑える無停止に近い移行が可能になります。

具体例

高価なOracleライセンスをやめ、無停止でAurora PostgreSQLへ移りたい、という典型プロジェクトを工程順に見ます。

  • 業務サーバー20台 → MGN … 稼働中のサーバーに軽量エージェントを入れ、ブロックレベルで継続レプリケーション。準備でき次第カットオーバーするので、切り替え時のダウンタイムが最小。
  • Oracle → Aurora PostgreSQL（異種DB）→ SCT ＋ DMS … エンジンが違うので、まずSCTでテーブル定義・ビュー・ストアドプロシージャの方言（SQL構文の違い）を変換。その後DMSでデータ移行。
  • 無停止の肝 → DMSの継続的レプリケーション（CDC） … 初回フルロード後も更新差分を流し続け、旧Oracleを動かしたまま切替直前まで同期。カットオーバーは数分で済む。

もしこれが同じエンジン同士（Oracle → RDS for Oracle）なら、方言変換は不要なのでDMSだけでよい。「サーバー＝MGN、DB＝DMS、異種DBの方言変換＝SCT」を軸に、「同種ならSCT不要」「DMSのCDCで無停止に近い移行」が正誤判定の頻出ポイントです。

読んでみよう

「サーバーを移す」ならMGN、「データベースを移す」ならDMS、「異種DB間でスキーマの方言を変換する」ならSCT、という対応をまず覚えてください。その上で、「同種DB移行ならSCTは不要」という点、「DMSは継続レプリケーションでダウンタイムを最小化できる」という点は、選択肢の正誤判定でよく問われるポイントです。

次のレッスンへ →