SlideShare a Scribd company logo
ソーシャルゲームに
レコメンドエンジンを導入し
た話
    ところてん@Drecom
   Twitter: @tokoroten


                         1
自己紹介
• ところてん@Drecom
 – 高機能雑用
   • R&D&火消し&データ分析&企画
   • 最近、インフラ業務が外れた
 – 定額働きたい放題プラン、意識の高い社
   畜

 – Pythonista
 – awkかわいいよawk
 – Rubyは読めるけど書けない
   • 注)DrecomはRailsの会社です   2
自己紹介
• 学生時代はセキュリティ屋
 – 電子透かしの実装
 – 認知心理を集合知でエミュレーション、フィッシン
   グ検知
 – NNでPlaceEngineのクローンを書いたり

• 前職、某電話屋さんの研究所
 –   マルウェアの逆アセンブル、ハニーポット
 –   QEMUをいじり倒す
 –   某検索エンジンのクローラ
 –   某OSSの分散機械学習エンジンのアプリ
 –   表に出せなかった仕事
     • GA+コードカバレッジ+Fuzzing
     • GPで数式解いてみたり
                             3
本日のアジェンダ


                  か機素
                  と械晴
                  思学ら
で度コ残              っ習し
し サ念              たのい
た イ               ?話
! ン
  類
  似


                        4
本日のアジェンダ
• Drecomのデータ分析の環境の話
• ソーシャルゲームのゲームモデルの
  話
• データまいにんぐー
• 予備実験
• 本番環境構築
• 本番投入
• まとめ、反省
                      5
ドリコムのデータ分析の概要
• 言語
 – Hadoop、hive、sh、R、SPSS、Knime、
   Python

• 環境
 – 分析用の専用サーバ*2(1.2TBのFIO搭載)
 – Hadoopクラスタ
   • Impalaを本番投入準備中

• 仕事
 – ゲームのバランスチェック、KPI設計、継
   続率、収益予測、テキストマイニング、広6
ドリコムのデータ分析環境の構成

                                                        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
データ分析の人的問題

• 全部を満たすのは難しい
 –統計分析能力(必須)
 –ゲームそのものに対する理解
 –データ抽出、前処理能力
 –機械学習、マイニング
 –可視化
 –並列処理、分散処理(hadoop)
                      8
分析のトレードオフ
• 分散を諦めた
 – ゲームのDBからぶっこぬいてきたデータを
   hadoopに再格納するのか?
 – FIOが速いので、分散する必要が無い
 – PDCAが3日で回っていると、分散処理をデ
   バッグしている暇が無い
 – Impalaの本番投入待ち

• 分析用サーバは核実験場
 – 分析メソッドが安定化したら、インフラ部
   隊と連携してhadoopに移植
                       9
本日のアジェンダ
• Drecomのデータ分析の環境の話
• ソーシャルゲームのゲームモデルの
  話
• データまいにんぐー
• 予備実験
• 本番環境構築
• 本番投入
• まとめ、反省
                      10
ソーシャルゲームのゲームモデル
• Raidモデル
 – 強力なボスをみんなで殴って倒す
 – 例)ドリ■ンド

• 問題点
 – 自分の仲間と時間帯が合わないと一緒
   に楽しめない
 – 寝てるときに救援を出されてもなぁ

→とりあえずアクセスパターンを調査 11
ユーザのアクセスパターンの分析
• ユーザの活動時間を分析する
 – 1時間ごとにスロット分割
 – 当該時間帯にアクセスしたかどうかをカ
   ウント
 – 100回アクセスも1回アクセスも1とカウン
   ト
 – 一年分のアクセスパターンを足して畳み
   込む

