ゲームサーバーの負荷対策、グローバルで快適に遊べるサーバにするには #AWSreInvent

このセッションでは、ネットワークゲームのローンチ時の急激な負荷にどのように対応したのか、世界中のプレイヤーが複数人にプレイする際、レイテンシなどを考慮しつつ、サーバーをどのように選択、構成したのか解説しています。

AWS re:Invent 2023

#ゲーム開発・運用

#Amazon GameLift

出村成和

2023.12.24

こんにちは。ゲームソリューション部の出村です。 AWS re:Invent 2023のセッションである「Scaling Warhammer 40,000: Darktide from 0 to 100,000 players in 1 hour」のレポートをお届けします。

概要

Learn how Fatshark developed its most complex game yet—Warhammer 40,000: Darktide—on AWS. In this session, discover how to build a game backend that scales to millions of players using a serverless infrastructure. Dive deep into how Fatshark uses Amazon GameLift FleetIQ and FlexMatch to solve real-time game server use cases with high real-time compute requirements without needing to provision for peak usage. They do this while using the extreme control over elasticity and Regional availability that the cloud provides. In addition, learn how Fatshark is using AWS Global Accelerator to improve global gaming performance.

スピーカー

Andrew Claridge : Technical Director, Fatshark
Joris van de Donk : Senior Solution Architect , AWS

動画

内容について

ここでは、このセッションの内容について注目した箇所を中心に解説します。セッション全体は動画で視聴できますので、そちらをご覧下さい。

今回取り上げているゲームであるWarhammer 40,000 : Darktideがどういったゲームなのか説明します。

このゲームはクロスプレイ、世界中のプレイヤーと遊べること、またクラウド上に専用サーバーを構築している、というゲームとなっています。

いくつか実現しないといけないことがありました。今回のゲームは、AWS上でゲームサーバーを構築する初めてのゲームですのでコスト感について念入りに調査したり、新しくプレイヤーが参加しても既存の参加中プレイヤーに影響しないようにしないといけない、あとゲームサーバーのレイテンシは110ms未満に抑える、といった事です。

そこで次の挑戦をしました。内容として1vCPUで4人のプレイヤーを支えることであったり、リリース直後数時間のトラフィックを捌くことです。このあたりのリリース直後のトラフィックがとてつもなく多いのはゲームリリースではよくある話です。

リリース直後の大量のトラフィック対策として、急激に増えるユーザーをそのまま受けいれるのではなく、アクセスを分散させてサーバー負荷が急激に上昇しないよう対応しています。これはリリース直後にアクセスしてくるユーザー数がまったく予測できず、ユーザーに不便をかけないためです。

このゲームでの流れ（プレイヤー体験）としては、ログイン、プロローグ、ハブ、マッチメイク、ミッション（プレイ環境）といったいくつかの体験を分けて与え、1度にサーバー負荷が増えないようにしています。また、ここではユーザー数が一度に大量に流れ込まないようにログインできるユーザーの制御を行っています。このような対策でローンチ時のサーバー負荷を分散していました。

次に4人同時プレイでのゲームサーバープロセスの割り当てをみていきます。

このゲームでは、4人同時プレイで1つのプロセス、1vCPUを割り当てています。このプロセスは、ゲームをプレイするプレイヤーが集まった時にプロセスが起動し、そしてプレイヤーのゲームが終了するタイミングでプロセスが再起動する仕組みです。これにより、プロセスがプレイ毎に新しくなるので、例えばメモリなどのゲームサーバーの問題が起こりにくくなります。

ゲームサーバーで、一緒にプレイするプレイヤーを決めるマッチメイクについても解説がありました。レイテンシによってプレイするサーバーのリージョンを決め、マッチメイクによって一緒にプレイするユーザーを決め、それらのプレイヤーたちはどのゲームサーバーでプレイするのかを決める、といった具合です。

それらを実現するために次のようなサーバーのアーキテクチャ構成となりました。UDP Echoによってレイテンシを計測し、Amazon GameLift FlexMatchでマッチメイクを行い、マッチメイクのイベントをAmazon SNSへ流し、AWS Lamdaをつかって、マッチメイクの様々な処理を行う、といった具合です。

ゲームサーバーは、北米、ヨーロッパ、中東、南米などさまざまな箇所に配置されています。では、実際にゲームサーバーを決める条件としては次の順序で検索します。まず、スポットインスタンスが利用できる地域、レイテンシーが同程度である、最後には何かしら一緒にプレイできるユーザーがいるゲームサーバー、といった具合です。

そして、それらのゲームサーバーでは、次のような構成となっています。リージョン毎にスポットインスタンス、オンデマンドインスタンスなどを用意してゲームサーバーが構築されています。また、ゲームクライアントが最寄りではないゲームサーバーに接続する事もあるため、それぞれのリージョンではAWS Global Acceleratorも導入されています。