アプリボットの分析環境について

データ分析 1 Minute

はじめまして。アプリボットのデータマイニングエンジニアのりんだです。
今回は、アプリボットの運用を支える分析環境について、システムの全体像などをご紹介したいと思います。

アプリボットは、運用を強みにしており、数字によるサービスの状況把握に重きを置いています。

アプリボットのサービスと分析チームのミッション

アプリボットでは、「ジョーカー～ギャングロード～」、「グリモア～私立グリモワール魔法学園～」を始めとして様々なサービスを取り扱っています。

分析チームの主なミッションは、

  • 各サービスの分析に必要なデータ解析基盤を安定的に供給
  • サービスのグロースに必要なレポートなどの作成、共有、横軸での連携

となっています。チームとしては、２〜３人の規模ですが、各サービスに所属する分析アナリストと連携を取ることで、横串組織として機能させています。

分析基盤と各サービスとの関わり

分析環境が目指すところ

アプリボットのデータ分析チームは、以下の点を留意しています。

  • 運用サービス全てのデータを取り扱う。
  • 必要なデータは、適切なタイミングで正しく届ける。
  • 社内全体がサービスの現状を数値で知れるようにする。

文字に起こすと当たり前のような内容ですが、全て満たすのはなかなか難しいです。

分析システム概要図

以下の図は、2016年12月時点でのアプリボットの分析システムです。

image01.png

簡単に言うと、

  1. ゲームに貯まるデータを、AWS Redshiftに集める
  2. いろいろSQLで加工する
  3. 内製ツールやTableauなどのBIツールで可視化しています。

分析システムのこれまで

上に挙げた分析システムが今の形になるまでのを簡単に説明します。昔の状況から、少しずつレベルアップしていく様を感じてください。

1. 入社前

私がアプリボットに入社する前、DAUを把握するのに翌日の昼になる以降になることが当たり前でした。
そのため、ユーザーの動向に合わせて施策が素早く打てないという問題点がありました。

当時の分析フローは、以下の様な流れでした。

  1.  ゲームのデータを一度、別のMySQLにいれる。
    使っていたPCのスペックも低く、夜間に開始したロード処理は始業時間までかかっていました。
  2. アナリストが、毎朝手動で分析用のSQLを実行し、DAUなどの各KPIを出す。
  3. 出したKPIをエクセルに転記し、午前中にかけてレポートを提出する。

2. 最初のミッション

アプリボットに来て、最初のミッションが、KPIレポートの自動化でした。ここで開発したものが、システム概要図にある「内製レポートツール」に当たります。
また、分析用のDWH(Data Warehouse)として、Redshiftを導入したのもこのタイミングでした。

アプリボットの分析チームや周囲環境として、

  • メンバーのほとんどがSQLを使える
  • ゲーム側はMySQLなどのRDSで構築されてる
  • 今後サービスが増える可能性がある

といった点がありました。これに合わせて、以下の観点からRedshiftが採用されました。

  • 一般的なSQLが使える
  • DBスキーマがRDSと似ておりDDLを流用しやすい
  • クラウドスケールしやすい

Redshiftが導入されれば、あとはデータのETL(Extract/Transform/Load)をガンガン自動化していくのみでした。

ETLで助かったのは、「Flydata」というサービスです。
これは、Redshiftへのロードを担ってくれるサービスなんですが、Webで登録するだけで利用可能になります。
ロードでエラーが起きても再送や、リトライなどを自動で行ってくれました。

立ち上げ当初、Redshiftの経験はなくても、FlydataのおかげでETL部分を早く構築することができました。

3. 行動（アクション）ログへのスイッチ

Redshiftと内製の分析ツールの開発によって、社内のKPI把握は格段に早くなりました。
次に、ユーザーの行動にフォーカスした、もっと深い分析へのニーズが出てきました。

ただ、ゲーム側のテーブルだけでは、分析に必要なデータが足りない状況がありました。
例えば、ユーザのLvなどを常にUPDATEで上書きしてしまうなど。

これだと、あるユーザが、いつLvアップしたなど、時系列的な関係性が把握できないことになってしまいます。

毎回スナップショット的にダンプして、履歴的に残すことは可能ですが、不要なデータも多く残すことになります。

また、ダンプ頻度が1日になると、1日の間で何度もLvアップした部分は残りません。

そこで、ユーザが行動（アクション）するたびに出力する専用のログを設計し、サーバーエンジニアと連携して、ユーザーの行動ごとに出力する行動ログを作成することにしました。
それらをfluentdを使って、１箇所に集約し、Redshiftにロードするという流れを導入しました。

これによって、別のメリットもありました。
夜間バッチの実装が減り、常時流れてくるログによりリアルタイムに近い（※1）分析が可能になりました。

※1…実質は、fluentdの負荷軽減、Redshiftのロード間隔の調整などで、2時間遅れくらいで最新のデータが入るようになっています。

使っている技術・サービス

分析環境は少ない人数で、企画サイドのニーズに合わせて、迅速に導入する必要がありました。そのため、様々なサービスを組み合わせて、分析環境を構築しています。

＜DWH（データウェアハウス）＞

  • Amazon Redshift
  • Google BigQuery

＜ETL＞

＜View＞

まとめ

現在、安定運用できているの分析システムは、以上の構成です。
ただ、ここには出てないサービスなども実は裏で検討＆挑戦中です。

アプリボットでは先に挙げたコンセプトをぶらさず、よりよい分析システムを作れるように日夜考えて実行しています！
今回はざっと全体像のご紹介でしたが、もっと詳細な実装や、システム設計の考え方についてもご紹介していけたらと思っています。

投稿者: adsys

Published