Aurora のデータをDMS でCDC同期 - Tansan Kenta テックブログ

こんにちは！Happy New Year ですね！2026年もいい年になりますように！ということで、年明け早々からブログを書いていきます！

AWS Data Migration Service について調べる機会がありまして、データ移行するときってData Migration Service 通称DMS を用いてデータを移行したりすることってあると思います。

ただ、このサービス実は移行以外のこともできるのです。それがCDC、つまりChange Data Capture です。変更があった差分を検知することです。検知する機能があるということはデータベースのインスタンス間での同期が可能ということです。今回はDMS のCDC について書いていきたいと思います！

今回の構成
今回実施する内容
構築手順
まとめ
参考サイト

今回の構成

構成はとても簡単です。DMS を通じて、2 台のAurora Cluster のデータを同期できるような構成になっています。細かい部分についてはこの構成図には書いていないので、後々説明しています。

今回実施する内容

今回はAWS DMS を使って、データ移行ではなく、データの双方向同期ができることが目標になっています。その前に仕組みや一体どんな設定が必要なのっていうところを図を用いて説明していこうと思います。

CDC とは

簡単に説明すると、ソースのDB からDMS インスタンスを通じてターゲットDB にデータを同期することです。ただ、その同期する内容がソースDBとターゲットDBの間で差分がある箇所のみを同期することができます。(前提として元々両方のDBが差分がない状態で始まる必要があります)

なので、Update やInsert がソースDB の方で実行されてデータが書き換わると、それがターゲットDB にも反映されるようになっています。

どうやってその差分はわかるの？

データベースによって差はあるかもしれませんが、MySQL の場合はbinlog、つまりトランザクションログを追いかけて差分を検出します。これによって、差分を検知することができます。なので、基本的にはプライマリー・セカンダリーの構成とほとんど変わりないですね。あれもbinlog の位置を読んで、セカンダリーのインスタンスに流していきます。

DMS の機能としてCDC を実施する上である特定のスキーマで実施したいであったり、特定のテーブルでCDC を実施したいといった要件にも対応することができるため、全部流す必要はプライマリー・セカンダリー構成のようにないようになっています。(そういうことがプライマリー・セカンダリー構成でできたらすいません)

それで、気になってくるのは費用ですよね。

費用について

まず、必ず必要になってくるのが、Aurora Cluster の料金ですね。これは同期しているので、2台分の料金が必ず必要になります。では、DMS はどんな料金が発生するのでしょうか？

DMS 料金について

DMS インスタンスの料金
- DMS を実行する際にその処理するために別途インスタンスが必要になります
- dms.m5.xlarge のインスタンスの場合
  - シングルAZ の場合: $0.41 per/h
  - マルチAZ の場合: $0.82 per/h
ストレージ料金
- インスタンスを実行するためにはストレージ要りますよね
- 100GB あたり$11.50 /月でかかります

なので、ここだけでもマルチAZを選択して、100GB などにしたら、$600ほど費用が発生しそうですね。これプラス通信費などもAZ が違えば発生するので、データ通信量によっては$1000 かかるなんてことも発生しそうなので、この辺りは費用のアラート通知鳴らすなりして、見守る必要があると思います。

そして忘れてはいけないのが、これにAurora 2台分の料金が発生するので、月額全部で30万円近くというのもざらに発生する可能性もありますので、ご注意ください。

ここまで説明してきましたが、実際に同期してみましょう！

構築手順

今回Aurora の構築の手順は省きます。ただ、カスタムパラメータを作成するのは大事なので、ここだけ手順にしておきます。

カスタムパラメータ作成

目的はbinlog を有効化するためです。Aurora を使用するので、Cluster とinstance のカスタムパラメータを作成していきます。

Cluster 用カスタムパラメータ

MySQL は8なので、mysql8.0 のパラメータを指定して、Cluster parameter group をタイプにします。

Instance 用のカスタムパラメータ

タイプのみ間違えないようにinstance用を指定してください。

binlog_format の設定

値をROW に設定してください。Cluster のパラメータグループの設定になります。

DMS 作成

エンドポイントの作成

ソースから作成

対象のRDS インスタンスを指定すると自動で入力してくれます。パスワードのみ自分で選択しましょう。

ターゲットエンドポイント

ターゲットもソースと同様に作成していきます。

DMS サブネットグループ作成

DMS にもサブネットグループが必要になるので、作成します。内容はRDS のサブネットグループを作成と同じです。

レプリケーションインスタンスの作成

DMS を動かすためのインスタンスを作成していきます。

スペック選択

ネットワークとメンテナンス

Aurora 作成の時に使用したVPC と先ほど作成したサブネットグループを選択します。メンテナンスは自動でバージョンアップをするとCDC の処理でダウンタイムが発生する可能性があるので、同期が止まっても問題ないという許容度がない限りは自動でアップグレードはお勧めではないですね。

ここまで設定できたら作成していきます！

