0
ソーシャルゲームにレコメンドエンジンを導入した話    ところてん@Drecom   Twitter: @tokoroten                         1
自己紹介• ところてん@Drecom – 高機能雑用   • R&D&火消し&データ分析&企画   • 最近、インフラ業務が外れた – 定額働きたい放題プラン、意識の高い社   畜 – Pythonista – awkかわいいよawk – Ru...
自己紹介• 学生時代はセキュリティ屋 – 電子透かしの実装 – 認知心理を集合知でエミュレーション、フィッシン   グ検知 – NNでPlaceEngineのクローンを書いたり• 前職、某電話屋さんの研究所 –   マルウェアの逆アセンブル、ハ...
本日のアジェンダ                  か機素                  と械晴                  思学らで度コ残              っ習しし サ念              たのいた イ      ...
本日のアジェンダ• Drecomのデータ分析の環境の話• ソーシャルゲームのゲームモデルの  話• データまいにんぐー• 予備実験• 本番環境構築• 本番投入• まとめ、反省                      5
ドリコムのデータ分析の概要• 言語 – Hadoop、hive、sh、R、SPSS、Knime、   Python• 環境 – 分析用の専用サーバ*2(1.2TBのFIO搭載) – Hadoopクラスタ   • Impalaを本番投入準備中• ...
ドリコムのデータ分析環境の構成                                                        Webサーバ                                             ...
データ分析の人的問題• 全部を満たすのは難しい –統計分析能力(必須) –ゲームそのものに対する理解 –データ抽出、前処理能力 –機械学習、マイニング –可視化 –並列処理、分散処理(hadoop)                      8
分析のトレードオフ• 分散を諦めた – ゲームのDBからぶっこぬいてきたデータを   hadoopに再格納するのか? – FIOが速いので、分散する必要が無い – PDCAが3日で回っていると、分散処理をデ   バッグしている暇が無い – Im...
本日のアジェンダ• Drecomのデータ分析の環境の話• ソーシャルゲームのゲームモデルの  話• データまいにんぐー• 予備実験• 本番環境構築• 本番投入• まとめ、反省                      10
ソーシャルゲームのゲームモデル• Raidモデル – 強力なボスをみんなで殴って倒す – 例)ドリ■ンド• 問題点 – 自分の仲間と時間帯が合わないと一緒   に楽しめない – 寝てるときに救援を出されてもなぁ→とりあえずアクセスパターンを調査...
ユーザのアクセスパターンの分析• ユーザの活動時間を分析する – 1時間ごとにスロット分割 – 当該時間帯にアクセスしたかどうかをカ   ウント – 100回アクセスも1回アクセスも1とカウン   ト – 一年分のアクセスパターンを足して畳み ...
一日分のアクセスパターン• 横軸時間、縦軸ユーザ                 13
アクセスパターンの畳み込み• 過去一年分を加算する• 24次元のベクトルとみなして正規化   14
一般的なアクセスパターン• 朝7時~24時が中心                 15
飲食店勤務型• 12時台にアクセスできない – 朝夕のログインが多い                  16
通勤電車型• 7時と19時付近にアクセスが集中 – 残業によって帰宅時のピークは前後?                       17
夜型• 23時~4時を中心にログイン                   18
本日のアジェンダ• Drecomのデータ分析の環境の話• ソーシャルゲームのゲームモデルの  話• データまいにんぐー• 予備実験• 本番環境構築• 本番投入• まとめ、反省                      19
仮説• 前提 – 通勤電車型が夜型と友達になっても、   救援依頼が飛んでこなくて面白くない   可能性• 仮説 – 生活リズムが一致するユーザを結びつ   ければ、救援依頼がリアルタイムにな   り、ゲームが活性化する可能性→アクセスパターン...
プロトタイプの実験• アクセスパターンをコサイン類似度 – 上段元、下段推薦                     21
プロトタイプの実験• アクセスパターンをコサイン類似度 – なんか正しいっぽい                     22
本番環境を作る• 構成検討                              仲間リクエス            仲間候補                 ト レコメンドサーバ    HTTP   ゲームサーバ            優...
データ量の見積もり• データ量の見積もり – 浮動小数点 – 24次元の固定長ベクトル – ユーザ数は100万人を想定 – 推定で200MB   • 8*24*1000000/1024/1024 = 183• オンメモリで余裕(多分) – Di...
本番の実装• Python+BasicHTTPServerで実装  – オンメモリでやるにはここからやらんと・・・• HTTPでリクエストを受け付け  – ゲームと疎結合にできる。    • (Ruby書かなくてもいい)  – 引数に推薦対象の...
本体の運用周りの細かい話• アプリ開発者が困らないように – ブラウザで叩くとAPIリファレンス                       26
運用周りのコード• 特徴ベクトルの更新 – crontabでログサーバからアクセスログ拾って   きて、アクセスパターンを毎日に生成 – 直近N日分のアクセスパターンを束ねて正規化 – レコメンドサーバにkill SIGUSR1を送って更   ...
実装量• レコメンドエンジン本体 Python300行 –   オンメモリでユーザの特徴ベクトル保持 –   HTTPで待ち受けてコサイン類似度 –   スレッドセーフなロガーの提供 –   Kill SIGUSR1でデータ更新• /etc/i...
負荷試験• ApatchBenchで負荷試験 – 700 QPS が出る – ローカルポートが足りなくなってABが落ち   る• レイテンシー – 負荷試験時でも 7ms – アプリ側のタイムアウトは50msで設定• 実際のアプリで仲間探しの呼...
本日のアジェンダ• Drecomのデータ分析の環境の話• ソーシャルゲームのゲームモデルの  話• データまいにんぐー• 予備実験• 本番環境構築• 本番投入• まとめ、反省                      30
アプリ導入と段階的開放• アプリの人からの段階解放の提案• 第一段階 – 10%のユーザでレコメンドサーバを叩く – 結果は破棄• 第二段階 – 10%のユーザでレコメンドサーバを叩く – 結果を利用• 第三段階 – 50%のユーザでレコメンド...
2ヶ月間ABテストの結果• ユーザのゲーム継続率で評価 – 差が出ない                  32
結果と考察• 結果 – 生活時間があうユーザを優先的に組み合わせて   も、継続率や売り上げに差が出なかった• 考察 – ユーザの仲間検索の利用頻度が低い – ユーザはRaidで活躍したユーザに対して、   直接仲間申請を出している – アクセ...
反省• 既存ユーザのフレンドの調査 – ゲーム内のスコアのよいユーザは時間帯が   合っているのか?その逆は? – 夜型の人は昼にプレイする人と比べてログ   イン回数が多いか? – 時間帯が合ってるフレンドが多いとどうな   る?• 導入後の...
まとめ• 仮説 – 似た人を仲間にしよう• 実装 – コサイン類似度でドーン• 結果 – 差が出なかったorz – パラメータ弄ってがんばってま   す・・・             35
Upcoming SlideShare
Loading in...5
×

