Slide 1

Slide 1 text

RDBリファクタリングと 異種間DB移行の戦い Amazon DMSを使って サービスを止めずにリファクタリングする手法 JAWS DAYS 2019

Slide 2

Slide 2 text

What is it? RDB使ってますか?

Slide 3

Slide 3 text

What is it? データベースリファクタリング してますか?

Slide 4

Slide 4 text

What is it? データベースの寿命は アプリケーションより長い

Slide 5

Slide 5 text

https://employment.en-japan.com/engineerhub/entry/2018/12/11/110000

Slide 6

Slide 6 text

What is it? この記事でも細かく記載されています (興味が出たら読んでみてください)

Slide 7

Slide 7 text

What is it? 今、まさにやってる事をお話します

Slide 8

Slide 8 text

あじぇんだ 1 自己紹介 2 リファクタリングする理由 3 Amazon DMSを選んだ理由 4 サービスを止めるな! 5 まとめ

Slide 9

Slide 9 text

あじぇんだ 1 自己紹介 2 リファクタリングする理由 3 Amazon DMSを選んだ理由 4 サービスを止めるな! 5 まとめ

Slide 10

Slide 10 text

自己紹介 曽根 壮大(34歳) 株式会社オミカレ 副社長/CTO • 日本PostgreSQLユーザ会 勉強会分科会 座長 • 3人の子供がいます • 技術的にはWeb/LL言語/RDBが好きです そ ね た け と も

Slide 11

Slide 11 text

自己紹介 曽根 壮大(34歳) 株式会社オミカレ 副社長/CTO • 日本PostgreSQLユーザ会 勉強会分科会 座長 • 3人の子供がいます • 技術的にはWeb/LL言語/RDBが好きです そ ね た け と も

Slide 12

Slide 12 text

婚活といえばオミカレ https://party-calendar.net/

Slide 13

Slide 13 text

あじぇんだ 1 自己紹介 2 リファクタリングする理由 3 Amazon DMSを選んだ理由 4 サービスを止めるな! 5 まとめ

Slide 14

Slide 14 text

リファクタリングをする理由 システム、三日会わざれば刮目して見よ

Slide 15

Slide 15 text

リファクタリングをする理由 いなかった時期

Slide 16

Slide 16 text

リファクタリングをする理由 わずか1年半 しかし成長するには充分な時間である

Slide 17

Slide 17 text

リファクタリングをする理由 とある日の出来事 「TABLEを眺める会をやろう!」

Slide 18

Slide 18 text

リファクタリングをする理由 このTABLEってなんですか? それな、俺も知らないんだ…

Slide 19

Slide 19 text

リファクタリングをする理由 誰も知らないTABLEの恐怖

Slide 20

Slide 20 text

謎のデータ mysql> SELECT gender FROM demo GROUP BY gender; +--------+ | gender | +--------+ | 0 | | 1 | | 女性 | | 男性 | +--------+ 4 rows in set (0.62 sec)

Slide 21

Slide 21 text

なるほど???

Slide 22

Slide 22 text

リファクタリングをする理由 8年目のWebサービス

Slide 23

Slide 23 text

リファクタリングをする理由 8年目のWebサービス ↓ 多くの変化によって、技術的負債が出来る 事業の成長のために優先順として仕方ないところもある

Slide 24

Slide 24 text

リファクタリングをする理由 • 誰も知らないTABLE • 不適切な値の入ったレコード • 制約が無く、壊れた整合性 • 非正規化によって、複雑化したコード …etc 主な技術的負債

Slide 25

Slide 25 text

リファクタリングをする理由 有るモノを嘆いても何も変わらない

Slide 26

Slide 26 text

リファクタリングをする理由 有るモノを嘆いても何も変わらない ↓ 自分たちが技術で解決していくしか無い

Slide 27

Slide 27 text

リファクタリングをする理由 リファクタリングのための要件 • なるべく無停止で進めたい • 複数のWebサービスから参照されるが 同時には直せない • 工数は限られ、新規開発は止めない

Slide 28

Slide 28 text

リファクタリングをする理由 そーだいさん「無理やで?」

Slide 29

Slide 29 text

リファクタリングをする理由 といっても仕方ないので考えた

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

リファクタリングをする理由 先人の知恵を借りた結果

Slide 33

Slide 33 text

リファクタリングをする理由 先人の知恵を借りた結果 ↓ トリガーを使って 肥大化したテーブルを分割する

Slide 34

Slide 34 text

リファクタリング方針 Aurora みんなの婚活 オミカレ party_detail party_open party 既存スキーマ 新スキーマ オミカレ データベース トリガー

Slide 35

Slide 35 text

