Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

268 views

Published on

ATEAM TECH MeetUp_Vol.09 エイチームフィナジーのバックエンド開発
登壇資料
https://ateam.connpass.com/event/139285/

Published in: Technology
  • Be the first to comment

  • Be the first to like this

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

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

×