$30 off During Our Annual Pro Sale. View details »

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

soudai sone
February 11, 2019

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

soudai sone

February 11, 2019
Tweet

More Decks by soudai sone

Other Decks in Technology

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. リファクタリングをする理由

  31. None
  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. ご清聴ありがとうございました