リファクタリング方針 Aurora みんなの婚活 オミカレ party_detail party_open party 既存スキーマ 新スキーマ オミカレ データベース トリガー ① アプリケーション がデータを書き込む

Slide 36

Slide 36 text

リファクタリング方針 Aurora みんなの婚活 オミカレ party_detail party_open party 既存スキーマ 新スキーマ オミカレ データベース トリガー ②書き込みをイベント にトリガーが起動

Slide 37

Slide 37 text

リファクタリング方針 Aurora みんなの婚活 オミカレ party_detail party_open party 既存スキーマ 新スキーマ オミカレ データベース トリガー ③トリガーがそれぞれのテーブル に書き込みを行う

Slide 38

Slide 38 text

リファクタリングをする理由 サービスを止めずに データベースをリファクタリング

Slide 39

Slide 39 text

リファクタリングをする理由 Aurora MySQL 5.6互換を利用

Slide 40

Slide 40 text

リファクタリングをする理由 Aurora MySQL 5.6互換を利用 ↓ MySQLは1つのテーブルに対し、 同じイベントには 複数のトリガーを設定出来ない

Slide 41

Slide 41 text

リファクタリングをする理由 たとえば、1つのテーブルに対して 2つの BEFORE UPDATE トリガーを 定義することはできません https://dev.mysql.com/doc/refman/5.6/ja/trigger-syntax.html 1 つのテーブルに対して 2 つの BEFORE UPDATE トリガーを定義することはできません

Slide 42

Slide 42 text

リファクタリングをする理由 小規模なら問題ないが 今回は大規模なので…

Slide 43

Slide 43 text

リファクタリングをする理由 PostgreSQLなら… トリガーが使えるのに…

Slide 44

Slide 44 text

リファクタリングをする理由 なので異種間DB移行

Slide 45

Slide 45 text

リファクタリングをする理由 Aurora MySQL 5.6互換 ↓ RDS for PostgreSQL

Slide 46

Slide 46 text

リファクタリングをする理由 Aurora PostgreSQL互換 で良いのでは? 真っ当な意見だと思います

Slide 47

Slide 47 text

RDS for PostgreSQLの採用 主な理由 • トリガーを複数設定できるRDBMSである • Aurora PostgreSQL互換の情報の少なさ • AuroraはAuroraであり、OSSでは無い – ローカルで同じ開発環境を用意できない – 場合によってはExtensionの自作が必要かもしれない →EC2に移せる選択肢が必要

Slide 48

Slide 48 text

リファクタリング方針 Aurora みんなの婚活 オミカレ party_detail party_open party 既存スキーマ 新スキーマ PostgreSQL トリガー 異種DB間の レプリケーションが必要

Slide 49

Slide 49 text

あじぇんだ 1 自己紹介 2 リファクタリングする理由 3 Amazon DMSを選んだ理由 4 サービスを止めるな! 5 まとめ

Slide 50

Slide 50 text

Amazon DMSを選んだ理由 AWS Database Migration Service

Slide 51

Slide 51 text

Amazon DMSを選んだ理由 異種間DBレプリケーション

Slide 52

Slide 52 text

Amazon DMSの仕組み ソース エンドポイント (Aurora) タスク テーブル単位でのレプリケーションが可能 ターゲット エンドポイント (PostgreSQL) レプリケーション インスタンス タスク

Slide 53

Slide 53 text

Amazon DMSの仕組み https://speakerdeck.com/takahashiikki/postgresqljapan2018

Slide 54

Slide 54 text

Amazon DMSを選んだ理由 主なタスクの種類 • 全ロード+継続的なレプリケーション(CDC) – オミカレで利用しているのはここ – 既存のデータの全ロードはPostgreSQLはCOPY文 – その後はbinlogやWALを基に差分レプリケーション • 継続的なレプリケーション(CDC)のみ • 全ロードのみ

Slide 55

Slide 55 text

Amazon DMSを選んだ理由 タスクの実行単位の指定方法 • 正規表現でのテーブル名の指定 – user_% や %hoge% のような指定 • 移行ルールの指定 – 移行元と移行先でテーブル名が違う場合 – 対象データをWHERE句で絞り込みたい

Slide 56

Slide 56 text

リファクタリング方針 Aurora みんなの婚活 オミカレ party_detail party_open party 既存スキーマ 新スキーマ PostgreSQL トリガー 出来る!

Slide 57

Slide 57 text

Amazon DMSを選んだ理由 他の類似製品は?

Slide 58

Slide 58 text

Amazon DMSを選んだ理由 諦めた他の手法 • ライセンスコストが高かった – 高いやつは高速だしなんでも出来るが… • 技術介入度が高すぎた – 運用コストが高すぎる • 技術サポートがなかった – リスクが高すぎる

Slide 59

