Amazon GameLift Serversでプレイヤーレイテンシーを最適化する

本記事は、2025 年 10 月 14 日に公開された “Fine-tuning player latency with Amazon GameLift Servers” を翻訳したものです。翻訳は Technical Account Manager の西岡美穂が担当しました。

マルチプレイヤーオンラインゲームをローンチしたことがある方なら、レイテンシーに関するフォーラムでの苦情ほどイライラさせられる（そしておそらく避けられない）ものはないことをご存知でしょう。運営側が影響を与えることができる問題（サーバーの近接性やコードの最適化）と、コントロールできない問題（プレイヤー側のハードウェアの性能不足やネットワークの問題）を切り分けることは困難です。

本記事では、 Amazon GameLift Servers の機能を活用したゲームタイトルのレイテンシーの測定と改善方法について説明します。Amazon GameLift Servers は、クラウド上にセッションベースのマルチプレイヤーゲーム専用の低コストサーバーをデプロイ、運用、およびスケールするために使用されます。 シミュレートされたプレイヤーのトラフィックパターンと異なるリージョンの デプロイ設定 の分析を通じて、プレイヤーのゲーム体験を最適化するための実用的なソリューションを示します。

成功したゲームローンチ

あなたのゲームは開発後、ついにリリースされ急速な成長を遂げています : インストールベースは予想を超え、同時接続ユーザ数（CCU）は常に 300,000 を超えてピークに達しています。しかし、一部のプレイヤーはレイテンシーと応答性の問題を報告しています。これには、プレイヤーのローカルなインターネット環境、広範なインターネットの問題、最適化されていないサーバーコードなど、いくつかの異なる原因が考えられます。

原因がコントロール可能なものか否かをどのように判断し、プレイヤーが可能な限り最高の体験を得られるためには何をする必要があるでしょうか?

最初のステップは、ゲームサーバーのロケーションに対するプレイヤーのレイテンシーを測定することです。これには Amazon GameLift Servers の UDP ping ビーコンが役立ちます。Amazon GameLift Servers のビーコンエンドポイントは、Amazon Web Services（AWS）のグローバルリージョンおよびローカルゾーン全てで利用可能です。ゲームサーバーがどこにデプロイされていても、プレイヤーからサーバーまでのレイテンシーを正確に測定できます。多くのレイテンシーに敏感なゲームは UDP プロトコルを使用するため、UDP ping ビーコンは現実的なレイテンシー測定を提供します。

ベストプラクティスとサンプルコードを使用すると、実装は簡単です。これらのビーコンからの正確なレイテンシーデータを利用することで、より公平なマッチメイキング体験を作成したり、プレイヤーの接続不良が発生するインスタンスを減らすことができます。リージョンへの ping が 150 ミリ秒のプレイヤーが、30 ミリ秒で ping しているプレイヤーと同じゲームに入れられるのは、フラストレーションとなるでしょう。正確なレイテンシー測定は、このようなシナリオを回避するための鍵となります。

注釈：現在運用していないロケーションへのレイテンシーを測定することも有用です。これは、プレイヤーのレイテンシーを改善する可能性のある追加のロケーションを特定するのに役立ち、プレイヤーベースの満足度を高めることを可能にします。

リージョンの選択

ゲームセッションに最適なリージョンを選択することはサーバー管理において重要ですが、トレードオフを慎重に検討する必要があります。Amazon GameLift Servers は、32 のリージョンとローカルゾーンへのアクセスを提供しており（この数は増え続けています）、より多くのプレイヤーに低レイテンシーのエクスペリエンスを提供します。しかし、プレイヤーを最速のロケーションにターゲティングするために必要以上に多くのロケーションで運用すると、マッチメイキングプールが断片化され、マッチ時間が長くなる可能性があります。

例えば、単一のリージョンから 10 の均等に分散されたリージョンに移行すると、各リージョンでマッチを検索するプレイヤー数が 10% になります。これにより、希望するゲームモード、スキルの均等性、ゲームを成立させるのに十分なプレイヤー数などの必要なプロパティを満たすことが難しくなる可能性があります。さらに、ゲームセッションを近隣のロケーションでまとめて統合するのではなく、使用頻度の低い複数のロケーションに分散させると、アイドル状態のサーバーを過剰に保持する可能性があります。

