Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie ソーシャルゲームにレコメンドエンジンを導入した話
Ähnlich wie ソーシャルゲームにレコメンドエンジンを導入した話 (20)
Mehr von Tokoroten Nakayama
Mehr von Tokoroten Nakayama (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (10)
ソーシャルゲームにレコメンドエンジンを導入した話
- 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