©MIXI 「モンスターストライク」の運営を ⽀えるデータ分析基盤の歴史と進化 株式会社MIXI デジタルエンターテインメントオペレーションズ本部 事業戦略部 解析グループ 渡辺⼤貴（taiki.watanabe）

2 ©MIXI 1. データ分析基盤の歴史と進化 a. データ分析基盤の変遷 b. 2024年の課題とアップデート 2. 2024年の取り組み データ品質担保プロジェクト a. データ品質⼊⾨ b. Dataplex ⼊⾨編 c. Dataplex データ品質 運⽤編 Agenda

3 ©MIXI 2020年に新卒で株式会社ミクシィ（現 株式会社MIXI）に⼊社。 以来、データエンジニアとして、スマホゲームアプリ「モンスターストライク」 の運営を⽀えるデータ分析基盤の開発および保守‧運⽤に従事。 渡辺 ⼤貴（Taiki Watanabe） 株式会社MIXI デジタルエンターテインメントオペレーションズ本部 事業戦略部 解析グループ ⾃⼰紹介

4 ©MIXI 誰でも簡単に楽しめる爽快アクションRPG。 ⼀緒にいる友だちと最⼤4⼈まで同時に遊べる 協⼒プレイ（マルチプレイ）が特徴です。 モンスターストライクについて

©MIXI 「モンスターストライク」の運営を ⽀えるデータ分析基盤の歴史と進化

6 ©MIXI 1. 「モンスターストライク」の運営をデータで⽀える組織 a. 「コトダマン」のデータ分析基盤、「モンソニ! 」の分析基盤構築‧分析も担当 2. 解析チーム（データエンジニアチーム） a. データ分析基盤の構築‧運⽤（BigQuery、内製ワークフローエンジンなど） b. 新規施策分析のためのデータ取得、データマート構築、Looker保守運⽤ 3. 分析チーム（データアナリストチーム） a. 施策の振り返り、KPI分析、次期施策の意思決定⽀援 b. 分析のためのデータマート構築、Looker保守運⽤ 解析グループについて

7 ©MIXI 1. 施策振り返り‧次期施策意思決定⽀援のためのデータ分析 2. KPI 可視化 3. CS（カスタマーサポート）対応のためのデータ調査 4. 補填対応のための事実調査 5. ゲームへのリバースETL データ分析基盤の役割

8 ©MIXI リリース当初（2013年〜2014年）   最初は⼀⼈。スクリプトで集計。 データレイク時代（2014年〜）   ⼈⼒では限界になりデータ分析基盤が必要に。   Amazon EMR Hiveによるデータ加⼯パイプライン、内製ワークフローエンジンの導⼊。 AWS データウェアハウス時代（2015年〜2021年）   よりアジリティが⾼い集計‧分析へ向けて。   Amazon Redshiftの導⼊。 Google BigQuery移⾏（2020年〜）   インフラ管理コストの削減、データガバナンス（権限管理など）の強化など。   データウェアハウスをRedshiftからBigQueryへ移⾏。 データ分析基盤の歴史

9 ©MIXI 「モンスターストライク」のデータ分析基盤（2014〜2020） Amazon Web Services オンプレ App Server Load Balancer ログ収集 エージェント Database ログデータ S3 スナップショット S3 データ加工 EMR, Athena データレイク S3 1. Hiveで⽣データの加⼯、データマート構築 2. データのクエリはRedshiftが中⼼ 3. BIツールは適材適所で併⽤ データマート Redshift BI tools Redash Metabase Zeppelin 内製

10 ©MIXI Google Cloud 「モンスターストライク」のデータ分析基盤（2021年） Amazon Web Services ログデータ S3 スナップショット S3 データ加工 EMR, Athena データレイク S3 1. データのクエリはBigQuery中⼼ 2. ⽣データの加⼯や⼀部データマートの構築はまだHive 3. BIツールはLookerで統⼀ a. 参考 : 【MIXI TECH CONFERENCE 2023】データ⺠主化を推進するモンストでのLooker導⼊ データレイク Cloud Storage データマート BigQuery データマート BigQuery BI tools ダッシュボード Looker Storage Transfer Service オンプレ App Server Load Balancer ログ収集 エージェント Database