ソーシャルゲームにレコメンドエンジンを導入した話

19,537

Published on

Published in: Technology
1 Comment
102 Likes
Statistics
Notes
No Downloads
Views
Total Views
19,537
On Slideshare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
130
Comments
1
Likes
102
Embeds 0
No embeds

No notes for slide

Transcript of "ソーシャルゲームにレコメンドエンジンを導入した話"

  1. 1. ソーシャルゲームにレコメンドエンジンを導入した話 ところてん@Drecom Twitter: @tokoroten 1
  2. 2. 自己紹介• ところてん@Drecom – 高機能雑用 • R&D&火消し&データ分析&企画 • 最近、インフラ業務が外れた – 定額働きたい放題プラン、意識の高い社 畜 – Pythonista – awkかわいいよawk – Rubyは読めるけど書けない • 注)DrecomはRailsの会社です 2
  3. 3. 自己紹介• 学生時代はセキュリティ屋 – 電子透かしの実装 – 認知心理を集合知でエミュレーション、フィッシン グ検知 – NNでPlaceEngineのクローンを書いたり• 前職、某電話屋さんの研究所 – マルウェアの逆アセンブル、ハニーポット – QEMUをいじり倒す – 某検索エンジンのクローラ – 某OSSの分散機械学習エンジンのアプリ – 表に出せなかった仕事 • GA+コードカバレッジ+Fuzzing • GPで数式解いてみたり 3
  4. 4. 本日のアジェンダ か機素 と械晴 思学らで度コ残 っ習しし サ念 たのいた イ ?話! ン 類 似 4
  5. 5. 本日のアジェンダ• Drecomのデータ分析の環境の話• ソーシャルゲームのゲームモデルの 話• データまいにんぐー• 予備実験• 本番環境構築• 本番投入• まとめ、反省 5
  6. 6. ドリコムのデータ分析の概要• 言語 – Hadoop、hive、sh、R、SPSS、Knime、 Python• 環境 – 分析用の専用サーバ*2(1.2TBのFIO搭載) – Hadoopクラスタ • Impalaを本番投入準備中• 仕事 – ゲームのバランスチェック、KPI設計、継 続率、収益予測、テキストマイニング、広6
  7. 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. 8. データ分析の人的問題• 全部を満たすのは難しい –統計分析能力(必須) –ゲームそのものに対する理解 –データ抽出、前処理能力 –機械学習、マイニング –可視化 –並列処理、分散処理(hadoop) 8
  9. 9. 分析のトレードオフ• 分散を諦めた – ゲームのDBからぶっこぬいてきたデータを hadoopに再格納するのか? – FIOが速いので、分散する必要が無い – PDCAが3日で回っていると、分散処理をデ バッグしている暇が無い – Impalaの本番投入待ち• 分析用サーバは核実験場 – 分析メソッドが安定化したら、インフラ部 隊と連携してhadoopに移植 9
  10. 10. 本日のアジェンダ• Drecomのデータ分析の環境の話• ソーシャルゲームのゲームモデルの 話• データまいにんぐー• 予備実験• 本番環境構築• 本番投入• まとめ、反省 10
  11. 11. ソーシャルゲームのゲームモデル• Raidモデル – 強力なボスをみんなで殴って倒す – 例)ドリ■ンド• 問題点 – 自分の仲間と時間帯が合わないと一緒 に楽しめない – 寝てるときに救援を出されてもなぁ→とりあえずアクセスパターンを調査 11
  12. 12. ユーザのアクセスパターンの分析• ユーザの活動時間を分析する – 1時間ごとにスロット分割 – 当該時間帯にアクセスしたかどうかをカ ウント – 100回アクセスも1回アクセスも1とカウン ト – 一年分のアクセスパターンを足して畳み 込む• 可視化はExcel (キリッ 12
  13. 13. 一日分のアクセスパターン• 横軸時間、縦軸ユーザ 13
  14. 14. アクセスパターンの畳み込み• 過去一年分を加算する• 24次元のベクトルとみなして正規化 14
  15. 15. 一般的なアクセスパターン• 朝7時~24時が中心 15
  16. 16. 飲食店勤務型• 12時台にアクセスできない – 朝夕のログインが多い 16
  17. 17. 通勤電車型• 7時と19時付近にアクセスが集中 – 残業によって帰宅時のピークは前後? 17
  18. 18. 夜型• 23時~4時を中心にログイン 18
  19. 19. 本日のアジェンダ• Drecomのデータ分析の環境の話• ソーシャルゲームのゲームモデルの 話• データまいにんぐー• 予備実験• 本番環境構築• 本番投入• まとめ、反省 19
  20. 20. 仮説• 前提 – 通勤電車型が夜型と友達になっても、 救援依頼が飛んでこなくて面白くない 可能性• 仮説 – 生活リズムが一致するユーザを結びつ ければ、救援依頼がリアルタイムにな り、ゲームが活性化する可能性→アクセスパターンを元にフレンドを 20
  21. 21. プロトタイプの実験• アクセスパターンをコサイン類似度 – 上段元、下段推薦 21
  22. 22. プロトタイプの実験• アクセスパターンをコサイン類似度 – なんか正しいっぽい 22
  23. 23. 本番環境を作る• 構成検討 仲間リクエス 仲間候補 ト レコメンドサーバ HTTP ゲームサーバ 優先度 定期的に参 照 アクセスログ書き込み アップ デート 定期的に ユーザの 変換 アクセスログ アクセスパターン (HDFS) (特徴ベクトル) 23
  24. 24. データ量の見積もり• データ量の見積もり – 浮動小数点 – 24次元の固定長ベクトル – ユーザ数は100万人を想定 – 推定で200MB • 8*24*1000000/1024/1024 = 183• オンメモリで余裕(多分) – Dict型で実装 – {user_id: feature_vector} 24
  25. 25. 本番の実装• Python+BasicHTTPServerで実装 – オンメモリでやるにはここからやらんと・・・• HTTPでリクエストを受け付け – ゲームと疎結合にできる。 • (Ruby書かなくてもいい) – 引数に推薦対象のIDと候補のIDを入れる – コサイン類似度の高い順にJSONで返される• 見積もりとはいったいなんだったのか – ListからArrayにしてメモリ消費を半分にした が・・・ 25 ナンカイカOOMKillerニコロサレマ
  26. 26. 本体の運用周りの細かい話• アプリ開発者が困らないように – ブラウザで叩くとAPIリファレンス 26
  27. 27. 運用周りのコード• 特徴ベクトルの更新 – crontabでログサーバからアクセスログ拾って きて、アクセスパターンを毎日に生成 – 直近N日分のアクセスパターンを束ねて正規化 – レコメンドサーバにkill SIGUSR1を送って更 新 – /etc/init.d/hogehoge を頑張って書く • PIDの記録とかメンドクサイ・・・• ログ周り – 俺俺スレッドセーフロガーを作ったり 27
  28. 28. 実装量• レコメンドエンジン本体 Python300行 – オンメモリでユーザの特徴ベクトル保持 – HTTPで待ち受けてコサイン類似度 – スレッドセーフなロガーの提供 – Kill SIGUSR1でデータ更新• /etc/init.d/用のシェルスクリプト 85行 – start,stop,restart,update• ユーザのアクセスログの集計 Python150行 – HDFSを漁って、アクセスログからパターンを生成 – パターンから過去n日分を集計して特徴ベクトル化 28
  29. 29. 負荷試験• ApatchBenchで負荷試験 – 700 QPS が出る – ローカルポートが足りなくなってABが落ち る• レイテンシー – 負荷試験時でも 7ms – アプリ側のタイムアウトは50msで設定• 実際のアプリで仲間探しの呼び出し状況 – 1QPS ヤリスギ タ・・・ 29
  30. 30. 本日のアジェンダ• Drecomのデータ分析の環境の話• ソーシャルゲームのゲームモデルの 話• データまいにんぐー• 予備実験• 本番環境構築• 本番投入• まとめ、反省 30
  31. 31. アプリ導入と段階的開放• アプリの人からの段階解放の提案• 第一段階 – 10%のユーザでレコメンドサーバを叩く – 結果は破棄• 第二段階 – 10%のユーザでレコメンドサーバを叩く – 結果を利用• 第三段階 – 50%のユーザでレコメンドサーバを叩く – 結果を利用 31
  32. 32. 2ヶ月間ABテストの結果• ユーザのゲーム継続率で評価 – 差が出ない 32
  33. 33. 結果と考察• 結果 – 生活時間があうユーザを優先的に組み合わせて も、継続率や売り上げに差が出なかった• 考察 – ユーザの仲間検索の利用頻度が低い – ユーザはRaidで活躍したユーザに対して、 直接仲間申請を出している – アクセスパターンよりも、アクティブ率のほう が重要そう • 正規化の過程でアクティブ率の情報が消失してい る – gl○○psさんとか、CR○○Zさんのギルドゲー なら効果が出そう・・・ 33
  34. 34. 反省• 既存ユーザのフレンドの調査 – ゲーム内のスコアのよいユーザは時間帯が 合っているのか?その逆は? – 夜型の人は昼にプレイする人と比べてログ イン回数が多いか? – 時間帯が合ってるフレンドが多いとどうな る?• 導入後のフレンドの検証 – ABテストのユーザ群のフレンドを調査、プ レイ時間が合ったユーザが何人いるか 34
  35. 35. まとめ• 仮説 – 似た人を仲間にしよう• 実装 – コサイン類似度でドーン• 結果 – 差が出なかったorz – パラメータ弄ってがんばってま す・・・ 35
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×