【データベース移行】AWS Database Migration Service（AWS DMS）入門

本記事は ãƒžã‚¤ã‚°ãƒ¬ãƒ¼ã‚·ãƒ§ãƒ³ã‚¦ã‚£ãƒ¼ã‚¯ 4日目の記事です。
💻🖥 3日目 â–¶â–¶ æœ¬è¨˜äº‹ â–¶â–¶ 5日目 ðŸ–¥ðŸ’»

はじめに

こんにちは。インフラエンジニアの五十嵐です。

マイグレーションウィーク4日目の今回は、AWSが提供するデータベース移行サービス「AWS Database Migration Service」の概要の説明と、簡単な移行検証を行いたいと思います。

データベースの移行を検討されている方、本サービスの概要をざっくり理解したいという方の参考情報になれば幸いです。

AWS Database Migration Serviceとは

AWS Database Migration Service（以降AWS DMS）は、データベースの移行を支援するAWSサービスです。

AWS DMSの特徴

特徴は以下の通りです。

• 異なるデータベースエンジン間でのデータ移行に対応（RDBMS、NoSQL、データウェアハウスなど）
• 様々な環境上のデータベースに対応（オンプレミス環境、他クラウド環境も可）
• データベースを稼働させた状態でのデータ移行に対応し、移行時のダウンタイムを最小限に抑えられる
• 既存データの移行に加え、移行中に発生した変更も継続的に同期することが可能

AWS DMSを構成するコンポーネント

主に3つのコンポーネントで構成されています。

参考：What is AWS Database Migration Service? - AWS Database Migration Service

1. エンドポイント

• 移行元（ソース）、移行先（ターゲット）となるデータベースの接続情報を定義したもの

2. レプリケーションインスタンス

• 移行タスクに定義された処理に従いデータ移行を行うインスタンス
  • 実態はEC2インスタンスでT系・C系・R系インスタンスまたはサーバレスから選択可能
  • マルチAZによる冗長構成も選択可能

3. データ移行タスク

• どのような条件でデータ移行を行うかを定義したもの
• 以下の移行タイプから選択することができ、特定のテーブルのみを移行対象とするような条件指定も可能
  • 移行元の既存データを移行（フルロード）
  • 移行元で発生した更新データのみを継続的に移行（CDC）
  • 上記どちらも（フルロード＋CDC）

AWS DMSのデータ移行方式

AWS DMSは「論理レプリケーション」と呼ばれる方式でデータ移行を行います。これは移行元データベースで発生した変更内容（トランザクションログ）を、移行先データベースに合わせたSQLに変換して連携する方法です。

引用元：はじめてAWS DMSを検討する際に読んでいただきたいこと | Amazon Web Services ブログ

このような「論理レプリケーション」方式であることから、AWS DMSは様々なデータベースエンジンでのデータ移行に対応しています。
ただし、AWS DMSでも移行対象外となるデータもあります。例えば、セカンダリインデックスやストアドプロシージャなど、一部のデータベースオブジェクトは自動的に移行されない場合があるため、事前検証は必ず行うようにしましょう。
対応している移行対象については、AWS re:Postに詳細が記載されています。
repost.aws

AWS DMSでデータ移行をやってみる

では実際にデータベースのデータ移行を検証してみます。
※今回は基本的な機能と使用方法の解説をメインとしているため、一部の手順は詳細に記載していません。

検証内容

EC2インスタンス上で稼働するMySQLデータベースからAurora MySQLへ、AWS DMSでデータ移行を行います。
またデータ移行条件として、特定のテーブルのみ移行を行う設定とし、想定通りのデータ移行ができているかも確認します。
以下が全体構成です。

1. データベース環境の準備

データ移行の準備作業として、移行元（ソース）となるEC2インスタンス、移行先（ターゲット）となるAuroraインスタンスを作成しておきます。以下の赤枠箇所です。

1.1 移行元（ソース）環境の作成