11 ©MIXI Google Cloud 「モンスターストライク」のデータ分析基盤（2024年） スナップショット S3 Amazon Web Services ログデータ S3 データ加工 EMR, Athena データレイク S3 1. Hiveで構築していたデータマート、ログデータELTのBigQuery移⾏が完全完了 2. スナップショットの加⼯（カラムナフォーマットへの変換）のみがAWSへ残る形へ データレイク Cloud Storage データマート BigQuery データマート BigQuery BI tools ダッシュボード Looker オンプレ App Server Storage Transfer Service Load Balancer ログ収集 エージェント Database ログデータ Cloud Storage スナップショット S3

12 ©MIXI Google Cloud 「モンスターストライク」のデータ分析基盤（未来?） 1. 2024年現在スナップショットELT基盤のBigQuery移⾏は並⾏稼働段階へ 2. 管理コストを下げつつ必要なデータを素早く提供できるデータ基盤を⽬指して データマート BigQuery データマート BigQuery BI tools ダッシュボード Looker オンプレ App Server Load Balancer ログ収集 エージェント Database Pub/Sub? Dataflow? 2024年 BigQueryを中⼼としたスナップショットELT基盤 （並⾏稼働段階） 2024年 ログ収集エージェントのクラウド移⾏（設計段階）

13 ©MIXI 1. スナップショットデータの加⼯基盤がまだAWS EMR Hive   データとインフラをAWS/Google Cloudで2重管理している   データ転送待ち時間によるラグ、データ転送コストの発⽣ 2. 内製ワークフローエンジンの⽼朽化   2014年(?)当時から動いているRuby製内製ワークフローエンジンを保守‧改修しながら運⽤   DAGに含まれるタスク数は1000+   安定して稼働はできているものの保守コストは年々増加 3. データ品質周りの課題   次のスライドへ データ分析基盤の課題 2024年

14 ©MIXI 1.「いつの間にかデータが壊れていた」に気が付きたい   利⽤者（ビジネスユーザー）のエスカレーションで気がつく   データ基盤移⾏や上流データソースの仕様変更などの作業に巻き込まれて壊れる 2. 分析時のデータ確認⼯数を削減したい   おかしなデータが含まれていないかを確認するところから分析がスタートする   分析のアジリティを向上させるために分析以外の雑務を減らしたい データ品質周りの課題 2024年 Dataplexでデータ品質周りの課題解決を試みた話 後半のお話

©MIXI データ品質担保の取り組み

16 ©MIXI 1. 誤ったデータは誤った意思決定につながる 2. 売上データは会社のP/Lへも直結 3. CS対応‧補填対応‧ゲームへのリバースETLへも影響 なぜデータ品質が重要か？

17 ©MIXI 正確性 Accuracy   収集したデータは事実として正しいか？ 重複した数値はないか？ 数値は正確か？ 完全性 Completeness   レコードは完全か？ すべての必須項⽬に有効な値が得られているか？ 適時性 Timeliness   レコードは期限内に得られたか？ データ品質の定義 by 『Data Governance: The Definitive Guide』 データが⽋損なく、誤りなく、最新である Excerpt From データエンジニアリングの基礎 2.2.2.5 データ品質

©MIXI Dataplex データ品質 ⼊⾨編

©MIXI Dataplexを知っている 会場アンケート

©MIXI Dataplexを使ったことがある 会場アンケート

21 ©MIXI Dataplexとは データガバナンスをいい感じにするためのGoogle Cloudのサービス

22 ©MIXI Dataplexとは データカタログ プロファイル・データ品質 レイクハウス データカタログ、データプロファイル、データ品質など その他、BigQueryに統合されたデータリネージなどもDataplexの機能

23 ©MIXI 1. テーブルの統計情報をプロファイリングしてくれるサービス a. 各カラムのmin/max/avg等の統計情報 b. NULLが含まれる割合、ユニークかどうか 2. BigQueryに統合されている Dataplexとは Data Profiling Data Quality 1. データ品質をテスト‧可視化してくれるサービス a. Auto data quality（マネージド）とData Quality Task（OSSベース）の2種が存在 b. 後者はレガシー。元々前者は機能不⾜だったらしいが2024年末現在はだいぶやれることが増えてきた c. OSS: GoogleCloudPlatform/cloud-data-quality ; Python+dbt 2. Data Profilingの結果を元にテストを⾃動⽣成してくれる機能も存在 3. こちらもBigQueryに統合されている

