Amazon Web Services ブログ
Amazon GameLift Servers でローンチを成功させるためのステップ：開発フェーズ
本記事は、2025 年 10 月 9 日に公開された Development phase steps for successful launches on Amazon GameLift Servers を日本語に翻訳したものです。翻訳はソリューションアーキテクトの安藤怜央が担当しました。
マルチプレイヤーゲームの開発において、ゲームサーバーのグローバルなホスティング、スケーリング、監視の効率的な方法について検討されているのではないでしょうか。また、世界中のプレイヤーに最高のゲーム体験を提供するため、セッション配置の最適化についてもお悩みかもしれません。これらすべてを一から構築するのは、かなりの労力を必要とする作業です。
私たちはグローバルなゲームサーバーホスティングのためのフルマネージド型サービスである Amazon GameLift Servers をお勧めしています。このサービスは、オーケストレーション、グローバルなセッション配置、ゲームセッションライフサイクル管理を担うため、マルチプレイヤーゲームのローンチにおける運用作業とストレスを軽減するのに役立ちます。
このブログシリーズでは、ゲームローンチを成功させるための準備の重要な考慮事項について説明します。この最初のブログはプリプロダクションで実行すべきアクションに焦点を当て、第 2 部はプリローンチ準備 ( ローンチの 2〜3 ヶ月前 ) に焦点を当てます。これらの推奨事項は、開発初期のインテグレーションからゲームローンチまで数百のゲームスタジオをサポートした経験に基づいています。
このブログの内容の理解を進めるために、以下の知識があることを想定しています：
- Amazon GameLift Servers の基本に精通していること
- ゲームエンジンとゲーム開発の知識
- マルチプレイヤーネットワーキング概念の理解
ゲームローンチの初期計画における 4 つの重要な領域について説明します：
- ゲームサーバーのテストとインスタンスタイプの選択
- ゲームセッションライフサイクル管理の設定
- セッション配置のためのキューとキューイベントの活用
- モニタリング、ログ記録、アラームの設定
ゲームサーバーのテストとインスタンスタイプの選択
ゲームサーバーのテストは通常、ローカル上でゲームサーバーをテストするところから始まります。ローカルサーバーの動作が確認できたら、次のステップは Amazon GameLift Servers フリートにデプロイし、サービス上でパフォーマンスをテストすることです。
正しいインスタンスタイプとサイズを特定するのに役立つ重要な測定メトリクスは以下の通りです：
- リソース消費量 ( CPU 集約型と比較したメモリ集約型 )
- 各インスタンスで実行できるゲームサーバーコンテナまたはプロセスの数
- 最大プレイヤー負荷でのインスタンス上のゲームサーバーのパフォーマンス
このフェーズは小さなフリート、単一リージョンの 1 つのインスタンスでも実行できます。この時点で、リソース分離のために別の開発用 Amazon Web Services ( AWS ) アカウントを作成することをお勧めします。後でテストや本番などの他の環境を追加できます。フリートは非常に線形にスケールアウトするため、実際のテスターやボットクライアントで単一インスタンスを最大プレイヤー負荷にかけることで、ゲームサーバーのパフォーマンスについて良い指標を得ることができます。
推奨されるフリートタイプはコンテナフリートです。コンテナフリートでは、各ゲームサーバーの vCPU とメモリ要件を定義できます。Amazon GameLift Servers は、選択されたインスタンスタイプに可能な限り多くのセッションを自動的に配置します。
組み込みの Amazon CloudWatch メトリクスは、ゲームサーバーのメモリと CPU 制約を特定するのに役立ちます。このテスト使用データに基づいて調整し、C インスタンスファミリー ( より多くの CPU が必要な場合 ) 、M インスタンスファミリー( メモリと CPU のバランス )、R インスタンスファミリー ( より多くのメモリが必要な場合 ) の中から選択できます。物理シミュレーションは多くの CPU リソースを消費するため、ほとんどのゲームは C インスタンスファミリーまたは M インスタンスファミリーを使用します。
Amazon GameLift Servers でサポートされている最新世代のインスタンスは、最高の価格パフォーマンスを提供します。ARM ベースの AWS Graviton インスタンスを活用することで、パフォーマンスをさらに向上させることができます。
選択したインスタンスタイプに何個のコンテナ ( コンテナフリートの場合 ) またはゲームサーバープロセス ( Amazon EC2 フリートの場合 ) を配置できるかを決定するには、実際の負荷でテストし、パフォーマンスを監視する必要があります。これは、ゲームをプレイするテストグループ、またはサーバーに接続して事前定義されたスクリプトでゲームを自動的にプレイするヘッドレスボットクライアントのいずれかで実行できます。
このテストは、クライアントとサーバー間で実際のデータトラフィックが流れる状態で実行する必要があります。サーバー上のローカルボットでシミュレーションをテストするだけでは、パフォーマンスの包括的な全体像を得られないためです。複数のリージョンにボットクライアントや実際のテスターを配置することも、地理的なネットワークトラフィックレイテンシーがパフォーマンスにどのように影響するかをより現実的に理解するのに役立ちます。
図 1 は、Amazon CloudWatch メトリクスとログを通じてパフォーマンスを監視しながら、ゲームセッションにトラフィックを生成するボットクライアントを示しています。コンテナフリートは自動的にゲームサーバーログを Amazon CloudWatch にプッシュし、Amazon EC2 フリートでは CloudWatch Agent を使用してログを CloudWatch にプッシュできます。
図 1：ゲームサーバーのパフォーマンステスト
ゲームセッションライフサイクル管理の設定
ゲームサーバープロセスのライフサイクルにはいくつかの重要な要素があり、すべてを考慮することがフリートの健全性を保つために不可欠です。それでは、ゲームサーバーフリートでのセッション管理のシーケンスを詳しく見てみましょう。
起動時、ゲームサーバープロセスは Amazon GameLift Servers との通信を確立し、ゲームセッションをホストする準備ができていることを報告します。
ゲームサーバープロセスは以下のサーバー SDK 操作を順番に呼び出します：
- ゲームサーバーの初期化
- サーバー準備完了の通知
- ゲームサーバーヘルスの評価
- ゲームセッションイベントの処理
- ゲームセッションの終了
1. ゲームサーバーの初期化
サーバーは InitSDK 呼び出しメソッドで開始します。この関数は、サーバープロセスを認証し、Amazon GameLift Servers のオーケストレーションの準備を行います。
考慮事項：
- Amazon GameLift Servers との通信を速やかに確立するため、サーバープロセスの起動時に最初の呼び出しとして
InitSDKを実行してください。 - フリートの監視をサポートし、サイレントな障害を防ぐため、SDK 初期化エラーのログ取得とハンドリングを行ってください。
2. サーバー準備完了の通知
リソースとゲームロジックがロードされたら、ProcessReady を呼び出して Amazon GameLift Servers にプロセスがゲームセッションをホストする準備ができていることを通知します。この呼び出しでは、ゲームクライアントがゲームセッションに接続するために使用するプロセスの接続情報も報告されます。Amazon GameLift Servers はゲームサーバープロセスのステータスを ACTIVE に更新し、新しいゲームセッションをホストできる状態になります。
考慮事項：
- すべての初期化が完了した後にのみ
ProcessReadyを呼び出し、重複した呼び出しを避けてください。 OnStartGameSessionやOnHealthCheckなどの必要なコールバックをすべて提供し、適切なエラーハンドリングと再試行を実装してください。- Amazon GameLift Servers コンソールまたは API からセッションログにアクセスできることを確認するため、EC2 フリートで正確なログパスを提供してください。
3. ゲームサーバーヘルスの評価
サーバープロセスが ACTIVE に設定されると、Amazon GameLift Servers はゲームサーバープロセスからヘルスステータスを要求するため、定期的に OnHealthCheck コールバックを呼び出し始めます。プロセスが unhealthy と報告するか、ヘルスチェックに応答しない場合、サービスはプロセスのアクティブステータスを変更し、新しいプロセスに置き換えます。
考慮事項：
- サーバー SDK で堅牢な
OnHealthCheckコールバックを実装し、true で応答する前にサーバーが健全であることを適切に検証してください。
4. ゲームセッションイベントの処理
プレイヤーがゲームへの参加を要求すると、ゲームクライアントはバックエンドサービスにリクエストを送信し、新しいセッションを開始するために StartGameSessionPlacement または CreateGameSession を呼び出す場合があります。サービスは利用可能なサーバープロセスをフリートで検索します。見つかると、ゲームセッションを作成し、OnStartGameSession コールバックを呼び出します。サーバーは自身の準備ができたら ActivateGameSession を呼び出し、Amazon GameLift Servers はセッションを PENDING から ACTIVE に更新し、配置を完了します。
考慮事項：
OnStartGameSessionを受信した後にのみプレイヤーが接続するようにしてください。Amazon GameLift Servers は、サーバープロセスが新しいゲームセッションのホストを開始することを望む場合にこのコールバックを呼び出します。これにより、実際にゲームがロードされる前にサーバーへの接続を試みることによって発生する問題を減らすことができます。- ゲームマップやその他の設定を適切にセットアップし、セッションをホストする完全な準備ができてから、
OnStartGameSessionコールバック内でActivateGameSessionを呼び出してください。ActivateGameSessionを呼び出すことで、サーバーが新しいゲームセッションをホストするための初期化を完了し、プレイヤー接続を確立するための着信トラフィックを受信する準備ができたことを Amazon GameLift サービスに通知します。 - プロセスがセッション配置を数日間待機している場合、ヘルスチェックですべてのシステムが正しく動作していることを確認してください。これは、フリートを事前にセットアップしたものの、実際の本番トラフィックを後から受信する場合や、時間帯によってプレイヤートラフィックが変化する場合に当てはまります。一部のロケーションでは、セッション配置を受信しない時間帯が存在する可能性があります。
5. ゲームセッションの終了
ゲームセッションの終了時に、サーバープロセスは Amazon GameLift Servers にゲームセッションステータスを通知します。ゲームサーバープロセスは、サーバー SDK 操作 ProcessEnding を呼び出してシャットダウンを開始します。ゲームセッション終了の一環として、Amazon GameLift Servers はゲームセッションとサーバープロセスのステータスを TERMINATED に変更します。
考慮事項：
- ゲームセッションがサーバーに配置され (
OnStartGameSessionが呼び出され ) たものの、プレイヤーが接続しない、または切断された場合のバックアッププロセス終了メカニズムを実装してください。これらの状況で確実にプロセスを正しく終了させ、新しいゲームサーバーに置き換えられるようにする必要があります。 - 複数のセッションでサーバープロセスを再利用しないでください。セッション終了後、
ProcessEndingを呼び出して終了してください。これにより、新しいプロセスの作成と登録が即座にトリガーされます。 - サーバーが終了する可能性のあるすべてのパスで Amazon GameLift Servers SDK の
ProcessEndingを呼び出してください。これにより、適切にクリーンアップされ、直ちに新しいセッションに置き換えられることが保証されます。
図 2 は、ゲームサーバープロセスのライフサイクルと、すべてのゲームサーバーの実装において考慮すべき重要なステップを示しています。
図 2：ゲームサーバーライフサイクル
セッション配置のためのキューとキューイベントの活用
Amazon GameLift Servers キューは、フリートで直接セッションを作成するよりもいくつかの利点を提供します。
キューの利点として以下があります：
- 最初のオプションが利用できない場合、セカンダリのフリートロケーションにフェイルオーバーできます
- 複数のフリートに跨ってセッションを配置できます
- バックエンドが処理できるセッション配置イベントを提供します
- レイテンシーとコストに基づいて送信先 ( destination ) を優先順位付けします
キューを使用する場合、StartGameSessionPlacement 呼び出しが使用する必要がある唯一の API です。残りはキューイベントを通じて管理されます。
キューを使用する際のベストプラクティスは以下です：
- 適切なキャパシティが見つからない場合に配置が失敗と見なすまでの時間を定義するため、キューのタイムアウトを設定してください 。
- キューにプレイヤーのレイテンシーを提供する場合は、プレイヤーレイテンシーポリシーを設定してください。ここで設定する制限は現実的なものにしてください。多くのマッチで一部のプレイヤーが到達できないレイテンシー値を待つために長時間待機することは避けるべきです。プレイヤーレイテンシーポリシーがない場合でも、キューにレイテンシーデータを提供すると、このデータに基づいてセッションが配置されます。デフォルトの動作は平均値に基づいて機能しますが、プレイヤーレイテンシーポリシーは最大レイテンシー制限を超えるプレイヤーがいないことを保証します。
- ゲームセッション配置の優先順位を定義してください。ほとんどの場合、登録されたすべてのフリートでレイテンシーを優先し、次にコストを考慮するというデフォルトの動作を推奨します。ただし、レイテンシーの品質に関係なく Amazon GameLift Servers Anywhere フリートリソースを最初に使用したい場合は、その送信先を最優先に設定してください。
キューイベントを使用する際のベストプラクティスは以下です：
- ゲームセッション配置イベントの通知を受信するために、Amazon Simple Notification Service ( Amazon SNS ) トピックを登録するか、Amazon EventBridge を使用してください。
- AWS Lambda 関数をイベントに登録し、Amazon DynamoDB などのデータベースにイベントデータを保存したり、WebSocket を介してプレイヤーに直接更新を送信したりできます。Describe API の使用と比較して、イベントの使用は非常にスケーラブルです。
図 3 は、Amazon GameLift Servers キューを活用したゲームセッションの配置と Amazon SNS トピックへのサブスクライブを通じたイベント処理に関する基本的なアーキテクチャ概要を示しています。
図 3：Amazon GameLift Servers キューを活用するための基本的なアーキテクチャ
レイテンシポリシーを使用せず、特定のロケーションを優先して正確にセッションを配置する必要がある場合は、StartGameSessionPlacement リクエストで Priority Configuration Override を定義できます。これは、ゲームデザイン上、プレイヤーが特定のロケーションまたは優先ロケーションのリストから選択できる機能を提供する場合に役立ちます。また、マッチメーカーが各ロケーションのレイテンシーを個別に提供する代わりに、優先順位リストを提供する場合にも役立ちます。
マッチメーカーとして Amazon GameLift Servers FlexMatch を使用している場合、定義したキューとネイティブに統合されます。その後、セッション配置プロセスを追跡するために、キューイベントの代わりに FlexMatch イベントを使用できます。
メトリクス、ログ記録、アラームの設定
環境で何が起きているかを理解する上で、オブザーバビリティは重要です。Amazon GameLift Servers には、これをサポートするいくつかのネイティブ機能があります。ログ、モニタリング、アラームという 3 つの重要な側面について説明します。
ログ
コンテナフリートでは、追加のツールやサービスを使用せずに、ゲームサーバーの出力を Amazon CloudWatch または Amazon Simple Storage Service ( Amazon S3 ) に送信するように設定できます。デバッグ時に適切ログファイルを検索できるよう、ゲームサーバーの出力にゲームセッション ID を書き込むようにしてください。EC2 フリートでは、ゲームセッション終了後 14 日以内にログファイルをダウンロードできます。EC2 フリートでも Amazon CloudWatch にログをプッシュしたい場合は、AWS Game Backend Framework ガイダンスの Amazon GameLift Servers integration が Amazon CloudWatch Agent の設定に役立ちます。
ゲームサーバープロセスからログ出力を生成する際は、ロギングシステムでログの詳細度を定義できるようにすることをお勧めします。開発時にはより詳細なロギングを使用し、本番環境では収集するデータ量を減らすことができます。JSON 形式などの構造化されたログ出力を使用することで、CloudWatch のクエリ機能を活用しやすくなります。
さらに、サイドカーコンテナを実行するか、EC2 フリートの場合はインスタンス上でバックグラウンドエージェントを実行することで、任意のサードパーティログ管理ツールにログ出力を送信できます。
メトリクス
Amazon GameLift Servers は広範囲な CloudWatch メトリクスを提供します。これには、フリート内のインスタンスとゲームセッションの情報、キューによる配置時間、リソース使用率メトリクス、その他多くが含まれます。これらのメトリクスは、Amazon GameLift Servers コンソールと CloudWatch で直接利用できます。
監視すべき主要なメトリクスは以下です：
- リソース使用率：
CPUutilization、MemoryUtilization（コンテナフリート用）、NetworkIn/NetworkOut。これらのメトリクスは、ゲームサーバープロセスのパフォーマンスと使用しているリソース量の概要を提供します。 - セッション可用性：
PercentAvailableGameSessions、AvailableGameSessions。これらのメトリクスは、フリートの健全性と新しいセッションを配置する能力を示します。 - 潜在的な問題：
UnhealthyInstancesReplaced、ServerProcessAbnormalTerminations。これらのメトリクスは、動作を継続するためのリソースが不足しているインスタンスと、プロセスが正しく終了していない問題を示します。 - キューメトリクス：
AverageWaitTime、PlacementsFailed、PlacementsTimedOut。これらのメトリクスは、プレイヤーがマッチに配置されるまでの速さや、配置の失敗頻度など、キューの健全性の指標を提供します。
ログと同様に、サイドカーコンテナまたは EC2 フリートのエージェントを使用して、他のシステムに関するカスタマーメトリクスを収集できます。これには、Grafana で視覚化できる Prometheus インスタンスでメトリクスを収集する OpenTelemetry エージェントなどのツールやサービスが含まれます。
アラーム
アラームは、ゲームバックエンドに問題があることを運用チームに通知するメカニズムです。問題の可能性を示すメトリクスに対して適切なアラームを作成する必要があります。これには、PercentAvailableGameSessions ( 低いまたはゼロ ) 、ServerProcessAbnormalTerminations、UnhealthyInstancesReplaced、PlacementsFailed などのメトリクスや、ニーズに関連するその他のメトリクスが含まれます。さらに、CloudWatch Logs からメトリクスを抽出し、抽出されたメトリクスに基づいてアラームを作成できます。ログからのメトリクスの迅速な抽出には JSON 形式が推奨されます。
図 4 は、CloudWatch のメトリクスとログを活用して、問題が発生した際にアラームを生成し、オンコールチームに通知する方法の例を示しています。同様のアプローチは、Prometheus でメトリクスを収集し、Grafana で可視化する場合にも適用できます。
図 4：ログとメトリクスに基づくオンコールチームへのアラーム
結論
Amazon GameLift Servers をゲームサーバーホスティングに使用することで、ゲームローンチの成功に向けた運用面で準備を整えるためのベースラインについて説明しました。正しいインスタンスタイプとサーバープロセス、またはコンテナパッキングを選択することで、高性能でコスト最適化された構成を確保する方法について議論しました。また、すべてのアーキテクチャが適切に制御されたイベントベースのセッション配置のためにキューを活用すべき方法についても考察しました。最後に、ログ、モニタリング、アラームの設定が問題の特定とゲームサーバーのパフォーマンスに関する情報収集にどのように役立つかについて議論しました。
シリーズの第 2 回ブログ「Amazon GameLift Servers でローンチを成功させるためのステップ：ローンチフェーズ」では、ゲームローンチの準備についてより深く掘り下げます。
マルチプレイヤーゲームサーバーホスティングのために Amazon GameLift Servers を今すぐ始めましょう。ビジネスの加速にどのように役立つかを学ぶために、AWS 担当者にお問い合わせください。