こんにちは。インフラエンジニアの永井(shnagai)です。
RDS(MySQL)にあるデータを検索エンジン(今回でいうとOpenSearch)に同期したいというプロジェクトがあり、AWS Database Migration Service(以下、DMS)について調べる機会があったので、これまでAWS SAの方に聞いたりwebで調べたことについてざっとまとめてみました。
この記事はコネヒト Advent Calendar 2021の7日目の記事です。
やりたいことのざっくり要件
最初に今回調査をするトリガとなったプロジェクトの要件を簡単に紹介します。
端的に言うと、RDSにある特定のテーブルをAmazon OpenSearch Service（以下、OpenSearch）に同期したいというもので
- RDSにある特定のテーブルのデータをOpenSearchに同期
- 将来的にはニアリアルタイム(準同期)でデータを同期したい
- データ同期の運用コストは低ければ低いほどよい(もちろん開発すれば同期処理作れるがそれは最後の手段とする)
データ同期手法の候補
AWS SAの方に相談したところいくつかのデータ同期パターンを提案してもらいました。
- AWS Database Migration Service(DMS)を使うパターン
- 名前の通りデータベースマイグレーションのためのAWSサービス
- Bootstrap(バッチ)
- CDC（継続レプリ）
- Glue Elastic Views（プレビュー）
- まだプレビューですがGlueにも同じような機能が開発されている模様
- https://aws.amazon.com/jp/glue/features/elastic-views/
- EC2にLogstashエージェントを使うパターン
- JDBCドライバでRDSに接続
- logstashなので、OpenSearchへの接続はお手の物
DMSを使うことで要件を満たせそうだという肌感を得たのでDMSについて、公式ドキュメントを中心にどんなサービスなのか調査してみました。
AWS DMSの特徴
以下は、公式ドキュメントを読み解きながら自分の中で理解したメモになります。
全体像
公式ドキュメントを開くと一番目のつくところに下記の全体像の図が飛び込んできます。
下記の図の登場人物を紹介するとこんな役割になります。
- Replication Instance: AWS DMSの中心人物。実際のデータ同期処理を実行するEC2インスタンス
- Source Database: 読んで字のごとくですが同期元のデータソース
- Source Endpoint: Replication InstanceがSource Databaseに接続するための接続情報
- Target Database: 読んで字のごとくですが同期先のデータソース
- Target Endpoint: Replication InstanceがTarget Databaseに接続するための接続情報
一見データマイグレーションするサービスと考えるとまぁそうだよなという登場人物なのですが、ここでうれしいのがターゲットデータソースの多様さです。
AWSマネージドサービスということでデータの同期先に、下記のようなRDB以外のデータソースも指定することが出来、そのアクセスはIAMロールで制御可能なのはうれしいポイントではないでしょうか。
もちろん今回の同期先に要件であるOpenSearchも入っています。
ただ、この異なるデータソース間のデータ同期であればバルクデータローダであるEmbulkや他にもツールは色々ありそうです。
AWS DMSの強みはCDC(継続的なレプリケーション)
先程も書きましたが、異なるデータソース間のデータ同期であればそれが実現出来るツールは世の中にたくさんあります。
では、継続的なレプリケーションで異なるデータソース間のデータ同期となるとどうでしょう?自分の知る限りだと、そのようなツールは多くはありません。
DMSを調べているうちにこの継続的なレプリケーションで、異なるデータソースにデータを同期出来るのが最大の強みだという結論に達しました。
DMSのCDCには下記の仕様があります。
- CDCを使う場合には、ソースデータストアはレプリケーション出来る必要がある(MySQL系ならbinlog)
これはつまりMySQLの例で示すと、
- MySQLでいうとbinlogレプリのスレーブにDMSのReplication Instanceを登録
- DMSはbinlogレプリされた内容を、Replication Instance内でターゲットに即した形に変換して、Target Databaseに同期する
- Replication Instance内で、特定のテーブルだけを同期するようなフィルタや型変換が出来るから必要なものだけターゲットへは同期することが可能
ソースのデータ同期には、枯れた(信頼性も高い)binlogレプリの仕組みを使い、ターゲットへの同期には、AWSマネージドでデータ変換等にも柔軟に対応してくれるというのは調べている限りかなり筋のいいサービスだなという印象を持ちました。
特に、運用コスト面がほぼかからないのではという点が強力に映ります。
来月には技術検証を終える予定なので、実際の検証でのプロセスはまた別で書こうと思います。
明日は、 @takoba_によるPHPのエントリの予定なのでお楽しみに。
コネヒトではサービスの信頼性向上をミッションに幅広い領域をカバーしながらエンジニアリングの力でサービスをよりよくしていけるエンジニアを募集しています。 少しでも興味もたれた方は、是非気軽にお話出来るとうれしいです。
