段階的なシステムリプレースを実現するデータ同期技術

Transcript

1. 段階的なシステムリプレースを実現するデータ同期技術 Ateam Tech Meetup Vol.9 株式会社エイチームフィナジー テクニカルソリューション部 R&Dチーム 鈴⽊就⽃ GitHub @s2terminal Twitter @suzukiterminal Qiita @suzuki_sh
2. © 2018 Ateam Inc. 今回お話する対象サービス ◧ ⾦融メディア事業の中のいちWebメディア ◧ 2013年12⽉(約 5 年半前)ローンチ ◧ グループ最⼤規模の売上に成⻑ 図: エイチームグループ ライフスタイルサポート事業の売上規模推移
3. © 2018 Ateam Inc. 3 画像の出典: https://unsplash.com/photos/O2MdroNurVw 運⽤を続けるうちに、システムが肥⼤化・複雑化 Webサイト上のコンテンツの ”正確な” 管理・更新が 問題となっていった
4. © 2018 Ateam Inc. 4 画像の出典: https://pixabay.com/images/id-1743963/ 複雑化した旧システムを刷新し 新しいシステムへ段階的な リプレースを実現したい 社内向け管理画⾯とお客様向けのページでは 失敗時のリスクの重さが異なる ページによっても広告出稿の 影響度の⼤⼩がある
5. © 2018 Ateam Inc. 5 システムリプレースの前提条件 新システムを機能毎に⼤きく3つのTier(段階)に分け Tier内でもURL毎に影響度の⼤⼩で分割し、段階的にリプレースした。 旧システムはPHPで動いているが、新システムには 社内に技術的な資産の多いRuby on Railsへのリプレースを選択。 当然、RubyとPHPでは技術的に互換性は無いが、同時に稼働させる必要がある。 影響度の低い箇所から、段階的に移⾏したい そのため、移⾏期間中は 新旧の両システムを同時に稼働させたい
6. © 2018 Ateam Inc. 6 リプレースの構成概要と データ同期 画像の出典: https://pixabay.com/images/id-3246116/
7. © 2018 Ateam Inc. 7 データを同期させる必要 ユーザ向け ページ 社員向け 管理画⾯ 旧システム MySQL データベース リプレース前の状態
8. © 2018 Ateam Inc. 8 データを同期させる必要 ユーザ向け ページ 社員向け 管理画⾯ MySQL データベース 旧システム ユーザ向け ページ 社員向け 管理画⾯ 新システム データ同期 MySQL データベース
9. © 2018 Ateam Inc. 9 新システムへのリプレース後の各データの扱い マスタデータ トランザクションデータ 旧システム Readのみ Read/Write両⽅可能 新システム Read/Write両⽅可能 扱わない 今回のタイミングではマスタデータのみをリプレースし、 顧客申込情報などのトランザクションデータは まだ新システムでは取り扱わない事にした。 ￭今回のプロジェクトの⽬的はマスタデータの取り扱いの課題からであり、 トランザクションデータを扱うシステムのリプレースは必須ではなかった ￭移⾏先のシステムの仕様上、両者はシステム的に分離可能だった
10. © 2018 Ateam Inc. 10 データを同期させる必要 マスタデータのみを新システムに持っていくと決めたが 依然として、新システムと旧システムとを同時に稼働させ、 段階的にリプレースする必要がある。 新旧システム間のDBスキーマの形式は、似ているものの 完全⼀致するわけではない。 段階的なリプレースを実現するには、新旧の異なるシステムで 同⼀のマスタデータを参照できるようにする必要がある。
11. © 2018 Ateam Inc. 11 データ同期を実現した 3つの技術 画像の出典: https://pixta.jp/photo/46119614
12. © 2018 Ateam Inc. 12 データ同期の技術 ユーザ向け ページ 社員向け 管理画⾯ データベース 旧システム ユーザ向け ページ 社員向け 管理画⾯ データベース 新システム ②継続的な変更反映 ①初期移⾏ ③変換
13. © 2018 Ateam Inc. 13 1: 旧システム→新システムへの初期データの移⾏ 旧システムのデータを新システム⽤に変換する スクリプトを開発 • 新システムをリリースする時に、1度だけ実⾏。 • 新システム側のモデルクラスとして扱うため、 新システム側にRubyプログラムとして実装。 • プログラムの中⾝は、旧システムのデータをSQLで取得し 新システム側のデータモデルとして保存するもの。
14. © 2018 Ateam Inc. 14 2: 新システム→旧システムへと継続的にデータの変更を反映 • MySQL Replicationを使って 新システムから旧システムにデータを複製。 • Replicationは枯れた仕組みであり、運⽤も⽐較的低コスト • 今回発⽣する変更は社員向け管理画⾯のマスタデータ操作のみのため、 データ同期の反映は⾮同期でOK。 数秒のレプリケーション遅延は許容範囲だった。 • 別途データの変換を⾏う必要がある 開発当初の案としては、EmbulkやRubyのスクリプトを書いて 定期的にバッチ処理を動かすことで、新システムから旧システムへ データを変換しながら転送することを考えていた。 運⽤におけるコストの⾼さ(整合性の保証やリトライなど)が懸念で、やめた。
15. © 2018 Ateam Inc. 15 3: 旧システムで利⽤できるスキーマに変換 • MySQL Viewを使い、新システムのデータを 旧システムのスキーマに沿うように変換した。 • MySQL Replicationは同⼀データをそのまま複製するだけなので、 そのままのデータを旧システム上では使えない。 • 基本的に、新システムの機能は旧システムの上位互換となっていたため 旧システムのデータは新システムのデータのみを使って表現できた。 • 不⾜した部分は専⽤のテーブルを作るか、簡単なCASE⽂で対処 • Replicationで作られたテーブルを参照するViewを作り、 RENAME TABLEで新旧のテーブル名を差し替える事で 旧システムの参照データを新システムの物にリプレース。
16. © 2018 Ateam Inc. 16 データ同期の技術 データベース 旧システム データベース 新システム ②継続的な変更反映 ①初期移⾏ ③変換 新旧システム間でのデータ同期が実現
17. © 2018 Ateam Inc. 17 Amazon Aurora MySQLでの レプリケーションを利⽤した データ同期 画像の出典: https://pixta.jp/illustration/50017474
18. © 2018 Ateam Inc. 18 Amazon Aurora MySQLにおけるレプリケーションの利⽤ 今回のサービスは、DBにAmazon Aurora MySQLを利⽤ Auroraにbinlogベースのレプリケーションを⼿動で構築 AWS側にもフルマネージドのレプリケーション機能は存在しているが、 インスタンス毎の完全なレプリカ作成しかできない。 今回は、旧システムのデータベースインスタンス内に 新システムのテーブルを共存させる必要があったため、binlogで⼿動構築。 Amazon Aurora MySQL とは AWSで提供されている、MySQLと互換性のあるマネージドのRDBMS パフォーマンス、セキュリティ、可⽤性の⾼さが特徴
19. © 2018 Ateam Inc. 19 Amazon Aurora MySQLにおけるレプリケーションの利⽤ Amazon Aurora MySQLは、binlogを利⽤した ⼿動でのレプリケーション構築にも対応している。 外部のMySQLデータベースへデータを複製するための⼿段として、 AWS公式ドキュメントにも⼿順が紹介されている。 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/Aur oraMySQL.Replication.MySQL.html 通常のMySQLでは「CHANGE MASTER TO」などのコマンドを使うところが AWS専⽤のコマンドに置き換えられている箇所があるため、要確認。
20. © 2018 Ateam Inc. 20 Amazon Aurora MySQLにおけるレプリケーションの利⽤ AWS CloudWatchでのレプリケーション遅延の監視 CloudWatchの「AuroraBinlogReplicaLag」というメトリクスで レプリケーション遅延 (いわゆる Seconds_Behind_Master) が、 CloudWatch上で計測できる。 似た名称の「AuroraReplicaLag」というメトリクスがあるが これはAWSのフルマネージド機能で作られたレプリカの話であり、 binlogベースのレプリケーション遅延ではない点に注意。
21. © 2018 Ateam Inc. 21 初期移⾏スクリプトと、MySQLのReplication・Viewを使い 新システムのマスタデータを、旧システムでも利⽤可能に。 このデータ同期により、同⼀のマスタデータを取り扱う 新システムへの段階的な移⾏が実現した。 管理画⾯やユーザ向けページを影響度毎に切り分け 部分的に旧システムを稼働させたまま、 新システムに移⾏できた。 まとめ 画像の出典: https://unsplash.com/photos/ckfkPwCEMNs
22. © 2018 Ateam Inc. 22 Links • 事業を変えるシステムリプレース • https://logmi.jp/tech/articles/321808 • 今回のリプレースについての、別の場所での発表資料です。 • 「なぜリプレースをしたか」「なぜRubyを選んだか」等についてはこちらを参照ください。 • 画像の出典 • https://unsplash.com/photos/O2MdroNurVw • https://unsplash.com/photos/ckfkPwCEMNs • https://pixabay.com/images/id-1743963/ • https://pixabay.com/images/id-3246116/ • https://pixta.jp/photo/46119614 • https://pixta.jp/illustration/50017474
23. 「みんなで幸せになれる会社にすること」 「今から100年続く会社にすること」