24 ©MIXI Dataplex Data Profiling ここから実⾏できます デフォルトで10%サンプリ ングしてスキャン

25 ©MIXI Dataplex Data Profiling

26 ©MIXI Dataplex Data Profiling 分析例: LONG TERMに移⾏ したパーティション は全体の91% カラム名（例:storage_tier） Null percentage Unique percentage Min/Max/Avg

27 ©MIXI Dataplex Data Quality ここから実⾏できます

28 ©MIXI Dataplex Data Quality ルール(test)⼀覧 テーブル⼀つに対して 複数のルール(test)

29 ©MIXI Dataplex Data Qualityで扱えるテストの種類 組み込みルール   列（カラム）の⼀意性、NULL チェック、正規表現‧セット（IN演算⼦）によるチェック   条件を満たす⾏（レコード）がn%でpass カスタムSQL ⾏の条件   任意のWHERE句に書ける   条件を満たす⾏（レコード）がn%でpass カスタムSQL テーブルの条件   集計関数を実⾏した結果をテスト   サブクエリで他テーブルへのアクセス可能 SQLアサーション   SQL⽂全体を書ける BigQuery MLモデルを呼び出すことで異常値検知テストも可能 ¡POINT!

30 ©MIXI Why Dataplex? その他選択肢 1. dbt unit test 2. 内製ワークフローエンジンでのテスト Dataplexを選んだ理由 1. フルマネージドサービスである a. Schedulerも内包しており管理するインフラがない 2. エコシステムとドキュメントが充実している a. テストをデプロイするためのTerraform Moduleが存在している b. テストの書き⽅がGoogle Cloudの公式ドキュメントに載っている 3. APIが充実している 4. BigQueryコンソールと統合されている a. BigQueryコンソールをデータカタログとして使うためにスキーマ情報（description）を充実化していた b. データ品質の結果もコンソールから⾒れると必要な情報が⼀箇所にまとまって良さそう 決め⼿

©MIXI Dataplex データ品質 運⽤編 運⽤フロー 開発フロー 実装 テスト 料⾦

32 ©MIXI 実装 1. 毎⽇正午にデータ品質テストを実⾏ 2. もしテストが落ちていたらSlack通知 3. そのままLookerダッシュボードで落ちたテスト の詳細確認 運⽤フロー テストが落ちたときのSlack通知 1. テストの定期実⾏は内包のスケジューラーで 2. テスト実⾏結果はBigQueryテーブルへ書き出し 3. BigQueryテーブルをLookerで可視化 4. Lookerダッシュボードのアラート機能でしきい値 を決めてアラート failedしたテストの詳細

33 ©MIXI 運⽤フロー 1. テストの結果を⾒てデータに異常があれば調査‧修正 2. テストが悪ければテストを修正 3. ⼿動運⽤を促すテストを書いたりもする a. 新しい商品が追加されたからレポートにも反映してね、みたいな ルールに違反している レコードを洗い出す クエリ（SQL） テスト対象 テストの中⾝ 結果

34 ©MIXI 1. GitHubでテストを定義したYAMLファイルを⼀つ追加するだけ 開発フロー

35 ©MIXI 1. ..yamlでPRすると、そのテーブルを対象に毎⽇テストが 実⾏されるように 2. Terraformでテストをデプロイ。CIとしてPRすると terraform plan、マージでデプロイ 3. https://github.com/GoogleCloudPlatform/terraform-google-dataplex-auto-data-quality を参考に独⾃カスタマイズ。 a. テストのデプロイ⾃体はTerraform Google Providerにリソース定義がある b. 上記ModuleではYAMLで書かれたテストをTerraformのリソース定義へ変換するロジックを持つ c. 独⾃でSchedulingやSampling, Incrementalの設定もYAMLでできるように拡張 d. 独⾃で対象データセットとテーブル名をファイル名へ埋め込むロジックも実装 e. 詳しくは、Terraform を使⽤してデータ品質ルールをコードとして管理する | Dataplex | Google Cloud 開発フロー②

