AWS Database Migration ServiceでオンプレDBからAmazon RDSへデータ移行してみた

1. はじめに

こんにちは。
今年7月、担当システムのデータベースをオンプレミスのOracleからAWS RDS for PostgreSQLに移行しました。
オンプレミスからクラウドへの移行、異種データベース間の移行はどちらも初めてで何もかもが手探り状態。
その際に救世主となった「AWS Database Migration Service」についてご紹介します。

2. AWS Database Migration Serviceとは

AWS Database Migration Service（以降DMSと記載）とは、データベース間でデータ移行するためのクラウドサービスです。

DMSを利用することで以下が実現出来ます。

• 移行処理が自動で実行される
• 移行プロセス中の高可用性と最小限のダウンタイムを維持して移行が可能
• 同種および異種データベースからの移行が可能
• 移行プロセス中に使用されたコンピュータリソースと追加のログストレージのみの支払いとなる

移行環境や処理を自前で用意する必要がないのに加え最低限のコストで済むため、移行初心者には大変ありがたいサービスです。

3. レプリケーションインスタンスとサーバーレス

DMSではレプリケーション（移行）にレプリケーションインスタンスを利用するかサーバーレスで実施するかを選ぶことが出来ます。
レプリケーションインスタンスを使用する場合、レプリケーションインスタンスがデータへの接続・読取・データフォーマット・書込を実施します。

レプリケーションインスタンスを利用する場合はインスタンスクラスを指定する必要がありますが、サーバーレスを利用する場合はリソースが自動的にプロビジョニングされるため、インスタンスクラスの選定に悩む必要はありません。
ただしサーバーレスには制限もあるので、利用するケースに応じて使い分けが必要です。

今回はターゲットとなるデータベースのバージョンがサーバーレスのエンジンバージョンに対応していなかったため、レプリケーションインスタンスを選択しました。

4. 利用手順

ではレプリケーションインスタンスを使ったDMSの利用方法について、自身がちょっと悩んだりつまづいた点を中心にご説明します。

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

まずは「DMS > レプリケーションインスタンス > レプリケーションインスタンスの作成」からレプリケーションインスタンスを作成します。

• インスタンスクラス
  クラスによって移行にかかる時間が変わってきます
  事前に何度かリハーサルを行い、予定時間内で移行が完了出来るクラスを選択しました
• エンジンバージョン
  バージョンにより対応するデータベースバージョンなどが異なる場合があります
• VPCセキュリティグループ
  ソースとターゲットのデータベースに接続出来る設定をしたセキュリティグループを設定します

設定が終わったら「レプリケーションインスタンスの作成」を押して完了です。

4.2. エンドポイントの作成

次にソースとターゲットのエンドポイントを「DMS > エンドポイント > エンドポイントの作成」から作成します。

★ソース（移行元）

★ターゲット（移行先）

ソース、ターゲットともに接続情報を入力して「エンドポイントの作成」を押して完了です。
レプリケーションインスタンスを使用して接続テストも出来るため、必要があればテストを実施してください。

4.3. データ移行タスクの作成および実行

最後に「DMS > データ移行タスク > データ移行タスクの作成」から移行処理を実施するタスクを作成します。

• 移行タイプ
  移行をどのように行うかを選択します
  • 既存のデータを移行する
    1回限りの移行となります　※今回はこれを選択
  • 既存のデータを移行して、継続的な変更をレプリケートする
    1回限りの移行後、変更されたデータをレプリケートします
  • データの変更のみをレプリケートする
    1回限りの移行をせず、変更されたデータをレプリケートします
• ターゲットテーブル準備モード
  ターゲットテーブルの扱いについて選択します。
  • 何もしない
    ターゲットに存在するテーブルへデータ追加する
  • ターゲット上のテーブルを削除
    ターゲットに存在するテーブルを削除して再作成して移行する
  • 切り捨て
    ターゲットに存在するテーブル内のデータを削除してデータ追加する　※今回はこれを選択
• LOB列設定
  ラージオブジェクト(LOB)の移行について選択します
  • LOB列を含めない
    LOBは移行されません
  • 完全LOBモード
    LOBをすべて移行しますが時間がかかります　※今回はこれを選択
  • 制限付きLOBモード
    最大LOBサイズまで移行します
• データ検証
  ソースとターゲットの比較をするかどうかを選択します
  今回はオフにして比較は自前で行いました
• 移行前評価を有効化
  移行タスク開始前に問題点のチェックを行うかを選択します
  今回は事前にリハーサルを実施していたのでオフにしました
• テーブルマッピング
  移行方法をカスタマイズすることが出来ます
  例えばソースには移行不要のスキーマが存在していたので、移行対象から除外する設定をしました。
  
  ソースはテーブル名・項目名が大文字、ターゲットは小文字のため、小文字に変換する設定も行いました。
  

設定が終わったら「タスクの作成」を押して完了です。
これで移行タスクが実行出来るようになりました。

5. 移行タスクの実行

移行タスクを実行中、進捗を確認することが出来ます。

進捗を見ていると以下の点に気がつきました。

• テーブル名の昇順で移行される
  テーブル間で親子関係がある場合、順番によっては移行がエラーとなるテーブルが発生するので注意が必要です
  今回は数テーブルでエラーが発生しましたがデータ量も少なかったため、対象テーブルは弊社のDataSpider Servistaを使用して移行を実施しました

• 複数テーブルが並行で移行される
  並行で移行が実施されても、データ量の多いテーブルが最後のほうに実行されるとロスタイムが発生します
  場合によっては移行タスクを複数作成してテーブルをグループ分けすると効率が良さそうです

6. まとめ

DMSを利用することにより、データベース移行に関する専門的な知識がなくても簡単・スムーズにデータ移行を行うことが出来ました。
ちなみに本番データ移行にかかった時間およびコストは以下となります。どちらも最小限で収めることが出来ました。

• 時間　：5時間程度
• コスト：$6.26

また今回はご紹介していませんが、データベースオブジェクトの変換には「AWS Schema Conversion Tool(SCT)」というツールを利用しました。

こちらについてはまた機会があれば記事を書きたいと思います。