分析基盤のコストを削減した話

2023.10.13 (Fri.) に開催されたハッカー鮨のLTです
https://hackermeshi.com/parties/457

Transcript

1. 分析基盤のコストを年間数百万削減した話 ハッカー鮨 update Oct 13, 2023
2. 渡邊 直登 Naoto Watanabe 取締役 CTO 兼 執行役員｜プロダクト開発部 部長 SIerにてエンジニア/ディレクターの経験後、事業会社で正社員向けサービスの開発 に携わる。その後、医療系の新規事業の立ち上げを経験を経て 2017年にマイベスト 入社。 現在は、業務委託を含めたエンジニアのマネジメント、マーケ・営業系施策の開発サ ポート、Enablingミッションのリード、データ分析基盤の運用を担当。 プロフィール
3. マイベストの分析基盤について Index 1 当時の状況について 2 どうやって解消したのか？ 3 これから 4
4. マイベストの分析基盤について ETL(trocco) + DWH(BigQuery) + BI(Redash / Looker) 画像
5. ETL(trocco) + DWH(BigQuery) + BI(Redash / Looker) マイベストの分析基盤について データ分析基盤構成
6. データソース・データウェアハウス・データマートに分類して処理 マイベストの分析基盤について データ基盤 データレイク （生データ） アクセスログ、イベントログ、購買データ etc データウェアハウス （分析元データ） URL x 日別クリックログ、URL x EC別収益ログ データマート （分析データ≒BIデータ） 直近30日のCVボタンクリックログ
7. すべての処理・フローはtroccoに集約 マイベストの分析基盤について データワークフロー
8. 分析用データマートは非エンジニアが作成 マイベストの分析基盤について BI
9. データレイク （生データ） エンジニアが作成 データウェアハウス （分析元データ） エンジニアが作成 データマート （分析データ≒BIデータ） 非エンジニアが作成 分析用データマートは非エンジニアが作成 マイベストの分析基盤について BI
10. 当時の状況について データ分析基盤が活用開始からコスト増まで 画像
11. 活用していたのはプロダクトを改善する部署に限定されており、金額も 1-3万程度 当時の状況について データ分析基盤は2021年から存在していた
12. データ分析基盤の積極的な活用が始まる 01 UA提供終了に伴う利用 ログの変更 02 データ活用部署の増 加 03 データ活用用途の 多様化
13. UA/GAは詳細分析の際にデータがサンプリングされてしまうので、 PrimeNumber社のWeb行動ログ収集SDKにリプレイス UA提供終了に伴う利用ログの変更 UAが7月で提供終了するタイミングでデータソースを生ログに変える
14. GAの分析画面が利用できなくなることもあり、各部署がデータ活用のためのダッシュボードを作成する データ活用部署の増加 色々なダッシュボードが爆誕する Lookerを本格活用 マーケティング部が各部のニーズをヒアリング し作成。中にはGA4のデータを活用したような 重めのダッシュボードも...
15. Lookerから発行されたSQLがBQのプロジェクト履歴に流れる データ活用用途の多様化 意図しないクエリが増える 不穏なクエリが大量に発行 “GA4のアクセスログすべて” とか ”指定期間 の生データ” みたいなクエリが1クエリで1テラバ イトを超えていた 1.2 TB 1.1 TB
16. すると...
17. コストが跳ね上がる... 本格活用前までは月 3万程度だった料金が 月55万程度まで増える
18. 利用してもらえることは良いこと
19. ただ、このままだとコストが原因で 本格稼働前に見直しが入りかねない...
20. どうやって解消したのか？ 可視化から仕組み化まで
21. 具体的なアプローチは3つ 01 可視化 02 権限・クエリ整理 03 アラート設定
22. ユーザー毎とクエリ毎で課金額を調査。そもそも原因が特定し辛い状況になっていることに気づく 可視化 ボトルネックとなるクエリを特定 原因が特定しづらかった理由 どのアカウントでクエリを発行しているのか？は わかったが、人が書いたものか or サービスが 発行したものかが分からなかったのでボトル ネックとなるクエリを見てもすぐに打ち手にはた どり着けなかった。
23. 用途に合わせてアカウントを調整 権限・クエリ整理 クエリ発行者を管理 アカウントはツールごとに Lookerで利用するアカウントは部のメーリング リスト。BigQueryで利用するアカウントは個人 のものと分けることで、発行クエリで人・用途の 判別がしやすくなった
24. 曖昧だったデータウェアハウス作成の定義を見直し。一部を汎用集計テーブルとして再定義 権限・クエリ整理 データ基盤を整備し、不要なデータウェアハウスを統合 汎用集計テーブルにすることで、一部データ ウェアハウスの参照するデータ量が大幅に削 減（ページビュー系：1.04 TB→20.36 GB、イベ ント系：183.9 GB→16.11 GB） 汎用集計テーブルを作成
25. 月額の利用想定から閾値を設定。日次で超えた場合には Slackに通知→クエリ発行者に確認のフローを作成 アラート設定 コストの閾値を決めアラートを設定 1. #trocco-alerts に通知がくる（通知例） 2. 前日のユーザー・クエリ単位での BQの利用状況を確認する 3. そのクエリが個人アカウントで発行されているものはスルー、メーリスで発行されているものは純増になるのでクエリを見 直す 通知例
26. その結果...
27. 大幅なコスト削減に成功！ 月 55万 月 7万
28. これでまたガンガン使えそう...！ めでたしめでたし
29. これから マイベストのデータ活用の未来 画像
30. データを活用した改善の 頻度と精度を上げたい 今は改善活動のための基盤ができただけの状態。 これからは、基盤を活用してプロダクト・コンテンツの改善をデータ観点から改善できるような体 制・環境を作り上げたい
31. マーケティング部が主体となり、データ活用の啓蒙や環境整備を実施 利用範囲が広がっています 部署を横断したデータ活用が動き始めています
32. オペレーションに利用している JIRA、kintoneなども連携または連携準備中 利用範囲が広がっています オペレーションもデータドリブンに改善できるように仕込み中
33. ABテスト改善、検索・マッチング精度改善、施策評価、効果試算などはまだまだ道半ば。データ活用には伸び代しかない！ 一方で... 精度の改善にはまだ多くの余地がある ABテスト自体をもっと信頼できるものに改善し ていきたい... アクションプランを立てるうえでインパクトを見積 もりたい... ユーザーのフィードバックを効果的に サービスに反映したい ... 施策の優先度をデータドリブンで判断できるよう になるといいな...
34. 分析基盤はデータベースを強みとする mybestのData Opsの中心。興味ある方はぜひ懇親会で話しましょう！ つまり データの蓄積から活用のフェーズに アクセス イベントログ 分析 順位 データ パーソナライズ プロダクト 検証 情報 改善 購買 データ 用途に応じたデータの活用 データの蓄積とルールの整備 これから これまで データ基盤
35. ご清聴ありがとうございました