はじめに
こんにちは。プラットフォーム開発本部第１開発部アカウントサービスグループ会員バックエンドチームの中島です。
私たちのチームでは、AWS Database Migration Service (DMS) を用いてMySQLのデータ移行を実施してきました。利用するにあたり注意すべきポイントがあるため、Tipsとして共有します。
AWS Database Migration Service とは
AWS Database Migration Service (DMS) は、データベースの移行を支援するAWSのフルマネージドクラウドサービスです。 同種データベース間だけでなく、異種データベース間の移行もサポートします。
公式サイト：https://aws.amazon.com/jp/dms/
DMSの仕組み
DMSは主に以下の要素で構成されます。
- Replication Instance (データレプリケーションを実行するインスタンス)
- Replication Task (データレプリケーションの実行単位)
- Source Endpoint (ソースデータベースへの接続定義)
- Target Endpoint (ターゲットデータベースへの接続定義)
DMS移行タスク
AWS DMSでは３種類の移行タスクを設定できます。
| 方法 | 説明 |
|---|---|
| フルロード | ソースとなるデータベースからターゲットのデータベースに対してデータの移行を実施 |
| 継続的レプリケーション（CDC）のみ | ソースとなるデータベースからターゲットのデータベースに対してレプリケーションを実施 |
| フルロード+継続的レプリケーション（CDC） | フルロードの実施後、レプリケーションを実施 |
Tips集
アカウントサービスグループではMySQLを利用しており、DB移設やAuroraのメジャーバージョンのアップグレードでDMSを利用してきました。
DB移設については別の記事で解説しているのでこちらを御覧ください。 （DMM会員基盤 オンプレミスMySQLからAmazon Aurora MySQLへの移行方法とハマった点）
MySQLで利用した際に詰まったポイントや気をつけておいたほうが良いポイントを紹介します。
エンドポイント設定
エンドポイントの設定時に追加の接続情報を設定できる項目が存在します。 DMSの移行タスク関連のチューニング設定や接続時に流すスクリプトの設定が可能です。
ソースエンドポイントとターゲットエンドポイントで設定可能な項目が変わるため、詳しくはドキュメントで確認をお願いします。 DMSの移行タスクでの設定ではなく、エンドポイントの設定もあるため一度目を通しておくことをおすすめします！
参考）
- Using a MySQL-compatible database as a source for AWS DMS
- Using a MySQL-compatible database as a target for AWS Database Migration Service
ターゲットテーブル作成モードで作成される型について
データの移行開始前に、ターゲットデータベースに対してテーブルを自動で生成する機能が存在します。 事前に準備しなくてもデータの移行が開始できる反面、デフォルトの定義で作成されてしまう恐れがあります。
そのため、データ型の桁数や精度を指定している場合は、DMSの自動テーブル作成機能を利用せず、事前にターゲットデータベースにテーブルを作成する必要があります。
参考）
データ検証機能
DMSにはデータ検証機能があり、データがソースデータベースからターゲットデータベースへ正確に移行されたことを確認できます。
データ検証する際に注意すべきポイントを紹介します。
プライマリキーの型
検証対象のテーブルには、プライマリキーまたは一意のインデックスが必要です。 また、プライマリキーについて以下の制約が適用されます。
- プライマリキー列の型を CLOB、BLOB、または BYTE に設定することはできません。
- 型が VARCHAR または CHAR であるプライマリキー列の場合、長さは 1024 未満にする必要があります。データ型の長さを指定する必要があります。無制限のデータ型をデータ検証のプライマリキーとして使用することはできません。
ここで出てきている「CLOB」「BLOB」「BYTE」はDMSの組み込みデータ型で以下になります。
| AWS DMSデータ型 | 説明 |
|---|---|
| CLOB | 文字ラージ オブジェクト |
| BLOB | バイナリラージオブジェクト |
| BYTE | バイナリデータ値 |
引用：AWS Database Migration Service のデータ型
以上の型や文字数の場合、データ検証機能を利用できません。 この場合、各DBに対してデータダンプを取得し差分を確認するなど手動で検証し、データが正しく移設されたことを確認する必要があります。
データ検証に伴う負荷
データ検証では、ソースデータベースとターゲットデータベースに対して追加のクエリが生成されます。 追加のクエリが発行されるため、それを処理するためのリソースが確保されていることを確認する必要があります。
ケースによっては、ソースデータベースに本番ワークロードで利用されているDBを採用していることも考えられます。 その場合は負荷試験等であらかじめ問題ないか確認することをおすすめします。
Amazon Aurora MySQLをソースとする場合のCDC機能利用について
DMSでCDC (継続的データキャプチャ) を行う場合、ソースエンドポイントに設定するインスタンスにはバイナリログを有効にしておく必要があります。 Amazon Aurora MySQLでは、バイナリログはプライマリ DB インスタンスのみ発行されるため、必ずプライマリDBインスタンスをソースとして指定する必要があります。
プライマリDBインスタンスの負荷が高いワークロードの場合は、負荷試験を事前に行い本番ワークロードに影響が出ないような設定をする必要があります。
フルロードのみを実施する場合はリーダーインスタンスを利用できます。
参考）
- Using a MySQL-compatible database as a source for AWS DMS
- Aurora MySQL バイナリログの設定
- Aurora MySQL をソースとして AWS DMS を使用するときに受け取ったバイナリログ記録エラーをトラブルシューティングするにはどうすればよいですか?
最後に
ここまでAWS DMSやMySQLで利用する際のTipsを紹介してきました。 今回紹介した情報の一部は、MySQL以外のデータベース環境でも応用可能です。
今回記載した情報に加え、ベストプラクティスの確認もおすすめします。 AWS Database Migration Service のベストプラクティス
あくまでも記載時点での情報であるため、最新情報はAWS公式ドキュメントで確認をお願いします。
プラットフォーム開発本部では、一緒に働く仲間を募集しています。 ご興味のある方はこちらへ！ dmm-corp.com
