Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ソーシャルゲームログ解析基盤のMongoDB活用事例

9,104 views

Published on

【エンジニアカフェEvent×gumiStudy】ソーシャルゲームの解析を支える技術-MongoDB編-
https://www.facebook.com/event.php?eid=295541553794432

の発表資料です。

  • Be the first to comment

ソーシャルゲームログ解析基盤のMongoDB活用事例

  1. 1. ソーシャルゲームログ解析の MongoDB活用事例∼gumiさん、MongoDB始めました∼ 1
  2. 2. アジェンダ1. 自己紹介2. ログ解析に至った経緯3. 現在のMongoDB活用状況4. MongoDBを使ってみて 2
  3. 3. 自己紹介名前:本間 知教(ほんま とものり)Twitter:@CkRealgumi歴1ヶ月半 前職は国内某ITコンサルティング会社入社前の想定 現実 MySQL fluentd Python MongoDB Django Hadoop 3
  4. 4. ログ解析に至った経緯 4
  5. 5. これまでのgumi ユーザの行動詳細が見えない ユーザがどの段階で、ゲームをやめたのか? 何故、あのイベントが好まれたのか? ゲーム 開発ゲームユーザー ゲーム開発者 ?5
  6. 6. これまでのgumiゲームごとの各サーバに蓄積されているログ アクセスログとアクションログが、各サーバに散在 サーバ障害発生時、各ログはロストorzAPサーバ APサーバ NFSサーバアクセスログ ・・・ アクセスログ アクションログ 各サーバごとに調査 ゲーム開発者 6
  7. 7. ログ解析システムの対象者 社内のあらゆる視点で必要な指標を提供する カスタマーサポート ゲーム開発者 経営陣 ユーザごとの ユーザが各イベントで どのゲームに経営資源を詳細な行動結果の把握 楽しめているかを把握 投入すべきかの判断材料ミクロ マクロ 7
  8. 8. ログ解析システムの構想 解析用途を分け、2経路からログの解析を行う。 ログ解析システム リアルタイム転送 バッチ転送(第2回) 収集 解析 fluentd 選別 ユーザに必要なアプローチを行うゲームユーザー ゲーム関係者 8
  9. 9. 現在のMongoDB活用状況 9
  10. 10. MongoDB採用の経緯解析に必要なログを突っ込めるストレージDB 挿入・検索速度>信頼性 データ設計が柔軟に行えるDB豊富な日本語資料 国内でも増えつつある構築事例 MongoDB JPの方々に感謝(次回は11月15日開催) 最近、@doryokujinさんのアイコンを見ると、拝みたくなります。 10
  11. 11. 現在のシステム構成 まずはアクセスログのリアルタイム転送を構築 1ゲームのアクセスログだけで、約1,000万件/日 APAP AP APサーバ ログ収集サーバ ログ解析DBサーバ サーバ サーバd サーバ fluentd fluentd mongos mongod(PRIMARY) アクセスログ ログ解析DBサーバ アクションログ config mongod(SECONDARY) ログ収集サーバ ログ解析DBサーバ fluentd mongos mongod(SECONDARY) config ReplicaSets & Sharding NFSサーバ アクション集約ログ 新規構築フロー 既存フロー 11
  12. 12. 現在のサーバスペック AWS上に、以下の構成で構築 サーバ OS SW APサーバ(c1.xlarge)×19台 CentOS 5.6 fluentd 0.10.1 fluentd 0.10.1 ログ収集サーバ(c1.xlarge)×2台 CentOS 6.0 MongoDB 2.0ログ解析DBサーバ(m1.xlarge)×3台 CentOS 6.0 MongoDB 2.0 ハイ CPU エクストララージ インスタンス エクストララージ インスタンス  7 GB メモリ  15 GB メモリ  20 ECU(2.5 ECU × 8仮想コア)  8 ECU(2 ECU × 4仮想コア)  1690 GB インスタンスストレージ  1,690 GB インスタンスストレージ  64ビット プラットフォーム  64ビット プラットフォーム  I/O 性能: 高速  I/O 性能: 高速  API 名: c1.xlarge  API 名: m1.xlarge 12
  13. 13. 現在のSharding構成 Sharding設計 ログ種別(データベース)単位でShardingを行なっている ログ形式が定まっていないため、コレクション単位のShardingは未定Shard1 Shard2アクセスログ(データベース) アクションログ(データベース) −アプリA  −日付:YYYY-MM-DD −アプリB 13
  14. 14. 現在の取得ログアクセスログとりあえず、fluentd経由で突っ込んではみたけど…アクションログ共通フォーマット:時間、ユーザID、アプリ名、サーバ名アプリごとのフォーマット:ここを中心に解析したい 14
  15. 15. MongoDBを使ってみて 15
  16. 16. MongoDBを構築してみてインストールが簡単 yum installで一発。Oracleェ…ReplicaSetの追加・削除が簡単 Sharding環境でも、mongosが自動で更新してくれる。Shardingは、構築しないとわからない。 db.runCommand( { enablesharding : "【データベース名】" } )を忘れないように… 16
  17. 17. MongoDBを運用し始めてみて対話シェルのUIが運用者に優しい どこで作業しているかがわかりやすい。 例)mongos>db.printShardingStatus()   PRIMARY>rs.status()MongoDBのクエリが豊富 豊富すぎて、使いこなせてない><運用トラブルの不安 mongosが落ちる?Shardingが止まらない?監視方法は? 17
  18. 18. .......でも、MongoDB JPがあるから、 きっと大丈夫(*´ω`*) 18
  19. 19. ご清聴ありがとうございました。 19

×