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

段階的なシステムリプレースを実現するデータ同期技術
Ateam Tech Meetup Vol.9
株式会社エイチームフィナジー
テクニカルソリューション部 R&Dチーム
鈴⽊就⽃
GitHub @s2terminal
Twitter @suzukiterminal
Qiita @suzuki_sh

© 2018 Ateam Inc.
今回お話する対象サービス
◧ ⾦融メディア事業の中のいちWebメディア
◧ 2013年12⽉(約 5 年半前)ローンチ
◧ グループ最⼤規模の売上に成⻑
図: エイチームグループ
ライフスタイルサポート事業の売上規模推移

© 2018 Ateam Inc. 3画像の出典: https://unsplash.com/photos/O2MdroNurVw
運⽤を続けるうちに、システムが肥⼤化・複雑化
Webサイト上のコンテンツの ”正確な” 管理・更新が
問題となっていった

© 2018 Ateam Inc. 4画像の出典: https://pixabay.com/images/id-1743963/
複雑化した旧システムを刷新し
新しいシステムへ段階的な
リプレースを実現したい
社内向け管理画⾯とお客様向けのページでは
失敗時のリスクの重さが異なる
ページによっても広告出稿の
影響度の⼤⼩がある

© 2018 Ateam Inc. 5
システムリプレースの前提条件
新システムを機能毎に⼤きく3つのTier(段階)に分け
Tier内でもURL毎に影響度の⼤⼩で分割し、段階的にリプレースした。
旧システムはPHPで動いているが、新システムには
社内に技術的な資産の多いRuby on Railsへのリプレースを選択。
当然、RubyとPHPでは技術的に互換性は無いが、同時に稼働させる必要がある。
影響度の低い箇所から、段階的に移⾏したい
そのため、移⾏期間中は
新旧の両システムを同時に稼働させたい

リプレースの構成概要と
データ同期
画像の出典: https://pixabay.com/images/id-3246116/

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

ユーザ向け
ページ
社員向け
管理画⾯
MySQL
データベース
旧システム
ユーザ向け
ページ
社員向け
管理画⾯
新システム
データ同期
MySQL
データベース

新システムへのリプレース後の各データの扱い
マスタデータトランザクションデータ
旧システム Readのみ Read/Write両⽅可能
新システム Read/Write両⽅可能扱わない
今回のタイミングではマスタデータのみをリプレースし、
顧客申込情報などのトランザクションデータは
まだ新システムでは取り扱わない事にした。
￭今回のプロジェクトの⽬的はマスタデータの取り扱いの課題からであり、
トランザクションデータを扱うシステムのリプレースは必須ではなかった
￭移⾏先のシステムの仕様上、両者はシステム的に分離可能だった

マスタデータのみを新システムに持っていくと決めたが
依然として、新システムと旧システムとを同時に稼働させ、
段階的にリプレースする必要がある。
新旧システム間のDBスキーマの形式は、似ているものの
完全⼀致するわけではない。
段階的なリプレースを実現するには、新旧の異なるシステムで
同⼀のマスタデータを参照できるようにする必要がある。

データ同期を実現した
3つの技術
画像の出典: https://pixta.jp/photo/46119614

データ同期の技術
ユーザ向け
ページ
社員向け
管理画⾯
データベース
旧システム
ユーザ向け
ページ
社員向け
管理画⾯
データベース
新システム
②継続的な変更反映
①初期移⾏③変換

1: 旧システム→新システムへの初期データの移⾏
旧システムのデータを新システム⽤に変換する
スクリプトを開発
• 新システムをリリースする時に、1度だけ実⾏。
• 新システム側のモデルクラスとして扱うため、
新システム側にRubyプログラムとして実装。
• プログラムの中⾝は、旧システムのデータをSQLで取得し
新システム側のデータモデルとして保存するもの。

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

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

データ同期の技術
データベース
旧システム
データベース
新システム
②継続的な変更反映
①初期移⾏③変換
新旧システム間でのデータ同期が実現

Amazon Aurora MySQLでの
レプリケーションを利⽤した
データ同期
画像の出典: https://pixta.jp/illustration/50017474

Amazon Aurora MySQLにおけるレプリケーションの利⽤
今回のサービスは、DBにAmazon Aurora MySQLを利⽤
Auroraにbinlogベースのレプリケーションを⼿動で構築
AWS側にもフルマネージドのレプリケーション機能は存在しているが、
インスタンス毎の完全なレプリカ作成しかできない。
今回は、旧システムのデータベースインスタンス内に
新システムのテーブルを共存させる必要があったため、binlogで⼿動構築。
Amazon Aurora MySQL とは
AWSで提供されている、MySQLと互換性のあるマネージドのRDBMS
パフォーマンス、セキュリティ、可⽤性の⾼さが特徴

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専⽤のコマンドに置き換えられている箇所があるため、要確認。

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

初期移⾏スクリプトと、MySQLのReplication・Viewを使い
新システムのマスタデータを、旧システムでも利⽤可能に。
このデータ同期により、同⼀のマスタデータを取り扱う
新システムへの段階的な移⾏が実現した。
管理画⾯やユーザ向けページを影響度毎に切り分け
部分的に旧システムを稼働させたまま、
新システムに移⾏できた。
まとめ
画像の出典: https://unsplash.com/photos/ckfkPwCEMNs

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

「みんなで幸せになれる会社にすること」
「今から100年続く会社にすること」

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

Recomendados

Recomendados

Mais conteúdo relacionado

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

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

Mais de Shuto Suzuki

Mais de Shuto Suzuki (7)

Último

Último (11)

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