Amazon Web Services ブログ

【開催報告】AWS for Games Live これからのゲームデータ分析環境を考える (10/19)

こんにちは、アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクトの川島です。2023 年 10 月 19 日に AWS for Games Live を開催いたしました。

AWS for Games Live とは?

AWS for Games Live は、AWS 公式ウェブマガジン builders.flash の記事と連動したイベントで、AWS for Games の 3 つの柱「Build」「Run」「Grow」の柱のうち 1 つにフォーカスを当てて、その内容を掘り下げるものです。参加者の方々には、ゲーム業界のトレンドを知ったりネットワーキングを楽しんだりする時間として活用していただいています。今回は、「これからのゲームデータ分析環境を考える」と題して、AWS でのゲーム分析について 4 つのセッションを設けました。

Aws for Games Live Session 01

AWS でこれから始めるゲーム分析

はじめに、ソリューションアーキテクト渡邉 真太郎から、ゲームを改善するための分析を予算や工数が限られたなかで進めていくために、サーバーレスな分析サービスを組み合わせた AWS でのゲーム分析の導入例をご紹介しました。資料はこちらのリンクからご覧いただけます。

本セッションでは最初に、Amazon Aurora にある基本 KPI データをエンジニアが SQL でアドホックに集計して制作チームに共有している状況を仮定しました。このとき、集計の処理時間の長期化や集計対応の工数が課題として想定されます。そこで第一に、Amazon Redshift Serverless というクラスター管理不要のクラウドデータウェアハウスを導入し、Amazon Aurora との Zero-ETL 統合をセットアップします。Amazon Aurora と Amazon Redshift の Zero-ETL 統合は現在機能の制限がある Public Preview のものであり、後段のセッションで詳しく紹介します。第二に、幅広いメンバーが定常的にデータを確認・分析するための可視化に、サーバーレスな BI サービスである Amazon QuickSight を導入します。

しかしこれでもなお、基本 KPI データだけではゲーム内のユーザーの動向を定量的に確認することができず、この課題を解消するためにはユーザー行動ログも出力し分析する必要があります。そこで第三に、Amazon Kinesis Data Firehose によりゲームサーバーやクライアントからユーザー行動ログを吸い出して Amazon Redshift Serverless に格納します。これにより、分析に必要な基本 KPI データとユーザー行動ログの双方を分析・可視化できるようになります。

このようにAWSのサーバーレスな分析サービスを組み合わせていくことで分析要件の変化に応じてゲーム分析環境を発展させられることをお話ししました。

Aws for Games Live Session 02

Amazon Aurora と Amazon Redshift の Zero-ETL 統合のご紹介

次に、同じくソリューションアーキテクトの佐藤 祥多から、Amazon Aurora と Amazon Redshift の Zero-ETL 統合 (以下単に「Zero-ETL 統合」) についてご紹介しました。資料はこちらのリンクからご確認ください。

Zero-ETL 統合は、ETL パイプライン不要で複数の Amazon Aurora データベースから Amazon Redshift に対して数秒以内にデータを複製できる、現在 Public Preview 中の機能です。現在は Amazon Aurora MySQL の一部バージョンのみをサポートしています。内部では Amazon Aurora の拡張 Binlog を利用してデータ複製をしているため、MySQL クラスタへの負荷を最小限に抑えられることや Crash recovery の時間が大幅に改善していることも特徴です。本機能は、ETL の運用軽減・データベースへの負荷軽減・リアルタイムでの可視化といった用途でお使いいただけます。

本セッションでは、ゲーム内の仮想通貨の動きをリアルタイムで可視化するデモもお見せしました。クライアントから送られた情報が、Amazon Aurora から Amazon Redshift に同期され、Amazon Managed Grafana で可視化されるという一連の流れをお見せし、設定の簡単さやリアルタイム性を実感していただける内容でした。

AWS for Games Live Session 03

Amazon Aurora MySQL と Amazon Redshift の Zero-ETL 統合について使い所を考えてみた!

続いて、面白法人カヤックの池田 将士氏から、Zero-ETL 統合の具体的な使い道やメリットについてご紹介をいただきました。資料はこちらのリンクからご覧いただけます。

池田氏が Zero-ETL 統合のメリットを論じるにあたって挙げたキーワードは「VPC 超え」でした。

AWS for Games Live Session 03

