[レポート] 【ミクシィXFLAG スタジオ様ご登壇事例】モンスターストライクを支えるデータ分析基盤と準リアルタイム集計システム #AWSSummit

本日 5/30 から 6/1 まで、東京・品川で開催されています AWS Summit Tokyo 2018。こちらで講演されたセッション「【ミクシィXFLAG スタジオ様ご登壇事例】モンスターストライクを支えるデータ分析基盤と準リアルタイム集計システム」を聴講しましたのでレポートします。

今回のAWS Summitでは全セッションで撮影が禁止されているため、文字だけでお届けします。

概要

スマホアプリ「モンスターストライク」の世界累計利用者数は先日4,500万人を超えました。このサービスのデータ分析基盤は、Amazon Redshift や Amazon EMR をはじめとした AWS の各種サービスをフル活用して構築されています。本セッションでは、弊社のデータ分析基盤の構成をご紹介します。また、各種キャンペーンで活用されている リアルタイム集計の構成についてもご紹介します。

スピーカー

• 株式会社ミクシィXFLAG スタジオ モンスト事業本部 ゲーム運営部 解析グループ 解析チームデータエンジニア
  • 生島 光（おじまひかる）

（※敬称略）

レポート

モンストとは

リリースから5年経ち、ユーザーも4500万人を突破。現在は各種ダッシュボードを活用して運用している。

• 分析する人たち
  • データ分析の専任チームは5人
  • 各サービスの運営に関わるスタッフ（200+人）
• データ量
  • 2TB/day
  • 1PB total
• 活用技術
  • EMRとRedshift

アジェンダ

• データ分析基盤
  • 基盤運用の課題
  • データ活用の課題
• 準リアルタム集計
  • XFLAGスタジオの事例紹介

データ分析基盤

• Batch Layer
  • KPI集計など
• Speed Layer
  • キャンペーンなど

データ分析基盤として、立ち上げ当初（2014年）はS3にそのまま保存し、それを使って集計していた（DAUやアドホック分析）。

基盤運用の課題

• EMRの起動が遅い
  • 起動に30分以上かかる
  • →Hiveメタストアの再構築などを行い5分に短縮
• Hiveが遅い
  • バッチ処理に15時間かかる
  • SQL、Hive Metastoreが便利なので諦めたくない
  • →ORC化、スキャン量削減、並列実行を行い9時間に短縮
• バッチ処理の運用が困難
  • 約300のタスクが存在し複雑に依存している
  • →独自のジョブフロー管理ツールを内製
    • タスクの並列実行が可能になったことで、バッチ処理が大幅に短縮
    • リカバリが容易になり、安定運用できるようになった

データ活用の課題

• エンジニアしかデータにさわれない
  • ログデータにアクセスするには、分析環境にSSHしないといけない
  • →ZeppelinやMetabaseといったBIツールを導入
• 集計クエリが複雑
  • 特定のエンジニアしかクエリがかけない（長く、複雑）
  • →Dimensional Modelingに基づいて分析用のテーブルを再設計・整備
    • 分析のスピードアップ
    • 分析の柔軟性
    • 集計クエリのハードルが下がった
• データの信頼性
  • データは壊れるということ
    • ログの遅延・欠損
    • SQLの記述ミス
    • Hiveのバグ
  • 事前のテストは困難
  • →データの事後検証を行う
    • ジョブフローの後半でデータ品質チェックを実行
    • 複数の異なるデータソースで比較
    • 変換前後の比較
    • NULLのカラムがないか確認
    • これらをユニットテストのフレームワークで検証できるようにした

現在は、データを多段に変換し活用している。

準リアルタム集計

期間限定のキャンペーンを盛り上げるため、いくつか準リアルタイム集計をしてきた。

• 十二支再競争
  • YouTubeで番組を配信
  • 配信に先立って、予想をサイト上に表示
  • S3、Lambda、Kinesis、Flinkを活用
• サーティワンGETキャンペーン
  • ゲーム内キャラクタを育成すると、アイスと交換できるクーポンをプレゼント
  • クーポン数を集計した
  • S3、Lambda、DynamoDB、CloudWatchを活用
• モンストBINGO
  • ユーザー参加型ビンゴ大会を企画
  • 現在のビンゴ達成者数を集計して生放送内でお知らせ
  • S3、Lambda、Redshiftを活用
• ファイトリーグブランドカップ
  • 2時間の間、参加者でスコアを競う
  • 上位者をサイト上にリアルタイム表示
  • 複数のログをJOINする必要があった
  • Kinesis、Firehose、Redshift、Lambda、S3を活用

要件によって構成はさまざまだが、サービスを組み合わせることで簡単に実装できる。S3やKinesisを利用することで、本番システムに影響を与えることなく、準リアルタイム集計をアドホックに実装することができた。

今後の課題

• 全サービスを横断して分析する仕組み
  • 新しいサービスも横断的に分析できるように
• データガバナンスの強化
  • 誰にどこまで見せるのかを制御
• ML/AIのための基盤づくり
  • データ分析基盤とどう掛け合わせるのか

最後に

いかがだったでしょうか。前半はEMR、特にHiveに関する話題が多くありました。後半はAWSのサービスを組み合わせることでさまざまな要件に対してデータをリアルタイムに集計するアーキテクチャが紹介されました。一昔前では難しかった大量のデータを用いた分析も、AWSのサービスを利用することで簡単に、安価に構築できることはとてもすばらしいですね。ぜひ参考にしていきましょう。

現場からは以上です。