Google Cloud Next Tokyo ’24 にて行われたセッション「BNE ゲームタイトルにおけるリリース前後のインフラの最適化と課題」のレポートです。
Google Cloud Next Tokyo ’24 とは？
2024年 8月1日、2日の2日間でパシフィコ横浜で開催されている、Google Cloud が主催する国内最大級規模のイベントです。
https://cloudonair.withgoogle.com/events/next-tokyo-24
登壇者
株式会社バンダイナムコ エンターテインメント （以下、BNE社）
河原 真太郎 氏
道脇 翔平 氏
セッション内容
最新のタイトル事例
はじめに、直近でリリースした2つのタイトルについて軽く触れられていました。
1つ目は 僕のヒーローアカデミア ULTRA RUMBLE というリアルタイム対戦を行うオンラインゲームです。
アーキテクチャは以下のようになっております。
試合数が多いほどに図上の専用ゲームサーバーが増えるため、1サーバーで可能な試合数やCPU効率の観点からマシンタイプの選定を行われていました。
その結果、起動されるサーバー数も減り、コスト削減を実現した事例となっておりました。
2つ目は 鉄拳8 という格闘ゲームで、こちらもオンラインでの対戦がメインとなっています。
アーキテクチャは以下のようになっております。
ターンサーバーによってリアルタイムな通信を行うことで、展開されている3つのリージョンで最小限の遅延を実現しているとのことでした。
また、これまでの様々なイベントで事例を紹介されているとのことなので、詳しい話はそちらをチェックしましょう。
Kubernetes & Agones
Agones について
上記のゲームサーバーは共通して GKE を利用されていますが、具体的には Agones を用いた設計となっています。
従来のシステムでは、スケーリングをステートレスに制御するのが難しく、独自の運用や仕組みを導入する必要がありましたが、Agones を使うことで Kubernetes クラスタ内で自動的にスケーリングできるようになることが大きな特徴として挙げられていました。
なお、Google Cloud の公式ドキュメントに GKE クラスタ上でのガイドが記載されています。
GKE クラスタで Agones コントローラを分離する
使用上の注意点
次に、Kubernetes 上で Agones を使うにあたって、設計段階、リリース前、リリース後の3つのフェーズにおける注意点について紹介されています。
設計段階では、1Pod あたりに接続可能なユーザー数とそれに対する CPU がどれだけ必要か？を調整することにより、コストを最低限に抑えることが挙げられていました。
リリース前の段階では、リリース直後にアクセス増が見込まれるため、ノード数の上限の確認、および負荷試験や検証で通信量に異常がないかの確認などを行うことが重要とのことです。
リリース後もそのままにするのではなく、通信料金や Pod 数の推移などをメトリクスから確認することで、さらに最適なコストパフォーマンスを改善していく姿勢や努力が見られました。
Spanner
選定理由
DB には Spanner を利用しており、主に以下の点で最も優れていることが選定理由となっています。
- 高信頼性
- 高パフォーマンス
- 高スケーラビリティの分散 DB
使用上の注意点
こちらはリリース前の注意点として、プロファイリング手段とウォームアップについて話されていました。
プロファイリング手段は、他にも Google Cloud 上に豊富なサービスがありますし、なるべく APM を用いたトレースなどと併用してチューニングを行うことが望ましい（というかほぼ必須）とのことです。
ウォームアップについては、当然 MySQL と同じように使えず、学習コストも決して低くないというデメリットがありますが、それ以上にインフラの運用コストを下げられるというメリットのほうが大きく、今後も継続して利用したいと仰っていました。
終わりに
BNE社のゲームインフラに関するチューニングやコスト削減方法について紹介されていました。
Agones を初めて知りましたが、柔軟なスケールが可能になることでコストパフォーマンスにおいても非常にメリットが大きいのではないかと思います。
また、Spanner 起因の障害実績はこれまでないと仰っており、説得力も高く感じました。