• EC2インスタンスの作成
• MySQLのインストールとセットアップ（DMS用ユーザの作成とアクセス許可 等）
• サンプルデータをMySQLへインポート（今回はMySQL公式のサンプルデータベース「world database」を利用します）
  • データベース「world」に作成されていたテーブルは以下の通りです
  • 今回の検証では「cityテーブル、countryテーブル」のみを移行する条件で設定します

mysql> show tables;
+-----------------+
| Tables_in_world |
+-----------------+
| city            | #←移行対象
| country         | #←移行対象
| countrylanguage |
+-----------------+
3 rows in set (0.00 sec)

mysql>

1.2 移行先（ターゲット）環境の作成

• Auroraインスタンスの作成
  • 作成のみとなります

1.3 セキュリティグループの設定

• DMSのレプリケーションインスタンスから各データベースへ、3306ポートで接続するため、EC2インスタンスとAuroraインスタンスのセキュリティグループに許可設定を追加しておきます
  • 今回は、後ほど作成するDMSのレプリケーションインスタンスに設定するセキュリティグループからの接続を許可します

2. AWS DMSの準備

先ほど説明した各コンポーネントを作成していきます。以下の赤枠箇所です。

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

事前作業として、レプリケーションインスタンスを作成するサブネットグループを作成します。

• 先ほど作成したデータベース環境と同じVPCのプライベートサブネット上に構築します

設定項目	設定値
VPC	EC2インスタンスとAuroraインスタンスと同じVPC
サブネット	EC2インスタンスとAuroraインスタンスと同じサブネット

続いてレプリケーションインスタンスを作成します。

• 今回は検証なので最小構成とします

設定項目	設定値
インスタンスクラス	dms.t3.micro
マルチAZオプション	シングル AZ
レプリケーションサブネットグループ	先ほど作成したサブネットグループ
VPCセキュリティグループ	1.3で許可したセキュリティグループ
パブリックアクセス可能	選択しない

作成できました。

2.2 エンドポイントの作成と疎通テスト

以下の内容で各エンドポイントを作成します。

設定項目	ソースエンドポイント	ターゲットエンドポイント
エンドポイントタイプ	ソースエンドポイント	ターゲットエンドポイント
RDSインスタンスの選択	-	チェックありで作成済みのAuroraインスタンスを選択
データベースへのアクセス	手動	手動
サーバ名	EC2インスタンスのローカルIP	Auroraのクラスターエンドポイント
ポート	3306	3306
ユーザ・パスワード	手動で入力	手動で入力

作成できました。

• エンドポイントを作成すると、先ほど作成したレプリケーションインスタンスから接続テストが実施できるため、正常に接続できることを確認します
  • ソースエンドポイント
  • ターゲットエンドポイント

2.3 データ移行タスクの作成

以下の内容で移行タスクを作成します。

• 後ほど指定する該当のテーブルの既存データのみを移行
• データ移行後、ソースとターゲットのデータを確認するため「データ検証」を有効
  • タスク設定

設定項目	設定値
レプリケーションインスタンス	2.2で作成したものを指定
エンドポイント	1.1、1.2で作成したものを指定
移行タイプ	既存のデータを移行する（フルロード）
データ検証	検証（データ移行あり）

• cityテーブル、countryテーブルの既存データのみを移行対象とします
  • テーブルマッピング

ルール	ソース名	ソーステーブル名	アクション
選択ルール	world	city	含む（include）
選択ルール	world	country	含む（include）

• 移行タスクは手動で実行します
  • 移行タスクのスタートアップ設定

設定項目	設定値
移行タスクを開始	後で手動で行う

作成できました。

3. AWS DMSでデータ移行

必要な準備作業は完了したのでデータ移行を行います。

• アクションより「再起動/再開」でタスクを起動

• 進行状況が100％になり、ステータスが完了となりました！！

