トップ > AWS > 【移行編】Database Migration Serviceにチャレンジ！

【移行編】Database Migration Serviceにチャレンジ！

AWS DMS データベース
記事タイトルとURLをコピーする

こんにちは、技術４課の多田です。

最近、筋肉系Youtuberと言われている方々の動画を見ながら筋トレすることが趣味になり、会社にプロテインを持ち込むようになりました。
周りからは苦笑されますが、筋肥大が目下のテーマですね。

さて、前回から間があいてしまいましたが、今回はSQL ServerからAuroraに移行するためにDatabase Migration Service(以下、DMS)でのデータの「移行編」となります。
今回は検証時と本番データ移行時の経験を踏まえて記事を書いていきたいと思います。

なお、前回の記事はこちら！

データベースの移行の概要

今回の移行では大きく3点のことを行いました。

  1. Schema Conversion Tool(以下、SCT)によるスキーマの変換
  2. DMSを使ったテーブルのフルロード
  3. 継続的レプリケーションの実施

以下では特に1と2にフォーカスして、記事を書いていきます。

1. SCTによるスキーマの変換

DMSでレプリケーションを行うためには、ソースデータベースからターゲットデータベースで扱えるスキーマへ変換する必要があります。
その役割を担うのがSCTで、これはソースデータベースのマシン上にインストールする必要があります。
インストーラーおよびソースデータベースおよびターゲットデータベースに接続するためのドライバはこちらのドキュメントを参照ください。

また、特徴的なのはソースデータベースからターゲットデータベースに移行できる/できないデータベースのオブジェクトを以下のようなレポートとして出力してくれます。
お客様と移行検討する対象を決めるときに大変助かりました。

2. DMSを使ったテーブルのフルロード

いよいよ本番環境のテーブルのフルロード作業を行った時の内容に入ります。
DMSでAuroraにフルロードが完了するまでに様々な考慮点が出てきましたので、項目別でまとめていきます

(i) レプリケーションインスタンスとストレージサイズ

まず、レプリケーションインスタンスとストレージサイズについてです。
DMSのレプリケーションインスタンスとストレージサイズが適切かどうかは検証を行うことでおおよその目安となります。
検証後、私が携わった案件では本番データ移行時に以下のようなパラメータで定義を行いました検証後、私が携わった案件では本番データ移行時に以下のようなパラメータで定義を行いました

(a) レプリケーションインスタンスタイプ

検証時のパラメータよりも倍のパフォーマンスがでる「dms.c4.xlarge」を選択しました.c4.xlarge」を選択しました

(b) ストレージサイズ

ストレージサイズは、ターゲットデータベースにデータの書き込みを行う前の一時領域として利用されます。
そのため、本番データを移行する際には、以下を参考にして最低でも移行するテーブルの中でも最も大きいテーブルサイズ以上にしました。
http://aws.typepad.com/sajp/2016/08/aws-black-belt-online-seminar-dms.html

上記の考慮から250GBを確保しました。

結果的にフルロード及び継続的レプリケーションにおいてレプリケーションインスタンスやストレージのリソースが枯渇する状況はありませんでした。
なお、レプリケーションインスタンスとストレージサイズは移行中に変更ができます。
ただ、フルロードが完了していない場合、再度1からテーブルをロードすることになる点は注意が必要です。

(ii) データ型の違いを考慮する

データベースエンジンが変わるため考慮が必要です。
SQL ServerのDATETIME型でミリ秒以下で7桁のものがあったのですが、Auroraに移行した時データの桁数が9桁となりました。

原因としては、DMSでソースデータベースからターゲットからターゲットベースに移行した時、ソースデータベースのデータを一度DMSのデータ型(中間データ型)に変換している影響でした。
つまり、この変換においてSQL ServerのDATETIME型は、中間データ型の DATETIME(TIMESTAMP) に変換されます。
中間データ型の DATETIME(TIMESTAMP) は秒以下を最大9桁まで保持することが出来ます。
そして、中間データ型の DATETIME(TIMESTAMP)からAurora データ型に変換される際には、秒以下の桁数に応じて以下のように異なるデータ型に変換されます。

  • 秒以下の桁数が6桁以下 の場合は、DATETIME型
  • 秒以下の桁数が7桁以上の場合は、 VARCHAR(37)型

上記のような変換対応があるため、Auroraに移行した時桁数のズレが生じました。
この事象には、ソースデータベース側の桁数を6桁に変更して対応しています。

なお、各データベースエンジンで扱えるデータ型については以下のドキュメントを参照ください。
Microsoft SQL Server のソースデータ型
AWS Database Migration Service のデーS Database Migration Service のデー
MySQL のターゲットットータ型

(iii) ネットワーク帯域を十分なもの確保する

移行当初は以下のようなVPNを使った構成を取っていました。

ところが、移行中、以下の図のようにネットワークスループットが極端に低下する事象が発生しました。

原因がお客様の利用されていたISPのネットワーク輻輳が発生していたためでした。
そこで、AWSへの接続手段をDirect Connectに切り替えてリトライして事象を改善しました。

(iv) ソースデータベースのログ設定を見直す

本番データ移行中にSQL Serverのトランザクションログのディスク領域が肥大化してしまう事象がありました。
お客様の環境は物理ディスクで構成されていたので、ディスクサイズを拡張できないため以下の対応を行いました。

  1. SQL Serverの バックアップモードは「完全」
  2. SQL Serverでは、トランザクションログを 定期的に圧縮する
  3. DMSのエンドポイント設定に、safeguardPolicy=EXCLUSIVE_AUTOMATIC_TRUNCATIONを有効化
  1. と 2. の対応で2. の2. の Server側のトランザクションログの領域を逼迫させないようにします。
    3. の設定でDMS移行タスクがトランザクションログを読み取った直後に、該当トランザクションログを切り捨てができます。
    上記の対応を行うことでトランザクションログの逼迫がなくなりました。
    DMSのレプリケーションでは、トランザクションログを圧縮しても影響ないのはすごいなと思います。

(v) Auroraの性能の一時的な向上

移行計画としてテーブルサイズが大きいものから順次移行し、それ以外のすべてのテーブルをまとめてフルロードしました。
その際にAuroraの書き込み/読み込み処理が詰まることが起こりました。
当初のAuroraの設計は既存のSQL Serverと同じメモリが載っているインスタンスを使っていたのですが、この事象の対応でインスタンスタイプを2つ上のものに変更しました。
また、パラメータグループで書込み処理のパフォーマンスを上げるためにループで書込み処理のパフォーマンスを上げるためにラメータを見直しました。

  • query_cache_typy_cache_typ
  • slow_query_log
  • general_log
  • innodb_max_dirty_pages_pct
  • innodb_flush_log_at_trx_commit

結果的に変更前からのパフォーマンスが改善して、残っていたテーブルすべてのフルロードが行えました。

まとめ

本番データの移行作業から考慮点をまとめてみましたが、いかがでしたでしょうか？

机上の設計だけでは想定しきれない事象が起こるので、しっかりとした検証や確認が肝になります。

この記事がで何かの役に立てば幸いです、それでは！