お問い合わせ

※下の記事は2021年4月13日に放送された Google Cloud (GCP) INSIDE Games & Apps のセッション内容をもとに作成しています。前編記事はこちら

ゲームのデータ分析のポイントと、インフラ構築の勘所

ゲームでは離脱ユーザーの予測やゲーム内のアイテムのリコメンドなど、様々なケースでデータ分析が活用されています。データ分析においては、アクティブユーザーの増加による大量のデータの発生を考慮し、これをいかに効率的に扱えるようにしていくかがポイントです。

Google Cloud (GCP) がソリューション デザインパターンを公式サイトで公開していますが、その中にはゲームに関するデータ分析のパターンもあります。こういった資料を参考にアーキテクチャを考えるのも一つの手法です。

ゲームのデータ分析パイプライン2類型

Google Cloud (GCP) を活用した処理のフローは、大きく2つあります。1つ目は、ストリーミング処理で個々のイベントを処理するフロー、2つ目は、バッチ処理で集約されたイベントを一括処理するフローです。

ストリーミング処理のパターンでは、Google アナリティクスを活用してログを集約し、BigQuery に連携するアーキテクチャを採用します。また、ゲーム関連のクライアントの場合、Cloud Pub/Sub を通して Dataflow を使用し、データを集計・加工して BigQuery に入れることでストリーミングのパイプラインを構築する例も多く見られます。

次にバッチ処理のパターンでは、CSV などの固まったデータを Cloud Storage などにまとめて置いておき、Dataflow で吸い上げて加工し BigQuery に入れていくフローを取ります。また、既に成形されているデータであれば gsutil を使ったり、他社のクラウドプロバイダに保管されたデータであれば StorageTransfer Service を使ってデータ連携を行うことで BigQuery に入れることもできます。

いずれのパターンにおいても、必要なデータを効率的に取得することは意識すべきです。無駄なデータの取得・分析にはコストがかかるので、どのような分析を行いたいかを念頭に置くことが重要となります。

実際のアーキテクチャ例①

grasysで実際に構築した事例をご紹介します。例①のパターンは、他社のシステムに置かれているログを転送して BigQuery に入れるストリーミング処理のフローです。fuluentd でログを送信し、そのログを仮想マシンで受け、それを別の仮想マシンの logstash に送ってBigQuery に保存しています。データはストリーミングで処理しますが、欠損の可能性に備えてバックアップを取るために、Google Cloud (GCP) Storage にもログを保存し、バッチ処理で一日一回、データの洗い替えを行うパイプラインも並列させています。

実際のアーキテクチャ例②

例②のパターンは、モバイル端末から取得したデータをゲームサーバーで受け、Cloud Pub/Sub を使って Dataflow を通し、BigQuery に入れるストリーミング処理のフローです。こちらは Google Cloud (GCP) が公式サイトで公開しているリファレンス アーキテクチャで、一度安定して稼働できれば管理の手間の少ない運用ができる構成となっています。

ゲームサーバーからストリーミングでデータを連携させるパイプラインとした理由は、クライアントの要望として、リアルタイムでデータ分析を行いたい意図があったためです。そこまでリアルタイムにこだわらないのであれば、10分に1回程度のバッチを回すことで、リアルタイムに近い分析を行うことは可能です。そのため、ストリーミング／バッチどちらを選択するかの判断のポイントとして、構築前にお客様とのディスカッションを行い、どれくらいのリアルタイム性でデータ分析を行う必要があるかを詰めることが重要です。

リファレンス アーキテクチャは、運用管理の手間やコストが抑えられるメリットはありますが、プログラム処理の問題など何かの拍子に上手くスケーリングしない場合もあります。そのため、構築段階から想定外のことが起こってもスケーリングするよう調整することを念頭に見積をしっかり行います。また常に安定して稼働できるよう、起動のパラメータを調整し、多めにワーカーノードが立ち上がる設定にするなど、自動調整だけに頼らず工夫を施しています。

Google Cloud (GCP) でデータ分析基盤を構築するメリット

データウェアハウスなら BigQuery、分散処理なら Dataflow など、一通りのサービスがマネージドで揃っている点が挙げられます。また、それらのサービスを組み合わせるためのインテグレーションが成されており、簡単な設定ですぐ連携できる点も長所です。特に BigQuery は、データを入れてしまえば手放しで運用でき、ひたすら分析に集中できるため非常に利便性が高いです。

前編記事のアーキテクチャ例でも紹介した Cloud Spanner は、ノードを大きくする・減らすことへのフレキシブルな対応ができる点に活用の幅を感じています。以前はデータベースをシャーディングして分散させることに手間をかけていたので、それを考えなくてよくなるメリットは大きいです。障害発生率も少なく、実際にインフラの運用コストを減らす効果がありました。

今後は、Cloud Run も活用していきたいと考えています。Cloud Run は、今までご説明した事例の構築時には GA されていなかったため採用していませんでしたが、様々なプロトコルに対応でき、機能が充実してきています。また GKE Autopilot は少し高価格ですが、今まで運用に回していたコストの削減が見込めたり、ノードプールの管理を自動化することで単価を下げられる可能性もあります。

今後も grasys では、Google Cloud (GCP) の幅広い選択肢を活用して、最適なソリューションを提案してまいります。