では、ゲームサーバーを実行するためにいくつのリージョンを使用すべきでしょうか？

これを検証するために、5 対 5 で 300,000 CCU のゲームのマッチメイキングをシミュレートしてみましょう。プレイヤーの位置情報と各サーバーリージョンへのレイテンシー測定をシミュレートできます。低レイテンシーのリージョンのいずれかにプレイヤーを配置し、マッチさせる必要があります。

図 1 は、リージョン数を変更した時に各種レイテンシー測定値のプレイヤーの割合がどう変化するか示しています。50 ミリ秒のレイテンシーをゴールにすると、リージョンが 1 つの時は 30% のプレイヤーがこの閾値を達成するのに対し、リージョン設定が 3 つの時は 63% が達成します。注目すべき点の 1 つは、リージョンを追加することにより得られるプレイヤーのエクスペリエンスの向上がある時点からは減少していることです。9 番目のリージョンを追加すると、50 ミリ秒（またはそれ以下）のレイテンシーを達成するプレイヤーが 5% 増加しますが、それを超えると改善は最小限となり、プレイヤーにとっての改善効果は少なくなります。

もう 1 つ注意すべき点は、7 番目または 8 番目のリージョンを追加するのは、そのローカルリージョンでゲームを成立させるのに十分なプレイヤーがいる場合のみ有効だということです。これは、あなたが決断をする必要がある項目です。ゲームのレイテンシーを向上させるために、プレイヤーのマッチ時間が長くなることを受け入れられるのか、レイテンシーにセンシティブなゲームなのか、プレイヤーの規模はどれほどか、などの要因に基づいて判断する必要があります。

比較のため、図 2 では同じ設定を、はるかに小規模な 3,000 CCU のゲームでシミュレートしています。データは、リージョンの数が少ないうちは類似したレイテンシー曲線を示していますが、リージョンを追加しても、300,000 CCU の場合に見られたようなレイテンシーの改善には到達できていません。これは、プレイヤーの参加率がゲームを成立させるのに十分な速さではなく、プレイヤーをあまり望ましくないリージョンに配置せざるを得なくなるためです。重要な点は、両方のテストで同じレイテンシーを達成することは可能ですが、3,000 CCU のケースでは、小規模なリージョンでは最大 100 倍もの時間マッチを待つ必要があるということです。

最後に、どのリージョンを選択すべきかという問題があります。

説明した例では、リージョンの選択順序は、プレイヤーのシミュレートされたレイテンシーデータの分析に基づいてい決定されていますが、実際の運用では、いくつかの主要な地理的ゾーンにサーバーを配置することから始め、その後、プレイヤーのレイテンシーデータ（UDP Ping ビーコンで測定）の分析に基づいて拡張したいと思うでしょう。

お客様向けに 数百のゲームをホスティングしてきた 10 年の経験に基づいて、出発点として一般的なガイダンスを以下に示します：

• 3 つまたは 4 つのリージョンが、ほとんどのゲームに適した基本構成です
• 以下の各エリアから 1 つずつ選択することが、お客様にとって効果的でした：
  • 北米（例：us-east-2 または us-west-2）
  • ヨーロッパ（例：eu-central-1 または eu-west-2）
  • アジア太平洋（例：ap-northeast-1 または ap-northeast-2）
• さらにリージョンを追加する場合：
  • データがプレイヤー体験に有益なレイテンシー改善を示している場合
  • ゲームのプレイヤー人口が、断片化の問題を回避できるほど十分に大きい場合

