AWS DMS おぼえがき

これはなに?

AWS DMSについてざっくり概要を理解したので、忘れないように書いたメモです

AWS Database Migration Service(簡単、安全なデータベース移行)|AWS

先にまとめ

  • AWS DMSは、最小のダウンタイムでデーターベースの移行をしてくれるサービス
  • テーブル定義の移動はしてくれないので、予め移行するか AWS SCT か mysqldump などを使う
  • 移行後も変更に追従してくれるので、切替も切戻しもローリスク&最小ダウンタイムで実行可能

AWS DMSってなに?

AWS Database Migration Service

  • 既存のDBを最小のダウンタイムで他のDBに移行できるサービス

一番の特徴は?

異種間(OracleからMySQLなど)のDBの移行をサポートしていること

  • 同種間の移行もサポートしているが、性能や精度はオフィシャルのmigrationツールのほうがよいとのこと

「基本的に同種データベース間では、そのデータベース純正のレプリケーションツールの利用を推奨している。DMSでは内部構造的に、各種データベースの差分を吸収するため、一度データをDMS特有のデータ構造に変換していることから純正ツールに比べてどうしてもパフォーマンス的に不利になる。

AWS DMSでできることはなに?

以下の2つ(どちらかのみの実行も可能)

  • Full Load
    • データの移行
    • 全テーブルを1万行づつselectして、移行元に書き込む
    • メモリが不足すると、EBSにswapされるので、データサイズに合わせたメモリが合ったほうが良い
  • Change Data Capture(CDC)
    • データの変更に追従
    • トランザクションログを5秒毎にCaptureして、変更内容をSQLに置換して、変更元に書き込む
    • Full Load中や、変換が追いつかない場合キューイングされる
    • 変更が多い場合は、マシンの性能/台数を上げる必要がありそう

制限はある?

  • 元DBのエンジンのバージョンに制限あり

f:id:kasei_san:20181217130810p:plain
2017年資料なので少し古いかも

  • UTF8MB4はサポートしていない
    • MySQLだと致命的ですね...

docs.aws.amazon.com

  • その他DBのサイズなどに制限あり

docs.aws.amazon.com

DMSでできないことはある?

テーブル定義の移動

  • セカンダリインデックス、非プライマリーキー制約、デフォルト値などはサポートしておらず、移行先のDBに予め定義しておく必要がある

テーブル定義の移動はどうするの?

異種間の場合、AWS Schema Conversion Toolを使う

  • 同種間の移動なら、mysqldump などで移行できる

AWS SCTとは?

異種間のテーブル定義の移行をサポートしてくれるツール

docs.aws.amazon.com

AWS DMSでのDB移行の具体的な流れ

  1. 移行元DBの準備
  2. 移行先DBの準備
  3. DMSの設定
  4. 移行
  5. アプリ側の移行

移行元DBの準備

上述した、AWS SCTや、mysqldump などでテーブル定義を予め移行しておく

移行先DBの準備

  • VPN外の場合、インターネットに接続できるようにする
  • AWS内の場合、DMSが接続できるようにセキュリティグループを設定する

Full Load時に負荷がかかるので、専用のリードレプリカを用意したほうが良いと思う

DMSの設定

  • DMSのインスタンスタイプを決める
    • 性能が良い/台数が多いほうが当然移行が早くなる
      • 予め予行演習しておくと良いかも
    • FullLoadでメモリを食いそうな場合はメモリサイズを大きくしたほうが良い
    • CDCの頻度が高い場合も、マシンの性能/台数を増やしたほうが良い
  • DMSに接続する、移行元&移行先のDBのエンドポイントを用意する

移行

FullLoadと、CDCが行われることを見守る

アプリ側の移行

  1. 移行元DBへの書き込みを停止(ここからダウンタイム)
  2. 書き込みが完了したことを確認
    • AWS的では、最後に書き込まれるマーカートランザクションの使用を推奨している
  3. アプリのDBの参照先を移行元DBに変更(ここまでダウンタイム)

ダウンタイムを減らすのに良い方法はある?

CDCが始まった時点で、読み込みについては、移行元に変更したら良さそう

  • 書き込みのある処理だけダウンさせるという方法が取れるため、ダウンタイム発生が一部機能だけにできる
  • 予め読み込み部分だけでも、移行が正しく行われているかテストできる

Railsで読み込みだけ別DBにするのってどうするの?

いくつか方法がある

  • 案1. 読み込み/書き込みをAPI経由にして、それぞれ別々のDBを参照できるようにする
    • マイクロサービス化
  • 案2. 複数DBに対応のためのgemを導入する
  • 案3. Rails6を待つ

移行事例

PostgreSQL → PostgreSQL

  • DMSを使うことで旧verから低リスクで移行できたというお話

speakerdeck.com

MySQL(5.7) → Aurora(MySQL互換5.6)

  • 当時まだAuroraのMySQL互換が5.6しかなかったので、ダウングレードが必要だった

developer.feedforce.jp