PONOS Advent Calendar 2025の1日目の記事です。
前置き
本内容はGGLT late 2025での発表内容をベースにしております。
はじめに
ゲームのバランス調整を効率的に行うため、ゲームのステージを自動的にシミュレーションしたいというケースは多々あるかと思います。
今回はUnity製ゲームをGoogle Kubernetes Engine (GKE) 上で並列稼働させた事例を掻い摘んで紹介します。
課題
多くの場合、ステージのシミュレーションを行う上では、大きく二つの視点の課題があると思います。
- 再現性
- 速度
例えばゲームジャンルによっては、クリーンで独立したロジックコードのみで完結できる場合もあると思います。例えばシンプルな将棋などはそのイメージに近いと思います。そうした状況であれば、純粋なロジックのみを高速実行することはある程度低コストで実現できますし、再現性/速度の両面でも優れたパフォーマンスを発揮できるかもしれません。
しかし、例えば物理エンジンやゲームエンジンの機能への依存性が高いゲームであったりする場合、理論的なロジックだけを抽出することは困難だと思います。今回のケースでも、背景の理由はやや異なりますが、結果的には完全なゲームの状態でなければ再現性の担保が難しいという状況がありました。そうなると、速度、つまり何百回ものシミュレーションを行うためには、ゲームを並列して実行しなければ目標を達成できないということにもなります。
対応内容
Unity Game Simulation
まず、Unity公式のサービスとしてUnity Game Simulationというものがあります。
（厳密には、こちらはシミュレーションというよりは自動テストを主目的にしていたように見えますが）
ただ、残念ながらこちらは現在正式リリースを待たずして開発が中断されており、現時点で続報が見られておりません。
従い、今回はGKEを利用したシステムを構築しました。
GKEでのシミュレーション
システム構成要素
システム構成要素を簡単にご紹介します。
以下の構成を基本とし、Unityでビルドされたアプリを並列で数百同時実行しています。
Jenkins
- GKEのJOBをキックする
- JOBの再試行や結果の受け取りを行う
- JOBに実行のためのさまざまなパラメータの引き渡しを行う（ステージ選択とか）
GKE Cluster
- ノードプール
- 汎用プール：非GPU用
- ゲーム実行用プール：GPU用
- スペック（ゲーム用ノード）
- 1ノードあたり vCPU x 22, NVIDIA T4 GPU x 1
- TimeSharingでGPUを13個のアプリで共有
- コンテナ
- ベースイメージ：nvidia/cuda:xx.x.x-runtime-ubuntuxx.xx
- アプリのLinuxビルドを含む
- X11環境を構築
Cloud Storage
- Jenkinsとのファイルのやり取りの場所
- シミュレーターの出力結果がDockerからここにアウトプットされる
ポイント
ノードプールが二つである理由
主に運用コストの最適化を目的としています。
利用していない日などはできるだけノード数を0に近づけたいのですが、GKEのシステム関連コンポーネントが含まれているノードは必要です。しかしそこにGPUがついているとコストが非常に高い。
そのため、汎用プールは最低限スペックで最小1台とし、ゲーム実行用プールは最低0台までスケールインする構成としています。
目的にフォーカスしたスペック
GPUのコストは高く、潤沢なスペックで完全な解像度とFPSで実行しようとすると、かなりコストがかかってしまいます。そのため、例えば今回の場合は「再現性/速度」を重視してチューニングしており、レンダリング解像度などは意図的に落としています。それを前提としたスペック選択とチューニングが重要です。
また、GKEの場合は本要件であればSpotVMでも成立する場合が多いので、SpotVMにしておくとさらにコストダウンできます。
ブラックボックスにしない工夫
シミュレーションの結果だけが見える状況では、シミュレーションがクラッシュしたり疑わしい状況になった時の確認が大変ですので、できるだけ実行内容をクリアにしたいものです。
そこでこのケースでは以下の機能を盛り込んでいます。
- 実行ログが永続化される
- 全ての実行に対して画面録画が残る
- リモート接続で全てのアプリに接続できる
X11環境をベースとし、画面録画やリモート接続の機能もコンテナに盛り込んでいます。
もちろん、外部からの接続はできないようセキュリティ面の注意は必要です。
まとめ
今回は具体的なコードは示しておりませんが、取り組みの構成例としてご紹介させていただきました。
現状はLinuxビルドでの実行環境などいくつかの制約はありますが、それでも要件さえ合えば比較的低コストで有用な利用ができていると感じています。
それでは次回は@kerimekaさんです。