Amazon Web Services ブログ
AWS DMS を使ってデータベースの移行とリフレッシュ処理を自動化する
アプリケーション開発者やシステム管理者は、データの移行、更新、マスクなどの目的で、データストア間での複製を行うことがあります。事前調査、スキーマ変換、スクリプト変換、データ移行、機能試験、パフォーマンスのチューニング、その他のタスクが伴うデータ複製作業は、多くの組織にとって複雑で複数のフェーズが必要な作業となります。そのため、データ複製をサポートするいくつものツールが存在します。
AWS Database Migration Service (DMS) は、データベースを AWS に迅速かつ安全に移行するためのツールです。ソースのデータベースは移行処理中でも完全な機能を維持するので、アプリケーションの中断時間を最小にできます。AWS DMS を利用すると、オープンソースで広く使われている商用データベースとの間で、双方向のデータ移行が行えます。
同種間および異種間、両方の移行をサポートする AWS DMS では、高い可用性を維持したまま、データストア間でのデータ複製を持続的に実行できます。AWS DMS では、全ロードで変更がキャッシュされたデータを、データストア間で継続的に複製できます。
今回の記事では、グローバルなデータの移行や更新、マスキングを自動で行うソリューションをご紹介していきます。このソリューションでは、DMS、AWS Lambda、Amazon CloudWatch リソースなどを統合しながら、AWS CloudFormation スタックをデプロイします。DMS のレプリケーションタスクが、オンプレミスから AWS Cloud 上にあるデータストアへのデータ移行もしくは更新を行います。
今回のデモでは、オンプレミス側のデータベースとしては Amazon RDS for Oracle DB インスタンスを使い、クラウドデータベースとしては Amazon Aurora MySQL インスタンスを使います。DMS のイベントサブスクリプション機能を有効にしておくと、DMS のレプリケーションタスクはすべてのタスクイベントを、Amazon SNS トピックを使い通知するようになります。この SNS トピックは、サブスクライブした Lambda 関数へ通知されます。この Lambda 関数が CloudWatch Events のルールを有効化もしくは無効化した後、DMS のレプリケーションタスクをトリガーします。
ネットワーク上の問題を簡素化するため今回のソリューションでは、すべてのサポートサービスを 1 つの VPC 上に配置します。また、ここで使用するリソースのプロビジョニングとデプロイに役立つよう、AWS CloudFormation テンプレートも用意しました。このテンプレートは、今回のソリューションのデモ用に特別に作られたものです。実稼働のワークロードにこのテンプレートを使う場合は、十分な注意を払いながら必要な修正を加えてください。
ソリューションの概要
この記事では、次の作業について説明しています。
- 基本となるネットワークとデータベースリソースのプロビジョニングを行います。既存の DMS レプリケーションタスクがある場合は、このステップは省略して自動ソリューションのデプロイ (ステップ 3) を行わず、次に進むことができます。
- プロビジョニングされたリソースを検証します。
- 用意されている AWS CloudFormation テンプレートを使い、リソースのデプロイとソリューションのテストを行います。
- 移行後のクリーンアップを行います。
- 進行中の同期化処理とデータマスキング機能を検証します。
今回ご提案するソリューションのアーキテクチャ概要を次の図に示します。
前提条件
この記事で説明するステップを実行するには、AWS アカウントが必要です。
また、DMS タスクをプログラム的に起動するために、API および CLI に特価した dms-vpc-role ロールも必要です。このロールがあるかは、IAM コンソールの [Roles] をクリックして確認できます。このロールが見つからない場合は、次のセクションにある指示に従ってください。
1. DMS リソースのプロビジョニング
オプションであるこのステップでは、次のような基本ネットワーク接続とデータベースリソースの作成方法について説明します。
- 2 つのサブネットがある VPC
- Amazon RDS と DMS レプリケーションインスタンスのためのセキュリティグループ
- スナップショットからの Oracle データベース用 Amazon RDS
- Aurora MySQL データベース
- AWS DMS レプリケーションインスタンス
- AWS DMS エンドポイントとレプリケーションタスク
次に示す手順で、基本ネットワーク接続とデータベースリソースをプロビジョニングします。作業を簡素化するため、テンプレートにはほとんどの要素が記述済みです。必要な部分を修正して使用してください。
- DMS baseline resources template をダウンロードしてリソースの設定を行います。これらのリソースをコンソールから直接起動する場合は、[Launch Stack] 、[Next] の順にクリックします。
- [Specify stack details] ページでテンプレートの詳細設定をした後、[Next] をクリックします。
- [Configure Stack Options] ページの [Tags] に所望する値を入力し、[Next] をクリックします。
- [Review] ページで、[I acknowledge that AWS CloudFormation might create IAM resources with custom names] チェックボックスにチェックを入れ、[Create stack.] をクリックします。
プロビジョニングには、20~25 分間ほどかかります。[stack status] に Create Complete と表示されたら [Outputs] をクリックし、結果を確認します。
2. DMS リソースの検証
次に、リソースの検証を行います。
- DMS コンソールの [Resource Management] で [Endpoints] をクリックします。
- dms-blog-cloud-aurmysql-endpoint という DMS エンドポイントを選択し、[Actions] にある [Test Connections ] をクリックします。[Status] フィールドには successful と表示されるはずです。
- もう 1 つの DMS エンドポイント dms-blog-onpremise-oracle-endpoint についても同様の作業を行います。[Status] フィールドに successful と表示されていることを確認してください。
- [Conversion & migration] の [Database migration tasks] をクリックします。
- ora2aurmysql-copy タスクを選択し詳細を表示します。次の図に、データ移行と更新を有効化するためのソースおよびターゲットのエンドポイントが定義され、プロビジョニングされた DMS 移行タスクを示します。
3. ソリューションのために自動化されたリソースをデプロイする
このセクションでは、次のようなデータベースの移行もしくは更新を自動化するリソースのデプロイ方法を説明します。
- CloudWatch Events のルール
- DMS のタスクをトリガーする Lambda 関数
- データの後処理や、関連のある Lambda 処理を実行する、オプションの Lambda 関数
- DMS イベントのサブスクリプション
- SNS トピック
次の表は、データ移行と更新の処理を自動化するために、テンプレートで使用しているパラメータの有効な組み合わせを示しています。
MigrationRefreshIndicator | MigrationRefreshType | ScheduleOrOneTime |
data-refresh | full-load | schedule |
data-refresh | full-load | one-time |
data-migration | full-load | schedule |
data-migration | full-load | one-time |
data-migration | full-load-and-cdc | one-time |
data-migration | cdc | one-time |
次の手順で、ソリューションを自動化するためのリソースをプロビジョニングします。作業開始時点で DMS タスクを使いデータ更新が実行できるように、前出のテーブルにある最初のオプションはあらかじめ定義してあります。必要な部分を修正して使用してください。
- リソースのセットアップを行うため、resources template をダウンロードします。
- [Launch Stack] をクリックし、スタックをコンソールから直接起動します。
- [Specify stack details] ページの定義済みパラメータを必要に応じて修正した後、[Next] をクリックします。
- [Configure Stack Options] ページの [Tags] フィールドにオプションの値を入力した後、[Next] をクリックします。
- [Review] ページで、[I acknowledge that AWS CloudFormation might create IAM resources with custom names ] チェックボックスにチェックを入れ、[Create stack] をクリックします。リソースのプロビジョニングは、約 5~10 分間で完了します。
- CloudFormation Stacks のコンソールが Create Complete と表示したら、[Outputs] をクリックし結果を確認します。
TaskStarterLambda の Lambda 関数である dms-task-starter-lambda は、次のようなタスクを実行します。
- 既存のもの、もしくはプロビジョニングされた DMS タスクをトリガーすることで、データ移行もしくは更新を開始します。
- 呼び出しの重複を防止するため、CloudWatch Events ルールを無効化します。
移行もしくは更新処理を実行するには、次のステップを実行します。
- CloudWatch コンソールで [Rules] をクリックし、dmstask-scheduler-eventrule を選択します。このルールは、DMS のレプリケーションタスクをトリガーさせるため、Lambda 関数の Cron スケジュールを 00:00 GMT に設定します。この時刻はリソースのプロビジョニング時に選択した時刻です。
- Lambda コンソールから DMS タスクを手動で呼び出す場合は、dms-task-starter-lambda という名の Lambda 関数を選択します。
- [Test] をクリックします。[configure test event] スクリーンで [Create new test event] をクリックします。[Event Template] で [Hello World] を選択します。[Event name] に demo と入力し [Create] をクリックします。
- 再び [Test] をクリックし、ここで定義されたテストイベントを使う Lambda 関数をトリガーします。この Lambda 関数が、CloudWatch Events ルールを無効化した後で、DMS タスクをトリガーします。次のスクリーンショットに出力のサンプルを示します。
- DMS タスクのステータスを確認するには、DMS コンソールで [Database migration tasks,] をクリックし、ora2aurmysql-copy という名前のタスクを選択します。[Status] フィールドには、starting あるいは running と表示されるはずです。
先のステップで既存の DMS タスクを入力している場合は、そのタスクの [Status] フィールドが、starting あるいは running と表示します。
この DMS タスクでは、RDS for Oracle DB にある小さなテーブルを、Aurora MySQL データベースにコピーします。[Table statistics] セクションの [Load state] 覧に、次のスクリーンショットのような表示があることを確認します。
DMS イベントサブスクリプション機能が有効化されていると、DMS のレプリケーションタスクでは、全タスクイベントについてSNS トピックをトリガーします。レプリケーションインスタンスで作成もしくは削除などの DMS イベントが発生すると、DMS では SNS を使い通知を送信します。SNS 通知には、任意の AWS リージョンについて、E メール、テキストメッセージ、あるいは HTTP エンドポイントの呼び出しのどれかを設定しておきます。
DMS コンソールで [Events] をクリックし、発生するイベントのシーケンスを確認します。
[Event subscriptions] をクリックし、DMS イベントに関する SNS トピックのサブスクリプションを確認します。
SNS トピックは、すべての DMS レプリケーションタスクイベントについて、dataprocess-eventenable-lambda という名前の Lambda 関数を呼び出すように定義されています。この関数では、次のようなタスクを実行します。
- オプションで行うクラウドデータストアの後処理。
- CloudWatch Events ルールの再有効化。
タスクのステータスをチェックするために、DMS コンソールに戻ります。タスクの [Status] が Load Complete と表示されたら、次のステップを実行しログを表示します。
- Lambda コンソールで、dataprocess-eventenable-lambda という名前の Lambda 関数を選択します。
- [Monitoring]、[View logs in CloudWatch] の順にクリックします。
- 一覧表示から、最も新しい Log Streams を選択すると、対応するストリームのログが開きます。さまざまな DMS レプリケーションタスクイベントに関する Lambda 関数からの出力サンプルを、次の図に示します。
- このログのスクリーンショットで分かるとおり、Lambda 関数はレプリケーションタスクイベントに応答しています。
Replication task has stopped.Stop Reason FULL_LOAD_ONLY_FINISHED
.アプリケーションに渡す前に、データの整備、もしくは秘密情報のマスキングなどのイベント後処理を行いたい場合は、この Lambda 関数を使用します。
移行もしくは更新の後処理を行う、これらの Lambda 関数 は、15 分間の関数タイムアウト以内に処理を完了する必要があることにはご注意ください。詳細は「AWS Lambda の制限」をご参照ください。
4. 移行後のクリーンアップ
このソリューションのテストを完了したら、タスクを停止し、AWS CloudFormation スタックの削除を行って、リソースをクリーンアップしておきます。詳細は「AWS CloudFormation コンソールでのスタックの削除」をご参照ください。
5. 今回のソリューションに関するその他の機能とユースケース
異なる環境間でのデータ更新
アプリケーション開発チームは、開発、品質保証 (QA) 、ステージング、製品化などのさまざまな環境に対応しなければなりません。開発チームでは、製品としてデプロイする前に、プロトタイプ環境で製品品質のテストや確認を行います。彼らには、新機能のテストやバグ修正のために、製品版のものと同じようなデータを備えた環境が必要です。
ここで概説したソリューションでは、製品版からプロトタイプ版へ継続的にデータを更新するように定義しなおすことができます。データマスキング、カスタムデータ生成、個人識別情報 (PII) の消去などを、CloudWatch Events ルールを有効化し実行を継続する前に処理するよう、後処理用の Lambda 関数を設定してください。
異なる環境間でデータテーブルサブセットを同期化する
クラウドへの移行は、しばしば、複雑なアプリケーション環境下でサービスを移行することからはじまります。どの場合でも、パフォーマンス上の要求から、オンプレミスでのワークロードが完全にクラウドのストレージに複製されることが要求されます。
こういったシナリオに対処する 1 つの方法は、読み込み専用ワークロードにより移行を開始するというものです。データベースとアプリケーションが完全に再起動するまでの間は、ポイントはオンプレミスストレージに対し書き込みを行います。この場合では、移行済みのアプリケーションに対しては一方向性データ同期処理がサポートを行うと同時に、オンプレミスのデータベースには整合性を維持することができます。この記事で概説したソリューションを使い、オンプレミスからクラウドデータベースへのテーブルサブセットの複製をスケジューリングし、一方向性同期化処理を行うことができます。
マルチアクセスのためのデータマスキング
アプリケーションのチームでは、変更されることから守るためにソースデータベースの設定をマスキングした上で、データへのアクセスを提供することがあります。適切にデータのマスキングをするように、こういったマルチアクセス戦略を自動化する目的にも、この記事で説明した DMS のレプリケーションソリューションが使えます。
DMS レプリケーションを CDC モードを使わないように設定してください。ソースのデータベースが変更中であることを知るために、DMS ではエンジン特化型の API 処理を使い、ソースエンジンからのトランザクションログを読み取ります。各ソースエンジンには、指定されたユーザーアカウントに対し変更点をストリームするための、専用の設定事項があります。これにより、オリジナルデータの完全性をリスクにさらすことなく、希望するスケジュールでのデータべ―ス同期化が行えます。
まとめ
今回の記事では、DMS を使った自動移行処理、ワンタイムリフレッシュ、継続的な同期化処理、データマスキングなどのソリューションを概説しました。この記事がお役に立つことを願っています。
いつものように、AWS では皆さんのフィードバックをお待ちしています。コメント、質問、ならびに機能へのリクエストなどをお寄せください。
著者について
Udayasimha Theepireddy (Uday) は 2017 年 11 月よりアマゾン ウェブ サービスのシニアクラウドデータベースアーキテクトとして活躍しています。Amazon の社内顧客と協力して、いくつかのサービスをオンプレミスの Oracle から Aurora や RDS PostgreSQL、RDS MySQL、Redshift データベースに移行する作業を担当しています。
Satya Vajrapu は DevOps のコンサルタント として、アマゾン ウェブ サービスで働いています。彼は、インフラストラクチャー、アプリケーション、そしてプロセスのためのモジュールの設計やコーディングで、AWS のお客様を支援しています。