【レポート】未来のための設計、ゲームのためのフレキシブルな分析アーキテクチャの構築 #reinvent #GAM401

はじめに

本記事はAWS re:Invent 2017のセッション「GAM401 - Designing for the Future: Building a Flexible Event-based Analytics Architecture for Games」のレポートです。

登壇者

Brent Nash - Sr. Software Dev Engineer, Amazon Game Studios

レポート

概要

The pace of technology innovation is relentless, especially at AWS. Designing and building new system architectures is a balancing act between using established, production-ready technologies while maintaining the ability to evolve and take advantage of new features and innovations as they become available. In this session, learn how Amazon Game Studios built a flexible analytics pipeline on AWS for their team battle sport game, Breakaway, that provided value on day one, but was built with the future in mind. We will discuss the challenges we faced and the solution we built for ingesting, storing and analyzing gameplay telemetry and dive deep into the technical architecture using AWS many services including Amazon Kinesis, Amazon S3, and Amazon Redshift. This session will focus on game analytics as a specific use case, but will emphasize an overarching focus on designing an architectural flexibility that is relevant to any system.

本セッションは、ゲームの分析用ログの取得の仕組みについての解説です。

例として、ゲームの難易度を分析するためのヒートマップ（プレイ中に死亡イベントが起きた場所をゲームのマップ上に可視化）の作成があげられていました。

死にやすい場所はどこか？開発者の想定していない場所ではないか？を分析することで、マップの構造やその他要素の検討材料となります。

2015年と現在のプロトタイピング

• かつてはゲームそのもののプロトタイピングだったが、分析によるプロトタイピングが行える
  • 色々な条件からくる、変更や新しい要素を適用する準備をしたい

アーキテクチャ

ログのフォーマット

• 選択肢は色々ある（CSV,JSON,バイナリ,xml....）
• 帯域の制限はどうか？
• ダウンストリームのサポートはある？
• 拡張できる？

データはどこから送られてくる？

• サーバから送られてくるデータは信頼できる
• クライアントサイドから送られてくるデータは信頼できない（改竄できる）

大雑把なログの利用の流れ

• Kinesissで受け取ったイベントを保存し、保存して分析

ログの種別ごとのアーキテクチャ（Coldデータ）

どんなデータ？

• 長く保持したい（数年単位）
• アクセスはすぐにできなくてもいい
• 厳密ではないが、構造化されている
• 重複してしまってもいい

アーキテクチャ

Elastic BeanstalkアプリケーションでKinessisからデータをS3に投入

アプリケーションの動作の流れ

ログの種別ごとのアーキテクチャ（Warmデータ）

どんなデータ？

• 半年単位で保持
• アクセスはそれなりに早くできる必要がある
• 分析結果は1時間くらいで応答
• 構造化されている
• 重複は許さない

アーキテクチャ

• S3に投入したデータをRedshiftに投入するアプリケーションを使う
• RedshiftからTableauやその他ツールで分析する

重複はどうする？

1. まずステージング用の一時テーブルにデータを投入
2. クエリで新しいイベントデータだけをdeputeテーブルに投入
3. deputeテーブルをメインのテーブルに写して1,2で作成した一時テーブルを削除

Pythonでヒートマップを出力する場合のコード例

座標でグルーピングしたデータをカウントしています。

ログの種別ごとのアーキテクチャ（Hotデータ）

どんなデータ？

• 週単位で保持
• アクセスは素早くできる必要がある
• 分析結果は5分くらいで応答
• 構造化されている
• 重複は許さない

アーキテクチャ

KinessisからElasticsearchに流すアプリケーションを使う

クラッシュレポートはどうする？

SNS経由でKinesisに流す。

新しいサービスを使ったアーキテクチャ

• KinesisからAmazon Kinesis Analyticsで分析
• S3からAmazon Athenaで分析
• RedshiftからAmazon QuickSightで分析

まとめ

ログはただ出力すれば良いものではなく使えるものを出力しなければいけませんが、一方でユースケースは無数にあり分析内容を事前に確定させることは難しいです。 柔軟に利用できるログの出力について、大雑把なユースケースからログの種類を分類し、速度感に合わせたそれぞれのアーキテクチャの紹介セッションでした。

ヒートマップはゲームの世界に関わらず、WebやモバイルのアプリケーションでもUIとマッピングすることで何か役に立つ分析ができそうな気がします。

私からは以上です。