はじめてAWS DMSを検討する際に読んでいただきたいこと

こんにちは。
プロフェッショナルサービス本部の小田です。本資料ははじめてAWS Database Migration Service (AWS DMS)をお使いいただく方に基本的なポイントを理解していただくための記事になります。

はじめに

データベース（DB）を移行する、もしくはDB間でデータを連携する際に、AWS DMSを検討いただくことが増えてきました。AWS DMSはマネージドサービスの良さをもつ、柔軟なデータ連携が可能なサービスですが、気をつけるべき点も存在します。本記事では、ファイル移行とデータ移行を比較することでDBのデータ移行のイメージを持っていただき、その後、注意点やTipsを紹介します。

ファイルの移行とDBの移行

ファイルの移行とDBの移行は、データを移行するという意味では似ていますが、考慮すべき点が異なります。DBMSが異なれば、データの型が異なりますし、DBMSのバージョンが異なれば、内部のフォーマットも異なるでしょう。そのため、DBの移行や連携は、ファイルの移行よりもより複雑で考慮すべきことが多いタスクと言えます。表で比較すると次のようになります。

このようにDBの移行は考慮すべきことや行うべきことが多いと言えます。

AWS DMSの特徴と強み

データ連携製品は、物理レプリケーション方式と論理（ロジカル）レプリケーション方式の２つに分けられます。一般的な仕組みはこのようになります。物理方式は、連携元（ソース）のトランザクションログを連携先（ターゲット）に転送し、それをそのまま連携先のDBへ適用する方式です。

ロジカル方式は、トランザクションログから独立性の高いSQL等を生成し、ターゲットのDBに実行する方式です。

物理方式は一般的に同一DBMS製品の同一バージョンにしか使用できませんが、それはこの仕組みが理由です。DBMSやバージョンが変われば、トランザクションログの仕様も変わってしまいます。
参考：後述するBlack Beltの P19とP20にも物理方式と論理方式の紹介があります。

AWS DMSはロジカル方式を採用したデータ変換のサービスです。ロジカル方式の強みは、処理方式から分かるように、DBMSからの独立性です。１つづつ説明します。

強み　DBMSの実装の影響を受けにくい

DBMSの実装とは異なる、独自の連携（SQL等）を使用するため、ソースからの読み取りと、ターゲットへの適用部分を変えるだけで、異なるDBMSにも対応できます。これが柔軟な移行を実現している理由の１つです。

強み　DBMSのバージョンをまたがって処理できる

物理方式では、トランザクションログの制約があるため、同一バージョン間でのみデータ連携が行えます。そのため、一般的にはバージョンアップにおいて利用できないという制限があります。ロジカル方式は対応しているバージョンであれば変換が可能であるため、バージョンアップにおいても使用できるという強みになります。

強み　テーブルごとに柔軟な制御を実装できる

物理方式はDB全体をかたまりとしてトランザクションログを適用します。そのような仕組みのため、柔軟にデータ移行対象を選択することは困難です。ロジカル方式は変更を抽出するため、どのテーブルには変更を適用するといった制御が可能です。AWS DMSもテーブルの選択やデータの加工などを行うことができます。また、１つのテーブルを複数のテーブルにデータ移行するような複数テーブルにまたがる変換も行えます。

注意点

以下の注意点は、AWS DMSの固有というわけではなく、ロジカル方式なデータ連携製品であれば大なり小なり持ち合わせているものです。ロジカル方式がもつ強みの裏返しです。

注意点　制限事項

変換作業を行うことで物理実装からの独立性が高くなっていますが、ロジカル方式では仕組み上対応が難しい部分もあり、対応していない部分は制限事項になります。ソースとしての制限、ターゲットとしての制限の双方がありますので、該当していないことを確認ください。制限事項に該当しないことをプロジェクトの初期に確認することは一般的に重要と言えます。
たとえば、PostgreSQLからMySQLに移行する場合には、ソースとしてのPostgreSQLの制限、ターゲットとしてのMySQLの制限を確認することになります。