タスク作成

それぞれ作成したエンドポイント・プロビジョンドインスタンスを指定します。

タスクタイプ選択

今回は移行と複製どちらもしたいので、真ん中の「移行および複製」を選択します。こうすることによって、移行と移行が完了したらCDC を実施してくれるようになります。

CDC カスタム設定

設定

ターゲットテーブルはない場合は作成するように設定しました。

テーブルマッピングとスタートアップ設定

スタートアップ設定は後で手動で実行するようにします。テーブルマッピングは今回の対象テーブルを紹介した後に設定しますので、この段階では全てアスタリスクの設定にします。つまり全データベースの全テーブルが対象です。

これで移行の準備はできたので、これから使用するテーブルやデータベースを作成していきます。テスト用なので、皆さんは既に存在しているテーブルなどがあればそれを使用してください。

データベース・テーブル作成

ここで作成する対象のインスタンスはもちろんソースデータベースのほうです。ターゲットの方に作成しても今回は同期されませんので、ご注意ください。他のタスクを作成すれば逆も可能です。

今回はテストなので、Gemini にデータベースとテーブル作成とそのテストデータ作成のコマンドを作成してもらいました。まずはデータベースは下記を作成します。

create database test;

テーブルを作成します。

CREATE TABLE orders_test (
    order_id INT AUTO_INCREMENT PRIMARY KEY,
    user_email VARCHAR(100),
    product_name VARCHAR(50),
    order_status VARCHAR(20),
    price DECIMAL(10, 2),
    long_description TEXT,   -- ここでサイズを稼ぎます
    created_at DATETIME
);

データを作成します。

SELECT 
    CONCAT(SUBSTRING(MD5(RAND()), 1, 8), '@example.com'), 
    CASE FLOOR(RAND() * 3) 
        WHEN 0 THEN 'Laptop PC' 
        WHEN 1 THEN 'Smartphone' 
        ELSE 'Tablet' 
    END, 
    IF(RAND() > 0.5, 'SHIPPED', 'PENDING'), 
    ROUND(RAND() * 10000, 2), 
    REPEAT(MD5(RAND()), 30), 
    DATE_ADD('2023-01-01', INTERVAL FLOOR(RAND() * 365) DAY) 
FROM (
    SELECT a.N + b.N * 10 + c.N * 100 AS n
    FROM (SELECT 0 AS N UNION SELECT 1 UNION SELECT 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5 UNION SELECT 6 UNION SELECT 7 UNION SELECT 8 UNION SELECT 9) a,
         (SELECT 0 AS N UNION SELECT 1 UNION SELECT 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5 UNION SELECT 6 UNION SELECT 7 UNION SELECT 8 UNION SELECT 9) b,
         (SELECT 0 AS N UNION SELECT 1 UNION SELECT 2 UNION SELECT 3 UNION SELECT 4 UNION SELECT 5 UNION SELECT 6 UNION SELECT 7 UNION SELECT 8 UNION SELECT 9) c
) temp;

データを増やしていきます。

INSERT INTO orders_test (user_email, product_name, order_status, price, long_description, created_at)
SELECT 
    user_email, 
    product_name, 
    order_status, 
    price, 
    long_description, 
    DATE_ADD(created_at, INTERVAL 1 HOUR)
FROM orders_test;

テストデータが入っていることを確認

SELECT product_name, COUNT(*), SUM(price) FROM orders_test GROUP BY product_name;

DMS を実行

ここまでできたら、DMS で問題なく移行と差分の反映ができることを確認していきます！

タスクの開始

少しするとロードを実行中に変わります。

移行確認

移行したテーブルやスキーマでフィルタリングしたときにTable completed となっていれば問題ないです。

CDC の確認

CDC の設定を確認するために設定を変更します。対象テーブルに絞って再度実施していきます。

設定の変更

対象テーブルをorders_test のみにします。これで変更差分をすぐに捉えることができます。

データの追加

CDC が問題なく実行されるかを検証するためにデータをいれます。その前に現在の状態について調べます。

データ量確認

SELECT product_name, COUNT(*), SUM(price) FROM orders_test GROUP BY product_name;

データ追加

256,000件のデータをInsert したので、512000件になりました。

INSERT INTO orders_test (user_email, product_name, order_status, price, long_description, created_at)
SELECT 
    user_email, 
    product_name, 
    order_status, 
    price, 
    long_description, 
    DATE_ADD(created_at, INTERVAL 1 HOUR)
FROM orders_test;

レプリケーション実行中

テーブル統計

512000件のデータが入っていれば問題なく同期完了しています！

CDC メトリクス

ここからもCDC が問題なく実行されていることが確認できますね。これどれくらい遅延が発生するのかは気になりますが、5分以内には完了はしていたように思います。恐らく同期するデータ量やテーブル量にもよるのかもしれませんが、データ量が莫大に多くない限りは分単位で遅延するのかというのも少し検証してみたいところですね。