AWS DMSを理解する

DMSによる既存データの移行と、移行中に生じる更新の追従を学びます。異種DBの構造変換、接続条件、データ検証、切替を別工程として理解し、転送完了だけでは足りない条件を確認します。

この単元で学ぶこと

  • フルロードとCDCの目的を区別する
  • スキーマ変換とデータ移行の役割を説明する
  • 接続・整合性・切替の確認事項を判断する

本文解説

1. DBデータの移行 AWS DMSは対応するデータストア間でデータを移すサービスです。DBを同じエンジンの別環境へ移す場合と、異なるエンジンへ変える場合があります。移行元と移行先の組合せ、バージョン、型や機能の制約を確認します。任意のDBから任意のDBへ全機能をそのまま移せるという意味ではありません。

2. 初回のフルロード フルロードは対象の既存データを移行先へ読み込む段階です。例えば100万件の注文があれば、選択した表の既存内容を移します。対象選択や変換、移行先の準備を設定します。この間も元DBが更新されるなら、既存データをコピーしただけで最後の更新まで一致したと判断しないようにします。

3. 変更を追うCDC Change Data Capture(CDC)は元データの変更を継続的に取り込み、移行先へ反映する方法です。DMSではフルロードと継続的な複製を組み合わせる構成を選べます。DBのログ設定や権限等が必要で、対応条件はエンジンによります。変更の発生速度が反映速度を上回れば遅れが増えるため、同期の状態を監視します。

4. スキーマは別に評価する 異なるDBエンジンへ移る場合、表の構造、データ型、ビュー、ストアドコード等がそのまま使えるとは限りません。DMS Schema Conversionやローカルで使うAWS SCT等で変換を評価します。自動変換できる部分と修正が必要な部分を分け、アプリのSQLや業務動作も確認します。行データを運ぶことと、全コードの意味を同一にすることは違います。

5. 接続と許可 移行元・移行先のエンドポイントには接続先の情報を設定し、ネットワーク経路、DBの認証、必要な読取りや変更取得等の権限を確認します。TCP接続ができても必要な表を読めるとは限らず、ログを読む権限がなければCDCが動かない場合があります。通信暗号化と認可の条件も別に確認します。

6. 検証の観点 対応する条件ではDMSのデータ検証を使って元と先を比較できます。それに加え、業務として必要な件数、金額、文字コード、日付、参照関係等を確認します。100行ずつあっても一行の金額が違えば内容は一致しません。全機能や全組合せで同じ検証ができるとはせず、検証範囲と未確認を記録します。

7. 切替の管理 停止を短くするには、事前に転送と追従を進め、切替時に書込みを制御し、変更分の反映を確認してアプリの接続先を切り替えます。再開後の確認と戻す条件も必要です。DMSを使うというだけで停止ゼロを保証したり、両DBへ独立して書いても矛盾しないと考えたりしません。

8. サーバー移行との比較 OSやアプリを含むサーバーをそのまま移す中心はMGN、一般のファイル群を転送する中心はDataSyncです。DMSはDBデータと変更の移行という役割から比較します。例えばサーバーはMGNで移し、別DBへのデータはDMSを使う等、対象を分けた計画もあります。DB移行後の権限・バックアップ・監視も新環境に合わせて整えます。

図解

DB移行の三つの確認
DMSのデータ移行と、スキーマ変換や業務の切替を一つの操作とみなしません。

重要ポイント

  • 初回のコピーと継続する変更の追従を分ける。
  • スキーマ変換の未対応部分とアプリ互換性を確認する。
  • 接続成功・データ一致・業務成功を別々に検証する。

間違えやすい点

  • 同じ行数なら同じ内容と判断する。
  • DMSを選んだだけで書込み停止や接続切替が不要になると考える。

用語解説

フルロード
対象の既存データを移行先へ読み込む処理。
CDC
データの変更を取得し、継続的に反映する方式。
エンドポイント
DMSが接続する移行元・移行先の情報。
複製の遅れ
元で発生した変更が移行先へ反映されるまでの遅延。

関連教材

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。