Amazon Web Services ブログ
Amazon GameLift Servers でローンチを成功させるためのステップ：ローンチフェーズ
本記事は、2025 年 10 月 16 日に公開された “Launch phase steps for successful launches on Amazon GameLift Servers” を翻訳したものです。翻訳は Solutions Architect の西坂信哉が担当しました。
ゲームが急激にヒットした場合に備え、最初から成功に向けた準備をしておくことが重要です。本記事では、Amazon GameLift Servers でマルチプレイヤーゲームを立ち上げる際に考慮すべき重要な点について説明します。ゲームのローンチの 2-3 ヶ月前に必要な作業に焦点を当てます。これは、ゲームの本番ローンチだけでなく、オープンベータ、アーリーアクセス、あるいは実際のプレイヤーが参加する他のマイルストーンも含まれます。
ゲームローンチに向けた最終計画の 5 つの重要な領域について説明します。
- ゲームローンチに関するアンケートに記入し、サービスのクォータ (制限値) を引き上げます
- 本番環境のフリートをセットアップします
- 負荷テストを実施し、クリティカルパスをテストします
- API スロットリングを監視します
- 新しいゲームサーバーバージョンを本番環境にデプロイする際は、Blue/Green デプロイメントを使用します
1 – 起動に関するアンケートの記入とクォータの引き上げ
オープンベータ、アーリーアクセス、そして最終的な本番ローンチなどのマイルストーンを実現するための重要なポイントの 1 つは、必要に応じてサービスのクォータを引き上げることです。Amazon GameLift Servers のデフォルトのサービスクォータは、開発初期の段階で意図せずスケールアウトしてしまうことからアカウントを保護するために設定されています。プレイヤーのサポートを本格的に開始する準備が整ったら、プレイヤーの負荷をサポートするために必要なインフラストラクチャを提供できるよう、より高いクォータが必要になる場合があります。
Launch Questionnaire は、Amazon GameLift Servers コンソールの左側メニューの Resources から Prepare to launch を選択すると確認できます。このアンケートでは、選択したインスタンスタイプのインスタンス制限と、Amazon GameLift Servers API のスロットリング制限の両方について説明しています。
アンケートに記入する際の重要なポイントは以下の通りです:
- ローンチの 2-3 ヶ月前を目安に早めに実施してください。
- ベータ版やプライベートプレビューもローンチの一種であることを忘れないでください。そのためにもクォータの引き上げが必要です。次のマイルストーンに向けて、アンケートの新しいバージョンをいつでも提出できます。
- マルチロケーションフリートには、ホームリージョンと追加のロケーションがあります。フリートのホームリージョンを定義し、選択したホームリージョンに対して各ロケーションのクォータ引き上げを要求することを忘れないでください。ロケーション固有のインスタンス制限は、各ホームリージョンごとに個別に設定されます。
- 使用している Amazon GameLift Servers API を正確に確認し、予想されるピーク時のリクエストレートに合わせてクォータの引き上げを要求してください。Describe API は一般的に各プレイヤーのリクエストごとに呼び出すようには設計されていないため、ゲームセッション作成フローでの使用は避けてください。これらの API を呼び出す必要がある場合は、Host persistent world games on Amazon GameLift Servers で説明されているように、中央管理的な方法で実装できます。
- 必要なすべての Amazon Web Services (AWS) アカウントに対してクォータの引き上げを要求するようにしてください。これには、本番環境、テスト環境、および負荷テスト用のアカウントが含まれる場合があります。
アンケートを送信する際は、担当の AWS アカウントチームがいる場合、全員が同じ情報を共有できるよう、メールに AWS アカウントチームを追加するようにしてください。
図 1 は、Amazon GameLift Servers コンソールで Launch Questionnaire を見つける場所を示しています。
図 1: Amazon GameLift Servers の Launch Questionnaire
2 – 本番環境フリートの設定
Amazon GameLift Servers の本番環境のフリートは、開発環境のフリートとは異なる設定にすることをお勧めします。
主な考慮事項:
- Game Scaling Protection Policy を Full Protection に設定します。これにより、フリートがスケールダウンする際に、実行中のゲームセッションが保護されます。
- Target-based Auto-scaling policy を有効にし、ローンチ日に向けて十分なバッファ (30-50% までが目安) を確保してください。トラフィックが安定した後で、この値を減らすことができます。
- 各リージョンに個別のフリートを設定するのではなく、マルチロケーションフリートを使用してください。グローバルなフリートのリソースを一元的に表示でき、運用の複雑さが軽減されるため、運用が大幅に効率化されます。
- レイテンシーの目標とプレイヤー人口を考慮し、それに応じてロケーションを選択してください。レイテンシーの低い FPS ゲームでは、通常、各大陸エリアに複数のロケーションが必要です。比較的レイテンシシビアではないゲームでは、より少ないロケーション数で対応でき、運用も効率化できます。クライアント側でレイテンシーを測定するには、Amazon GameLift が提供する UDP ping ビーコンを使用できます。
- 各ロケーションのスケーリング設定 (min と max) を設定し、各ロケーションで健全なベースライン (min) と、突発的な需要の増加に対応できる余裕 (max) を確保してください。
ローンチ日には、各ロケーションの最小値を、初期トラフィックのピークに対応できる十分な基準値に設定して、事前にスケールアウトすることをお勧めします。トラフィックパターンが安定した後は、この値を低く設定することもできますが、初期ローンチ時のピークに備えておくことが重要です。
複数のインスタンスタイプを使用してゲームサーバーをホストできる機能により、予期せぬプレイヤー負荷に対する準備を確認してください。これは例えば、選択したインスタンスファミリーの .large と .xlarge のバリエーション、または同じインスタンスファミリー内の異なるインスタンスファミリーや世代を使用することができます。ほとんどのゲームでは複数のフリートをホストする必要はありませんが、大規模な環境では、マルチフリート戦略をオプションとして持つことで、必要な容量を確保することができます。
図 2 は、2 つのマルチロケーションフリートが同じ Amazon GameLift Servers Queue に登録されている様子を示しています。1 つ目のフリートは C6i.large インスタンスタイプを使用し、ゲームの起動に対応するためにスケールアウトされています。2 つ目のフリートは C5.large インスタンスタイプを使用し、スケールアウトされていません。両方のインスタンスタイプの制限は、本番トラフィックを処理するために Launch Questionnaire で引き上げられています。いずれかのロケーションで C6i.large の可用性が低下するという稀なケースでは、バックアップフリートにより異なるインスタンスタイプでスケールアウトし、プレイヤーへのサービスを継続できます。バックアップフリートには、C6i.xlarge など、C6i ファミリーの別のインスタンスサイズを使用することもできます。
図 2:大規模なスケーリングに向けたマルチロケーションフリートの利用
3 – 負荷テストとクリティカルパスのテスト
負荷テストは、インフラストラクチャのボトルネックを明らかにするために重要です。これは、ローンチの準備における最も重要なステップの 1 つです。
特に Amazon GameLift Servers の場合、負荷テストでは以下のような問題が浮き彫りになります：
- インスタンス制限緩和の不足
- API クォータ (各 API に個別に適用)
- ゲームサーバーが通信するバックエンドシステムなどの依存関係の問題
実際のトラフィックパターンを再現した大規模な負荷テストを実施することで、これらの問題が表面化します。これは、高い同時ユーザー数で発生するように、すべてのロケーションでセッション配置リクエストを段階的に増やし、すべてのシステムが期待通りに動作することを確認することを意味します。
ゼロから 5 分間で 50 万の同時ユーザーまでスケールアウトするテストは、紙の上では良いテストに見えますが、実際のトラフィックパターンを反映していない可能性があります。現実的なパターンでテストすることで、期待値を過度に高めすぎないようにすることができます。通常、ピークまでの増加は、より長い期間 (通常は数時間) にわたって発生します。過去のゲームのデータや、SteamDB などのツールを使用して、ローンチ時の一般的なトラフィックパターンを確認することができます。
負荷テストを実施するには、主に 2 つの方法があります。
- フリートのスケーリングとセッション配置のテストは、
StartGameSessionPlacementなどの API を直接呼び出すことで実行できます。比較的少数の実際のクライアントで、Python や Bash スクリプトを使用して実行できます。これは、API とインスタンスの制限、およびスケーリング設定の優れたスモークテストとなります。 - ゲームサーバーに加えてバックエンドサービスも含めた、重要なシナリオ全体をテストします。このアプローチには、実際のアカウント作成とゲームへのログイン、およびバックエンドを使用したマッチメイキングやセッション配置のリクエストが含まれます。これは、バックエンドのボトルネックもテストする、より包括的な負荷テストのアプローチです。このテストは、(AWS Fargate コンテナで実行される) ゲームのヘッドレスボットクライアントを使用するか、クライアントにできるだけ近い動作をするスクリプトを使用して実行することをお勧めします。
完全なテストを実施する際は、クライアントがゲームサーバーに接続し、通常のプレイヤーと同様に移動やその他のアクションを送信してゲームをプレイすることもできるのが理想的です。これにより、ゲームサーバーのパフォーマンスもストレステストされます。また、クライアントがセッションをプレイし、次のセッションに接続するためにログアウトする際の、現実的なセッション時間とゲームセッションのローテーションのテストにも役立ちます。
これらのテストを正しくモニタリングするには、このブログシリーズの第 1 回 Amazon GameLift Servers でローンチを成功させるためのステップ：開発フェーズ のモニタリング、ロギング、アラームのセクションで説明したアプローチを使用してください。さらに、Amazon GameLift Servers API からのエラーやスロットリング、および自社やサードパーティが管理するその他のサービスやコンポーネントからのエラーやスロットリングも追跡する必要があります。これについては、セクション 4「API スロットリングのモニタリング」で詳しく説明します。
Werner Vogels (Amazon の CTO) が述べているように、「障害は当たり前のことであり、すべてのものは最終的に障害を起こします」。重要なシナリオが、あらゆる依存関係 (Steam、コンソールログイン、データベースなど) の障害を適切に処理できることを確認する必要があります。また、内部障害からの復旧が確実にできることも確認する必要があります。これにより、ローンチ日のあらゆる予期せぬ事態に備えることができます。
図 3 は、AWS Fargate 上でロードテストクライアントをサービスとしてホストする例を示しています。このサービスは複数の Amazon ECS タスクを実行し、各タスクは最大 10 個の個別のクライアントコンテナをホストできます。ロードテストクライアントは、複数の AWS リージョンにまたがって実行でき、レイテンシーとプレイヤーの位置がゲーム体験にどのように影響するかをテストできます。クライアントは、実際のゲームクライアントのスクリプト化されたヘッドレスバージョン、またはゲームクライアントとして動作するスクリプトのいずれかを使用できます。
図 3: 重要なシナリオを負荷試験する
4 – API スロットリングのモニタリング
負荷テスト中、Amazon GameLift Servers API の呼び出しが デフォルトのプロビジョニング制限を超えると、スロットリングエラーが発生する可能性があります。スロットリングされた呼び出しを特定し対応することは、運用の安定性、可用性、そしてシームレスなプレイヤーエクスペリエンスを確保する上で重要です。
AWS CloudTrail は、Amazon GameLift Servers の包括的な API イベント追跡機能を提供し、すべての API 使用状況を監視および監査できます。
CloudTrail を以下の用途で効果的に使用できます:
- Amazon GameLift Servers API のアクティビティを追跡
- スロットリングを特定
- CloudWatch のカスタムメトリクスにアラームを設定
- 予想されるピーク時のリクエストレートに合わせてクォータの引き上げを運用チームに通知
CloudTrail レコードに適用される eventSource が gamelift.amazonaws.com で、以下のいずれかの errorCode または errorMessage が適用されるスロットリングを監視します。
errorCodeがThrottlingExceptionの場合errorCodeがRequestLimitExceededの場合errorMessageがRateExceededの場合
運用の可視性を確保するため、CloudTrail で新しい証跡を作成し、CloudWatch Logs を有効にします。CloudWatch Logs にログを書き込むための適切な AWS Identity and Access Management (IAM) のアクセス許可があることを確認してください。Amazon GameLift イベントを取得するためにCloudWatch のロググループを指定します。設定が完了すると、すべての Amazon GameLift Servers API コールと関連するスロットリングエラーを CloudWatch Logs で確認できるようになります。
CloudWatch Logs で、CloudTrail がログを書き込むために使用するロググループを選択し、スロットリングのパターンを特定するためのカスタムメトリクスフィルターを作成します。namespace を割り当て、スロットリングが発生するたびにインクリメントされるカスタムメトリクスを正常に作成する必要があります。
以下はフィルターパターンの例です。
{ ($.eventSource = "gamelift.amazonaws.com") && ($.errorCode = "ThrottlingException") }
カスタムメトリクスを設定したら、スロットリングのしきい値を監視するための CloudWatch アラームを設定します。例えば、5 分間に 10 件以上のスロットリングリクエストが発生した場合にアラームを発生させます。作成したアラームを Amazon SNS トピックにアタッチし、運用チームにメール、ショートメッセージサービス (SMS)、またはチャット通知を送信します。これにより、運用チームは API の使用状況を確認し、適切なアクションを取ることができます。
クォータの緩和をリクエストする前にスロットリングを最小限に抑えるには：
- Amazon GameLift Servers API 呼び出しに対してエクスポネンシャルバックオフを実装します
- Amazon GameLift Servers API から大規模なデータセットを取得する際は、ページネーションとフィルタリングを使用します
- フリート情報などの頻繁にアクセスされるデータをキャッシュして、API 呼び出しの繰り返しを避けます
- 可能な場合は操作をバッチ処理して、API 呼び出しの頻度を減らします
5 – 本番環境における新しいゲームサーバーバージョンには Blue/Green デプロイを使う
本番環境に移行した後、特に初期の段階では、ゲームサーバーに比較的頻繁にパッチを適用する必要があります。また、ゲームに機能や改善を加えていく中で、継続的なパッチ適用も必要になります。Amazon GameLift Servers でのアップデートには、Blue/Green デプロイメントが推奨されます。
このアプローチでは、新しいゲームサーバービルドまたはコンテナイメージを使用して、完全に新しい本番フリートをセットアップします。新しいフリートの準備が整い、モニタリングの状態が良好であることを確認したら、いくつかのゲームセッションでスモークテストを実施する追加ステップを設けることができます。その後、Amazon GameLift Servers Queue の設定を変更して、ゲームセッション配置要求を古いフリートから新しいフリートにルーティングすることで、運用中のアップデートを実行できます。新しいバージョンで新規セッションが作成され始めますが、古いフリート上で実行中のセッションは中断されることなく継続できます。
※訳注 : Blue/Green デプロイメントでは、Blue と Green の環境が同時に起動する時間帯において、通常時の倍近くの数のインスタンスを起動する必要があり得ます。インスタンスの制限の緩和申請においてはその点を加味した数を申請ください。
すべてが問題なく見える場合は、全てのセッションが完全に終了（ドレイン）した後で古いフリートを終了できます。以前のバージョンにロールバックする必要がある場合は、キューのターゲットを切り替えることで古いバージョンに戻すことができます。これは Blue/Green デプロイメントの主要なメリットの 1 つです。
セッション配置にキューを使用しない場合、エイリアスリソースを同様の方法で使用できます。Amazon GameLift Servers Toolkit には、このアプローチの実装方法を示す Python スクリプトが用意されています。
図 4 は、キューの背後にあるフリートを新しいものに置き換え、以前のフリートで古いセッションをドレインする Blue/Green デプロイメントを示しています。
図 4: Blue/Green デプロイメント
まとめ
Amazon GameLift Servers での本番環境のローンチを成功させるために、サービスクォータをスケールアウトする方法について説明しました。次に、本番環境のフリートを設定する際の重要な考慮事項について説明しました。また、負荷テストがローンチの準備にどのように役立つか、そして負荷テストを実施する一般的な方法についても説明しました。最後に、本番環境での運用中のサーバーバージョンの更新を管理するのに Blue/Green デプロイメントがどのように役立つかについて説明しました。
このシリーズでは、Amazon GameLift Servers でのゲームローンチを成功させるために、運用面とアーキテクチャ面での準備に関する幅広い側面を取り上げました。マルチプレイヤーゲームサーバーのホスティングには、Amazon GameLift Servers をぜひご利用ください。ビジネスの加速に向けた支援について詳しく知りたい場合は、AWS の担当者までお問い合わせください。