そのため、AWSのRDSを利用することでデータベースの運用面で負担を軽くしたいと検討するケースがあります。しかし、データベースの移行は移行元（ソースデータベース）・移行先（ターゲットデータベース）に関わらず、複雑で大きな負担となるケースが多くあります。
そこでAWSでは、そのデータベースの移行を円滑に行うためのツールが用意されています。それが、AWS Database Migration Service（DMS）です。
AWS Database Migration Service（DMS)
AWSへのデータベース移行を短期間で円滑に行う移行支援サービスです。オンプレミス→AWS、AWS→オンプレミス、どちらにも対応しています。同種（同じエンジンの2つのデータベース間）そして異種（違うエンジンを持つ2つのデータベース）の移行をサポートしています。
DMSのメリット
DMSは簡単な操作でデータベース移行を進めることができます。また、データベース移行時のダウンタイムを最小限にするために継続的にレプリケーションを行い、データベースが使える状態を保ちながら移行を進めることができます。
サポートをしているデータベースが多く、一般的によく利用されているデータベース全てに対応が可能です。
データの冗長性をレプリケーションによって確保している他、一時的に移行がストップしてしまった場合にも、自動的に再起動され移行が継続されます。そしてサービス利用が低コストであることも大きなメリットのひとつです。
DMSで出来ること
DMSを利用して出来ることは以下の通りになっています。
・同種間のデータベース移行
・異種間のデータベース移行（SCTも同時に利用）
・開発・テスト用ににデータベース移行
・データベースの統合
・継続的なレプリケーション
異種間のデータベース移行は大きく2つのステップを通して移行をします。
1.SCTで移行先（ターゲットデータベース）に適用出来るようにスキーマとコードを変換
2.DMSで移行
データベースの統合では、いくつかのデータベースを一つのデータベースにまとめることができます。ソースデータベースは、同種・異種関係なく利用することができます。
その他には、暗号化されたデータを移行することもでき、ターゲット（移行先）でも暗号化を設定しておくことでセキュリティ面は確保されます。
DMSの基本的な仕組み
DMSは、4つの要素で構成されます。
・Source Endpoint（ソース エンドポイント）
・Replication Instance （レプリケーション インスタンス）
・Replication Task（レプリケーション タスク）
・Target Endpoint（ターゲット エンドポイント）
上から順にデータが通過していくイメージになります。レプリケーションを行いながら、データを移行先へと送ります。
DMSで移行する手順
標準的なデータベースの移行の手順は以下のようになります。
・ターゲットデータベースの作成
・データベーススキーマの移行
・データレプリケーションプロセスの設定
・最大負荷でプロセスを開始して、その後変更データをキャプチャし適用する。
・ターゲットデータベースの内容がソースデータベースに追いついたら、実稼働環境を新し いデータベースに切り替えて終了する。
データベースの移行状況は、AWSのマネジメントコンソールで確認することができます。
AWS Schema Conversion Tool (AWS SCT)
異種間のデータベース移行の時に、移行元（ソースデータベース）のスキーマとコードを移行先（ターゲットデータベース）のスキーマとコードへ変換するサービスです。STCは連邦情報処理標準 (FIPS) などの業界標準をサポートしています。コンプライアンス面にも配慮がされています。
STCを使用するには、ソースデータマシン上にインストールが必要です。また、STCを利用するとソースデータベースからターゲットデータベースに移行が出来るオブジェクトとできないオブジェクトをレポートとして出力をしてくれます。ソースデータベースの中でも移行をする対象を決めやすくなります。
データ移行を円滑に行うポイント
データベースの移行は、データの量が多くなればなるほど複雑になります。事前に出来る準備をしっかりしておくことで円滑に行うことが出来るようになります。
情報を洗い出す
・情報セキュリティポリシーの確認
・移行元データベースの調査
・移行先データベースの選定
・移行先データベースのRDB（リレーショナルデータベース）エンジンの選定
・移行の方法（段階移行など）
が重要なポイントとされています。
検証環境を整える
実際にデータベース移行の検証を行うことで一つ一つの工程を確認していきましょう。
・必要な初期設定
・実際に移行にかかる時間
・移行したいデータがDMSのみで可能かどうか
・エラーの可能性がありそうなポイントや転送時に注意したいこと
・レプリケーションインスタンスとストレージサイズは適切か？
・ネットワーク帯域は十分か？
他にも、検証をしておきたいポイントがあると思いますがあげたポイントの中でも本番環境でのネットワークへの負荷などにも気をつけておくと良いです。移行がスムーズにいかなかったことから、接続方法を変更することで対処したケースがあります。移行の時に課題に上がるポイントでもある、ダウンタイムについても注意をしておきましょう。
DMS/STCの制約条件や使い方を理解する。
DMSでできる範囲をしっかりと把握しておくことで、実際の環境ではできないと判断されることを避けることができます。それと同時に、使い方などもきちんと確認しておきましょう。さらにAWSドキュメントの中にあるドキュメントや実際の手順に関するチュートリアルなども参考にしておくことで、問題なくデータ移行を進めることができます。
データ移行が正しく行われたかどうかを確認する方法を決めておく。
正常な移行が行われているかどうかを判断することが大切になります。これは、いくつかの方法が考えられますが、最適な確認方法は状況による判断となります。本番環境での移行前に確認する内容をしっかりときめておくことがポイントになります。
・レコード件数での確認
・ログの確認（異常がないかどうか）
・ランダムで選んだレコードの整合性で判断をする
などが考えられます。
AWSへの移行を含めてDMSは13万件の実績があります。操作手順は簡単で利用がしやすいサービスだと思います。データを損傷することがなく移行を済ませることができる安全性や、ダウンタイムが最小限で済むことなどメリットとなることが多くあります。
DMSを円滑に利用するためには、ソースデータベースのデータを調査しておくことが大切です。移行をしたいデータを明確にしていく作業の中で、SCTを利用して移行できないデータを洗い出していくことでデータを選択していくことが不可欠です。
本番環境に近い環境での検証を通して、検証していく内容を洗い出していくこともトラブルを避けるためには大切なポイントとなります。検証環境では、気にしていなかったけれど本番環境で思わぬトラブルが怒らないように気をつけなければいけません。
データベース移行で課題になるダウンタイムについても、DMSではレプリケーションを行うことで損失や中断などにも対応できるようになっていますが、環境やデータの状況では、ゼロではないかもしれません。事前に許容範囲を設定するなどの対応が必要になるケースもあります。
また、リアルタイムでのオンプレミス環境との連携が必要となるケースもあります。DMSの利用ケースは様々ありますが、オンプレミス環境からのデータベース移行の場合は外部のコンサルタントに依頼をしてみるのも良いかもしれません。