参照：
ソースとしての制限事項を確認するには、https://docs.thinkwithwp.com/ja_jp/dms/latest/userguide/CHAP_Source.html から対象DBMSのページに移動し、そのページの中の「制限」を探してください。
ターゲットとしての制限事項は、を確認するには、https://docs.thinkwithwp.com/ja_jp/dms/latest/userguide/CHAP_Target.html から対象DBMSのページに移動し、そのページの中の「制限」を探してください。

注意点　非同期

物理方式の場合、同期モード（ソースDBでcommitを行うと、ターゲットDBにおけるトランザクションも保証される）が選べるものがありますが、ロジカル方式であるAWS DMSは非同期モード（ソースDBとターゲットDBの書き込みが異なる）となります。同期が必要な要件の場合にはAWS DMSは使用できませんが、ターゲットDBへの書き込みを待つことによるソースDB処理遅延を避けられるメリットがあります。

なお、ソースDBとターゲットDBの間で、データ変更適用の差が生まれます。これをラグと呼びますが、ラグの時間が大きくなりすぎないように注意してください。

注意点　性能

物理実装の影響を受けないように論理的に処理しています。その分、仕組みも増えることになります。物理方式に比べて性能がでないことがあるため、性能が気になる場合にはPoCを行うようにしましょう。性能が十分かは前述のラグを確認することで判断できます。

また、これは物理方式でも同様ですが、アプリケーションからのSQL処理をDBMSが処理できているからと言って、AWS DMSの連携も同じペースで処理できる（つまりラグが短い）とはかぎりません。環境（ネットワークや多重度、キャッシュやデータの状態など）も異なるからです。多くの時間帯は処理できていても、バッチ処理や処理が集中する時間には一時的に追いつかなくなることが多くあります。常にラグが短時間でなければならない場合、要件を満たせないことがあります。そのため、本番相当のデータを用意し、バッチや多重度を上げた処理をDBMSにかけつつ、AWS DMSを用いた連携が要件の時間内で行われるかを確認するようにしましょう。

注意点　文字化けや数値のまるめ

文字コードやデータ型が異なることで文字化けや数値のまるめが発生する可能性があります。テストで確認するようにしてください。前述の制限にも記載があります。

注意点　AWS DMSのバージョンアップ

AWS DMSもBug修正や機能追加、対応DBMS追加などのためにバージョンアップします。DB移行時のみの利用であれば不要ですが、常時利用する場合にはDBMSだけではなく、AWS DMSのバージョンアップとテストも計画に入れるようにしてください。
AWS DMSのバージョンアップはマネジメントコンソールから実行できます。

Tips

利用にあたってTipsです。これらの多くもAWS DMS固有というわけではなく、ロジカル方式のデータ連携ツールには共通的に当てはまるものです。

AWS DMSはデータ連携を目的としていて、型の移行やオブジェクトの移行は一部のみに限定されます。AWS DMSを実行する前にAWS Schema Conversion Tool (AWS SCT)を用いることで、それらの多くを補完できます。AWS DMSの検討の際にはAWS SCTも併せて検討してみてください。

ソース DB エンジンがターゲット DB エンジンと同じ場合、AWS DMS を試す前に、まずそのデータベースエンジンが持つネイティブ移行ツール（もしくはデータ連携機能）を検討してみましょう。制限事項が少ない等のメリットを持つツールもあります。

データが正しく移行されたか確認する必要がある場合、AWS DMSが持つ「データ検証」機能を検討ください。ソースとターゲットを比較し、データベースの内容が正しいかを検証できます。

インフラ担当者だけではAWS DMSの検討が難しいことがあります。データはアプリケーションと切っても切れない関係だからです。どのテーブルを移行対象にするのか、制限事項のどれに該当するのか、検討チームにアプリケーション担当者も入れるようにするとスムーズに進むことが多くあります。

まとめ

DMSの概要を理解するには、ロジカルなデータ連携製品の特徴を理解することが有効であることを説明しました。強みを活かし、注意点をおさえてデータ移行を検討していただければ幸いです。

参考：
AWS DMSについて、さらに詳しく知りたい方は、AWS Database Migration ServiceのBlack Beltを参照ください。