AWS DMSサーバレスの検証

サービス概要

AWS Database Migration Service(AWS DMS)は、データベース（RDB、データウェアハウス、NoSQL データベースなど）の移行を支援するマネージドサービスです。DMSサーバレスは、DMSからレプリケーションインスタンスを不要にしたものになります。2023年6月にGAになりました。

（https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/images/datarep-serverless-replication-process.pngより）

目的・やりたいこと

DMSとDMSサーバレスを比較し、新サービスであるDMSサーバレスの有用性を確認する。

対象者

データベース移行運用者（初級者〜中級者）

対象となる技術

• Database Migration Service
• Database Migration Serviceサーバレス

条件（導入にあたって前提事項）

・ダーゲットにアクセスできるロールはあらかじめ作成されているものとします。

参考URL

• AWS Database Migration Service サーバーレスの一般提供を発表
• AWS Database Migration Service とは?
• AWS DMS Serverless を使ってみた
• 【AWS Database Migration Service】AWSの基礎を学ぼう

制限事項

https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Serverless.Limitations.html

• 変更できるのは、CREATED、STOPPED または FAILED 状態の DMS レプリケーション設定のみ
• 削除できるのは、STOPPED または FAILED 状態にある AWS DMS レプリケーション設定のみ
• レプリケーションには、割り当てられた静的な 100GB ストレージが使用できる
• DMS サーバーレスレプリケーションには管理タスク用のパブリック IP アドレスがないため、コンソールを使用して管理する

作業の流れ

概要図

事前作業

最初に事前作業として通常のDMSを作成します。次に検証手順としてDMSサーバレスを作成し、比較します。

最小構成（シングルAZ）でRDS（MySQL）を作成
1．踏み台からLinuxサーバにログインし、mysqlをインストール

# yum install mysql

2．RDSのmysqlに接続

# mysql -u admin -p -h nozaki-mysql1.cz0t44sg1pez.ap-northeast-1.rds.amazonaws.com
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MySQL connection id is 21
Server version: 8.0.33 Source distribution

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MySQL [(none)]> SELECT * FROM mydb.product ORDER BY 1;
+------+------------+------------+
| id   | name       | col        |
+------+------------+------------+
|    1 | A000000001 | F000000001 |
|    2 | B000000002 | G000000002 |
|    3 | C000000003 | H000000003 |
|    4 | D000000004 | I000000004 |
|    5 | E000000005 | J000000005 |
+------+------------+------------+
5 rows in set (0.00 sec)

ちなみにこの時の接続パスワードは、いつものadminのパスワードの最後の@を取ったもの

3．参考URLの4番目にならってDBを入れ込む。ちなみに以下のデータベースを作るコマンドがなかった

MySQL [(none)]> create database mydb;

4．RDS（ソース）のエンドポイント作成

5．RDSのログイン情報を登録

6．S3（ターゲット）のエンドポイント作成
S3のアクセス情報を登録

7．レプリケーションサブネットグループの作成
レプリケーションインスタンスを作成する前に必ず事前に作成しておかなければならない。
説明を入れないと[サブネットグループの作成]ボタンが有効にならないので注意

7．レプリケーションインスタンスの作成
DMSのインスタンスサイズなどほぼ初期設定。SGの設定を忘れないように

このインスタンスの作成が結構かかります。10分くらいかかりました。

8．データベース移行タスクの作成
ほぼデフォルトのままでOK

このロードも本来時間かかるはずなんですが、元のRDSのデータ量がほぼなかったために1分未満で終わりました。

9．S3の確認
4つのフォルダができてました。

実際にmydb/product/LOAD00000001.csvをダウンロードして開いてみると

上記のmydb.productテーブルの内容がちゃんと表示されました！移行成功です！

ちなみにDMSのレプリケーションインスタンスは、t3.mediumでシングル構成でも月額95ドル課金されちゃいます。

検証手順

次はインスタンスを使わないDMSサーバレスでやってみます。
（その前に課金が惜しいのでレプリケーションインスタンスを削除しようとしましたが、対象となっているデータベース移行タスクを削除してからでないと削除できませんでした。）

1．[サーバレスレプリケーション]から[レプリケーションの作成]

DMSではデータベース移行タスクだったのが、DMSサーバレスでは「サーバレスレプリケーション」という名称に変わっています。

2．設定でソースエンドポイントとターゲットエンドポイントを指定

フルロードのみでもよかったんですが、結果のステータスが「停止およびプロビジョニング解除」になってしまい、失敗したかのような見栄えで良くないため、今回はフルロード＋CDCを選択

3．[ウィザード]はデフォルトのまま

4．[テーブルマッピング]はDMSタスクの時と同様

5．[コンピューティング設定]ではどっちにしろサブネットグループは必要みたい。

