データベース移行の設計 DMSとSCTでリスクを抑えて切り替える

この記事は SAP-C02 を目指す方に向けて、オンプレミスのデータベースをAWSへ移す際の設計を整理します。試験では「停止時間を最小に」「別のDBエンジンへ」といった条件が示され、どのツールをどう組み合わせるかが問われます。

覚え方は3つの観点です。入れ物を変えるか(同種か異種か)・止めてよい時間はどれだけか・切り戻せるか。この3つで方式が決まります。

同種移行と異種移行を切り分ける

Oracle から Oracle、MySQL から Aurora MySQL のような同種移行はスキーマがそのまま使えるため、DMS だけで完結します。一方 Oracle から Aurora PostgreSQL のような異種移行では、ストアドプロシージャや独自データ型が変換対象になるため、AWS Schema Conversion Tool (SCT) でスキーマとコードを変換してから DMS でデータを流します。SCT は変換できなかった箇所を評価レポートとして出すため、移行工数の見積もりにも使えます。

停止時間を最小にする

DMS のフルロードのみでは、コピー中の更新が反映されず長い停止が必要です。停止時間を数分にしたいならフルロードと変更データキャプチャ(CDC)の併用を選びます。初回コピーの裏で発生した更新を継続的に適用し、差分がほぼゼロになった時点でアプリの接続先を切り替えます。ソース側では、Oracleなら補足ログ、PostgreSQLなら論理レプリケーションの設定が前提になる点も問われます。

切り戻しと検証を用意する

切り替え後に問題が出たときのため、DMS のレプリケーションを逆向きにも構成しておくと新環境から旧環境へ書き戻せます。データの整合性は DMS のデータ検証機能で行単位に比較し、差分をログに出せます。大量データを短時間で運ぶ必要がある場合は、Snowball Edge へエクスポートして輸送し、到着後にCDCで差分を追いつかせる組み合わせも選択肢です。

チェックリスト

• 同種移行と異種移行でツール構成が変わる理由を説明できる
• SCTの評価レポートが何に役立つかを言える
• フルロードとCDCの併用で停止時間が短くなる仕組みを描ける
• ソースDB側に必要な事前設定を1つ以上挙げられる
• 切り戻し用の逆方向レプリケーションの意義を説明できる

まとめ

DB移行は「同種か異種か」「どれだけ止められるか」の2軸でほぼ方式が決まります。そこにデータ検証と切り戻しを足せば、実務でも試験でも通用する設計になります。

理解を確かめるにはクイズで腕試しを、最新の出題範囲はAWS認定 公式ページで必ず確認してください。