ソーシャルゲームにレコメンドエンジンを導入した話
•Descargar como PPTX, PDF•
109 recomendaciones•9,447 vistas
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a ソーシャルゲームにレコメンドエンジンを導入した話
Similar a ソーシャルゲームにレコメンドエンジンを導入した話 (20)
Más de Tokoroten Nakayama
Más de Tokoroten Nakayama (20)
Último
Último (11)
ソーシャルゲームにレコメンドエンジンを導入した話
- 1. ソーシャルゲームに レコメンドエンジンを導入し た話 ところてん＠Drecom Twitter: @tokoroten 1
- 2. 自己紹介 • ところてん＠Drecom – 高機能雑用 • R&D&火消し&データ分析&企画 • 最近、インフラ業務が外れた – 定額働きたい放題プラン、意識の高い社 畜 – Pythonista – awkかわいいよawk – Rubyは読めるけど書けない • 注）DrecomはRailsの会社です 2
- 3. 自己紹介 • 学生時代はセキュリティ屋 – 電子透かしの実装 – 認知心理を集合知でエミュレーション、フィッシン グ検知 – NNでPlaceEngineのクローンを書いたり • 前職、某電話屋さんの研究所 – マルウェアの逆アセンブル、ハニーポット – QEMUをいじり倒す – 某検索エンジンのクローラ – 某OSSの分散機械学習エンジンのアプリ – 表に出せなかった仕事 • GA+コードカバレッジ+Fuzzing • GPで数式解いてみたり 3
- 4. 本日のアジェンダ か機素 と械晴 思学ら で度コ残 っ習し し サ念 たのい た イ ？話 ！ ン 類 似 4
- 5. 本日のアジェンダ • Drecomのデータ分析の環境の話 • ソーシャルゲームのゲームモデルの 話 • データまいにんぐー • 予備実験 • 本番環境構築 • 本番投入 • まとめ、反省 5
- 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
- 8. データ分析の人的問題 • 全部を満たすのは難しい –統計分析能力（必須） –ゲームそのものに対する理解 –データ抽出、前処理能力 –機械学習、マイニング –可視化 –並列処理、分散処理(hadoop) 8
- 9. 分析のトレードオフ • 分散を諦めた – ゲームのDBからぶっこぬいてきたデータを hadoopに再格納するのか？ – FIOが速いので、分散する必要が無い – PDCAが3日で回っていると、分散処理をデ バッグしている暇が無い – Impalaの本番投入待ち • 分析用サーバは核実験場 – 分析メソッドが安定化したら、インフラ部 隊と連携してhadoopに移植 9
- 10. 本日のアジェンダ • Drecomのデータ分析の環境の話 • ソーシャルゲームのゲームモデルの 話 • データまいにんぐー • 予備実験 • 本番環境構築 • 本番投入 • まとめ、反省 10
- 11. ソーシャルゲームのゲームモデル • Raidモデル – 強力なボスをみんなで殴って倒す – 例)ドリ■ンド • 問題点 – 自分の仲間と時間帯が合わないと一緒 に楽しめない – 寝てるときに救援を出されてもなぁ →とりあえずアクセスパターンを調査 11
- 12. ユーザのアクセスパターンの分析 • ユーザの活動時間を分析する – 1時間ごとにスロット分割 – 当該時間帯にアクセスしたかどうかをカ ウント – 100回アクセスも1回アクセスも1とカウン ト – 一年分のアクセスパターンを足して畳み 込む • 可視化はExcel （キリッ 12
- 13. 一日分のアクセスパターン • 横軸時間、縦軸ユーザ 13
- 15. 一般的なアクセスパターン • 朝7時～24時が中心 15
- 16. 飲食店勤務型 • 12時台にアクセスできない – 朝夕のログインが多い 16
- 17. 通勤電車型 • 7時と19時付近にアクセスが集中 – 残業によって帰宅時のピークは前後？ 17
- 18. 夜型 • 23時～4時を中心にログイン 18
- 19. 本日のアジェンダ • Drecomのデータ分析の環境の話 • ソーシャルゲームのゲームモデルの 話 • データまいにんぐー • 予備実験 • 本番環境構築 • 本番投入 • まとめ、反省 19
- 20. 仮説 • 前提 – 通勤電車型が夜型と友達になっても、 救援依頼が飛んでこなくて面白くない 可能性 • 仮説 – 生活リズムが一致するユーザを結びつ ければ、救援依頼がリアルタイムにな り、ゲームが活性化する可能性 →アクセスパターンを元にフレンドを 20
- 21. プロトタイプの実験 • アクセスパターンをコサイン類似度 – 上段元、下段推薦 21
- 22. プロトタイプの実験 • アクセスパターンをコサイン類似度 – なんか正しいっぽい 22
- 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ニコロサレマ
- 26. 本体の運用周りの細かい話 • アプリ開発者が困らないように – ブラウザで叩くとAPIリファレンス 26
- 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
- 30. 本日のアジェンダ • Drecomのデータ分析の環境の話 • ソーシャルゲームのゲームモデルの 話 • データまいにんぐー • 予備実験 • 本番環境構築 • 本番投入 • まとめ、反省 30
- 31. アプリ導入と段階的開放 • アプリの人からの段階解放の提案 • 第一段階 – 10%のユーザでレコメンドサーバを叩く – 結果は破棄 • 第二段階 – 10%のユーザでレコメンドサーバを叩く – 結果を利用 • 第三段階 – 50%のユーザでレコメンドサーバを叩く – 結果を利用 31
- 32. 2ヶ月間ABテストの結果 • ユーザのゲーム継続率で評価 – 差が出ない 32
- 33. 結果と考察 • 結果 – 生活時間があうユーザを優先的に組み合わせて も、継続率や売り上げに差が出なかった • 考察 – ユーザの仲間検索の利用頻度が低い – ユーザはRaidで活躍したユーザに対して、 直接仲間申請を出している – アクセスパターンよりも、アクティブ率のほう が重要そう • 正規化の過程でアクティブ率の情報が消失してい る – gl○○psさんとか、CR○○Zさんのギルドゲー なら効果が出そう・・・ 33
- 34. 反省 • 既存ユーザのフレンドの調査 – ゲーム内のスコアのよいユーザは時間帯が 合っているのか？その逆は? – 夜型の人は昼にプレイする人と比べてログ イン回数が多いか？ – 時間帯が合ってるフレンドが多いとどうな る？ • 導入後のフレンドの検証 – ABテストのユーザ群のフレンドを調査、プ レイ時間が合ったユーザが何人いるか 34
- 35. まとめ • 仮説 – 似た人を仲間にしよう • 実装 – コサイン類似度でドーン • 結果 – 差が出なかったorz – パラメータ弄ってがんばってま す・・・ 35