AWS DMS を利用して DB のアップデートログを S3 に出力する

AWS の DMS (Database Migration Service) は異なる DBMS 間の
マイグレーション等を行うためのサービスです. 

また移行先には RDS だけでなく S3 も利用できます. 
さらにこれを利用すれば RDS で行われた CRUD 処理を S3 にログとして出力することができます.

## そもそもやろうとしたこと
RDS Aurora のあるテーブルに出力されるレコード(ログ情報)をお手軽に S3 に自動出力したかった.

## 手順
1. レプリケーション DB の作成
2. ソースエンドポイントの作成
3. ターゲットエンドポイントの作成
4. タスクの作成
5. タスクの実行

### レプリケーション DB の作成
ログ出力元の DB のレプリケーション DB を作成します.
AWS コンソールで DMS -> レプリケーションインスタンス から 「レプリケーションインスタンスの作成」を選択します.
設定内容は RDS でインスタンスを作成する内容とあまり変わらないです.

![スクリーンショット 2018-03-12 18.49.27.png](https://qiita-image-store.s3.amazonaws.com/0/3147/cb4f89ab-8dd9-329f-2d26-5d74d38b50f5.png)

インスタンスクラスは用途によりますが S3 への中継用ならそこまで大きなクラスは必要ないようです.
VPC はレプリケーション元の RDS と同じにした方が面倒は少ないでしょう. 
パブリックアクセスはセキュリティ面から無効の方が無難です.

さらにアドバンスト設定ではストレージサイズやセキュリティグループを設定できます.

### ソースエンドポイントの作成
ログ出力元の RDS からレプリケーション DB へのエンドポイントを作成します.
DMS -> エンドポイント から 「エンドポイントの作成」 を選択します.

![スクリーンショット 2018-03-12 18.57.08.png](https://qiita-image-store.s3.amazonaws.com/0/3147/d1db5927-e3ee-5aab-d7f8-c037d6fc4db5.png)

エンドポイントタイプは 「ソース」 を選択します.
ソースエンジンはレプリケーション元の RDS に合わせて, サーバー名は DB のエンドポイントを指定.
ポート, ユーザー名, パスワードは DB にアクセス可能なものをそれぞれ指定します.
その他必要な接続情報があればアドバンスト内で指定します.

<img width="828" alt="スクリーンショット 2018-03-12 19.02.59.png" src="https://qiita-image-store.s3.amazonaws.com/0/3147/2b7929c3-d467-cf46-4125-a7c08371d0e3.png">

さらに下部の エンドポイント接続のテスト にて先ほど作成したレプリケーション DB を指定します.
指定後は 「テストの実行」 で接続できることを確認しましょう. 
※レプリケーション DB から RDS インスタンスへアクセスできるようなセキュリティグループ設定が必要です.

#### RDS 側の設定
https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Introduction.Components.html
継続的なレプリケーション (変更データキャプチャ (CDC)) 項より, 

継続的な変更キャプチャには RDS 側のパラメータ設定が必要な場合があり, 
例えば MySQL ではバイナリログを有効にする必要があります.
RDS インスタンスの再起動が必要な場合がありますので稼働中システムでは注意しましょう. 


### ターゲットエンドポイントの設定
先ほどと同様に 「エンドポイントの作成」 を選択して今度はエンドポイントタイプに 「ターゲット」 を選択します.
![スクリーンショット 2018-03-12 19.06.59.png](https://qiita-image-store.s3.amazonaws.com/0/3147/c01a74bd-494a-a550-2bc9-96e21447c30e.png)
出力用に S3 バケットとフォルダを作成しておきます. またバケットに出力できるような IAM ロールも必要です.
(よく見たらフォルダは必須ではなかった)

今回もエンドポイントに先ほどと同様にレプリケーション DB を指定します.
こっちは レプリケーション DB -> S3 の接続設定とテストになります. 
IAM ロールの設定だけ合っていれば問題なく接続できるはずです.

### タスクの作成
2つのエンドポイントが作成できたら DMS -> タスク から 「タスクの作成」 を選択します.
<img width="826" alt="スクリーンショット 2018-03-12 19.13.39.png" src="https://qiita-image-store.s3.amazonaws.com/0/3147/64849fed-e61e-0ea5-a27a-63e06962dc90.png">
レプリケーションインスタンス, ソースエンドポイント, ターゲットエンドポイントには上記で作成したそれぞれを設定します.

移行タイプは 「既存のデータを移行する」 「既存のデータを移行して、継続な変更を...」 「データ変更のみをレプリケートする」 
の3つがあります. 今回はアップデートログが欲しいだけなので 「データ変更のみをレプリケートする」 を選択しました.

![スクリーンショット 2018-03-12 19.21.58.png](https://qiita-image-store.s3.amazonaws.com/0/3147/ea4c1046-5308-3f4e-44e5-e6102c4b7c1e.png)

続いて タスク設定 ではレプリケーション元のデータに応じた設定を行います. 
タスク内でエラーが発生した際の調査のために 「ロギングの有効化」 は ON にしておいた方がいいと思います.

![スクリーンショット 2018-03-12 19.28.39.png](https://qiita-image-store.s3.amazonaws.com/0/3147/0a9c2f11-02d1-3b21-33ac-45295baefd22.png)


最後に テーブルマッピング で特定のテーブルの更新情報だけ S3 に出力する, などの設定ができます.
今回は 「test」 テーブルの更新情報だけ出力するようにしてみました.  
最後に 「タスクの作成」 を選択して完了になります.

### タスクの実行
作成したタスクを開始すると, ステータスが 「開始中」 -> 「ロード完了、 レプリケーション進行中」 のように変わります.
(移行タイプによってはステータス表示が違うかもしれないです)
この状態で RDS にレコード更新をかけると S3 のバケット内に csv ファイルで更新データが出力されます.

![スクリーンショット 2018-03-12 21.12.16.png](https://qiita-image-store.s3.amazonaws.com/0/3147/d65a159a-8163-f77d-6455-ff2fe7ac3165.png)
こんな感じ

### 最後に
このように実験したものの, ログ DB にバイナリログを吐かせるに当たって
パフォーマンスがどれだけ落ちるか検証が必要だったり, 
レプリケーション DB もなんだかんだ管理コストがかかるなあ, 等々色々あって本番環境への導入は見送りました. 

DMS 自体はソースを S3 にして RDB に突っ込んだり等できるので使い方次第で面白いことができそうです.
(本来の DB 移行用途にももちろん有用です)