AWS Database Migration Serviceを使ってみる

はじめに

以前SCTを利用したスキーマ移行に触れたので、次はAWS Database Migration Service(DMS)を利用したデータ移行について書いてみます。
なお私が利用した際はOracle DatabaseからAuroraに移行したので、その際のポイントも記載します。

前提条件

※DMS使用に焦点をおいているため、NW周りや権限周りについては割愛しております。

• ソース or ターゲットのどちらかはAWS上にある
• 移行用のレプリケーションインスタンスを作成する

以下はOracle Databaseの設定

• CDC(Change DATA Capture)を利用した差分適用にはサプリメンタルロギングをオンにする
• CDCではLogMiner(Default)を使用するので使用可能にする必要がある。（Binary Readerの利用も可）
• ARCHIVELOGモードが有効である

ステップ

DMSを利用する際には下記の流れになるかと思います。

1. レプリケーションインスタンス作成
2. エンドポイント作成
3. タスク作成
4. モニタリング

イメージとしては下記のような形

1.レプリケーションインスタンス作成

• EC2ベース(T2,C4インスタンスをサポート)
• MultiAZによる冗長化可能
• コストはインスタンス + SSDストレージ + 通信費用
• メンテナンスウィンドウ有り
  コンソールではサポート外のため、AWS CLIかAWS DMS APIで管理・変更する
  公式ページより
  上記公式ページにメンテナンスウィンドウで利用される時間の範囲が記載されています。
  ただ私が確認した時は下記のように範囲外に設定されていたので一度確認した方がよいでしょう。

コマンドの出力結果はUTCです。

2.エンドポイント作成

エンドポイントの作成では 追加の接続属性 に注意が必要です。
最低限下記あたりは利用することになるかと思います。

• Oracle
  • addSupplementalLogging=Y
    新規追加オブジェクトの差分も適用する場合に設定
  • exposeViews=true
    Viewのデータを移行する場合に設定
• Aurora
  • initstmt=SET FOREIGN_KEY_CHECKS=0
    外部キーを使用していた場合、チェックを外しておきます
    その他にも利用できる設定があるのでこちらにて適宜ご確認ください。

3.タスク作成

タスク作成では主に下記3点がポイントかと思います。

• ロギングの有効化
  タスクの進捗状況を確認するグラフはデフォルトでも見れますが、エラーなどのメッセージはロギングの有効化をチェックしなければ表示されません。
  何かあったときのために有効化しておいた方がよいでしょう

• ターゲットテーブル作成モード
  デフォルトがターゲット上のテーブルのDropです。
  SCTを利用してスキーマの移行をしていた場合、Dropされてしまうので注意が必要です。

• テーブルマッピング
  SCT同様にテーブルマッピングの機能があります。(コンソール上で選択するGuidedかJSON形式で利用)
  SCTでスキーマ上の大文字小文字等を変更していた場合、同様に設定する必要があります。

4.モニタリング

データ移行自体にかかる時間はAWSの方いわく(理想的な条件のもと)1TB 10~15時間程度とのことでした。

また今年のAWS Summitで事例を発表された「株式会社ゲオホールティングス様」では200GBのデータを移行した際では10時間程度との発表もありました。
当初3日と11時間かかったそうですがチューニング（並列度、CommitRate,インスタンスタイプ変更）によって短縮されたそうです。

データサイズが大きい場合は時間短縮のため、負荷も考えならチューニングをしていくことがポイントになりそうですね。

まとめ

低コストかつ最小限のダウンタイムで移行が可能なのはかなり魅力的だと思います。

操作についてもそれほど複雑なところもありません。(公式ドキュメント等の確認は必要ですが)
SCTと組み合わせれば、より移行にかかる負荷を減らせると思います。

是非一度お試しください