Slide 59 text

Amazon DMSを選んだ理由 比較した結果 Amazon DMSを採用した

Slide 60

Slide 60 text

あじぇんだ 1 自己紹介 2 リファクタリングする理由 3 Amazon DMSを選んだ理由 4 サービスを止めるな! 5 まとめ

Slide 61

Slide 61 text

サービスを止めるな! 実際に運用してみてどうか

Slide 62

Slide 62 text

サービスを止めるな! https://employment.en-japan.com/engineerhub/entry/2018/12/11/110000

Slide 63

Slide 63 text

サービスを止めるな! データ量が少ないなら 簡単に実現出来る

Slide 64

Slide 64 text

サービスを止めるな! Amazon DMSは バージョン違いのRDSも可能 つまりローリングアップデートも可能!

Slide 65

Slide 65 text

サービスを止めるな! 参照を切り替える

Slide 66

Slide 66 text

サービスを止めるな! 参照を切り替える ↓ API経由にすることでModel単位で対応

Slide 67

Slide 67 text

そーだいなる監視 https://employment.en-japan.com/engineerhub/entry/2018/12/11/110000

Slide 68

Slide 68 text

この方法のメリット • Model単位で移行が可能 – 対象のテーブル単位で対応できる – リスクの範囲を小さくできる • 既存の仕組みを止める必要が無い – カナリヤリリース出来る – ロールバックしやすい • 以下のパターンで概ねリスク低く、対応出来る – 読み込みだけAPIにして書き込みはOLD • この場合はデータはAmazon DMSで連携 – 書き込みはAPIとOLDの両方に書き込み、 読み込みはOLD • この場合はAmazon DMSを使わない

Slide 69

Slide 69 text

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

Slide 70

Slide 70 text

サービスを止めるな! 実運用してみて

Slide 71

Slide 71 text

サービスを止めるな! 時々DMSが止まるッス! データの登録時のエラーを監視しよう

Slide 72

Slide 72 text

サービスを止めるな! RDSのログを PHP経由で定期的にチェックする

Slide 73

Slide 73 text

サービスを止めるな! 1. AWS SDK for PHPで downloadDBLogFilePortion関数を実行 2. Errorなどの特定のキーワードを拾ってalert 3. Mackerelのチェック監視の仕組みで通知

Slide 74

Slide 74 text

サービスを止めるな! AWS php mackerel-agent Slack ① SDKを実行 ② ログを取得 ③ ログを確認 ④Mackerel経由で通知 Mackerel-agentが定期的に実行する

Slide 75

Slide 75 text

実際に運用してわかったこと 1. 性別がintでは無く文字列のため表記揺れ 2. MySQLのZero Date問題(0000-00-00) 3. タイムゾーンがUTCでズレる

Slide 76

Slide 76 text

サービスを止めるな! 想定外のデータは意外とある

Slide 77

Slide 77 text

サービスを止めるな! 想定外のデータは意外とある ↓ 細かい制約と監視・観測で 1つ1つ潰して行く

Slide 78

Slide 78 text

サービスを止めるな! サービス開発と並行して リファクタリングを進めていける (参照は7割くらいはAPI化された)

Slide 79

Slide 79 text

あじぇんだ 1 自己紹介 2 リファクタリングする理由 3 Amazon DMSを選んだ理由 4 サービスを止めるな! 5 まとめ

Slide 80

Slide 80 text

まとめ Amazon DMSは便利なツール

Slide 81

Slide 81 text

まとめ 異種間でなくてもユースケースは多い バージョンアップ、複数DBの集約、 データセンターからの移行など

Slide 82

Slide 82 text

まとめ Amazon DMSは便利なツール ↓ しかし一時的利用をするためのツール

Slide 83

Slide 83 text

まとめ 更新が激しい場合は レプリケーションが追いつかないことも (参照がメインなら問題ない)

Slide 84

Slide 84 text

まとめ サービスの根底に据えるのは悪手

Slide 85

Slide 85 text

まとめ DBリファクタリングに必要なこと

Slide 86

Slide 86 text

まとめ

Slide 87

Slide 87 text

https://speakerdeck.com/soudai/rdb-antipattern-refactoring?slide=94

Slide 88

Slide 88 text

まとめ 諦めず、仕組みで解決していく

Slide 89

Slide 89 text

まとめ 諦めず、仕組みで解決していく ↓ 仕組みは技術力で解決できる

Slide 90

Slide 90 text

まとめ 技術で問題を解決していく

Slide 91

Slide 91 text

まとめ 自分たちが 改善のサイクルを回していく

Slide 92

Slide 92 text

まとめ “手を動かした者だけが世界を変える” id:onishi

Slide 93

Slide 93 text

ご清聴ありがとうございました