この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
どうもコンサルティング部の後藤です。
本記事は AWS re:Invent2020 セッション" Ubisoft: Building a multi-platform multiplayer game on AWS " のレポートになります。
セッション情報
セッション名
Ubisoft: Building a multi-platform multiplayer game on AWS
概要(機械翻訳)
Ubisoftは、インタラクティブエンターテインメントの大手クリエーター兼パブリッシャーであり、アサシンクリード、ファークライ、トムクランシーのビデオゲームシリーズなど、世界的に有名なゲームフランチャイズを担当しています。 このセッションでは、Ubisoft Live OperationsManagerのNaomiBarnesとクラウド開発エンジニアのMarieLaurentが、UbisoftがAWSで次の競争力のあるスポーツゲームであるRollerChampionsを立ち上げる準備をしている様子を共有します。 この新しいマルチプラットフォームマルチプレーヤーゲームの背後にあるサーバーレスのコンテナー化されたアーキテクチャの詳細と、UbisoftがAWSサービス（Amazon GameLift、Amazon ECS、Amazon DynamoDB、Amazon ElastiCacheなど）を活用して、プレーヤーに高性能で信頼性の高いエクスペリエンスを提供する方法をご覧ください 運用コストを削減しながら、世界中で。
スピーカー
セッションレポート
Ubisoft社について
Ubisoft社はフランスに本社を置き、ゲーム開発とゲームパブリッシングで有名な会社です。世界中にスタジオを持っており、代表的なタイトルとしてはレインボーシックスシージやファークライ等があります。
今回のセッションで取り扱うゲームは Roller CHAMPIONS というゲームになります。
Roller CHAMPIONSはマルチプラットフォーム(PC/PS4/XBOX/Swtich)で提供されているオンラインマルチプレイヤーゲームになります。
なぜAWSを利用したか
Roller CHAMPIONSでAWSを利用したのは、以下のような理由があったからだそうです。
- すぐに利用出来る
- 機材の調達や準備の時間を短縮できる
- ドキュメントも豊富で読みやすい
- マネージドサービスと信頼性
- 少ないチームでもインフラを管理できる
- 信頼性が高いゲームサーバはゲーム体験をよりよくする
- 拡張性と弾力性
- プレイヤーの需要に合わせ増減が可能
- 運用コストを抑え、稼働時間を長く出来る
- グローバル展開
- プレイヤーが世界の何処にいても、最高のゲーム体験が提供できる
- 高可用性
- 迅速かつ確実にサーバにアクセスさせることが、安定したプレイヤー体験を提供できる
- 安定したサーバは運用コストも下げる
- 低コスト
- インフラだけでなく、人的コストの削減も重要
Roller CHAMPIONの裏側について
Roller CHAMPIONのAWSバックエンドが実際にどのように動いているのか、以下に沿って説明してくれます。
- ゲームの概要
- カスタムマッチングとフルゲームセッションの流れ
- ゲームのデバッグ方法
- バックエンドコード、インフラストラクチャ、ゲームビルドのデプロイ方法
Roller CHAMPIONのゲームサーバの形式について
オンラインマルチプレイヤーゲームでよくあるネットワークモデルとして、以下の2つが挙げられます。
- Peer-To-Peer型
- 全てのゲームクライアントが相互接続され、その内の１人がホストとなる。
- 専用ゲームサーバ型
- 全てのゲームクライアントが共通の専用ゲームサーバに接続する。
Roller CHAMPIONではゲームセッションのコントロールが可能な点や、信頼性の高い体験を提供できる専用ゲームサーバ型を選択したそうです。
大まかなバックエンドは以下のようになっているそうです。
マッチメイキングについて
バックエンドで処理しているマッチメイキングの仕組みは、以下のように考えているそうです。
- より良いプレイヤー体験
- 同じスキルを持ったプレイヤー同士でマッチングさせつつ、ゲーム開始までの待ち時間を適切にする事が重要
- 柔軟性
- 複数のゲームモードを提供する
- マルチリージョンによるマッチング
- セッション待ち時間を短縮させるために複数のリージョンでマッチングを行う
- 拡張性、弾力性
- 負荷に応じて拡張、縮小出来るマッチメイキングが必要
- 朝と夜ではプレイヤーの需要が異なる
Rolle CHAMPIONは競争性の激しいゲームのため、ゲームの成功には質の高いマッチメイキングシステムが重要とのこと。
GameLiftの機能であるFlexMatchの利用も考慮したそうなのですが、完全にマッチング機能を制御できないことから選択肢から外れ、サーバレスのサービスを主に使用して独自のマッチングシステムを構築したそうです。
- クライアントがAPI Gatewayにマッチングのリクエストを送信。API Gatewayでは認証、認可の処理を行っている。
- Lambdaでゲームの種類を判別する。セッションを受けたらクライアントでは他のプレイヤーを待っている状態とする。
- SQSとセッションマネージャーサービスでセッションキューを管理し、6人分のキューが溜まったら、セッションを作成する。
- クライアントにはセッションサーバのIPアドレスとポートが送信され、その情報を元にGameLiftに接続してゲームが開始される。
ゲームセッション中、クライアントのコンテキストログやメトリクスはAPI Gateway、Lambdaを介してElasticSearchServiceに送信、GameLiftのゲームサーバも同様に送信しています。これらの情報はゲームデバッグに役立つとのこと。
ゲームが終了すると、ゲームサーバからLambdaに終了のリクエストを送信し、終了のリクエストを受け取ったLambdaはスコアの計算等の処理を行い、各プレイヤーの情報を含むメッセージをキューに送信し、クライアント側に表示させているとのこと。
次に、GameLiftでマルチリージョンのセッションを行う方法についてになります。
セッションマネージャーがセッションの準備が整うと、GameLiftにゲームサーバを要求します。GameLiftは理想的な待ち時間、条件を持つ地域のフリートを選択するそうです。
各デプロイについて
バックエンドのデプロイについて
- Gitlabに最新のコードがプッシュされると、パイプラインがコードアーティファクトを構築、それをS3にアップロードしている。
- 内部ツールを使用してS3にアップロードされたコードアーティファクトでデプロイを行う。
- 内部ツールでは複数のバージョンを選択することが出来るため、ロールバックも容易に可能。
インフラストラクチャのデプロイについて
- GitLabとTerraformを利用。
- GitLabに新しいコードがプッシュされると、パイプラインを通してTerraformでPlanを実行。
- Planの結果を検証した後、問題が無ければApplyで適用を行う。
- 自動で変更されるため、人的ミスが大きく減る。
ゲームのビルドについて
- GitLabに新しいコードがプッシュされると、ゲームクライアントとサーバのビルドが行われ、ビルド結果を内部のNASに送信している。
- 内部ツールが内部NASにある新しいバージョンのビルド結果を元に、GameLiftに更新を行う。
ゲームのデバッグについて
最後にゲームのデバッグ方法になります。
CloudWatch、ElasticsearchService、X-Ray等を活用。品質管理チームはダッシュボードを使い、デバッグや異常を検知しているとのこと。
特にX-Rayは開発時やデバッグ時、負荷テストの際には非常に有効だったとのこと。
まとめ
Roller CHAMPIONはαテストやβテストを行い、ユーザからのフィードバックだけでなく、サーバの安定性やマッチメイキングの時間等、様々な指標を検証していた。その中でサーバを閉鎖を繰り返し、改善を行っていった。
AWSのサービスを利用していたため、セットアップに殆ど時間が掛からず、様々なテストを容易に行うことが出来たため、プレイヤーからデータを元に意思決定を行うことが出来たとのこと。
最後に
以上、AWS reInvent2020のセッションのレポートになります。如何だったでしょうか。
GameLiftを利用したマルチプレイヤーゲームの事例はまだまだ少なく、マッチングの機能を独自で開発し利用されている非常に貴重な事例セッションだったと思います。
3
