モンストシリーズでのデータ分析戦略

Transcript

1. ©MIXI ©MIXI モンストシリーズでの データ分析戦略 株式会社MIXI デジタルエンターテインメント事業本部 ⽩川裕介
2. 2 ©MIXI ⾃⼰紹介 • ⽒名 ◦ ⽩川裕介 • 経歴 ◦ 2012年新卒 • 主な業務 ◦ 新規ゲーム開発/リリース/運⽤に⾄るまでの横断的なサポート ◦ エンジニアリング/デザイン/QA/解析など様々な⾯でのサポート • 趣味 ◦ 筋トレ
3. ©MIXI モンストシリーズ
4. 4 ©MIXI モンストシリーズの紹介
5. 5 ©MIXI 開発体制 • MIXI社はパブリッシャー ◦ デベロッパーとしてゲーム開発会社に開発運⽤を委託 ◦ タイトル個別に様々な座組での開発体制が存在 ◦ 内製開発のタイトルも⼀部あり • 開発会社毎で選定される設計や技術 ◦ ゲーム開発において統⼀された基準やフローが存在しない ◦ 様々な技術スタックの会社があり会社毎に得意不得意が存在 ◦ 全てにおいて各タイトルで個別最適 すべてを自由に開発会社が選定するのではなく一定のルールや方針を整備し準拠してもらう
6. 6 ©MIXI 何をルールとして決めたか？ • クラウド事業者やプログラミング⾔語など ◦ 弊社内で⼀定の知⾒や実績があるものに限定 • リリース/運⽤に向けて最低限クリアすべき要件 ◦ ソーシャルゲーム前提で運⽤を⾒据えた際に必要となる要件を定義 • 最低限QAすべき項⽬ ◦ リリース時に⼤きな問題が起こらないために最低限のクオリティを担保する項⽬ • KPIなどのデータ分析の⽅針 ◦ KPIログの形式やゲーム内のデータ分析⼿法についてのルールを決定 本日はこちらについてのお話
7. ©MIXI データ分析戦略
8. 8 ©MIXI データ分析戦略の⽅針 • 最初に⼤きなデータ分析⽅針を策定 ◦ 後からルールを作り適⽤していくのは難しい ◦ データ分析基盤を統⼀ ▪ タイトル毎に作成するのは効率的ではない ▪ データ形式やインフラ側も⼀定整備して共通化 • 各タイトル個別最適ではなく、横並びで横断的に分析可能な状態 ◦ タイトル個別に分析するニーズは確実にあるため両⽴させる • ⼀定のルールを決めつつも柔軟に対応可能なルール ◦ 基本的にはPJ側の意⾒を尊重しつつ最低限の強制⼒をもたせたルール
9. 9 ©MIXI データ分析戦略 その1 • 全タイトルで共通のKPIログを定義 ◦ ゲーム共通で必須となるKPIログを定義 ▪ ログイン / 課⾦ / ゲームプレイなど ◦ ログフォーマットも共通化 ◦ タイトル個別ではなく全タイトル共通の分析基盤で分析可能に設計 • その他の各タイトル固有のKPIログは個別に相談し追加 ◦ ゲーム性やアウトゲームのフローが各タイトルで異なる ◦ タイトル固有のKPIログとし個別にKPIログとして定義して分析
10. 10 ©MIXI データ分析戦略 その2 • KPIログの転送 / DBのスナップショット ◦ 各タイトルで利⽤しているAWSアカウントのS3のbucketへログを格納 ◦ 基本となるアーキテクト設計を弊社で提供 ▪ 弊社側で検証を⾏いサンプルの実装を提供 • 検証結果はすべて共有 ▪ CloudFormationで構築を可能にサンプル提供 • データ分析基盤 ◦ S3から分析基盤へのデータ転送など処理は弊社側で担当 ▪ S3から解析基盤にデータを載せて ▪ 弊社側で⽤意した分析基盤を利⽤可能
11. 11 ©MIXI KPIログ転送の仕組み
12. 12 ©MIXI KPIログ転送の仕組み • Kinesis Agent ◦ EC2上で動作 ◦ ファイルを継続的に監視し更新があった差分をKinesis Data Streamsに送信 • Kinesis Data Streams ◦ ⼤量のストリーミングデータをリアルタイムで収集し処理 ◦ 受け取ったデータはコンシューマーと呼ばれるアプリケーションで処理 ▪ ex: Lambda, Kinesis Data Firehose • Kinesis Data Firehose ◦ 任意のエンドポイントにストリーミングデータを配信
13. 13 ©MIXI KPIログ転送の仕組み • Kinesis DataStreamsなしでも対応可能 ◦ Kinesis Agent 経由で Kinesis Data Firehoseを直接利⽤ ◦ ログの量が⼗分に少ない場合に限る • 注意点 ◦ ストリーミングデータの流量制限 ◦ putRecord時にデータ毎に改⾏が必須
14. 14 ©MIXI ストリーミングデータの流量制限 • DIRECT PUT構成の場合は以下の制限(Quota引き上げリクエストで緩和可) ◦ 1MB/s ◦ 10万レコード/s ◦ 1000リクエスト/s ▪ Kinesis Data Streamsを導⼊時は制限なし • 上限を超えた場合 ◦ ⼀時的なスパイク ▪ Kinesis Agent側で制御するため遅延が発⽣する程度 ◦ 恒常的な場合 ▪ Kinesis Data Streamsを導⼊検討
15. 15 ©MIXI putRecord時にデータごとに改⾏が必須 • S3オブジェクト内のデータが改⾏で区切られない • 改⾏が含まれない場合 ◦ putRecordの実⾏回数とデータ数が合わない状態 • Kinesis AgentやKinesis Data Streamsを利⽤時は⾃動で処理
16. 16 ©MIXI KPIログ転送の仕組み • 弊社からはあくまでも標準仕様を提供 • 各社で柔軟にカスタマイズして利⽤を想定 ◦ カスタマイズ例 ▪ kinesis AgentではなくFluentBitを利⽤ ▪ CloudWatchを挟んで開発会社側でもログを利⽤ • エラーログ監視など
17. 17 ©MIXI スナップショットの仕組み • Aurora(MySQL)を利⽤している前提 ◦ 弊社側で検証を⾏い2つの奨励⽅針として提⽰ 1. SELECT INTO OUTFILE S3機能を利⽤ 2. S3エクスポート機能を利⽤ SELECT INTO OUTFILE S3 S3エクスポート RDSへの負荷 あり(リードレプリカで実行奨励 ) なし 処理速度 並列処理可能 並列処理不可 出力先 設定自由 Prefixのみ指定可 出力形式 CSV/TSV Parquet
18. 18 ©MIXI SELECT INTO OUTFILE S3機能 • Aurora(MySQL)からS3にデータを直接コピーする機能 ◦ 任意の数の⾏をCSVファイルとして出⼒する ◦ 最⼤サイズが6GB、超える場合は複数のCSVに分割 • RDSに対して負荷がかかるためリードレプリカなどで実⾏が奨励 • GlueジョブのPython Shellでの実⾏を奨励 ◦ Lambdaではタイムアウトする可能性 SELECT * FROM hogehoge INTO OUTFILE S3 's3://your_backetname/upload_data/file' FIELDS TERMINATED BY ',' LINES TERMINATED BY '\n'
19. 19 ©MIXI S3エクスポート機能 • DBクラスターのスナップショットからS3にParquetファイルを出⼒する機能 ◦ テーブル内の全データの出⼒機能のみ ◦ ⼤規模なDBから⼤量のテーブルを出⼒する場合は⾮奨励 • 同じDBクラスターに対して複数のジョブを同時実⾏不可 • 1つのテーブルを書き出すだけでも、実⾏時間はクラスター全体の容量に依存 • ⼀部のデータがスキップされる可能性あり ◦ 特定の⽂字列やサポート外の⽂字列が含まれている場合 ◦ 出⼒後にデータ⾏数とテーブル数を確認する必要 • DBクラスターが対象であれば⼿軽に実⾏できる優位性あり
20. 20 ©MIXI 結果どうだったか • 良かった点 ◦ 全タイトルで共通のフォーマットでKPIログを取得 ▪ データ分析においても仕組みの共通化が可能 ▪ タイトル毎の⽐較が容易に可能 ◦ 開発会社側での実装もスムーズに完了 ▪ 実装例を提⽰することで知⾒がない開発会社でも導⼊が可能 ▪ 弊社側で検証を⾏いノウハウを提供することでコストが低減 ◦ データ分析の効率化を実現 ▪ KPIを出すのにSQLの使いまわしが可能 • 分析基盤やログフォーマットが統⼀されている
21. 21 ©MIXI 結果どうだったか • 反省点 ◦ ログ精度のばらつき ▪ ログの重複や⽋損 ▪ 意図した型や全く別のIDが⼊っていたりなど ◦ 送られてくる問題のあるKPIログの検知が遅れた ▪ 初期実装のミスで仕様どおりでないログ ▪ ログの不具合の検知が後⼿に回った • 実際にKPIログの分析中に発覚
22. 22 ©MIXI 今後のついて • 意図通りでないログの検知 ◦ 開発段階で気付けるような仕組みやフローを検討 • データや仕組みを統⼀することは実施 ◦ 今後はさらにそれらを⽤いて知⾒を貯める ◦ 新規タイトルや他の既存タイトルで柔軟に活⽤できる体制を作る • 継続し続ける ◦ 新規タイトルにおいても同様の取り組みでログを蓄積 ▪ 途中でやめずにやり続けることにも意味があると考える ◦ 過去のタイトルとの⽐較や、これまでのタイトルのKPIログを蓄積 ◦ 社内の資産となるようなものを⽬指す
23. 23 ©MIXI まとめ • タイトル個別の分析、タイトルを横断した分析の両⽅を実現するための戦略を推進 • データ分析について ◦ 全タイトル共通の取り決め ▪ KPIログの内容やフォーマットなどの仕様 ▪ 開発会社がKPIログに関する開発のハードルを下げる • アーキテクチャの設計や検証実施し実装例として展開 ◦ 後から共通化するより最初に決めておくことが⼤事 ▪ データや分析基盤が整っていれば後から如何⽤にも利⽤可能
24. ©MIXI