概要
1月20, 21日と、会社の開発合宿に行ってきました。 取り組んだ内容はタイトルの通り、AWS Database Migration Service(以下DMS)を使ったデータベース統合です。
解決したかった問題
PIXTAではマイクロサービスアーキテクチャを採用しています。
また、サービスは大きく4つに分かれており、それぞれ独立したDBを持っています。
サービスの運用をしていると、しばしばデータ抽出依頼がくるのですが、その依頼内容の中には複数のDB間をまたいだテーブル結合が必要になってくる依頼もあります。
「Aサービスが持つDBのテーブルの条件 かつ Bサービスが持つDBのテーブルの条件を満たしたもののうち、CサービスのDBのテーブルの内容を抽出」といった感じです。
これまで、このようなデータ抽出依頼は下記のようなことをやっていました。
- CサービスのDBの値が取得できるように、外部キーをBサービスのDBから取得するクエリ
- そのBサービスの値を取得するための外部キーをAサービスのDBから取得するためのクエリ
- 最後にCサービスのDBに対しての本当に欲しかった値のクエリ
本当は、クエリ1つで済むはずなのに・・・。
そこで、今回の開発合宿はDMSを使ったデータベース統合に取り組むことにしました。
AWS Database Migration Serviceとは
簡単に言うとDB移行サービスです。
オンプレ / AWS内問わず、どちらかがAWS内にあれば、移行が可能です。
また、Oracle から AWS Auroraなど、異なるDBプラットフォーム間の移行もDMSがうまいことやってくれます。
さらに単純に移行だけではなく、MySQLとMariaDBとか、2DBを1つのDBに異種交配することも可能ですし、移行元のデータの差分更新を検知し、反映してくれます。ダウンタイムもありません。
AWS Database Migration Serviceでデータベースを統合するまでの手順
では具体的に処理の手順を説明していきます。 処理自体は3ステップなので簡単です。
- Replication Instanceを作成
- SourceとなるDBの設定と移行先のDBの設定
- データ移行タスクの設定
1. Replication Instanceを作成
DMSの本丸と言いますか、タスクを実行するために必要なインスタンスを作成します。
DMS > Replication Instances > Create replication instance
次に、インスタンスの情報を諸々設定していきます。 VPCに入れることが前提なので、ネットワーク関連でややハマるかもしれません。
今回、Production相当のRDSをターゲットに移行をしたのですが、インスタンスサイズに関してはあまりリソースは必要としていないようでした。 t2.smallでも十分でした。
2. SourceとなるDBの設定と移行先のDBの設定
続いて、Replication Instanceで処理する移行対象のDBの設定します。 データ移行元となるSourceと、データ移行先となるTargetの2つ設定が必要です。
Source Databaseの設定
DMS > Endpoints > Create endpointを押下します。
画像の赤枠でも囲ってあるServernameはホストを指定します。*1
次に、導通確認をします。
Run testが通れば最低限、Replication InstanceからDBに接続ができています。
Target Databaseの設定
Target Databaseも基本はSourceDBと同じです。
自分が勘違いしていた点は、TargetDBは、DMSの方で用意してくれるものかと思っていたのですが、DMSの挙動は、TargetDBに対して、SourceDBをコピーする動きになるので、TargetDBはあらかじめ用意する必要がありました。
3. データ移行タスクの設定
DMS > Tasks > Create taskを押下します。
基本的には、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のリンクを開き、確認するとログを見ることができるはずです。
タスクは実行されれば、テーブルごとに1万件ずつinsertが走っていきます。 また、最大8並列で実行されます*2
何事もなければ、TaskのStatusがLoad compliteとなり、レプリケーションは完了です。
まとめ
これまで、分割されたDBからデータ抽出をするのに、何回もクエリを実行したり、DBを統合するのにスクリプトなどを書く必要がありましたが、AWS DMSを使えば、マネジメントコンソール上からの設定で手軽にDB統合することができました。 また、データ統合だけではなく、その逆の統合されたDBを再度分割することも可能です。
DMSは当初、オンプレのDBを移行するだけのものだと思っていましたが、このような使い方ができるには驚きました。
ただ、200GB以上のDBをレプリケーションしようとした場合、移行にかかる時間が数時間かかっていたので、速度改善の余地は十分にありそうです。