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