上記で示しているように、プレイヤーベースが大きいと、より多くのリージョンの追加を真剣に検討することになります。これは、既存のリージョンがプレイヤーにとって最速の N リージョンではないケースがどの程度一般的かで評価できます。ここでの N は、ゲームのレイテンシー要件（レイテンシーがクリティカルなゲームではより低く、レイテンシーが許容されるゲームではより高く）によって決定されます。例えば、3 つのリージョンで運用しており、プレイヤーの 60% にとって最速の 2～3 リージョンに既存のリージョンが含まれていないことが判明した場合、改善の余地があると言えます。その場合、そのカバーできていない 60% のプレイヤーに最も近いリージョンへの拡張を優先することになります。

注意点として、同じゲーム人口であっても、すべての人にとって唯一の最適解が存在するわけではありません。プレイヤー数が少ないゲーム（PvP対戦ゲーム）では、一般的でないリージョンでもマッチメイキングが比較的早く成立します。一方、南米で特に人気が高い場合は、その地域にサーバーを配置することが不可欠である可能性があります。

広範囲に及ぶ問題の特定

UDP ping ビーコン を使用することで、すべてのプレイヤーの正確なレイテンシー測定値を受信でき、このデータを使用して世界中のゲームサーバーを合理的かつ最適に配置することができます。これは素晴らしいスタートです。可能な限り、プレイヤーを近くのゲームサーバーに配置することで、ポジティブな体験ができる可能性を最大限に高めます。それが不可能な場合でも、プレイヤーがゲームプレイ中にレイテンシーの問題を経験する可能性が高い状況を特定することができます。

しかし、ゲームプレイの不具合がサーバーサイドの問題なのか、プレイヤーサイドの問題なのか判断できない場合はどうでしょうか。さらにコントロールが難しいケースとして、広範囲にわたるインターネットの問題がゲームに影響を与えている場合はどうでしょうか。サーバー側の視点ではすべてが正常に応答しているように見えるのに、プレイヤーからの苦情が続くのは非常にフラストレーションが溜まる状況です。

プレイヤー固有のレイテンシーに関する苦情を調査する時の出発点は、そのプレイヤーがゲームセッションのリージョンに対してどのようなレイテンシー測定値を示していたかを確認することです。Amazon GameLift Servers キューを使用している場合は、配置 ID とプレイヤー ID から開始し、describe-game-session-placement API を使用してレイテンシーを迅速に検索できます。

以下は、特定のプレースメントリクエストを行うために使用される、プレイヤーのレイテンシーを抽出できる Python スクリプトです：

#!/usr/bin/env python3
import boto3
import csv
import sys
from collections import defaultdict

client = boto3.client('gamelift')
placement_data = client.describe_game_session_placement(PlacementId=sys.argv[1])

players = defaultdict(dict)
regions = set()

for p in placement_data['GameSessionPlacement']['PlayerLatencies']:
    players[p['PlayerId']][p['RegionIdentifier']] = p['LatencyInMilliseconds']
    regions.add(p['RegionIdentifier'])

regions = sorted(regions)
writer = csv.writer(sys.stdout)
writer.writerow(['PlayerId'] + regions)
for pid, latencies in players.items():
    writer.writerow([pid] + [latencies.get(r, '') for r in regions])

このスクリプトを実行すると、次のような出力が得られます：

> python3 parse_latencies.py 4484032d-f3ca-4496-b663-31f842f0123d
PlayerId,ap-northeast-1,eu-central-1,eu-west-2,us-east-2,us-west-2
player-312,42.0,74.0,65.0,113.0,70.0
player-441,94.0,98.0,113.0,144.0,122.0

出力結果から、そのゲームセッションに参加している各プレイヤーの各リージョンへのレイテンシー（各リージョンのミリ秒単位）を確認できます。最初に確認すべきは、ゲームセッションをホストしているリージョンです。サンプル出力に基づくと、ap-northeast-1 が最も低い平均レイテンシーを示しているようです。また 2 人のプレイヤー間でレイテンシーにかなりの差があります。マッチメイキングにおいてレイテンシーの均等性を優先することは対処する価値があるかもしれません。また、player-441 は、どのリージョンがゲームセッションをホストしても、比較的高いレイテンシーを経験することになることがわかります。もしこのプレイヤーが苦情を申し立てている場合、その体験を改善できる範囲には限界があるかもしれません。

