Upgrade to Pro — share decks privately, control downloads, hide ads and more …

GCPをフル活用したゲームログ収集基盤の構築

 GCPをフル活用したゲームログ収集基盤の構築

Takumasa Sakao

July 14, 2018
Tweet

More Decks by Takumasa Sakao

Other Decks in Technology

Transcript

  1. 自己紹介 • @sachaos (サカオスと読みます) • 好きなもの – 黒い画面 – Golang

    – OSS をいくつかGitHubで 公開しています • 所属: 株式会社アカツキ – 新卒 3 年目 – 技術基盤開発 – Golang, GCP とか – ゲーム新規開発・運用 – Ruby on Rails, etc – 最近仕事で Elixir 書き始めました
  2. ゲームログの例 ・ ・ ・ • 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 がガチャを引いて強キャラを手に入れた!
  3. 定常的な分析 • DAU (Daily Active User) や 売上など毎日知りたい情報。 • KPI

    の達成具合を測り、様々な意思決定をする。 • ダッシュボードで常に表示しておく。 • Slack に定期的に通知するようにしている。
  4. アドホックな分析 • 今後の施策の意思決定のために現状を把握する。 – e.g. エリクサーが多く流通している。 次はもう少し難しいイベントを企画してみよう。 • 因果関係を見つける為、仮説を探し検証する。 –

    e.g. 1. 継続率が高い(毎日ログインしている)ユーザーを 分析して見ると他のユーザーに比べて フレンドが多いという結果が出た。 2. これを仮説として、 フレンドを増やす施策を打ち出してみた。 3. これの効果測定(継続率が上がったか否か)をして、 仮説を検証する。
  5. GCPをフル活用した ゲームログ収集基盤 Cloud Pub/Sub Cloud Dataflow BigQuery App Engine App

    Engine AWS GCP Cloud Dataflow 定期的なバッチ処理 BigQueryと BIツール(Metabase)による分析 ログの収集システム アプリケーション サーバークラスタ
  6. Fluentd Log Aggregator Pattern • Pros – Fluentd Plugin が豊富なので、簡単に

    Aggregator から 様々なデータウェアハウスに送ることができる。 • Cons – プラグインごとに設定を細かく行う必要がある。 – マネージドサービスはない – 自前でサーバーを立てないといけない。 – データの送信失敗などを監視・通知するような仕組みを 作らないといけない – Log Aggregator が落ち、fluentd の設定不足で ログを欠損させてしまったという苦い思い出もある・・・。
  7. AWS Kinesis Firehose • Pros – とりあえず S3 に自動的にデータを転送することができる。 勝手にスケールもする。

    • Cons – S3 から BigQuery にどうやって格納するか という別の問題が発生する。 – Embulk などを使用する?しかしそれでは別のサーバーが必要。 – S3 の Put event を検知して AWS Lambda を走らせる? しかし、失敗した場合はどのように再実行させるか?
  8. AWS Kinesis + AWS Lambda • Pros – Firehose と比べるとストリームを

    Lambda で処理でき、 BigQuery にそのまま投げることができて嬉しい。 エラーが起きた場合はリトライもやってくれる。 • Cons – シャード数のチューニングを考えないといけない。
  9. Cloud Pub/Sub + Dataflow • Cloud Pub/Sub – アプリケーションのログを一旦ストアしておくために使用する。 メッセージキューサービス。

    – 複数のサブスクライバ(購読者)に対してメッセージを送ることが可能。 BigQuery 向けだけではなく Storage 向けの Dataflow にも購読させ、 両方にデータをストアするようにしている。 • Cloud Dataflow – Pub/Sub からデータを取得して BigQuery へインサートする。 – Google 提供のテンプレートも存在する – Pub/Sub to BigQuery – Pub/Sub to Storage – 処理するデータ量、計算量に応じて勝手にスケールする。 – エラーの際にリトライはもちろん、 コードに問題があった場合は更新もすることができる。 – サーバーレスは麻薬。
  10. インフラ管理 • リソース作成・更新操作が必要 – Dataflow の Job の実行 – BigQuery

    の テーブル定義 – Pub/Sub トピックの作成 • これらをコードで管理したい • Terraform でもよかったが GCP API を Rake タスクで叩くようにした。
  11. Q. なぜ GCP API ? A. BigQuery のテーブルのスキーマと ログのスキーマ定義の二重管理を 防ぎたかったから

    また、設定項目がシンプルなので API を叩くだけで十分そうだった。
  12. ログのスキーマ定義の二重管理 • BigQuery のスキーマを定義する何か(例えば JSON, DDL)と アプリケーション内でログを表す(例えばクラス)で スキーマ定義が重複する。 • e.g.

    signin というユーザーのサインインのログを考える signin.rb signin.json RUBY JSON LOG ログデータ BigQuery の signin テーブル
  13. バッチ処理をやるにも GCP では様々な選択肢がある。 • Cloud Dataflow – バッチ、ストリーム両方に対応した ETL サービス。

    • Cloud Functions – AWS の Lambda のようなもの – いわゆる FaaS • Google App Engine – AWS Elastic beanstalk, heroku のようなもの – いわゆる PaaS – Standard Environment と Flexible Environment がある。 – SE の方が、 FE に比べて様々な制限があるが、 よりサーバーレスをキメることができる。 – デプロイ早い! – スケールも爆速!
  14. クエリ一発で終わって 結果セットが小さい物は GAE。 それ以外は Dataflow。 • クエリ1発で結果セットが小さい物は Cloud Dataflow で実行させる必要がない。

    – 例えば、売上を計算する場合結果セットは 1 レコードで済む – しかし、ユーザーごとの売り上げを計算する場合は ユーザーごとにレコードがあり、結果セットが大きい。 • Dataflow は実行のオーバーヘッドがかなり大きいので、 小さなものを処理させるのには向いていない。 • GAE を使用すると GAE Cron Serviceと組み合わせることもできて楽。
  15. 定常的な分析、ダッシュボード • Google App Engine Flexible Environment を使って 試験的に Metabase

    を動かしている。 • が、Metabase のつらみは結構ある。。。 – BigQuery Standard SQL の相性が悪い。 – 複合グラフが作れない – Slack の public チャンネルにしか投稿できない – etc • Re:dash, Google Data Studio の導入を検討中。