Mirrativを支えるシンプルで堅牢な分析基盤

「複雑さに呑まれないデータ基盤：規模・コスト・運用で見極める“ちょうど良い”設計」（https://findy-tools.connpass.com/event/370964/）の登壇資料です。内容は2025年10月24日（発表当時）のものです。

Transcript

1. 2025-10-24 芝尾幸一郎 @shibacow Mirrativを支えるシンプル で堅牢な分析基盤
2. 自己紹介 • 2005年オンラインゲームサーバサイドエンジニ アとしてキャリアをスタート • 複数の会社で、データ分析基盤構築に関わる • 特にGCPなかでもBigQueryについては初期から 触っている。 • 執筆した。ゲーム開発が変わる！Google Cloud Platform 実践インフラ構築 2 芝尾幸一郎 ミラティブ事業本部データ分析チーム データ分析基盤担当
4. 4 データ分析基盤紹介
5. 5 分析基盤の特徴
6. 6 シンプルで堅牢
7. 2020年以降 大きなトラブルなし 7
8. 分析基盤図 8
9. 9 特徴 - シンプルな構成 - 本番環境との分離 - 冪等性
10. 10 個別紹介
11. 11 データ入力部 行動 ログ DB
12. 12 データ入力部 データベース(状態データ) embulkを使って本番 環境DBから分析基盤BQ上にデータをロード 行動ログ - fluentdを利用して、本番環境のログ を分析基盤BQ上の行動ログ日別テーブルに格納
13. 13 入力部-落とし穴と工夫
14. 14 本番環境とは分離(VPCPeering) 本番環境DB 本番環境 分析基盤 分析基盤BQ ネットワーク分離 GCP VPC Peering 本番環境と分析環境でネット ワーク的には分離。 本番環境データベースに特定 の環境・ポートからしかアク セス出来ないようにする。
15. ネットワーク分離により分析基盤にクラッカーが侵入しても本番環境には悪さは出 来ない。 分析基盤環境で何らかの不具合が発生しても本番環境に悪影響を与えない。 ネットワーク的に分離することで本番環境への悪影響を最小限に保つ。 15 本番環境接続とVPC Peering
16. 落とし穴: 分析基盤のembulkで集計に時間がかかるSQLを実行した際に、本番環 境接続VPC Peeringで無通信と判断され、本番環境とのリンク切断(その当時は、 600秒で切断された)。 解決方法: OS レイヤーで、keepaliveの設定は 7200秒から60秒に変更 embulkのjdbcパラメーターで、tcpKeepAlive:trueを設定。定期的にパケットを 送信してリンク切断を防ぐ。 16 VPC Peeringの落とし穴 一定時間無通信で接続切れる
17. 17 行動ログ-行動種別でテーブル分離
18. 18 [問題]日付テーブルに行動ログを格納-その後分配 行動ログ_YYYYMMDD 視聴 配信 コメント 着替え 行動種別で振り分け
19. 行動種別振り分け。SQLを使うと行動種別ごとに select insert しかし、この手法は、テーブルごとに行わねばならず非効率。 解決 GCP dataflowを使う。 BigQueryのテーブルから、行動種別ごとにテーブルを動的に選んでデータを格納 できる。 19 [解決]効率的な行動種別振り分け
20. 20 [解決]効率的な行動種別振り分け 行動ログ_YYYYMMDD 視聴 配信 コメント 着替え 行動種別で動的に振 り分け DataflowのBigQuery TableDestinationで動的に テーブルにインサートでき る
21. 本番のテーブルで知らない間にスキーマが増えている。 知らない間に、新しいフィールドが追加される。 事前に、分析チームに情報を共有してと言っても忙して実行できない。 embulkで select * from hoge とクエリーを設定していると、分析基板上のテー ブルと本番テーブルでスキーマが異なりロードエラーになる。 21 [問題]本番テーブルで知らない間にスキーマが変わる
22. 22 [解決]本番テーブルスキーマ変更検知チェッカー 本番テーブルでスキーマが追加され たときに、スキーマ変更を検知して アラートを出すプログラムを書いた。 人力で情報を共有しようとすると取 りこぼすので、システム化したほう が良い
23. 23 集計部
24. 24 集計部
25. 集計部とは、行動ログとデータベースから意味のある単位にデータをサマライズす ること（データウェアハウス） 例えば１配信単位や１視聴単位ギフト送信に対する属性情報の付与など分析者が分 析しやすい粒度に情報を集約する。 深夜バッチで前日のデータを集計(始業までに集計が終わる必要あり) 25 集計部の特徴
26. 26 工夫
27. 27 データウェアハウステーブル作成は冪等性を保つ データウェアハウステーブルは集計に失敗しても誰でも再実行できるように冪 等性を保っている。集計結果のレコードサイズが小さい場合には、全部洗替。 大きい場合には、前日分のみを上書き。 何回実行しても、同じテーブル全体としては同じ件数になるように作成した。 DigDag上でRUNボタンを 押せばOK
28. 安全なリトライ処理の実現 バッチ処理には、エラーがつきもの。エラーがあった際には、リトライを行うこと になる。冪等性が守られるように作っておけば、何度でも安全にリトライできる。 データパイプラインの復旧の容易さ 中間テーブル作成全体で、冪等性と保っていれば、エラーが発生したステップ以降 を再試行すれば良いので、データパイプラインの復旧が容易になる。 28 冪等性はなぜ大事か
29. 29 分析可視化部
30. 30 分析・可視化部
31. 31 落とし穴と工夫
32. 32 [問題]redashでエラー Redashで意味不明のエラー
33. 33 [解決] Chromeの自動翻訳ONだと前記のエラーが出ることがある。
34. Redashには検索が付いているが、なかなかマッチしな い。 queryの中身をうまく検索できない。クエリーにあるコ メントなども検索できない。タイトルは検索できるが、 クエリーの中身は検索できないという指摘がある。 34 [問題]Redashの検索が使いづらい
35. 35 [解決]Redashの全クエリを定期的にBQに格納 BigQuery APIでRedashの全クエリ ーを取得 Redahのクエリー検索は使 わずに、BigQueryでクエリ ーを全文検索。 クエリーで使ったテーブル やコメント、タイトル説明 文など何でもマッチさせる
36. 36 分析基盤運用
37. 37 分析基盤担当者の悩み 少人数運用（1-2名）
38. アラートに気付けない。特に深夜にバッチが実行 されるので、就寝中にアラートに気づきたい。 38 [問題]分析基盤担当者の悩み
39. 39 解決-アラート通知システム（注意音が出ます） 天 国 と 地 獄 . mp4 slackの分析基盤アラートチャン ネルを監視して、アラートが出 たら、枕元で音楽がなる仕組み を作る。 寝てても気づくことができる。
40. 40 スイッチサイエンス M5 Atom ECHO 電子工作で使われるモジュール。 ネットワーク接続が出来て、小型の スピーカーが付いているので寝室に おいても邪魔になりません。
41. 41 アラートシステムの仕組み 分析基盤のアラートが流れるslackチャンネルを 監視して、アラートが上がれば、天国と地獄が流 れる。
42. 42 今後の注力事例
43. 43 今後の注力事例 非構造化データの活用 - 分析基盤に格納された動画、音声、サムネイル、コメントなどを分析に活用し、 ユーザー解像度を上げる 生成AIの活用 - 分析において生成AIの活用を推進する
44. ご興味を持ってくださった方は、お気軽にご連絡ください！ 44 さいごに-We are hiring! ミラティブ採用サイト