導入
計画ができたら、いよいよ実際にサーバーとデータベースを移します。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へ切り替え直前まで同期し続け、カットオーバー時のダウンタイムを数分程度に抑える無停止に近い移行が可能になります。
読んでみよう
「サーバーを移す」ならMGN、「データベースを移す」ならDMS、「異種DB間でスキーマの方言を変換する」ならSCT、という対応をまず覚えてください。その上で、「同種DB移行ならSCTは不要」という点、「DMSは継続レプリケーションでダウンタイムを最小化できる」という点は、選択肢の正誤判定でよく問われるポイントです。