36 ©MIXI 1. テーブルの存在チェック‧最新パーティションにレコードが0件以上存在するか a. INFORMATION_SCHEMA.PARTITIONSメタデータを利⽤ b. 直接テーブルをスキャンしないので低コストでのテストが実⾏可能 c. 200件以上のテーブルの適時性 Timelinessを担保 2. 各カラムがNULLではない、UNIQUEである a. Data Profilingの結果から100テーブルほどのテーブルに対するテストを⾃動⽣成 b. GitHub Copilotで⽣成されたルールを命名。⼈⼒で不要なテストを削除してPR c. 完全性 Completenessを担保 実装済みのテスト TODO 1. ドメインに寄り添ったデータの正確性 Accuracyの担保する 2. 眠っているデータの闇 “data downtime” を洗い出して修正する 3. データ品質テストの結果をBigQueryコンソールから⾒れるようにする a. API経由で実⾏した場合そのままではコンソールから⾒れない。結果のPublishが必要

37 ©MIXI 1. Data Profiling / Data Quality どちらも同じ料⾦体系 2. $0.114 per DCU-hr ※2024年12⽉10⽇時点. asia-northeast1 a. > DCU 時間の使⽤量は、データのプロファイリングとデータ品質指標の計算に必要な処理に⽐例します。こ れは 1 秒ごとに課⾦されます。 3. しっかりSampling/Incremental scanすれば$10/dayはいかないくらい a. 料⾦はデータ量に依存するため でもお⾼いんでしょう？

38 ©MIXI でもお⾼いんでしょう？ ⻘: GCS ストレージ料⾦ ⾚: BQ ストレージ料⾦ その他コンピュート等 （BigQueryを除く） もしもフルスキャンしてしまったら...

39 ©MIXI でもお⾼いんでしょう？ ⻘: GCS ストレージ料⾦ ⾚: BQ ストレージ料⾦ ⻩: Dataplex ?!????????? その他コンピュート等 （BigQueryを除く）

40 ©MIXI 1. Dataplexの1⽇あたりの料⾦がヤバいことに 2. 原因はData Profilingを激重テーブルも含めてフルスキャンしてしまったこと 3. なぜおきたか: サンプリングされていると勘違い & 料⾦を勘違い a. コンソールではデフォルトで10%サンプリング。API, gcloudコマンド経由の操作ではデフォルトでフルス キャン。 b. 2024年末時点において、DSUを知る術がない（実⾏時間はログからわかるが、裏側で消費されたDSUがわか らない。Google CloudのCEさんへフィードバック済み） 4. ※激重Data Profilingの結果は漏れなくData Qualityテストの⾃動⽣成に活⽤しました 2024年のやらかし

41 ©MIXI 1. 「いつの間にかデータが壊れていた」に気が付きたい 2. 分析時のデータ確認⼯数を削減したい データ品質担保の取り組み まとめ 解析Tの課題 1. Dataplex Data Qualityで定期テストする仕組みを導⼊ 2. テーブル200+件の適時性 Timelinessとテーブル27件の完全性 Completenessを テスト‧可視化‧アラート 2024年の取り組み 1. データの鮮度‧⽋損に気がつけるようになり、誤った古いデータで意思決定するリスクは減った 2. まだ分析業務の⼯数削減にはつながっていない点が今後の課題 創出した価値と今後の課題

42 ©MIXI 1. 「モンスターストライク」の運営を⽀えるデータ分析基盤の歴史と進化を紹介 セッションまとめ 概要 1. データの流れを最適化するための脱クロスクラウド化を進⾏中 2. データ基盤移⾏に伴うデータ品質の低下を防ぐための仕組みを導⼊した 2024年の取り組み 1. Data ingestionも含めたデータの流れの最適化 2. ワークフローエンジン移⾏（Dagster, Composer3 etc） 3. データ品質テスト充実化も含めたデータ‧インフラ監視周りの強化 今後の課題

©MIXI We’re hiring！ データエンジニア/データアナリスト募集中！

©MIXI