• 可視化はExcel (キリッ      12
一日分のアクセスパターン
• 横軸時間、縦軸ユーザ




                 13
アクセスパターンの畳み込み
• 過去一年分を加算する




• 24次元のベクトルとみなして正規化   14
一般的なアクセスパターン
• 朝7時~24時が中心




                 15
飲食店勤務型
• 12時台にアクセスできない
 – 朝夕のログインが多い




                  16
通勤電車型
• 7時と19時付近にアクセスが集中
 – 残業によって帰宅時のピークは前後?




                       17
夜型
• 23時~4時を中心にログイン




                   18
本日のアジェンダ
• Drecomのデータ分析の環境の話
• ソーシャルゲームのゲームモデルの
  話
• データまいにんぐー
• 予備実験
• 本番環境構築
• 本番投入
• まとめ、反省
                      19
仮説
• 前提
 – 通勤電車型が夜型と友達になっても、
   救援依頼が飛んでこなくて面白くない
   可能性

• 仮説
 – 生活リズムが一致するユーザを結びつ
   ければ、救援依頼がリアルタイムにな
   り、ゲームが活性化する可能性
→アクセスパターンを元にフレンドを 20
プロトタイプの実験
• アクセスパターンをコサイン類似度
 – 上段元、下段推薦




                     21
プロトタイプの実験
• アクセスパターンをコサイン類似度
 – なんか正しいっぽい




                     22
本番環境を作る
• 構成検討
                              仲間リクエス
            仲間候補                 ト

 レコメンドサーバ    HTTP   ゲームサーバ
            優先度

      定期的に参
      照                 アクセスログ書き込み
       アップ
      デート   定期的に
    ユーザの     変換
                    アクセスログ
 アクセスパターン
                     (HDFS)
  (特徴ベクトル)

                                     23
データ量の見積もり
• データ量の見積もり
 – 浮動小数点
 – 24次元の固定長ベクトル
 – ユーザ数は100万人を想定
 – 推定で200MB
   • 8*24*1000000/1024/1024 = 183

• オンメモリで余裕(多分)
 – Dict型で実装
 – {user_id: feature_vector}

                                    24
本番の実装
• Python+BasicHTTPServerで実装
  – オンメモリでやるにはここからやらんと・・・

• HTTPでリクエストを受け付け
  – ゲームと疎結合にできる。
    • (Ruby書かなくてもいい)
  – 引数に推薦対象のIDと候補のIDを入れる
  – コサイン類似度の高い順にJSONで返される

• 見積もりとはいったいなんだったのか
  – ListからArrayにしてメモリ消費を半分にした
    が・・・
                                        25
                       ナンカイカOOMKillerニコロサレマ
本体の運用周りの細かい話
• アプリ開発者が困らないように
 – ブラウザで叩くとAPIリファレンス




                       26
運用周りのコード
• 特徴ベクトルの更新
 – crontabでログサーバからアクセスログ拾って
   きて、アクセスパターンを毎日に生成
 – 直近N日分のアクセスパターンを束ねて正規化
 – レコメンドサーバにkill SIGUSR1を送って更
   新
 – /etc/init.d/hogehoge を頑張って書く
  • PIDの記録とかメンドクサイ・・・


• ログ周り
 – 俺俺スレッドセーフロガーを作ったり
                              27
実装量
• レコメンドエンジン本体 Python300行
 –   オンメモリでユーザの特徴ベクトル保持
 –   HTTPで待ち受けてコサイン類似度
 –   スレッドセーフなロガーの提供
 –   Kill SIGUSR1でデータ更新

• /etc/init.d/用のシェルスクリプト 85行
 – start,stop,restart,update

• ユーザのアクセスログの集計 Python150行
 – HDFSを漁って、アクセスログからパターンを生成
 – パターンから過去n日分を集計して特徴ベクトル化
                               28
負荷試験
• ApatchBenchで負荷試験
 – 700 QPS が出る
 – ローカルポートが足りなくなってABが落ち
   る

• レイテンシー
 – 負荷試験時でも 7ms
 – アプリ側のタイムアウトは50msで設定

• 実際のアプリで仲間探しの呼び出し状況
 – 1QPS     ヤリスギ
            タ・・・         29
本日のアジェンダ
• Drecomのデータ分析の環境の話
• ソーシャルゲームのゲームモデルの
  話
• データまいにんぐー
• 予備実験
• 本番環境構築
• 本番投入
• まとめ、反省
                      30
アプリ導入と段階的開放
• アプリの人からの段階解放の提案

• 第一段階
 – 10%のユーザでレコメンドサーバを叩く
 – 結果は破棄
• 第二段階
 – 10%のユーザでレコメンドサーバを叩く
 – 結果を利用
• 第三段階
 – 50%のユーザでレコメンドサーバを叩く
 – 結果を利用
                         31
2ヶ月間ABテストの結果
• ユーザのゲーム継続率で評価
 – 差が出ない




                  32
結果と考察
• 結果
 – 生活時間があうユーザを優先的に組み合わせて
   も、継続率や売り上げに差が出なかった

• 考察
 – ユーザの仲間検索の利用頻度が低い
 – ユーザはRaidで活躍したユーザに対して、
   直接仲間申請を出している
 – アクセスパターンよりも、アクティブ率のほう
   が重要そう
   • 正規化の過程でアクティブ率の情報が消失してい
     る
 – gl○○psさんとか、CR○○Zさんのギルドゲー
   なら効果が出そう・・・
                              33
反省
• 既存ユーザのフレンドの調査
 – ゲーム内のスコアのよいユーザは時間帯が
   合っているのか?その逆は?
 – 夜型の人は昼にプレイする人と比べてログ
   イン回数が多いか?
 – 時間帯が合ってるフレンドが多いとどうな
   る?
• 導入後のフレンドの検証
 – ABテストのユーザ群のフレンドを調査、プ
   レイ時間が合ったユーザが何人いるか
                      34
まとめ
• 仮説
 – 似た人を仲間にしよう

• 実装
 – コサイン類似度でドーン

• 結果
 – 差が出なかったorz
 – パラメータ弄ってがんばってま
   す・・・             35

More Related Content

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