AWS DMSを使って再構築したDBへデータ移行させた話

はじめに

こんにちは。システム事業部のTAKです。
記事を書くのは1年7ヶ月ぶりで、今回で3回目となりました。
入社直後に立ち上げに関わった社内システム（以下、システムA）も5年目に突入しようとしています。
運用年数を重ねると、構成が混沌としてくることがあります。
突貫対応による不要な枝葉や緊急対応として迂回したネットワーク構成、新しいシステムや要件に対応するために別VPCに切り出されたリードレプリカなど……

そう、混沌としてきたのです！

そうした経緯があり、今後のシステム間連携などを考えるうえで、システムAが持つRDSのVPCやサブネットなどのネットワーク構成を再構築することとなりました。
稼働を継続しながら別途構築を進める新RDS環境に対して、データを同期させる方法としてAWS DMSを利用しました。 DMSを利用して良かった点や注意する点などをお伝えできればと思います。

AWS Database Migration Serviceとは

AWS Database Migration Service (DMS) は、データベースの移行を簡単に行うためのマネージドサービスです。
オンプレミスやクラウドのデータベースをAWSに移行し、ダウンタイムを最小限に抑えることができます。
リアルタイムでのデータ複製も可能なので、運用停止できないようなサービスのDB移行に最適です。 aws.amazon.com

移行の背景

前述したように、5年以上前に構築されたネットワーク構成のため、現在のシステムAを扱ううえで技術的負債が溜まっていました。
具体的にはRDSの属するVPCのCIDRが社内ルールに則っていなかったり、リードレプリカが別VPC上に構築されていたりしました。
その結果、MySQLのバージョンアップやメンテナンス等でB/Gデプロイが使用できなかったり*1、IP管理や設定に支障がでる*2など負の要因がでてきていました。
また、基本的に24時間稼働させる必要があるRDSであったため、今回のデータ移行を含めメンテナンスを行う際は極力停止しない方針で進める必要がありました。

RDSを停止させずに移行したかったのでDMSを採用しましたが、システム停止時間を取れるのであればdumpでのデータ移行が手軽で、コストもあまりかからないと思います。

環境構成

移行前

移行後

DB再構築にあたって、新たに環境を用意しました。
図の背景色が青色が移行前のVPC（以下、旧VPC）、緑色が再構築用のVPC（以下、新VPC）です。
DMSによって継続的なデータ同期が有効になっている状態で、EC2（Webサーバー）のDB参照先を移行後のRDSに切り替えることで、システムを停止せずに切り替えを実施しました。

移行の流れ

移行手順

新VPCを新たに作成
新VPCにRDSインスタンス（以下、移行先RDS）を作成
移行先RDSに見直しを行ったセキュリティグループを適用
DMSで、現行稼働中のRDS（以下、移行元RDS）から移行先RDSへの移行タスクを作成しタスクを実行
移行元RDSを参照していたサーバーのDB接続先を、移行先RDSのエンドポイントに変更
システムが正常稼働していることを確認後、旧VPCおよび移行元RDSを削除

移行先にテーブルを用意する

DMSはデータ移行を行うサービスであるため、移行先のDBやテーブルは別途手動で作成する必要があります。
DMS実行時にテーブル等がなければ自動で作成してくれますが、データから推測して作成されるため、移行元と完全一致とならないので注意が必要です（詳しくは後述します）。

DMS利用におけるシステム構成

DMS環境は以下の4つを用意する必要があります。

機能	説明
ソースエンドポイント	移行元DBへの接続情報
ターゲットエンドポイント	移行先DBへの接続情報
レプリケーションインスタンス	データベース移行処理を実行する環境（EC2/サーバレス）
データベース移行タスク	どのレプリケーションインスタンスで、どのソースエンドポイントからどのターゲットエンドポイントに対して、どのスキーマからどんな条件でデータ移行を行うか等、DMSのメイン処理を扱う

DMS環境のVPCはネットワーク構成上扱いやすいよう新VPC内に作成していますが、旧VPCや別のVPCとしても問題ありません。

DMSを利用して

良かった点

データ移行先DBについても移行元DBと同じく書き込み可能であるため、Webサーバー側のDB接続先の設定を切り替えるだけでDBの移行が完了した
- リードレプリカを昇格させて切り替える方法でも似たような動作となるが、昇格作業後からWebサーバー側設定の切り替えの間に同期が停止してしまうため、短時間ではあるがシステム停止が発生してしまう
（今回はAWSのDBを使用したが）ソースエンドポイントはAWS以外のDBや、MySQL⇨PostgreSQLなど異なるデータベースを指定することも可能

注意すべき点

レプリケーションインスタンスの稼働コストや（リージョンやAZが異なる場合は）データ転送コストがかかる
- DMSでの移行が終わり次第、速やかにレプリケーションインスタンスを停止する必要がある
MySQLの場合、移行元DBのバイナリログ設定を「ROW」にしておく必要がある*3
移行先のテーブルや列が無い場合、DMSが移行データから推測して作成してしまう
- AUTO_INCREMENTの設定が欠落してしまったり、符号なし数値型（unsigned integer）だったものが符号付き数値型（signed integer）で作成される場合がある
- データベース移行タスクの設定で「ターゲットテーブル準備モード」がデフォルトのまま（ターゲット上のテーブルを削除）だと常に発生するため、データのみ削除する「切り捨て」とするほうがよい
- DMS同期中に移行元DBのテーブル列追加や変更を行った場合は、移行先DBのテーブルを再構築しないと推測で列を追加されてしまう（それらしく作られるため、移行後すぐには気付きづらい）