基本的にデフォルトのままでOKだが、最大DMS（DCU）は必須なので、適当に4とする。

6．[レプリケーションの作成]をクリック

7．[レプリケーションを開始]をクリック

8．開始して30分くらいしたところでようやくフルロード開始。でもフルロードが始まってからはデータ量が少ないのもあってか1分足らずで終了

9．どころがCloudWatchログで以下のエラーが出てるせいか、どうしてもロードがうまくいかず、「失敗」のステータスになってしまう。

2023-09-14T00:03:04 [TASK_MANAGER    ]E:  Error Code [10002] : MySQL binary Logging must use ROW format; Errors in MySQL server binary logging configuration. Follow all prerequisites for 'MySQL as a source in DMS' from https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.MySQL.html or'MySQL as a target in DMS' from https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Target.MySQL.html ; Failed while preparing stream component 'st_0_ZVSCSNXSVVZT4ZNKOFIEH7PQ5D2S2ZXMOWMLENY'.; Cannot initialize subtask; Stream component 'st_0_ZVSCSNXSVVZT4ZNKOFIEH7PQ5D2S2ZXMOWMLENY' terminated [1020418]  (replicationtask.c:2891)

どうもバイナリロギングをROWに設定しておかないといけないらしい。

10．バイナリロギングをROWにするため、まずはパラメータグループを作成

11．その後パラメータグループを編集し、binlog_formatをROWに設定

他にもUsing a MySQL-compatible database as a source for AWS DMSに従い、以下パラメータを設定

パラメータ	値
binlog_checksum	NONE
binlog_row_image	FULL

12．DBインスタンスにパラメータグループ「nozaki-mysqlgroup」を適用

13．mysqlに接続し、ログの保存期間を 24 時間に延長
AWS が管理する MySQL 互換データベースはバイナリ ログをできるだけ早くパージするため、ログが利用可能な状態を維持する時間を長くする必要があるため

MySQL [(none)]> call mysql.rds_show_configuration;
+------------------------+-------+-----------------------------------------------------------------------------------------------------------+
| name                   | value | description                                                                                               |
+------------------------+-------+-----------------------------------------------------------------------------------------------------------+
| binlog retention hours | NULL  | binlog retention hours specifies the duration in hours before binary logs are automatically deleted.      |
| source delay           | 0     | source delay specifies replication delay in seconds between current instance and its master.              |
| target delay           | 0     | target delay specifies replication delay in seconds between current instance and its future read-replica. |
+------------------------+-------+-----------------------------------------------------------------------------------------------------------+

MySQL [(none)]> call mysql.rds_set_configuration('binlog retention hours', 24);
Query OK, 0 rows affected (0.02 sec)

MySQL [(none)]> call mysql.rds_show_configuration;
+------------------------+-------+-----------------------------------------------------------------------------------------------------------+
| name                   | value | description                                                                                               |
+------------------------+-------+-----------------------------------------------------------------------------------------------------------+
| binlog retention hours | 24    | binlog retention hours specifies the duration in hours before binary logs are automatically deleted.      |
| source delay           | 0     | source delay specifies replication delay in seconds between current instance and its master.              |
| target delay           | 0     | target delay specifies replication delay in seconds between current instance and its future read-replica. |
+------------------------+-------+-----------------------------------------------------------------------------------------------------------+

14．それからこれを忘れそうになっちゃいますが超大事。RDSの再起動

15．改めて再実行（アクション > 処理を再開）
すると今度は無事ロードが完了しました！

16．試しに元のMySQLでデータを追加してみる。

MySQL [(none)]> INSERT INTO mydb.product VALUES (6, 'E000000006', 'J000000006');

Query OK, 1 row affected (0.01 sec)

MySQL [(none)]> INSERT INTO mydb.product VALUES (7, 'E000000007', 'J000000007');

Query OK, 1 row affected (0.01 sec)

17．S3を見に行くと、ご覧のようにファイルが2つ追加されているのがわかる。

18．新しい2番目のファイルを開いてみると、最後に追加した7番目のデータが表示されました！

所要時間

2時間

まとめ

DMSと比較したDMSサーバレスの大きな違いは、

レプリケーションインスタンスを作成しなくてよいこと

通常のDMSではレプリケーションインスタンスを作成するため、オンデマンドインスタンス料金が発生します。また、作成時にサイジングなどのプロビジョニングが必要です。
一方、DMSサーバレスではDMSレプリケーションインスタンス自体が不要となるのでオンデマンドインスタンス料金も不要となることと、DCUを指定することでキャパシティプロビジョニング自動化が受けられます。

DMSサーバレスではサーバレスレプリケーションの作成・開始に約30分かかることが若干の考慮点なくらいです。