資料請求
お問い合わせ
  • Google Cloudに関する記事
5分で読める

【まとめ】Google Cloud Next Tokyo ’24 DAY 2 ブレイクアウト セッション「BNE ゲームタイトルにおけるリリース前後のインフラの最適化と課題」

こんにちは、クラウドエース 技術本部 SRE 部の高橋です。

2024 年 8 月 2 日、Google Cloud のカンファレンス イベント Google Cloud Next Tokyo ’24 DAY 2 が開催され、Google Cloud の生成 AI のコンセプトと実際の活用事例についての発表が行われました。
 
今回は、Google Cloud Next Tokyo ’24 DAY 2 のブレイクアウト セッション「BNE ゲームタイトルにおけるリリース前後のインフラの最適化と課題」の内容をご紹介します。

このセッションでは、株式会社バンダイナムコエンターテインメント（以下、BNE社）がネットワークをメインにしたゲームをリリースする際、リリース当日からユーザーに完璧な体験を提供するために、堅牢でスケーラブルなクラウド インフラストラクチャを Google Cloud 上でどのように構築し、大きな負荷に備えているかについて話をされました。
複数のゲームタイトルを立ち上げる際の具体的な事例も交えながら解説されました。
 
まず、BNE 社の河原 真太郎 氏から、BNE 社が最近リリースした Google Cloud を使用したゲームが 2 つ紹介されました。
 

サーバーコストの圧縮

まず 1 つ目に、「僕のヒーローアカデミア ULTRA RUMBLE」が紹介されました。

このゲームは、アウトゲーム部分とインゲーム部分の 2 つのサーバーで構成されています。
今回はインゲーム部分の中でも、ゲーム内の対戦を管理する部分である Dedicated Game Sever におけるコストの圧縮についてのお話でした。

このゲームは元々、n1-standard-4 のマシンスペックの Dedicated サーバーで動かされており、CPU 1.8 コアで 1 試合分の動作をサーバーで処理できるため、1 サーバーにつき 2 試合同時に実行できていました。
 
試合が終わるごとにサーバーの課金が停止する、つまり試合数によって課金される仕組みになっており、コスト効率が非常に重要になります。
特に、このゲームはピーク時には数十万ユーザーのアクセスに達するため、サーバーのスケーリングとコスト管理が課題となります。
 
そこで、T2D-standard-4 のサーバーに置き換えることで、CPU 0.8 コアで 1 試合分の処理をできるようになり、1 サーバーにつき 4 試合同時に実行できるようになりました。これによりサーバーあたりで処理できる試合数が増え、サーバーコストの圧縮に成功したとのことでした。

鉄拳8 のワールドワイドなマッチングについて

続いて、「鉄拳8」の事例が紹介されました。

鉄拳8 は 3 つのリージョンに展開されており、Diarkis というリアルタイム サーバーを実現させるためのフレームワーク エンジンを使用しています。その中で Turn サーバーをどこに置くかが課題になっていたとのことです。
ゲームの都合上、ラグを最小限にする必要があります。
そこで、北米、ヨーロッパ、東アジアで Cluster を組み、各地に Turn サーバーを配置することで、最小限のラグとワールドワイドなゲーム体験を実現できたようです。

こちらの詳しい内容は以下のセッションで紹介されていると発表されていました。
https://gdcvault.com/play/1034632/Diarkis-Inc-The-Team-Behind
 

Agones と Google Kubernetes Engine の最適化

続いて、BNE 社の道脇 翔平 氏より Agones と Google Kubernetes Engine（GKE）の運用のポイントについてのお話がありました。

Agones について

Agones は、リアルタイムのマルチプレイヤー ゲーム（MMO など）のために設計されたオープンソースのゲームサーバー システムです。これにより、スケーリングとデプロイの手間を最小限に抑えることができます。
Room という単位でゲーム セッションやゲームマッチをホストします。
 
GKE と Agones を使う上で、以下のポイントが重要になります。

  • 1 Pod に収容する人数を設計段階で考慮しておく
    • 1 Pod に何人入るのか、1 Room を立ち上げるために、どれほどの CPU が必要なのかを考慮しておくことで、オーバー スペックな構成を防ぐことができます。
  • リリース前に最適化されているか
    • ノード数がクラスタの上限に達する可能性をあらかじめ考慮し、事前にマルチクラスタ構成を試しておくことが重要です。
    • Pod をより多くかつコストを抑えて収容できるノードタイプはどれかをあらかじめ検討します。
    • 通信量が異常値になっていないかを事前に確認します。
  • リリース後にリソースの確認を怠っていないか
    • VM からの Egress コストは Compute Engine の費用に含まれるため、異常な通信が起こっていないかをリソース確認を通して確認する必要があります。
    • 無駄なノードを生まないために、Pod が無駄なく各ノードで立ち上がっているかの確認が必要です。

 
また、Agones のコストを下げるために以下の取り組みをしているそうです。

  • GKE Autopilot への移行
    • Autopilot ではノードではなく、使った Pod に対して課金されるため、余剰な空きがあるノードへの課金が発生せずコスト削減が見込まれます。
  • 1 Pod に複数の Room を入れる
    • Agones は以前まで 1 Pod 1 Room という制約がありましたが、最近のアップデートで、1 Pod に複数の Room を入れることができるようになりました。

Spanner 運用で気をつけるポイント

最後に、Spanner を運用する際に気をつけるべきポイントについてのお話がありました。

まず、Spanner で意図しないリトライが発生した際に、プロファイリングの手段を必ず知っておくことが重要です。
当たり前のことかもしれないですが、Spanner の運用経験がない僕にとっては勉強になることでした。
 
そして、ウォームアップの実施です。
Spanner は高いスケーラビリティを提供する分散データベースですが、設定変更を行った直後はデータの分散が期待通りに行われないことがあります。
リリースの前に負荷試験のシナリオを流してリシャードすると良いとのことです。
これは広く知られていない情報なので、実際に運用する際は気をつけたいですね。

Spanner は SQL と同じように使えるわけではないので、学習コストがかかりますが、障害が少なく、インフラ運用コストを下げられるメリットは非常に大きいです。
 

まとめ

このセッションでは、BNE 社が Google Cloud の技術をどのように活用しているかが具体的に発表されました。
特に、サーバーコストの圧縮やワールドワイドなマッチングの実現方法は非常に参考になりました。 
また、Agones と GKE の運用ポイントや Spanner の運用に関する具体的なアドバイスは、実際の業務に直結する有益な情報だったと感じます。
 
※Google Cloud、GKE、Cloud Spanner、Google Compute Engine は Google LLC の商標です。
※僕のヒーローアカデミアは株式会社集英社の商標です。
※鉄拳は株式会社バンダイナムコエンターテインメントの商標です。
※Diarkis は株式会社Diarkis の商標です。
※この記事は迅速な情報提供を重視し、速報として掲載しております。もし記事内に誤りがございましたら、後日訂正いたします。

この記事を共有する

合わせて読みたい

↑