Slide 1
Slide 1 text
GCPをフル活用した
ゲームログ収集
基盤の構築
Rails Developers Meetup 2018 Day 3 Extreme
@sachaos
Slide 2
Slide 2 text
自己紹介
• @sachaos
(サカオスと読みます)
• 好きなもの
黒い画面
Golang
OSS をいくつかGitHubで
公開しています
• 所属: 株式会社アカツキ
新卒 3 年目
技術基盤開発
Golang, GCP とか
ゲーム新規開発・運用
Ruby on Rails, etc
最近仕事で Elixir 書き始めました
Slide 3
Slide 3 text
Q. ゲームログとはなにか？
Slide 4
Slide 4 text
Q. ゲームログとはなにか？
ゲームログ
=
プレイヤーの行動の記録
A.
Slide 5
Slide 5 text
ゲームログの例
・
・
・
• 2018/07/13 16:36:09 sachaos がエリクサーを 5 個手に入れた！
• 2018/07/13 16:36:13 sachaos がエリクサーを 3 個消費した！
• 2018/07/13 16:38:20 sachaos がクエストをクリアしたよ！
• 2018/07/14 01:10:05 sachaos がガチャを引いて強キャラを手に入れた！
Slide 6
Slide 6 text
Q. なぜログを集めるのか？
Slide 7
Slide 7 text
Q. なぜログを集めるのか？
A. 分析をするため
Slide 8
Slide 8 text
Q. なぜログを集めるのか？
A. 分析をするため
データからゲームを遊んでいるプレイヤーの状態、
感情を理解してそれをゲームの改善につなげる。
Slide 9
Slide 9 text
分析
• 定常的な分析
• アドホックな分析
Slide 10
Slide 10 text
定常的な
分析
Slide 11
Slide 11 text
定常的な分析
• DAU (Daily Active User) や 売上など毎日知りたい情報。
• KPI の達成具合を測り、様々な意思決定をする。
• ダッシュボードで常に表示しておく。
• Slack に定期的に通知するようにしている。
Slide 12
Slide 12 text
アドホックな
分析
Slide 13
Slide 13 text
アドホックな分析
• 今後の施策の意思決定のために現状を把握する。
e.g.
エリクサーが多く流通している。
次はもう少し難しいイベントを企画してみよう。
• 因果関係を見つける為、仮説を探し検証する。
e.g.
1. 継続率が高い(毎日ログインしている)ユーザーを
分析して見ると他のユーザーに比べて
フレンドが多いという結果が出た。
2. これを仮説として、
フレンドを増やす施策を打ち出してみた。
3. これの効果測定(継続率が上がったか否か)をして、
仮説を検証する。
Slide 14
Slide 14 text
ゲームログを
BigQuery に送ることができれば
とりあえず分析はできる
Slide 15
Slide 15 text
しかし、
早く正確に分析するために
遅延・抜け漏れ無く
ログを集めたい
Slide 16
Slide 16 text
GCPをフル活用した
ゲームログ収集基盤
Slide 17
Slide 17 text
GCPをフル活用した
ゲームログ収集基盤
Cloud
Pub/Sub
Cloud
Dataflow
BigQuery App Engine
App Engine
AWS GCP
Cloud
Dataflow
定期的なバッチ処理
BigQueryと
BIツール(Metabase)による分析
ログの収集システム
アプリケーション
サーバークラスタ
Slide 18
Slide 18 text
Q. なぜこの構成にしたのか？
Slide 19
Slide 19 text
Q. なぜこの構成にしたのか？
A. GCP が使いたかったから！
Slide 20
Slide 20 text
Q. なぜこの構成にしたのか？
A. GCP が使いたかったから！
A. 様々な構成を検討した結果、
一番楽に運用できそうだったから
Slide 21
Slide 21 text
検討したログ収集システム構成
Fluentd Log
Aggregator
Pattern
1
AWS Kinesis
Firehose
2
AWS Kinesis
+ Lambda
3
Cloud Pub/Sub
+ Dataflow
4
Slide 22
Slide 22 text
Fluentd
Log Aggregator Pattern
• Pros
Fluentd Plugin が豊富なので、簡単に Aggregator から
様々なデータウェアハウスに送ることができる。
• Cons
プラグインごとに設定を細かく行う必要がある。
マネージドサービスはない
自前でサーバーを立てないといけない。
データの送信失敗などを監視・通知するような仕組みを
作らないといけない
Log Aggregator が落ち、fluentd の設定不足で
ログを欠損させてしまったという苦い思い出もある・・・。
Slide 23
Slide 23 text
AWS Kinesis Firehose
• Pros
とりあえず S3 に自動的にデータを転送することができる。
勝手にスケールもする。
• Cons
S3 から BigQuery にどうやって格納するか
という別の問題が発生する。
Embulk などを使用する？しかしそれでは別のサーバーが必要。
S3 の Put event を検知して AWS Lambda を走らせる？
しかし、失敗した場合はどのように再実行させるか？
Slide 24
Slide 24 text
AWS Kinesis + AWS Lambda
• Pros
Firehose と比べるとストリームを Lambda で処理でき、
BigQuery にそのまま投げることができて嬉しい。
エラーが起きた場合はリトライもやってくれる。
• Cons
シャード数のチューニングを考えないといけない。
Slide 25
Slide 25 text
Cloud Pub/Sub + Dataflow
• Cloud Pub/Sub
アプリケーションのログを一旦ストアしておくために使用する。
メッセージキューサービス。
複数のサブスクライバ(購読者)に対してメッセージを送ることが可能。
BigQuery 向けだけではなく Storage 向けの Dataflow にも購読させ、
両方にデータをストアするようにしている。
• Cloud Dataflow
Pub/Sub からデータを取得して BigQuery へインサートする。
Google 提供のテンプレートも存在する
Pub/Sub to BigQuery
Pub/Sub to Storage
処理するデータ量、計算量に応じて勝手にスケールする。
エラーの際にリトライはもちろん、
コードに問題があった場合は更新もすることができる。
サーバーレスは麻薬。
Slide 26
Slide 26 text
運用
インフラ管理
バッチによる
データ処理の
方法
データ分析の
方法
Slide 27
Slide 27 text
インフラ管理
Slide 28
Slide 28 text
インフラ管理
• リソース作成・更新操作が必要
Dataflow の Job の実行
BigQuery の テーブル定義
Pub/Sub トピックの作成
• これらをコードで管理したい
• Terraform でもよかったが
GCP API を Rake タスクで叩くようにした。
Slide 29
Slide 29 text
Q. なぜ GCP API ?
A. BigQuery のテーブルのスキーマと
ログのスキーマ定義の二重管理を
防ぎたかったから
また、設定項目がシンプルなので
API を叩くだけで十分そうだった。
Slide 30
Slide 30 text
ログのスキーマ定義の二重管理
• BigQuery のスキーマを定義する何か(例えば JSON, DDL)と
アプリケーション内でログを表す(例えばクラス)で
スキーマ定義が重複する。
• e.g. signin というユーザーのサインインのログを考える
signin.rb
signin.json
RUBY
JSON
LOG
ログデータ
BigQuery の signin テーブル
Slide 31
Slide 31 text
ログのスキーマ定義の二重管理
• ログデータも、BigQuery のテーブルも同じファイルから
生成すれば二重管理ではなくなる。
• これによって、片方を更新し忘れて、
BigQuery のインサートに失敗するということがなくなる。
signin.rb
signin.json
RUBY
JSON
LOG
ログデータ
BigQuery の signin テーブル
Slide 32
Slide 32 text
Schema をログクラスに定義
テーブル名を
定義
各フィールドの
型を定義
Slide 33
Slide 33 text
Schema から
BigQuery のテーブルを作成
先ほどのクラス
を取得
BigQuery API
の形式に調整
APIを叩いて
テーブル作成
Slide 34
Slide 34 text
バッチによる
データ処理の方法
Slide 35
Slide 35 text
定常的な分析を行うために
• 定期的に(Cron のように)分析を行う。
• 分析のための中間テーブルを作成する。
Slide 36
Slide 36 text
バッチ処理をやるにも
GCP では様々な選択肢がある。
• Cloud Dataflow
バッチ、ストリーム両方に対応した ETL サービス。
• Cloud Functions
AWS の Lambda のようなもの
いわゆる FaaS
• Google App Engine
AWS Elastic beanstalk, heroku のようなもの
いわゆる PaaS
Standard Environment と Flexible Environment がある。
SE の方が、 FE に比べて様々な制限があるが、
よりサーバーレスをキメることができる。
デプロイ早い！
スケールも爆速！
Slide 37
Slide 37 text
クエリ一発で終わって
結果セットが小さい物は GAE。
それ以外は Dataflow。
• クエリ1発で結果セットが小さい物は
Cloud Dataflow で実行させる必要がない。
例えば、売上を計算する場合結果セットは 1 レコードで済む
しかし、ユーザーごとの売り上げを計算する場合は
ユーザーごとにレコードがあり、結果セットが大きい。
• Dataflow は実行のオーバーヘッドがかなり大きいので、
小さなものを処理させるのには向いていない。
• GAE を使用すると
GAE Cron Serviceと組み合わせることもできて楽。
Slide 38
Slide 38 text
データ分析の方法
Slide 39
Slide 39 text
定常的な分析、ダッシュボード
• Google App Engine Flexible Environment を使って
試験的に Metabase を動かしている。
• が、Metabase のつらみは結構ある。。。
BigQuery Standard SQL の相性が悪い。
複合グラフが作れない
Slack の public チャンネルにしか投稿できない
etc
• Re:dash, Google Data Studio の導入を検討中。
Slide 40
Slide 40 text
まとめ
• ユーザーを正しく分析するために早く正確な分析基盤を
作ることが大事です。
• GCP をフル活用したゲームログ収集基盤の構築とそこに
至った過程、運用方法の共有を行いました。
• GCP のマネージドサービスは
本当にマネージドされている感があって
運用フローも楽に構築できた印象です。
Slide 41
Slide 41 text
以上です。
ご静聴ありがとうございました。