Submit Search
ソーシャルゲームにレコメンドエンジンを導入した話
•
Download as PPTX, PDF
•
109 likes
•
9,488 views
Tokoroten Nakayama
Follow
1 of 35
Download now
Downloaded 138 times
More Related Content
ソーシャルゲームにレコメンドエンジンを導入した話
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
14.
アクセスパターンの畳み込み • 過去一年分を加算する • 24次元のベクトルとみなして正規化
14
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
Download