More Related Content
Similar to ソーシャルゲームにレコメンドエンジンを導入した話
Similar to ソーシャルゲームにレコメンドエンジンを導入した話 (20)
More from Tokoroten Nakayama
More from Tokoroten Nakayama (19)
ソーシャルゲームにレコメンドエンジンを導入した話
- 2. 自己紹介
• ところてん＠Drecom
– 高機能雑用
• R&D&火消し&データ分析&企画
• 最近、インフラ業務が外れた
– 定額働きたい放題プラン、意識の高い社
畜
– Pythonista
– awkかわいいよawk
– Rubyは読めるけど書けない
• 注）DrecomはRailsの会社です 2
- 3. 自己紹介
• 学生時代はセキュリティ屋
– 電子透かしの実装
– 認知心理を集合知でエミュレーション、フィッシン
グ検知
– NNでPlaceEngineのクローンを書いたり
• 前職、某電話屋さんの研究所
– マルウェアの逆アセンブル、ハニーポット
– QEMUをいじり倒す
– 某検索エンジンのクローラ
– 某OSSの分散機械学習エンジンのアプリ
– 表に出せなかった仕事
• GA+コードカバレッジ+Fuzzing
• GPで数式解いてみたり
3
- 4. 本日のアジェンダ
か機素
と械晴
思学ら
で度コ残 っ習し
し サ念 たのい
た イ ？話
！ ン
類
似
4
- 6. ドリコムのデータ分析の概要
• 言語
– Hadoop、hive、sh、R、SPSS、Knime、
Python
• 環境
– 分析用の専用サーバ*2(1.2TBのFIO搭載)
– Hadoopクラスタ
• Impalaを本番投入準備中
• 仕事
– ゲームのバランスチェック、KPI設計、継
続率、収益予測、テキストマイニング、広6
- 7. ドリコムのデータ分析環境の構成
Webサーバ
数十台
ActiveRecord Turntable
ユーザIDごとに水平分割
M-DB1 M-DB2 M-DB3 M-DB4 M-DB5 マスター5台
S-DB1S S-DB2 S-DB3 S-DB4 S-DB5 スレーブ5台
Fluentd 定期的にDBのダンプを取得
Fuse-hdfs FIOを搭載した分析用サーバ
ログサーバ
(HDFS) 1.2TBのFIO、16コア、メモリ
32GB
HDFSから必要なログを収集
7
- 9. 分析のトレードオフ
• 分散を諦めた
– ゲームのDBからぶっこぬいてきたデータを
hadoopに再格納するのか？
– FIOが速いので、分散する必要が無い
– PDCAが3日で回っていると、分散処理をデ
バッグしている暇が無い
– Impalaの本番投入待ち
• 分析用サーバは核実験場
– 分析メソッドが安定化したら、インフラ部
隊と連携してhadoopに移植
9
- 20. 仮説
• 前提
– 通勤電車型が夜型と友達になっても、
救援依頼が飛んでこなくて面白くない
可能性
• 仮説
– 生活リズムが一致するユーザを結びつ
ければ、救援依頼がリアルタイムにな
り、ゲームが活性化する可能性
→アクセスパターンを元にフレンドを 20
- 23. 本番環境を作る
• 構成検討
仲間リクエス
仲間候補 ト
レコメンドサーバ HTTP ゲームサーバ
優先度
定期的に参
照 アクセスログ書き込み
アップ
デート 定期的に
ユーザの 変換
アクセスログ
アクセスパターン
（HDFS）
(特徴ベクトル)
23
- 24. データ量の見積もり
• データ量の見積もり
– 浮動小数点
– 24次元の固定長ベクトル
– ユーザ数は100万人を想定
– 推定で200MB
• 8*24*1000000/1024/1024 = 183
• オンメモリで余裕(多分)
– Dict型で実装
– {user_id: feature_vector}
24
- 25. 本番の実装
• Python+BasicHTTPServerで実装
– オンメモリでやるにはここからやらんと・・・
• HTTPでリクエストを受け付け
– ゲームと疎結合にできる。
• (Ruby書かなくてもいい)
– 引数に推薦対象のIDと候補のIDを入れる
– コサイン類似度の高い順にJSONで返される
• 見積もりとはいったいなんだったのか
– ListからArrayにしてメモリ消費を半分にした
が・・・
25
ナンカイカOOMKillerニコロサレマ
- 27. 運用周りのコード
• 特徴ベクトルの更新
– crontabでログサーバからアクセスログ拾って
きて、アクセスパターンを毎日に生成
– 直近N日分のアクセスパターンを束ねて正規化
– レコメンドサーバにkill SIGUSR1を送って更
新
– /etc/init.d/hogehoge を頑張って書く
• PIDの記録とかメンドクサイ・・・
• ログ周り
– 俺俺スレッドセーフロガーを作ったり
27
- 28. 実装量
• レコメンドエンジン本体 Python300行
– オンメモリでユーザの特徴ベクトル保持
– HTTPで待ち受けてコサイン類似度
– スレッドセーフなロガーの提供
– Kill SIGUSR1でデータ更新
• /etc/init.d/用のシェルスクリプト 85行
– start,stop,restart,update
• ユーザのアクセスログの集計 Python150行
– HDFSを漁って、アクセスログからパターンを生成
– パターンから過去n日分を集計して特徴ベクトル化
28
- 29. 負荷試験
• ApatchBenchで負荷試験
– 700 QPS が出る
– ローカルポートが足りなくなってABが落ち
る
• レイテンシー
– 負荷試験時でも 7ms
– アプリ側のタイムアウトは50msで設定
• 実際のアプリで仲間探しの呼び出し状況
– 1QPS ヤリスギ
タ・・・ 29
- 33. 結果と考察
• 結果
– 生活時間があうユーザを優先的に組み合わせて
も、継続率や売り上げに差が出なかった
• 考察
– ユーザの仲間検索の利用頻度が低い
– ユーザはRaidで活躍したユーザに対して、
直接仲間申請を出している
– アクセスパターンよりも、アクティブ率のほう
が重要そう
• 正規化の過程でアクティブ率の情報が消失してい
る
– gl○○psさんとか、CR○○Zさんのギルドゲー
なら効果が出そう・・・
33
- 34. 反省
• 既存ユーザのフレンドの調査
– ゲーム内のスコアのよいユーザは時間帯が
合っているのか？その逆は?
– 夜型の人は昼にプレイする人と比べてログ
イン回数が多いか？
– 時間帯が合ってるフレンドが多いとどうな
る？
• 導入後のフレンドの検証
– ABテストのユーザ群のフレンドを調査、プ
レイ時間が合ったユーザが何人いるか
34
- 35. まとめ
• 仮説
– 似た人を仲間にしよう
• 実装
– コサイン類似度でドーン
• 結果
– 差が出なかったorz
– パラメータ弄ってがんばってま
す・・・ 35
