AWSのデータ移行：DMS、レプリケーション、バックアップツールを使った最適なクラウド移行手法

オンプレ環境のサーバ老朽化やDX、クラウドのマネージドサービス利用による運用コスト削減などの様々な理由でサービスの移行を実施する事があるかと思います。

ドリコムでも過去にオンプレ環境からパブリッククラウドへの移行や国内クラウドからパブリッククラウドへの移行を行ってきました。サービスの移行では環境の構築など含め様々な作業が発生しますが、最も重要な部分はデータ移行になるかと思います。

データ移行にも様々な手法があり、今回は以下の内容について紹介出来ればと思います。

AWS Database Migration Service
レプリケーション
mysqldump、Xtrabackup等のバックアップ＆リカバリツール

執筆者

AWS Database Migration Service

AWS Database Migration Service（AWS DMS）は、データベースをAWSに移行するためのサービスです。

特徴は以下になります。

同種類のデータベースだけでなく、異なるデータベースへのデータ移行も対応
様々な環境上のデータベースに対応（オンプレミス環境、他クラウド環境も可）
テーブルマッピングで移行対象などを細かく設定
AWS Key Management Service（KMS）とAWS Secure Socket Layers（SSL）を使った暗号化により高度なセキュリティ設定が可能
スケーラブルで高可用性もあり自動フェイルオーバーやデータのレプリケーションなど、信頼性が高い
利用した時間による課金体系のため検証や移行までのコストを最小限に抑える事が可能

DMSではソースおよびターゲットのエンドポイント、レプリケーション用のインスタンス、

データ移行のタスクを作成して処理を実行する形になります。

エンドポイント
データベースの接続情報の定義で移行元（ソース）、移行先（ターゲット）それぞれ定義される
レプリケーションインスタンス
移行タスクに定義された処理に従いデータベース移行タスクが実行されるインスタンス
データ移行タスク
ソースとターゲット間でのデータ移行を定義したもの
・フルロード：ソースのデータをターゲットに移行
・継続的なレプリケーション（CDC）：フルロードは実施せずソースに変更があった場合、変更データをターゲットに反映させる
・フルロード+継続的なレプリケーション（CDC）：フルロード完了後、ソースに変更があったデータをターゲットに反映させる

DMSを利用した移行方法の構成としてはこれらのようになり、移行元の環境からAWS DMSにインターネット経由で接続しデータ転送を行う形になります。

また、AWS DMSではマッピングを利用し3台で構成されている移行元のデータベースを1台のRDSに集約することも可能で、移行時にコスト最適化を実施することもできます。

ただ、DMSはテーブル、PK、データ以外は移行できない制約や、サポートされていないデータ型などの制約があるため、細かな検証が必要となります。

レプリケーション

こちらはAWS DMSを経由せずに移行元環境のデータベースと移行先のAWSのAuroraとを直接レプリケーションを構築、構成するかたちになります。構成は移行元環境から移行先のAuroraに対してレプリケーションを設定するのみになるので設定はシンプルなものになります。

暗号化通信等は自分たちで行う必要があるため、MySQL側のSSL設定やVPNによる接続設定などを行う必要があります。AWS DMSの制限も受けないためネットワーク接続に問題がなければ比較的スムーズに移行できるかと思います。

mysqldump、Xtrabackup等のバックアップ＆リカバリツール

mysqldump、Xtrabackupは移行元と移行先でレプリケーションなどの設定を行わずにバックアップファイルを利用して直接データを移行する形になります。

VPN接続などの事前の準備などはほぼなくテストも容易であるが、データベースのデータ容量が大きい場合はバックアップ、リストアともに時間が掛かってしまうため、メンテナンス時間がより多くかかってしまうことになります。メンテナンス当日の作業項目、手順が増えてしまう事もデメリットの一つになります。

ただ、データ容量が小さい場合は手軽に行えるため、検証期間の短縮や移行準備などを軽減するメリットもあります。バックアップファイルを利用する方法はRedisでも利用でき、RedisのbgsaveでバックアップしたデータをS3にアップロードしElastiCache起動時にクラスタへデータのインポートを行うことが出来ます。