この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちわ。崔です。
先日開催されたJAWS DAYS 2019 、Gトラックで行われた下記セッションをレポートします。AWS DMSを使ってサービスを止めずにRDBををリファクタリングする手法について、そのノウハウが公開されました。
スピーカー
株式会社オミカレはRDS上のAuroraからPostgreSQLへ Amazon Database Migration Serviceを使って異種間DB移行をしています。 その中で得た次のようなノウハウを余すことなくお伝えします。
資料
内容
リファクタリングする理由
テーブルを眺める会
- このテーブル何？
- 誰も知らないテーブル
- ８年目のWebサービスのため、多くの変化により技術的負債が出来た
主な技術的負債
- 誰も知らないテーブル
- 不適切な値の入ったレコード
- 制約がなく、壊れた整合性
- 非正規化によって、複雑化したコード
リファクタリングする理由
- 自分達で技術で解決
リファクタリングするための要件
- 無停止
- 同時には直せない
- 工数は限られる
リファクタリング方針
- トリガーを使って肥大化したテーブルを分割する
- 既存スキーマからトリガーを介して、新スキーマに分割された複数のテーブルに書きこむ
- しかしながら、Aurora MySQL ５.６互換では、１つのテーブルに対して、同じイベントには複数のトリガーを設定できない
- 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の集約、データセンターからの移行など
- しかし、一時的利用をするツール
- 更新が激しい場合は、レプリケーションが追いつかないことも
まとめ２
- 諦めず仕組みで解決していく
- 仕組みは技術力で解決できる
- 技術で問題を解決していく
所感
Aurora MySQL ５.６ 上で動くデータベースをどのようにリファクタリングしたか、RDS for PostgreSQLでトリガーを使う方法や、DBレプリケーションにDMSを使った手法が紹介されていました。
また、DMSを使うメリット／デメリットや、レプリケーション後のDBを参照させるための工夫についても、実際の苦労点含め、非常に参考になりました。
異種間DBのレプリケーションを行う際には、AWS DMSは第一の選択肢になると思います。そのような機会があれば、まずはテストで試してみることをお勧めします。
2
