2018に参加してきました。今回は事例を中心にセミナーを聞いてきました。スタジオ様によるモンスターストライクのデータ分析基盤についてレポートいたします。解析チームデータエンジニアスマホアプリ「モンスターストライク」の世界累計利用者数は先日4,500万人を超えました。各種サービスをフル活用して構築されています。本セッションでは、弊社のデータ分析基盤の構成をご紹介します。リアルタイム集計の構成についてもご紹介します。セッション一覧さて、モンスターストライクといえば誰もが知っているソーシャルゲームの超ビッグタイトルです。リリースから5年が経ち、ユーザー数は4,500万人と国内最大規模です。ソーシャルゲームの運営にはデータ分析が欠かせないと言われますが、これだけ大規模なタイトルになるといったいどんなスゴイ分析基盤を使っているのでしょうか。セミナーを聴く前からワクワクしていました。分析規模まず、分析対象データと分析担当者の規模ですが、データは毎日2TBのペースで増え続けていて、ストックされている総データは1PBにも及ぶそうです。分析専任担当者は5人で、それ以外にサービスの運営スタッフの方、200人超も分析を行います。AWSで主に使っている技術はEMRRedshiftです。課題と解決アプローチセミナーの骨子は、基盤の運用において6つの課題が発生したことと、それに対する解決方法の説明でした。課題1:EMRの起動が遅い起動に30分以上かかっていたそうです。解決1:EMRはクラスタを終了させるとメタストアにあるテーブル定義情報も一緒に失われてしまうことになります。クラスタを起動するたびに毎回テーブルやパーティションの作成を行っていたために時間が掛かっていたと思われます。Hiveメタストアの再構築などを行うことで、30分から5分に短縮できました。課題2:Hiveが遅いバッチ処理に15時間かかっていたそうです。Hive以外の選択もあるものの、Hiveメタストアの便利さなどのメリットを踏まえると他は考えにくい、という事情がありました。解決2:以下の3つの実施した結果、9時間に短縮できました。巨大なアプリケーションログを繰り返しスキャンしていたのを適当なサイズに分解したり、ソートしてインデックスをつけるなど。課題3:バッチ処理の運用が困難300にも及ぶタスクが相互に依存しており、運用が難しかったそうです。解決3:独自のジョブフロー管理ツールを内製し、タスクの並列実行を可能にしました。その結果、バッチ処理が大幅に短縮し、安定運用できるようになりました。課題4:エンジニアしかデータに触れられないログデータにアクセスするには、分析環境にSSH接続する必要があり、非エンジニアにとってはハードルが高かったそうです。内製ダッシュボードなどのBIツールを導入し、非エンジニアでもデータアクセスできるようにしました。metabeseですが、用途に応じて細かく使い分けているそうです。集計クエリの複雑さに困っていらっしゃったそうです。例としてマルチプレイをしたユーザーに関する集計の大変さが紹介されました。解決5:分析テーブルを構築(例:is_multiというカラムを追加)ディメンショナル・モデリングに従ってテーブルを再設計した結果として、分析のスピードアップや柔軟性向上が得られました。課題6:データの信頼性の問題ログの遅延・欠損SQLの書きミスHiveのバグなどに困らされたそうです。解決6:事前のテストは困難なので、データの事後検証を徹底するようにしました。変換前後の比較NULLカラムが無いかチェックなどを行うようにしたそうです。全サービスを横断して分析する仕組み基本的にサービス毎の分析の仕組みになっていますが、複数サービスを比べて得られる知見もあるし、新サービス立ち上げ時に他サービスとの比較を行う価値も高い。誰にどのデータをどこまで見せるのかをコントロールしつつ、業務に影響が出ないようにする必要があります。機械学習、AIのための基盤づくりデータ分析基盤の発展になるのか、新たな基盤にするのか。後者の場合どのように連携するのかなど検討項目は多そうです。まとめソーシャルゲームの超ビッグタイトルなので、どんな魔法のような分析を行っていらっしゃるのかと勝手に想像していましたが、実は基本に忠実で、一つ一つの課題を着実に解決することでパフォーマンスを向上されてきた、というお話でした。凡事徹底が肝心ですね。