grasys blog

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

文●grasys 編集● ASCII

  • この記事をはてなブックマークに追加
  • 本文印刷

本記事はgrasys が提供する「grasys blog」に掲載されたゲームのデータ分析のポイントと、インフラ構築の勘所」を再編集したものです。

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

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

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

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

 Google Cloudを活用した処理のフローは、大きく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 Storageにもログを保存し、バッチ処理で1日1回、データの洗い替えを行なうパイプラインも並列させています。

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

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

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

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

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

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

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

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

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

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

■関連サイト

過去記事アーカイブ

2023年
01月
2022年
01月
02月
03月
04月
05月
06月
07月
08月
12月
2021年
03月
04月
05月
06月
07月
08月
09月
10月
11月
12月
2020年
04月
05月
08月
09月
10月
11月
12月
2018年
09月
2017年
06月
2014年
07月