Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

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

s2terminal
September 13, 2019

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

s2terminal

September 13, 2019
Tweet

More Decks by s2terminal

Other Decks in Technology

Transcript

  1. © 2018 Ateam Inc. 今回お話する対象サービス ◧ ⾦融メディア事業の中のいちWebメディア ◧ 2013年12⽉(約 5

    年半前)ローンチ ◧ グループ最⼤規模の売上に成⻑ 図: エイチームグループ ライフスタイルサポート事業の売上規模推移
  2. © 2018 Ateam Inc. 4 画像の出典: https://pixabay.com/images/id-1743963/ 複雑化した旧システムを刷新し 新しいシステムへ段階的な リプレースを実現したい

    社内向け管理画⾯とお客様向けのページでは 失敗時のリスクの重さが異なる ページによっても広告出稿の 影響度の⼤⼩がある
  3. © 2018 Ateam Inc. 5 システムリプレースの前提条件 新システムを機能毎に⼤きく3つのTier(段階)に分け Tier内でもURL毎に影響度の⼤⼩で分割し、段階的にリプレースした。 旧システムはPHPで動いているが、新システムには 社内に技術的な資産の多いRuby

    on Railsへのリプレースを選択。 当然、RubyとPHPでは技術的に互換性は無いが、同時に稼働させる必要がある。 影響度の低い箇所から、段階的に移⾏したい そのため、移⾏期間中は 新旧の両システムを同時に稼働させたい
  4. © 2018 Ateam Inc. 7 データを同期させる必要 ユーザ向け ページ 社員向け 管理画⾯

    旧システム MySQL データベース リプレース前の状態
  5. © 2018 Ateam Inc. 8 データを同期させる必要 ユーザ向け ページ 社員向け 管理画⾯

    MySQL データベース 旧システム ユーザ向け ページ 社員向け 管理画⾯ 新システム データ同期 MySQL データベース
  6. © 2018 Ateam Inc. 9 新システムへのリプレース後の各データの扱い マスタデータ トランザクションデータ 旧システム Readのみ

    Read/Write両⽅可能 新システム Read/Write両⽅可能 扱わない 今回のタイミングではマスタデータのみをリプレースし、 顧客申込情報などのトランザクションデータは まだ新システムでは取り扱わない事にした。 ■今回のプロジェクトの⽬的はマスタデータの取り扱いの課題からであり、 トランザクションデータを扱うシステムのリプレースは必須ではなかった ■移⾏先のシステムの仕様上、両者はシステム的に分離可能だった
  7. © 2018 Ateam Inc. 12 データ同期の技術 ユーザ向け ページ 社員向け 管理画⾯

    データベース 旧システム ユーザ向け ページ 社員向け 管理画⾯ データベース 新システム ②継続的な変更反映 ①初期移⾏ ③変換
  8. © 2018 Ateam Inc. 13 1: 旧システム→新システムへの初期データの移⾏ 旧システムのデータを新システム⽤に変換する スクリプトを開発 •

    新システムをリリースする時に、1度だけ実⾏。 • 新システム側のモデルクラスとして扱うため、 新システム側にRubyプログラムとして実装。 • プログラムの中⾝は、旧システムのデータをSQLで取得し 新システム側のデータモデルとして保存するもの。
  9. © 2018 Ateam Inc. 14 2: 新システム→旧システムへと継続的にデータの変更を反映 • MySQL Replicationを使って

    新システムから旧システムにデータを複製。 • Replicationは枯れた仕組みであり、運⽤も⽐較的低コスト • 今回発⽣する変更は社員向け管理画⾯のマスタデータ操作のみのため、 データ同期の反映は⾮同期でOK。 数秒のレプリケーション遅延は許容範囲だった。 • 別途データの変換を⾏う必要がある 開発当初の案としては、EmbulkやRubyのスクリプトを書いて 定期的にバッチ処理を動かすことで、新システムから旧システムへ データを変換しながら転送することを考えていた。 運⽤におけるコストの⾼さ(整合性の保証やリトライなど)が懸念で、やめた。
  10. © 2018 Ateam Inc. 15 3: 旧システムで利⽤できるスキーマに変換 • MySQL Viewを使い、新システムのデータを

    旧システムのスキーマに沿うように変換した。 • MySQL Replicationは同⼀データをそのまま複製するだけなので、 そのままのデータを旧システム上では使えない。 • 基本的に、新システムの機能は旧システムの上位互換となっていたため 旧システムのデータは新システムのデータのみを使って表現できた。 • 不⾜した部分は専⽤のテーブルを作るか、簡単なCASE⽂で対処 • Replicationで作られたテーブルを参照するViewを作り、 RENAME TABLEで新旧のテーブル名を差し替える事で 旧システムの参照データを新システムの物にリプレース。
  11. © 2018 Ateam Inc. 16 データ同期の技術 データベース 旧システム データベース 新システム

    ②継続的な変更反映 ①初期移⾏ ③変換 新旧システム間でのデータ同期が実現
  12. © 2018 Ateam Inc. 18 Amazon Aurora MySQLにおけるレプリケーションの利⽤ 今回のサービスは、DBにAmazon Aurora

    MySQLを利⽤ Auroraにbinlogベースのレプリケーションを⼿動で構築 AWS側にもフルマネージドのレプリケーション機能は存在しているが、 インスタンス毎の完全なレプリカ作成しかできない。 今回は、旧システムのデータベースインスタンス内に 新システムのテーブルを共存させる必要があったため、binlogで⼿動構築。 Amazon Aurora MySQL とは AWSで提供されている、MySQLと互換性のあるマネージドのRDBMS パフォーマンス、セキュリティ、可⽤性の⾼さが特徴
  13. © 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専⽤のコマンドに置き換えられている箇所があるため、要確認。
  14. © 2018 Ateam Inc. 20 Amazon Aurora MySQLにおけるレプリケーションの利⽤ AWS CloudWatchでのレプリケーション遅延の監視

    CloudWatchの「AuroraBinlogReplicaLag」というメトリクスで レプリケーション遅延 (いわゆる Seconds_Behind_Master) が、 CloudWatch上で計測できる。 似た名称の「AuroraReplicaLag」というメトリクスがあるが これはAWSのフルマネージド機能で作られたレプリカの話であり、 binlogベースのレプリケーション遅延ではない点に注意。
  15. © 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