もう 1 つ確認すべき点は、現在サーバーを稼働させていないリージョンが最適なリージョンとなりうるかどうかです。これが一般的なパターンであれば、リージョン拡張の有力な候補を特定できたことになります。最後に、単一のプレイヤーやゲームセッションの範囲を超える問題については、プレイヤーのレイテンシーデータを分析ソリューションに入力して、より詳細な分析を行うことができます（AWSのGuidance for Game Analytics Pipeline を推奨します）。

Amazon GameLift Servers が提供するもう 1 つのソリューションは、Amazon CloudWatch Internet Monitor です。Internet Monitor は、広範囲にわたるインターネットのパフォーマンスと、それがゲームに与える影響を測定できます。その結果、Internet Monitor は、より広範なインターネット上の問題を特定できるだけでなく、プレイヤーに大幅なレイテンシー改善をもたらす可能性のある追加または代替のリージョンを提案することもできます。Internet Monitor はデフォルトでは無効になっていますが、Amazon GameLift Servers はお客様と協力してそれを有効にし、ゲームの地理的カバレッジの改善を提案することができます。

図 3 の例は、お客様のレイテンシーを改善する可能性のあるいくつかの提案を示しています。これはレイテンシーを TTFB（Time to First Byte：最初のバイト到達時間）として測定しており、総トラフィック量でソートされているため、最も多くのプレイヤーに影響を与える変更に焦点を当てることができます。他のロケーションでもわずかに多くのトラフィックを最適化できる可能性がありますが、フロリダ州クレストビュー地域のプレイヤーは、eu-central-1 ではなく us-east-1 に誘導することで、大幅な改善（139 ミリ秒から 36 ミリ秒への短縮）を実現できる可能性があります。

Internet Monitor は、広範囲にわたるインターネットの健全性に影響を与える問題を特定するためにも使用できます。これは、プレイヤー体験が悪い場合のトラブルシューティングや、問題がコントロールできるか否かを検証する際に有用です。図 4 は、イタリアのお客様に影響を与えている現在発生している問題の例です。この時期に複数のプレイヤーからゲームプレイに関する苦情があった場合、影響を確認し、プレイヤーに伝えるために必要な情報を得ることができます。このようなオープンなコミュニケーションは、運用を効果的に管理していることをプレイヤーに示すことができ、長期的なロイヤルティを築くのに役立ちます。

まとめ

Amazon GameLift Servers を使用してゲームのレイテンシー問題を効果的にトラブルシューティングし、対処する方法を説明しました。UDP ping ビーコン は、すべての AWS グローバルリージョンとローカルゾーンにわたるプレイヤーからサーバーへのレイテンシーを測定するために不可欠であり、サーバー配置とマッチメイキングに関するデータ主導の意思決定を支援することを示しました。

ここでは、運用するリージョン数がプレイヤー体験にどのように影響するか、リージョンを追加するとリターンがどのように減少するか、この決定には CCU とマッチメイキング要件とのバランスを取る必要があることを説明しました。シミュレーションを通じて、大規模（300,000 CCU）と小規模（ 3,000 CCU）の両方のプレイヤー集団に対して、異なるリージョン構成が与える影響を可視化しました。

また、Amazon CloudWatch Internet Monitor を活用して、広範囲にわたるインターネットの問題を特定し、プレイヤーにとって最適なリージョン構成を提案する方法についても説明しました。これにより、コミュニティとの透明性を維持し、可能な限り最高のゲーム体験を提供することができます。

UDP ping ビーコンを活用して、ゲームのリージョン展開とプレイヤー体験を最適化における次のステップを踏み出しましょう。

AWSの担当者に連絡して、ゲームのパフォーマンス最適化をどのようにサポートできるかを確認し、Amazon GameLift Servers での Internet Monitor の導入についてお問い合わせください。

参考資料

• Updated Game Analytics Pipeline
• Getting started with Amazon GameLift Servers
• Amazon GameLift Servers service locations