Unite Tokyo 2019 Google Cloud For Games
概要
ゲームサーバホスティング
プラットフォームサービス
ゲーム分析
今日は「リアルタイムマルチプレイヤー体験」「マッチング」
ゲームサーバとは
ゲームサーバはマルチプレイヤーゲーム内のイベントを受け持つサーバ
クライアントが正しいゲーム世界を表示するためにゲームの状態を送信
各プレイヤーからの入力を受け取って処理
プレイヤーからの入力を受ける
プライヤーの位置をトラッキング
移動や衝突を処理して、物理演算を行う
プレイヤーに処理した情報を送信
これらの処理は毎秒120回にもおよぶ!
P2Pじゃだめなの → スケールしない, チーター等で平均以下の体験になってしまう
専用サーバーモデル → スケーラブル, セキュアなのでワールドクラスの体験になる
Fortnite や APEX は専用サーバモデルで作られてる
全てのクライアントは1つのゲームサーバが判定する
流れ: クライアント → マッチメーカー → サーバーマネージャー (接続先サーバを判定) → ゲームサーバー
今日の話はサーバーマネージャーとゲームサーバーの話
専用サーバーは外部依存なし, コンテナは不要, コーディングは必須
専用サーバーのデプロイは1つのVMにコアごとに設置するのが今までの手法
コンテナ化すると、DockerEngine を使ってコンテナを動かす
コンテナ化はどの k8s 環境でも実行可, OSSでコミュニティが開発 (agones), コンテナ化は必須
Agones
オープンソース
ゲームサーバのホスティングとスケーリングをコンテナで行うためのソリューション
k8s 上で動作
2019/09/18 に v1.0 になり、本番環境で使えるようになった
コンテナ: ゲームサーバをコンテナに入れる!
SDK: Unity, UE4, C++...
SDKはゲームサーバのライフサイクル管理に使用
レディネス&停止, ヘルス状態, アクセスと監視の設定, 構成値を設定
yaml コードでゲームサーバを管理, インフラをコードで管理する ( IaC )
fleet: 複数台のゲームサーバを利用する, AutoScaller を使うと自動でスケール可能
fleetallocation: ゲームサーバの割当をすると allocate になり, ゲームサーバを減らしても allocate されてるゲームサーバは落とさないようにする (これがないとサーバ数を削減すると稼働中のゲームサーバも落ちる)
GCGS (GoogleCloudGameServer)
フルマネージド Agones (今までは自分で設定する必要があった)
シンプル, 柔軟, OSSと同じSDK
グローバル&リアルタイム&マルチプレイヤー: ゲームをローンチする最も簡単な方法
プラネットスケールマッチメイキング
OpenMatch: Unity社と共同出資したオープンソースのマッチメイク・フレームワーク
柔軟性, スケーラビリティ, 拡張性にフォーカスし、Goで記述されたものが k8s で実行されます
ハロウィンで公開したDoodleゲームで 65時間で1億人, 62カ国, 最大50万CCU を捌いた実績あり
1つのリージョンが落ちても, 他の近いリージョンに再ルーティングする (日本が落ちたら台湾を使う)
マッチングの方法は自分で実装する
チート対策のためにOMを直接アクセスさせない (クライアント側から自由なマッチングが出来てしまう為)
Client → game frontend (自社でロビーサーバを用意) → open match ← director → DGS (GameServers)
DGS は マッチングをトリガーするプロセス
Ticket は試合をリクエストしてるプレイヤー, Asignment はプレイヤー情報
実際は Client → Robby (Ticket発行) → OpenMatch → Director(Allocate) → Agones
OpenMatch の事例: GRENGE の Kick-Flight で利用された (2万人前後の先行プレイ)
マッチメイキングはフレームワークがあるのでそれを使うと楽
コンテナ
アプリケーションコードとその依存性を1つのユニットとしてまとめる
これにより、アプリとインフラを疎結合にすることが可能
VM は GuestOS が必要, コンテナは必要ない
コンテナを使うとデプロイの単位がアプリケーションになるので、起動が早い、ハイパフォーマンス
k8s: コンテナオーケストレーションシステム、コンテナを簡単に本番環境で使う事が出来る