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

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

ところてん＠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

ドリコムのデータ分析環境の構成

M-DB1 M-DB2 M-DB3 M-DB4 M-DB5

S-DB1S S-DB2 S-DB3 S-DB4 S-DB5

ActiveRecord TurntableユーザIDごとに水平分割

Webサーバ数十台

マスター5台

スレーブ5台

FIOを搭載した分析用サーバ1.2TBのFIO、16コア、メモリ32GB

定期的にDBのダンプを取得

ログサーバ(HDFS)

HDFSから必要なログを収集

Fluentd

7

Fuse-hdfs

データ分析の人的問題

• 全部を満たすのは難しい

–統計分析能力（必須）

–ゲームそのものに対する理解

–データ抽出、前処理能力

–機械学習、マイニング

–可視化

–並列処理、分散処理(hadoop)

8

分析のトレードオフ

• 分散を諦めた–ゲームのDBからぶっこぬいてきたデータをhadoopに再格納するのか？

– FIOが速いので、分散する必要が無い– PDCAが3日で回っていると、分散処理をデバッグしている暇が無い

– Impalaの本番投入待ち

• 分析用サーバは核実験場–分析メソッドが安定化したら、インフラ部隊と連携してhadoopに移植

9





• 予備実験


• 本番投入


ソーシャルゲームのゲームモデル

• Raidモデル

–強力なボスをみんなで殴って倒す

–例)ドリ■ンド

• 問題点

–自分の仲間と時間帯が合わないと一緒に楽しめない

–寝てるときに救援を出されてもなぁ

→とりあえずアクセスパターンを調査する

11

ユーザのアクセスパターンの分析

• ユーザの活動時間を分析する–1時間ごとにスロット分割

–当該時間帯にアクセスしたかどうかをカウント

–100回アクセスも1回アクセスも1とカウント

–一年分のアクセスパターンを足して畳み込む

• 可視化はExcel （キリッ–条件書式による擬似ヒートマップは正義

12

一日分のアクセスパターン

• 横軸時間、縦軸ユーザ

13

アクセスパターンの畳み込み

• 過去一年分を加算する

• 24次元のベクトルとみなして正規化14

一般的なアクセスパターン

• 朝7時～24時が中心

15

飲食店勤務型

• 12時台にアクセスできない

–朝夕のログインが多い

16

通勤電車型

• 7時と19時付近にアクセスが集中

–残業によって帰宅時のピークは前後？

17

夜型

• 23時～4時を中心にログイン

18





• 予備実験


• 本番投入


仮説

• 前提

–通勤電車型が夜型と友達になっても、救援依頼が飛んでこなくて面白くない可能性

• 仮説

–生活リズムが一致するユーザを結びつければ、救援依頼がリアルタイムになり、ゲームが活性化する可能性

→アクセスパターンを元にフレンドを推薦

20

プロトタイプの実験

• アクセスパターンをコサイン類似度

–上段元、下段推薦

21

プロトタイプの実験

• アクセスパターンをコサイン類似度

–なんか正しいっぽい

22

本番環境を作る

• 構成検討

レコメンドサーバ

仲間候補

優先度

アクセスログ（HDFS）

ユーザのアクセスパターン(特徴ベクトル)

定期的に変換

定期的に参照

アップデート

アクセスログ書き込み

仲間リクエスト

ゲームサーバHTTP

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にしてメモリ消費を半分にしたが・・・

ナンカイカOOMKillerニコロサレマシタ

25

本体の運用周りの細かい話

• アプリ開発者が困らないように

– ブラウザで叩くと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





• 予備実験


• 本番投入


アプリ導入と段階的開放

• アプリの人からの段階解放の提案

• 第一段階– 10%のユーザでレコメンドサーバを叩く– 結果は破棄

• 第二段階– 10%のユーザでレコメンドサーバを叩く– 結果を利用

• 第三段階– 50%のユーザでレコメンドサーバを叩く– 結果を利用

31

2ヶ月間ABテストの結果

• ユーザのゲーム継続率で評価

–差が出ない

32

結果と考察

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

• 考察– ユーザの仲間検索の利用頻度が低い– ユーザはRaidで活躍したユーザに対して、直接仲間申請を出している

– アクセスパターンよりも、アクティブ率のほうが重要そう• 正規化の過程でアクティブ率の情報が消失している

– gl○○psさんとか、CR○○Zさんのギルドゲーなら効果が出そう・・・

33

反省

• 既存ユーザのフレンドの調査

–ゲーム内のスコアのよいユーザは時間帯が合っているのか？その逆は?

–夜型の人は昼にプレイする人と比べてログイン回数が多いか？

–時間帯が合ってるフレンドが多いとどうなる？

• 導入後のフレンドの検証

– ABテストのユーザ群のフレンドを調査、プレイ時間が合ったユーザが何人いるか

34

まとめ

• 仮説

–似た人を仲間にしよう

• 実装

–コサイン類似度でドーン

• 結果

–差が出なかったorz

–パラメータ弄ってがんばってます・・・ 35

Technology

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