行動トラッキングデータベースリプレイスの道のり

http://www.techscore.com/blog/2019/01/15/replacing_behavior_tracking_database%F0%9F%90%AF/

Transcript

1. 行動トラッキング データベース リプレースの道のり シナジーマーケティング 馬場 彩子
2. アジェンダ • 行動トラッキング データベース リプレースの目的 • リプレース後のデータベース構成 • そこにいたる道のり • 教訓
3. 行動トラッキングデータベース リプレースの目的
4. 行動トラッキングデータベースとは • Synergy!(*1)の行動トラッキングデータを保存するデータベース • 行動トラッキングデータを利用している機能 ◦ レポート ◦ 行動ターゲティングによるメッセージ配信 *1 Synergy! ： TECHSCORE運営会社のシナジーマーケティング が運用しているCRMクラウドサービス
5. 行動トラッキングデータベース リプレースの動機 • 行動トラッキング対象の変化 メールクリック・アプリプッシュ開封などのメッセージ配信系の行動か らWebパーツ閲覧などのWeb系行動へ • データ量の急増 • データの性質の変化によりパフォーマンスが劣化 → レポート・行動ターゲティング配信の両機能をストレスなく提供する
6. リプレース前のテーブルの状況 • Postgresql に格納 • データは全アカウント同じテーブルに格納 • 重複した情報を1行に保持 • 週次でテーブルをパーティショニング
7. 課題はなにか • レポート表示のための集計が遅い • 行動ターゲティングのための問い合わせが遅い
8. リプレースの目的は何か • 「大量データ」を「高速にさばく」トラッキングデータベースをつくる ◦ レポート表示のための集計処理が速い ◦ 行動ターゲティングのための問い合わせが速い
9. リプレースの手段 • 利用用途ごとに最適なテーブル設計を採用する • トラッキングデータを利用する機能の精査を行い、参照頻度が少な い過去データを移行する
10. 忘れてはいけない大事な点 • データベースリプレースに際して、データの損失・ダウンタイムは許 されない • 既存のサービスを動かしながら、裏側でデータベースを切り替える 必要がある
11. リプレース後のデータベース構成
12. リプレースの方向性 • フェーズ1 : 暫定対応 アプリケーションを変更せずにデータベース移設 • フェーズ2：恒久対応 テーブルの構成をベストに変更・アプリケーションも変更 • いずれも2段階で無停止リプレース a. データを新旧両方のテーブルに登録 b. 参照系アプリの切り替え
13. データベース構成概要（Before） Postgresql Old App Old Log Parser
14. データベース構成概要（暫定対応移行期） Postgresql Old App Old Log Parser Old Tables Postgresql New
15. データベース構成概要（暫定対応After） Postgresql Old App Old Log Parser Postgresql New Old Tables
16. データベース構成概要（恒久対応移行期） App Old Log Parser Postgresql New Old Tables New Tables
17. Postgresql New データベース構成概要（恒久対応After） Log Parser New Tables App New
18. テーブル構成概要 • 行動トラッキング用のテーブルの再構築 ◦ クライアントごと・行動種類ごとのテーブル ◦ 月次でパーティショニング • レポート参照用のテーブルを新設
19. テーブルを用途ごとに分割した理由 • アクセスパターンが違う 行動ターゲティングではIDを指定して条件に合致する行動がある かみる / レポートでは一定期間のユニーク行動者数などをみる → 各クエリに最適なテーブル構成 / インデックス設計 • IOがボトルネック 必要な項目が違う。不要な項目の取得が多くIOを圧迫 → 必要な情報のみ取得できるようテーブルを分割
20. リプレースの道のり
21. ２０１７年６月 • ２０１５年稼働のシステム。パフォーマンス課題が顕在化 • Webパーツ機能リリース ◦ レポート表示のためのクエリが遅く表示前にブラウザタイムア ウト ◦ 「ほぼ障害」（→ アプリ改修でのりきる） • リターゲティングメール配信遅延 ◦ 探索条件が特別な場合、配信開始に1時間かかる場合も
22. ２０１７年７月 ー９月 （暫定対応） • 方針「アプリ改修せず、半年もつDBに」 • 方式検討 ◦ 改修後のシステムと移行方式、両方の検討が必要 ◦ テクニカルエキスパート 2名が素案作成 ◦ パフォーマンス検証と移行リハーサルを繰り返す • 方式決定 ◦ パーティション変更 / 現状と同じビューを用意 / insert trigger ◦ 直近 データは fdw による double insert 、過去データはRedshift 経由の移行 によりテーブル構成を変換しながら copy
23. ２０１７年１０月 • 1ヶ月かけて、過去データ移行 • 深夜作業で最終同期と切り替えを実施
24. ２０１７年１１−１２月 • PVが多いサイトにトラッキングタグが設置され、行動トラッキング データの流量が３倍に • アプリケーションの変更も視野にいれて「３年もつシステム」に • 技術検討開始 http://d.hatena.ne.jp/yohei-a/20170910/1505060875 Lamda ? Kappa ？ Redshift ? Athena? • 方式決定：RDS + 仕様変更
25. ２０１８年１月ー６月 • プロダクト企画チームに閉鎖する機能の利用状況説明、営業調整 を依頼 • データ移行開始 • 各チームにアプリ改修依頼 設計方針とマイルストーンの共有 • 実装 • 機能テストおよびパフォーマンステスト • アプリ切り替え
26. そして今にいたる • とてもはやくなった • 機能一部閉鎖による問い合わせ、（おそらく）ゼロ
27. 教訓
28. 範囲を絞る • 汎用性と無能は表裏一体。どんな利用方法にも対応できるDBが いつしか、どの問い合わせにも許容できないほど反応が遅いDBに • 未来はわからない。将来のために作り込んだ機能が、現状の拡張 やパフォーマンスの邪魔をする • 10年20年運用し続けたいなら、2-3 年ごとにシステムを更新する 覚悟をもち、「3年後まで現機能が元気に動くシステムを素早くリ リース」することにフォーカスする
29. 技術力は行動の源泉 • 自信があるから変えようと行動できる 「サービス止めずに2テラのデータベース移設する」一歩をふみだ せるか • 自信を形作るもの＝技術力 • 技術力は知識とその応用力 • 武器を増やす。たとえ今使わなくても
30. 実際に手を動かす • 動かしてみると初めてわかること 大規模のシステムではチュートリアルにあるようなシンプルな方法 だとシステム要件満たさない マニュアルに書いてあっても見過ごす細かい仕様が設計を左右す る（fdw の トランザクションレベルとか） • 新技術採用などの設計時から実際の稼働に近い形で検証すること で骨や肉になる知見が得られる ◦ AWS RDS の スナップショットの利用が可能だったのは楽だった ◦ リプレースだと非機能要件の見積もりが（比較的）容易
31. プロジェクト全体を俯瞰する • マイクロサービス構成に合わせた機能ごとのチーム編成になった ため、横断的にもれなく矛盾なくサービスを構成することが難しく なっていることを自覚する • 取り組み１： 全体の設計は1チーム・各機能の実現方法は各チームに任せる • 取り組み２： 結合のタイミングをめちゃくちゃ早く設定 → 最終リリース日時を変更することなく、テーブル設計の変更をす ることができた
32. 解決方法は技術以外にもある • 当初は現行仕様を一切変更せずに実現する方法を考えていた • ただしリソースは有限 ◦ Lambda Architecture などは実装コスト高い ◦ トラッキングデータを無期限で保存するのは運用コスト高い ◦ それで実現できるのが「３年前のメールクリック行動でターゲティング可能」 ◦ 仕様の矛盾なども • その機能・サービスは必要か？ ◦ 実装しない ≠ 力不足、負け ◦ この機能を維持するリソースで、他の価値あるものができないか？
33. このプレゼンテンプレがすばらしい • 「目的」「システム構成」「流れ」「教訓」とプロジェクトで得た知見を 網羅できる • みんな、やったらいいよ • もちろん内容もすばらしいのでみて*1 ZOZOTOWN システムリプレイスの道のり https://speakerdeck.com/labor/zozotown-geng-huan-yun-xi-ton g-zhi-dao *1 現在は公開されていません
34. おしまい