production.log

ピクスタ株式会社で開発部の部長をやっている星直史のブログです。

AWS Database Migration Serviceを使ったデータベース統合を試してみました

概要

1月20, 21日と、会社の開発合宿に行ってきました。 取り組んだ内容はタイトルの通り、AWS Database Migration Service(以下DMS)を使ったデータベース統合です。

解決したかった問題

PIXTAではマイクロサービスアーキテクチャを採用しています。
また、サービスは大きく4つに分かれており、それぞれ独立したDBを持っています。

サービスの運用をしていると、しばしばデータ抽出依頼がくるのですが、その依頼内容の中には複数のDB間をまたいだテーブル結合が必要になってくる依頼もあります。
「Aサービスが持つDBのテーブルの条件 かつ Bサービスが持つDBのテーブルの条件を満たしたもののうち、CサービスのDBのテーブルの内容を抽出」といった感じです。

これまで、このようなデータ抽出依頼は下記のようなことをやっていました。

  1. CサービスのDBの値が取得できるように、外部キーをBサービスのDBから取得するクエリ
  2. そのBサービスの値を取得するための外部キーをAサービスのDBから取得するためのクエリ
  3. 最後にCサービスのDBに対しての本当に欲しかった値のクエリ

本当は、クエリ1つで済むはずなのに・・・。

そこで、今回の開発合宿はDMSを使ったデータベース統合に取り組むことにしました。

AWS Database Migration Serviceとは

簡単に言うとDB移行サービスです。
オンプレ / AWS内問わず、どちらかがAWS内にあれば、移行が可能です。
また、Oracle から AWS Auroraなど、異なるDBプラットフォーム間の移行もDMSがうまいことやってくれます。
さらに単純に移行だけではなく、MySQLとMariaDBとか、2DBを1つのDBに異種交配することも可能ですし、移行元のデータの差分更新を検知し、反映してくれます。ダウンタイムもありません。

f:id:watasihasitujidesu:20180122131648p:plain

AWS Database Migration Serviceでデータベースを統合するまでの手順

では具体的に処理の手順を説明していきます。 処理自体は3ステップなので簡単です。

  1. Replication Instanceを作成
  2. SourceとなるDBの設定と移行先のDBの設定
  3. データ移行タスクの設定

1. Replication Instanceを作成

DMSの本丸と言いますか、タスクを実行するために必要なインスタンスを作成します。

DMS > Replication Instances > Create replication instance

f:id:watasihasitujidesu:20180121121944p:plain

次に、インスタンスの情報を諸々設定していきます。 VPCに入れることが前提なので、ネットワーク関連でややハマるかもしれません。

f:id:watasihasitujidesu:20180121122141p:plain

今回、Production相当のRDSをターゲットに移行をしたのですが、インスタンスサイズに関してはあまりリソースは必要としていないようでした。 t2.smallでも十分でした。

2. SourceとなるDBの設定と移行先のDBの設定

続いて、Replication Instanceで処理する移行対象のDBの設定します。 データ移行元となるSourceと、データ移行先となるTargetの2つ設定が必要です。

Source Databaseの設定

DMS > Endpoints > Create endpointを押下します。

f:id:watasihasitujidesu:20180121122848p:plain

画像の赤枠でも囲ってあるServernameはホストを指定します。*1

次に、導通確認をします。

f:id:watasihasitujidesu:20180121123144p:plain

Run testが通れば最低限、Replication InstanceからDBに接続ができています。

Target Databaseの設定

Target Databaseも基本はSourceDBと同じです。
自分が勘違いしていた点は、TargetDBは、DMSの方で用意してくれるものかと思っていたのですが、DMSの挙動は、TargetDBに対して、SourceDBをコピーする動きになるので、TargetDBはあらかじめ用意する必要がありました。

3. データ移行タスクの設定

DMS > Tasks > Create taskを押下します。

f:id:watasihasitujidesu:20180121135011p:plain

基本的には、SourceDBとTargetDBを設定して、Replicationの設定を行うだけです。

Migration Typeは3種類あり、それぞれ、下記のような挙動となります。

Migration Type 用途
Migrate existing data 現在のSourceDBの情報のみをReplicationする
Migrate existing data and replicate ongoing changes 現在のSourceDBの情報と、SourceDBに変更が加わった場合に差分更新を行う
Replicate data changes only SourceDBに変更が加わった場合にその変わったデータのみを追加する

また、後続の設定項目である、Task Settings の Enable loggingにチェックを行うとDMSで行う処理のログがCloudWatchに吐かれます。
ログは、通常処理の状況ではなく、Errorになった場合の情報も吐かれるので、チェックをしておくのをオススメします。

エラー状況はStatusやTables errorsの状況でわかります。 下記の図はエラーが76件出ているので、ページ下部のLogsからCloudWatchのリンクを開き、確認するとログを見ることができるはずです。

f:id:watasihasitujidesu:20180122131829p:plain

タスクは実行されれば、テーブルごとに1万件ずつinsertが走っていきます。 また、最大8並列で実行されます*2

何事もなければ、TaskのStatusがLoad compliteとなり、レプリケーションは完了です。

まとめ

これまで、分割されたDBからデータ抽出をするのに、何回もクエリを実行したり、DBを統合するのにスクリプトなどを書く必要がありましたが、AWS DMSを使えば、マネジメントコンソール上からの設定で手軽にDB統合することができました。 また、データ統合だけではなく、その逆の統合されたDBを再度分割することも可能です。

DMSは当初、オンプレのDBを移行するだけのものだと思っていましたが、このような使い方ができるには驚きました。

ただ、200GB以上のDBをレプリケーションしようとした場合、移行にかかる時間が数時間かかっていたので、速度改善の余地は十分にありそうです。

*1:当初AWSのサービスだし、RDSのインスタンス名の入力かと思いきやそうではありませんでした

*2:TargetDBがRedshift以外の場合