RDBリファクタリングと異種間DB移行の戦い / AWS-DMS

JAWS DAYS 2019の登壇資料です
- https://jawsdays2019.jaws-ug.jp/session/1108/

# 資料内リンク
- https://employment.en-japan.com/engineerhub/entry/2018/12/11/110000
- https://soudai.hatenablog.com/entry/rfbantipattern
- https://dev.mysql.com/doc/refman/5.6/ja/trigger-syntax.html
- https://www.ikkitang1211.site/entry/pgconf18j

Transcript

1. RDBリファクタリングと 異種間DB移行の戦い Amazon DMSを使って サービスを止めずにリファクタリングする手法 JAWS DAYS 2019
2. What is it? RDB使ってますか？
3. What is it? データベースリファクタリング してますか？
4. What is it? データベースの寿命は アプリケーションより長い
5. https://employment.en-japan.com/engineerhub/entry/2018/12/11/110000
6. What is it? この記事でも細かく記載されています (興味が出たら読んでみてください)
7. What is it? 今、まさにやってる事をお話します
8. あじぇんだ 1 自己紹介 2 リファクタリングする理由 3 Amazon DMSを選んだ理由 4 サービスを止めるな！ 5 まとめ
9. あじぇんだ 1 自己紹介 2 リファクタリングする理由 3 Amazon DMSを選んだ理由 4 サービスを止めるな！ 5 まとめ
10. 自己紹介 曽根 壮大（34歳) 株式会社オミカレ 副社長/CTO • 日本PostgreSQLユーザ会 勉強会分科会 座長 • 3人の子供がいます • 技術的にはWeb/LL言語/RDBが好きです そ ね た け と も
11. 自己紹介 曽根 壮大（34歳) 株式会社オミカレ 副社長/CTO • 日本PostgreSQLユーザ会 勉強会分科会 座長 • 3人の子供がいます • 技術的にはWeb/LL言語/RDBが好きです そ ね た け と も
12. 婚活といえばオミカレ https://party-calendar.net/
13. あじぇんだ 1 自己紹介 2 リファクタリングする理由 3 Amazon DMSを選んだ理由 4 サービスを止めるな！ 5 まとめ
14. リファクタリングをする理由 システム、三日会わざれば刮目して見よ
15. リファクタリングをする理由 いなかった時期
16. リファクタリングをする理由 わずか1年半 しかし成長するには充分な時間である
17. リファクタリングをする理由 とある日の出来事 「TABLEを眺める会をやろう！」
18. リファクタリングをする理由 このTABLEってなんですか？ それな、俺も知らないんだ…
19. リファクタリングをする理由 誰も知らないTABLEの恐怖
20. 謎のデータ mysql> SELECT gender FROM demo GROUP BY gender; +--------+ | gender | +--------+ | 0 | | 1 | | 女性 | | 男性 | +--------+ 4 rows in set (0.62 sec)
21. なるほど？？？
22. リファクタリングをする理由 8年目のWebサービス
23. リファクタリングをする理由 8年目のWebサービス ↓ 多くの変化によって、技術的負債が出来る 事業の成長のために優先順として仕方ないところもある
24. リファクタリングをする理由 • 誰も知らないTABLE • 不適切な値の入ったレコード • 制約が無く、壊れた整合性 • 非正規化によって、複雑化したコード …etc 主な技術的負債
25. リファクタリングをする理由 有るモノを嘆いても何も変わらない
26. リファクタリングをする理由 有るモノを嘆いても何も変わらない ↓ 自分たちが技術で解決していくしか無い
27. リファクタリングをする理由 リファクタリングのための要件 • なるべく無停止で進めたい • 複数のWebサービスから参照されるが 同時には直せない • 工数は限られ、新規開発は止めない
28. リファクタリングをする理由 そーだいさん「無理やで？」
29. リファクタリングをする理由 といっても仕方ないので考えた
30. リファクタリングをする理由
32. リファクタリングをする理由 先人の知恵を借りた結果
33. リファクタリングをする理由 先人の知恵を借りた結果 ↓ トリガーを使って 肥大化したテーブルを分割する
34. リファクタリング方針 Aurora みんなの婚活 オミカレ party_detail party_open party 既存スキーマ 新スキーマ オミカレ データベース トリガー
35. リファクタリング方針 Aurora みんなの婚活 オミカレ party_detail party_open party 既存スキーマ 新スキーマ オミカレ データベース トリガー ① アプリケーション がデータを書き込む
36. リファクタリング方針 Aurora みんなの婚活 オミカレ party_detail party_open party 既存スキーマ 新スキーマ オミカレ データベース トリガー ②書き込みをイベント にトリガーが起動
37. リファクタリング方針 Aurora みんなの婚活 オミカレ party_detail party_open party 既存スキーマ 新スキーマ オミカレ データベース トリガー ③トリガーがそれぞれのテーブル に書き込みを行う
38. リファクタリングをする理由 サービスを止めずに データベースをリファクタリング
39. リファクタリングをする理由 Aurora MySQL 5.6互換を利用
40. リファクタリングをする理由 Aurora MySQL 5.6互換を利用 ↓ MySQLは1つのテーブルに対し、 同じイベントには 複数のトリガーを設定出来ない
41. リファクタリングをする理由 たとえば、1つのテーブルに対して 2つの BEFORE UPDATE トリガーを 定義することはできません https://dev.mysql.com/doc/refman/5.6/ja/trigger-syntax.html 1 つのテーブルに対して 2 つの BEFORE UPDATE トリガーを定義することはできません
42. リファクタリングをする理由 小規模なら問題ないが 今回は大規模なので…
43. リファクタリングをする理由 PostgreSQLなら… トリガーが使えるのに…
44. リファクタリングをする理由 なので異種間DB移行
45. リファクタリングをする理由 Aurora MySQL 5.6互換 ↓ RDS for PostgreSQL
46. リファクタリングをする理由 Aurora PostgreSQL互換 で良いのでは？ 真っ当な意見だと思います
47. RDS for PostgreSQLの採用 主な理由 • トリガーを複数設定できるRDBMSである • Aurora PostgreSQL互換の情報の少なさ • AuroraはAuroraであり、OSSでは無い – ローカルで同じ開発環境を用意できない – 場合によってはExtensionの自作が必要かもしれない →EC2に移せる選択肢が必要
48. リファクタリング方針 Aurora みんなの婚活 オミカレ party_detail party_open party 既存スキーマ 新スキーマ PostgreSQL トリガー 異種DB間の レプリケーションが必要
49. あじぇんだ 1 自己紹介 2 リファクタリングする理由 3 Amazon DMSを選んだ理由 4 サービスを止めるな！ 5 まとめ
50. Amazon DMSを選んだ理由 AWS Database Migration Service
51. Amazon DMSを選んだ理由 異種間DBレプリケーション
52. Amazon DMSの仕組み ソース エンドポイント (Aurora) タスク テーブル単位でのレプリケーションが可能 ターゲット エンドポイント (PostgreSQL) レプリケーション インスタンス タスク
53. Amazon DMSの仕組み https://speakerdeck.com/takahashiikki/postgresqljapan2018
54. Amazon DMSを選んだ理由 主なタスクの種類 • 全ロード＋継続的なレプリケーション(CDC) – オミカレで利用しているのはここ – 既存のデータの全ロードはPostgreSQLはCOPY文 – その後はbinlogやWALを基に差分レプリケーション • 継続的なレプリケーション(CDC)のみ • 全ロードのみ
55. Amazon DMSを選んだ理由 タスクの実行単位の指定方法 • 正規表現でのテーブル名の指定 – user_% や %hoge% のような指定 • 移行ルールの指定 – 移行元と移行先でテーブル名が違う場合 – 対象データをWHERE句で絞り込みたい
56. リファクタリング方針 Aurora みんなの婚活 オミカレ party_detail party_open party 既存スキーマ 新スキーマ PostgreSQL トリガー 出来る！
57. Amazon DMSを選んだ理由 他の類似製品は？
58. Amazon DMSを選んだ理由 諦めた他の手法 • ライセンスコストが高かった – 高いやつは高速だしなんでも出来るが… • 技術介入度が高すぎた – 運用コストが高すぎる • 技術サポートがなかった – リスクが高すぎる
59. Amazon DMSを選んだ理由 比較した結果 Amazon DMSを採用した
60. あじぇんだ 1 自己紹介 2 リファクタリングする理由 3 Amazon DMSを選んだ理由 4 サービスを止めるな！ 5 まとめ
61. サービスを止めるな！ 実際に運用してみてどうか
62. サービスを止めるな！ https://employment.en-japan.com/engineerhub/entry/2018/12/11/110000
63. サービスを止めるな！ データ量が少ないなら 簡単に実現出来る
64. サービスを止めるな！ Amazon DMSは バージョン違いのRDSも可能 つまりローリングアップデートも可能！
65. サービスを止めるな！ 参照を切り替える
66. サービスを止めるな！ 参照を切り替える ↓ API経由にすることでModel単位で対応
67. そーだいなる監視 https://employment.en-japan.com/engineerhub/entry/2018/12/11/110000
68. この方法のメリット • Model単位で移行が可能 – 対象のテーブル単位で対応できる – リスクの範囲を小さくできる • 既存の仕組みを止める必要が無い – カナリヤリリース出来る – ロールバックしやすい • 以下のパターンで概ねリスク低く、対応出来る – 読み込みだけAPIにして書き込みはOLD • この場合はデータはAmazon DMSで連携 – 書き込みはAPIとOLDの両方に書き込み、 読み込みはOLD • この場合はAmazon DMSを使わない
69. この方法のデメリット • ローカルで再現出来ない – Amazon DMSが再現出来ない – 現状はAWS上に開発環境がある • DMSが単一障害点 – DMSが遅延したりすることが稀にある – トリガーが失敗するとDMSが止まる • DMSが止まるとサービス障害 • リードレプリカが昇格に未対応 – エンドポイントが変わるとDMSが止まる • DMSのタスクの上限がある – 開発環境を無限には作れない – 現状は本番で20以上のタスクが動いている
70. サービスを止めるな！ 実運用してみて
71. サービスを止めるな！ 時々DMSが止まるッス！ データの登録時のエラーを監視しよう
72. サービスを止めるな！ RDSのログを PHP経由で定期的にチェックする
73. サービスを止めるな！ 1. AWS SDK for PHPで downloadDBLogFilePortion関数を実行 2. Errorなどの特定のキーワードを拾ってalert 3. Mackerelのチェック監視の仕組みで通知
74. サービスを止めるな！ AWS php mackerel-agent Slack ① SDKを実行 ② ログを取得 ③ ログを確認 ④Mackerel経由で通知 Mackerel-agentが定期的に実行する
75. 実際に運用してわかったこと 1. 性別がintでは無く文字列のため表記揺れ 2. MySQLのZero Date問題(0000-00-00) 3. タイムゾーンがUTCでズレる
76. サービスを止めるな！ 想定外のデータは意外とある
77. サービスを止めるな！ 想定外のデータは意外とある ↓ 細かい制約と監視・観測で 1つ1つ潰して行く
78. サービスを止めるな！ サービス開発と並行して リファクタリングを進めていける (参照は7割くらいはAPI化された)
79. あじぇんだ 1 自己紹介 2 リファクタリングする理由 3 Amazon DMSを選んだ理由 4 サービスを止めるな！ 5 まとめ
80. まとめ Amazon DMSは便利なツール
81. まとめ 異種間でなくてもユースケースは多い バージョンアップ、複数DBの集約、 データセンターからの移行など
82. まとめ Amazon DMSは便利なツール ↓ しかし一時的利用をするためのツール
83. まとめ 更新が激しい場合は レプリケーションが追いつかないことも (参照がメインなら問題ない)
84. まとめ サービスの根底に据えるのは悪手
85. まとめ DBリファクタリングに必要なこと
86. まとめ
87. https://speakerdeck.com/soudai/rdb-antipattern-refactoring?slide=94
88. まとめ 諦めず、仕組みで解決していく
89. まとめ 諦めず、仕組みで解決していく ↓ 仕組みは技術力で解決できる
90. まとめ 技術で問題を解決していく
91. まとめ 自分たちが 改善のサイクルを回していく
92. まとめ “手を動かした者だけが世界を変える” id:onishi
93. ご清聴ありがとうございました