• フルロード実施後にデータ検証が行われ、テーブル統計のタブから検証結果が確認できます
  • 失敗が0件となっていましたので問題なさそうです

4. 移行データの確認

次はデータ移行先として指定したAurora MySQLのデータベースやテーブルを確認し、移行ができているか確認します。
また、DMSの移行対象外であるセカンダリインデックスについても確認します。

データベース

• 移行対象のデータベースである「world」が作成されており問題なさそうです

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| awsdms_control     | #←新たに作成されている
| information_schema |
| mysql              |
| performance_schema |
| sys                |
| world              | #←新たに作成されている
+--------------------+
6 rows in set (0.01 sec)

mysql>

• 「awsdms_control」も追加されていますが、こちらはデータ検証でデータ差分が発生していた際に、トラブルシューティングに利用できる詳細な情報を記録するためのデータベースとなります（中身を確認したところ0件でした）

テーブル

• 移行対象のテーブルである「cityテーブル、countryテーブル」のみが作成されており問題なさそうです

mysql> show tables;
+-----------------+
| Tables_in_world |
+-----------------+
| city            | #←新たに作成されている
| country         | #←新たに作成されている
+-----------------+
2 rows in set (0.00 sec)

mysql>

• レコード数も移行元と同じ件数となっています

mysql> select count(*) from city;
+----------+
| count(*) |
+----------+
|     4079 | #←移行元と同じ件数
+----------+
1 row in set (0.00 sec)

mysql>
mysql> select count(*) from country;
+----------+
| count(*) |
+----------+
|      239 | #←移行元と同じ件数
+----------+
1 row in set (0.00 sec)

mysql>

インデックス

• プライマリキーは移行できていますが、先ほど記載した通りセカンダリインデックスについてはDMSの移行対象外となるため、データが存在していません
• カーディナリティについても値が「0」となっており、移行元と差分がみられました
  • 移行元（ソース）環境

mysql> show index from city\G
*************************** 1. row ***************************
        Table: city
   Non_unique: 0
     Key_name: PRIMARY #←プライマリキー
 Seq_in_index: 1
  Column_name: ID
    Collation: A
  Cardinality: 4046 #←4046となっている
     Sub_part: NULL
       Packed: NULL
         Null:
   Index_type: BTREE
      Comment:
Index_comment:
      Visible: YES
   Expression: NULL
*************************** 2. row *************************** #←セカンダリインデックスあり
        Table: city
   Non_unique: 1
     Key_name: CountryCode 
 Seq_in_index: 1
  Column_name: CountryCode
    Collation: A
  Cardinality: 232 
     Sub_part: NULL
       Packed: NULL
         Null:
   Index_type: BTREE
      Comment:
Index_comment:
      Visible: YES
   Expression: NULL
2 rows in set (0.00 sec)

mysql>

• • 移行先（ターゲット）環境

mysql> show index from city\G
*************************** 1. row ***************************
        Table: city
   Non_unique: 0
     Key_name: PRIMARY #←プライマリキーは移行されている
 Seq_in_index: 1
  Column_name: ID
    Collation: A
  Cardinality: 0 #←0になっている
     Sub_part: NULL
       Packed: NULL
         Null:
   Index_type: BTREE
      Comment:
Index_comment:
      Visible: YES
   Expression: NULL
1 row in set (0.00 sec) #←セカンダリインデックスなし

mysql>

おわりに

AWS DMSの概要の説明と、簡単な移行検証を行いました。

AWS DMSは、様々なデータベース間でデータ移行が可能なため、多くの移行シナリオに柔軟に対応できるサービスです。
ただし、移行対象外となるデータや制限事項もあるため、事前に十分調査を行って移行計画考える必要がありそうです。

本サービスの利用を検討されている方は、以下のBlack Beltの資料やベストプラクティス集も参考になるかと思います。
是非チェックしてみて下さい。
aws.amazon.com
docs.aws.amazon.com
最後までお読みいただきありがとうございました！