[セッションレポート] RDBリファクタリングと異種間DB移行の戦い – Amazon DMSを使った止めずにリファクタリングする手法 #jawsdays #jawsug #jd2019_g

こんにちわ。崔です。

先日開催されたJAWS DAYS 2019 、Gトラックで行われた下記セッションをレポートします。AWS DMSを使ってサービスを止めずにRDBををリファクタリングする手法について、そのノウハウが公開されました。

スピーカー

株式会社オミカレはRDS上のAuroraからPostgreSQLへ Amazon Database Migration Serviceを使って異種間DB移行をしています。 その中で得た次のようなノウハウを余すことなくお伝えします。

資料

内容

リファクタリングする理由

テーブルを眺める会

  • このテーブル何?
  • 誰も知らないテーブル
  • 8年目のWebサービスのため、多くの変化により技術的負債が出来た

主な技術的負債

  • 誰も知らないテーブル
  • 不適切な値の入ったレコード
  • 制約がなく、壊れた整合性
  • 非正規化によって、複雑化したコード

リファクタリングする理由

  • 自分達で技術で解決

リファクタリングするための要件

  • 無停止
  • 同時には直せない
  • 工数は限られる

リファクタリング方針

  • トリガーを使って肥大化したテーブルを分割する
  • 既存スキーマからトリガーを介して、新スキーマに分割された複数のテーブルに書きこむ
  • しかしながら、Aurora MySQL 5.6互換では、1つのテーブルに対して、同じイベントには複数のトリガーを設定できない
  • PostgreSQLならトリガーが使える

RDS for PostgreSQLの採用

  • トリガーを複数設定できるRDBMS
  • Aurora PostgreSQLの情報の少なさ
  • AuroraはAuroraであり、OSSではない
    • ローカルで同じ開発環境を用意できない
    • Extensionの自作が必要かもしれない

DMSを選んだ理由

主なタスクの種類

  • 全ロード+継続的なレプリケーション(CDC)ができる
    • binlogやWALを基に差分レプリケーション
    • オミカレで利用しているのはココ
  • 継続的なレプリケーション(CDC)のみ
  • 全ロードのみ

タスク実行単位の指定方法

  • 正規表現でのテーブル名指定
  • 移行ルールの指定
    • 移行元と移行先でテーブル名が違う場合
    • 対象データをWhere句で絞り込む

他の製品を諦めた理由

  • ライセンスコストが高い
  • 技術介入度が高い
    • 運用コストが高い
  • 技術サポートがない
    • リスク高い

サービスを止めるな

実際に運用してみて

  • データ量が少ないなら簡単
  • DMSはローリングアップデートも可能
    • Postgre9.4 から10.0への移行も可能

参照を切り替える

  • API経由にすることでModel単位に

この方法のメリット

  • Model単位での移行が可能
    • 対象のテーブル単位でできる
    • リスク範囲を小さく
  • 既存の仕組みを止める必要がない
    • カナリヤリリース出来る
    • ロールバックしやすい
  • 概ねリスク低く対応
    • 読み込みだけAPIにして書き込みはOLDへ
    • 書き込みはAPIとOLDの両方に書き込み、読み込みはOLD

この方法のデメリット

  • ローカルで再現出来ない
  • DMSが単一障害点
    • 遅延したりすることがたまにある
    • トリガーが失敗するとDMSが止まる
  • Aurora リードレプリカが昇格に未対応
    • エンドポイントが変わるとDMSが止まる
  • DMSのタスクの上限がある
    • 開発環境を無限には作れない
    • 現状は本番で20以上のタスクが動いている

実運用してみて

  • 時々DMS止まる
    • データ登録時のエラーを監視
  • RDSのログをPHP経由で定期的にチェックする
  • 1.downloadDBLogFilePortion関数を実行
  • 2.Errorなどの特定のキーワードを拾ってalert
  • 3.Mackerelのチェック監視の仕組みで通知

実運用してわかったこと

  • 性別がintではなく文字列のため表記ゆれ
  • MySQLのZero Date問題
  • タイムゾーンがUTCでズレる
  • 想定外のデータは以外とある
    • 細かい制約と監視・観測で潰していく

まとめ

  • Amazon DMSは便利なツール
  • 異種間でなくてもユースケースは多い
    • バージョンアップ、複数DBの集約、データセンターからの移行など
  • しかし、一時的利用をするツール
    • 更新が激しい場合は、レプリケーションが追いつかないことも

まとめ2

  • 諦めず仕組みで解決していく
    • 仕組みは技術力で解決できる
  • 技術で問題を解決していく

所感

Aurora MySQL 5.6 上で動くデータベースをどのようにリファクタリングしたか、RDS for PostgreSQLでトリガーを使う方法や、DBレプリケーションにDMSを使った手法が紹介されていました。

また、DMSを使うメリット/デメリットや、レプリケーション後のDBを参照させるための工夫についても、実際の苦労点含め、非常に参考になりました。

異種間DBのレプリケーションを行う際には、AWS DMSは第一の選択肢になると思います。そのような機会があれば、まずはテストで試してみることをお勧めします。