Amazon Aurora と Amazon Redshift が異なる VPC にある場合、VPC を跨いだデータ搬送が必要になります。この「VPC 超え」の状況は、複数ゲームタイトルの統合的な分析のための分析用アカウントを用いるクロスアカウント分析の場合などに発生します。そして、そのときに Zero-ETL 統合のメリットが大きいというのが池田氏の着目する点です。「VPC 超え」のデータ搬送においては、これまで、Amazon S3 のスナップショットを経由する方法や VPC Peering で Federated Query もしくは変更データキャプチャ (CDC) を用いる方法、パブリックアクセスで AWS IAM を用いて権限を付与する方法といったものがありました。しかし、それぞれの方法で、リアルタイム性や管理の手間といった課題はありました。一方で Zero-ETL 統合なら、AWS マネージドかつニアリアルタイムで、VPC やアカウントが異なっていても CDC ができるという旨味があります。

一方で、Amazon Aurora と Amazon Redshift が同一 VPC 内に存在するときは、Federated Query で十分な場合もあります。しかしながら、それでも Zero-ETL 統合により享受できるメリットもあります。第一に、大量のデータを扱うときには Federated Query では Amazon Aurora 側の読み込み負荷が気になるため、Zero-ETL 統合によりその負荷を軽減できます。第二に、Amazon Aurora MySQL は行指向のデータベース、Amazon Redshift は列指向のデータベースなので、Zefo-ETL 統合を導入して両者を使い分けながらクエリを操作することで、効率的に分析できるようになります。これにより、HTAP (Hybrid Transactionla/Analytical Processing) と呼ばれる、トランザクション処理と分析処理の両方が行えるデータベースと同じような使い方が実現できるのです。

モンストシリーズでのデータ分析戦略

最後に、株式会社 MIXI の白川 裕介氏から、モンストシリーズにおけるデータ分析戦略についてご紹介をいただきました。資料はこちらのリンクからご覧いただけます。

モンストシリーズは 1 年弱で 6 個と多くのタイトルが出ており、内製開発と他社による開発のいずれもが共存しておりました。当初は各デベロッパーが個別最適化しながらゲーム開発していたのですが、その点に課題を感じた MIXI では統一されたルールを定義しました。そのなかで、今回は KPI などのデータ分析の方針のルールを取り上げてご紹介いただきました。

AWS for Games Live Session 04

第一に、ログイン・課金・ゲームプレイといった全タイトルで共通の KPI ログを定義し、ログフォーマットも共通化して同じクエリで分析できるようにしています。加えて、それ以外の各タイトル固有の KPI ログは個別に取得しています。ログの取得は MIXI で検証して開発社にサンプルの実装を提供しました。

第二に、KPI ログの転送では、Amazon Kinesis Agent・Amazon Kinesis Data Streams・Amazon Kinesis Data Firehose を用いたデータ転送フローの標準仕様を策定しました。なお、Amazon Kinesis Data Streams がなくても構成は可能ですが、Amazon Kinesis Data Firehose の仕様上 PutRecord 時のデータごとの改行が必要だったり、恒常的な大量の流量を捌けないことがあったりする点に注意が必要です。なお、開発社によっては Fluent Bit や CloudWatch を用いたカスタマイズもしています。

第三に、Aurora MySQL スナップショットの方法にも 2 通りの方法を決めています。 1 つ目が SELECT INTO OUTFILE の SQL ステートメントを実行する方法です。ここでは、インスタンスへの負荷を考慮してリードレプリカを用いることや AWS Lambda でのタイムアウトを避けるため AWS Glue ジョブの Python Shell で実行することを推奨しています。2 つ目が Amazon S3 のエクスポート機能を用いる方法です。こちらは制約が多い代わりに簡単に実行できるものです。

以上に挙げた内容は、後から決めるのではなく最初に決めておくことが大事だと白川氏は強調しました。MIXI では、一定のルールを設けつつも後から柔軟に変更しています。そしてデータ形式やインフラの共通化により、リソースの最適化や横断的な同様のクエリでの分析の実現といったメリットがありました。

最後に

今回ご紹介したものをはじめとして、AWS 上には効率的に分析するための様々なサービスや機能があります。ゲームを発展させるのに分析は一つの重要な要素ですので、ご自身のゲームにおいてもぜひ活用をご検討ください。また、AWS for Games Live は AWS 公式ウェブマガジン builders.flash と連動して、定期的に開催しております。今回複数のセッションで紹介された現在 Public Preview 中の Zero-ETL 統合機能も、builders.flash 内の記事で取り上げていますので、ご興味があればぜひご覧ください。

※この記事はTakumi Kawashimaが作成し、Hiroshi Sumiが代理で投稿しています。