選択
| GAMEPERF01 – ゲームインフラストラクチャをホストする地理的リージョンは、どのようにして決定しますか? |
|---|
GAMEPERF_BP01 – プレイヤーとビジネスステークホルダーからのフィードバックを確認します。
ゲームを最初に発売するときは、ビジネスステークホルダーとの話し合いに基づいて、インフラストラクチャをどこにデプロイするかを決定する必要があります。例えば、パブリッシングチームと話し合い、プレイヤーにゲームをリリースしたい場所や、リリース前のマーケティングと広告を集中的に行う場所を決定します。
また、ビジネスステークホルダーは、需要を刺激し、プレイヤーの受け入れや実現性の理解を深めるために役立つメカニズムを持っているはずです。例えば、これらのチームが用意するメカニズムには、ゲームの予約注文、マーケティングイベントやキャンペーン、関心を寄せているプレイヤーを発売前に登録するための公開メーリングリストのほか、発売時にゲームのプレイヤーが最も多いと思われる場所を判断するための関連シグナルを確立するアプローチなどがあります。ゲームでは、事前に決めたリージョンロールアウト戦略を使用する場合もあります。この戦略を使用してテストやソフトローンチを行い、リージョンのプレイヤーの需要をより詳しく判断できます。
GAMEPERF_BP02 - レイテンシーの影響を受けるゲームインフラストラクチャをプレイヤーの近くに配置してパフォーマンスを向上させるアプローチを設計します。
ゲームを最初に発売するときは、プレイヤーベースに関する十分な情報がないため、ゲームのプレイに関心が高いプレイヤーに最も近い場所としてどこにインフラストラクチャをデプロイすれよいかを適切に判断できない場合があります。これは一般的な課題であり、このような場合に備えて、ホスティング戦略を迅速に調整してサーバーのデプロイ先をプレイヤーに近づけることができるようにアーキテクチャを設計する必要があります。ゲームデベロッパーは、通常、ゲーム発売後にゲームインフラストラクチャのデプロイを定期的に評価し、反復的なアプローチを使用しての長期的な改善に向けて段階的に投資します。
ベストプラクティスは、VPC、サブセット設定、重要なゲームサービスのリリースに必要な依存関係など、インフラストラクチャの設定に AWS CloudFormation や Terraform などの Infrastructure as Code テンプレートを使用することです。これらのテンプレートを参照し、必要に応じてすばやくカスタマイズして、プレイヤーをサポートするために追加のインフラストラクチャが必要な場所にデプロイします。
また、現在のデプロイ戦略をどのように進化させれば将来の拡張につながるかについても理解しておく必要があります。例えば、ゲームサーバーをホストするためのサブネットを作成する場合は、そのサイズを考慮し、確実に成長に対応できる大きさにします。そのほか、複数の場所にデプロイしたゲームサーバーをゲームバックエンドに接続する方法も考慮する必要があります。ゲームバックエンドは、中央の場所または複数の場所でホストしている場合があり、プライベート接続をサポートするには追加の設定が必要になることがあります。これらの考慮事項は長期にわたって継続的に評価し、ゲームの要件が時間の経過とともに進化したり、プレイヤーの要件が変化したりしたときにはゲームのホスティング戦略を変更できるようにする必要があります。
ゲームにいくつのゲームホスティング場所を使用するか決定する場合は、以下の要因を考慮する必要があります。
-
プレイヤーエクスペリエンスの質の向上: ゲームのホスティング場所を増やすことで、プレイヤーエクスペリエンスをどの程度改善できるか。 その結果、パフォーマンがどれくらい向上するか。 このパフォーマンスの向上をどのようにして測定するか。
-
優先させるプレイヤー集団: ゲームのホスティング場所を増やした場合、どれくらいの数のプレイヤーのエクスペリエンスを改善できるか。 どのプレイヤー集団または地理的な場所を優先するか。
-
変更によるダウンストリームへの影響: ゲームホスティング戦略を変更した場合、プレイヤーのマッチメイキングの待ち時間にどのように影響するか。 変更を導入した場合、ゲームセッションを構成するために必要なマッチサイズやプレイヤー数は、世界各地で大規模なプレイヤー集団を構築する能力に影響するか。
ゲームホスティングの場所をどこで追加または削除するかを決定する場合は、これらの各考慮事項を評価する必要があります。例えば、ゲームプレイ体験のパフォーマンスが最も低い地域のプレイヤーや、最も熱心なフィードバックを一般に公開したり、コミュニティ管理チームに伝えたりしているプレイヤーのエクスペリエンスを優先的に改善することを選択できます。また、プレイヤーの収益化を優先させることもできます。例えば、ゲームの大きな収益源である地域や、パフォーマンスを改善することで収益増が見込める地域のプレイヤーのエクスペリエンスを改善することに集中的に取り組みます。
AWS リージョンでのインフラストラクチャのホスティングに加えて、 ローカルゾーン
また、既存のオンプレミスデータセンターやコロケーション施設に機能を拡張することもできます。そのためには、
Outposts
GAMEPERF_BP03 - ネットワークアクセラレーションテクノロジーを使用して、インターネット全体のパフォーマンスを向上させます。
プレイヤーエクスペリエンスを改善するには、レイテンシーの影響を受けやすいゲームインフラストラクチャをプレイヤーにより近い物理的な場所に配置するだけでなく、ゲームのネットワークパフォーマンスを最適化する方法もあります。プレイヤーがゲーム接続時に利用するネットワークやインターネットサービスプロバイダー (ISP) とゲームインフラストラクチャの接続を向上させるテクノロジーを使用します。ネットワークアクセラレーションでは、ネットワークパスを最適化してパフォーマンスを向上させます。最適化後のネットワークパスを通じて、プレイヤートラフィックをゲームクライアントからインターネット経由でゲームサーバーやゲームバックエンドサービスなどのゲームインフラストラクチャにルーティングします。例えば、AWS Global Accelerator
ゲーム開発チームは世界中に分散している場合があり、共有のコンテンツやアセットに効率的にアクセスする必要があります。Amazon S3 バケットに保存した共有コンテンツのパフォーマンスを向上させるには、 S3 クロスリージョンレプリケーション
を使用してリージョン間でのデータの双方向レプリケーションをセットアップし、ユーザーが自分に近いバケットからデータにアクセスできるようにします。このアクセスパターンを簡素化するには、 S3 マルチリージョンアクセスポイント を使用します。これにより、Global Accelerator を使用してグローバルネットワーク全体で S3 へのリクエストを高速化します。詳細については、「 Improving the Player Experience by Leveraging AWS Global Accelerator and Amazon GameLift FleetIQ (Global Accelerator と Amazon GameLift Servers FleetIQ を活用してプレイヤーエクスペリエンスを向上させる)
| GAMEPERF02 – ゲームセッションでの過剰なリソース使用が、同じゲームサーバーインスタンスで実行している他のプレイヤーに影響を与えないようにするには、どうすればよいですか? |
|---|
GAMEPERF_BP04 - ゲームサーバーのプロセスをモニタリングして問題を検出します。
ゲームサーバーインスタンスでリソースを効率的に使用するには、インスタンスごとに複数のゲームサーバープロセスを実行できます。この場合は、ゲームセッションをホストしている各ゲームサーバープロセスが、同じゲームサーバーインスタンスでホストしている他のゲームセッションに悪影響を与えないようにアーキテクチャを設計する必要があります。
ゲームサーバーインスタンスで使用できる限られたリソースをモニタリングして、各ゲームサーバープロセスが所定のリソース割当量のしきい値を超えたときにアラートを受信できるようにします。しきい値を超えた場合は、関連するシステムやゲームサーバーのログを、中央ログソリューションなどの耐久性のあるストレージにダンプするようにゲームサーバーソフトウェアを設定し、ゲームサーバーエンジニアがこの動作の原因を調査できるようにします。また、ゲームサーバーインスタンスで実行している各ゲームサーバープロセスのメトリクスを報告するようにインスタンスを設定し、インスタンスの全体的なメトリクスに加えて各ゲームサーバープロセスをモニタリングできるようにする必要があります。例えば、Amazon GameLift Servers は ゲームセッションをモニタリングするためのメトリクスを提供します。このメトリクスは、ゲームサーバーインスタンスに設定できる Amazon CloudWatch Agent を使用して収集したゲーム固有のカスタムメトリクスとログで拡張できます。これらのメトリクスは、CloudWatch で表示できます。または、Single Sign-On を使用して統合した Amazon Managed Grafana
GAMEPERF_BP05 - 実際のゲームプレイシナリオをシミュレートして、ゲームサーバーのパフォーマンスをテストします。
パフォーマンステストを実施し、さまざまなゲームプレイシナリオを評価して、ゲームサーバープロセスが EC2 インスタンスメモリ、CPU、ネットワーク帯域幅などの固定リソースの使用を適切に処理しているかどうかを判断する必要があります。
プレイヤーの一般的なゲームプレイのパスと動作をミラーリングできるボットを使用してゲームプレイをシミュレートするテストを作成し、ゲームサーバープロセスがさまざまな使用状況下でどのように処理するかを判断できるようにします。例えば、 AWS での分散負荷テスト
| GAMEPERF03 - ゲームに適したコンピューティングソリューションは、どのようにして選択しますか? |
|---|
GAMEPERF_BP06 - さまざまなコンピューティングタイプにわたってゲームパフォーマンスをベンチマークします。
ゲームサーバーのワークロードに関しては、ゲームサーバーをホストするための最適なコンピューティングソリューションを特定するための画一的なアプローチはありません。通常、ゲームサーバーにはコンピューティングに最適化された EC2 インスタンスを使用します。このインスタンスファミリーは、計算負荷の高いゲームサーバーなどのワークロード用に最適化されています。または、ゲームで特定の機能を実装するために大量のメモリが必要な場合は、メモリに最適化されたインスタンスが最適である場合もあります。
ワークロードが大量のネットワークリソースを使用するユースケースでは、ネットワークに最適化されたインスタンスを実装することを検討してください。ネットワークに最適化されたインスタンスは、通常、インスタンス名が「n」で始まります。ゲームは、レイテンシーや破棄されたパケットの影響を受けやすいため、EC2 拡張ネットワークを使用してゲームサーバーのネットワークパフォーマンスを向上させることをお勧めします。拡張ネットワークは、シングルルート I/O 仮想化 (SR-IOV) を使用して、 サポートしているインスタンスタイプ に対して高パフォーマンスのネットワーク機能を提供します。SR-IOV は、従来の仮想化ネットワークインターフェイスと比べて I/O パフォーマンスが高く、CPU 利用率が低いデバイス仮想化の手法です。拡張ネットワークは、高い帯域幅、1 秒あたりのパケット (PPS) の高いパフォーマンス、常に低いインスタンス間レイテンシーを実現します。Elastic Network Adapter による拡張ネットワークは、最新の EC2 インスタンスタイプで利用できます。
ゲームが複数の EC2 インスタンスタイプで同じように動作する場合は、複数のインスタンスタイプを使用してゲームサーバーをホストすることを検討します。これにより、経時的なパフォーマンスをモニタリングし、経時的なパフォーマンス傾向を特定できるだけの十分な本番ゲームセッションをホストした後で、さらに最適化を実行できます。ゲームに新しい機能を追加したことに伴って異なるリソース割り当てが必要になる場合、時間の経過とともにリソース要件が変わる場合があります。複数のインスタンスタイプを使用するように EC2 Auto Scaling グループ を設定できます。または、個別の Auto Scaling グループを使用して個別のインスタンスタイプを実行するゲームサーバーインスタンスをホストし、メトリクスの相関と集約を管理しやすくすることができます。
また、インテルベースのインスタンス、AMD ベースのインスタンス、ARM ベースの Graviton インスタンスなど、異なる種類のプロセッサごとにゲームがどのように動作するかを評価する必要があります。
さらに、コンテナと Lambda 関数を使用してゲームをホストした場合に、ゲームのパフォーマンスにどのような影響があるかをベンチマークする必要があります。非同期ゲームやゲームバックエンドサービスなど、ゲームサーバーによる存続期間が長い処理が不要なユースケースでは、Lambdaでサーバーレスアーキテクチャを使用することを検討します。これにより、ゲームオペレーションチームのために管理とオペレーションを簡素化し、ゲームをより迅速に多くの AWS リージョンにグローバルにデプロイできます。サーバーレスのベストプラクティスについては、「 サーバーレスアプリケーションレンズ - Well-Architected Framework」 を参照してください。詳細については、「
グローバルゲームサーバーに適したコンピューティング戦略を選択する
GAMEPERF_BP07 - ゲーム開発向けの仮想ワークステーションでは、グラフィックスインスタンスを使用します。
ゲームデザイナー、エンジニア、アーティスト、QA、その他の担当者は、仮想ワークステーションを使用することが必要になる場合があります。これらのユースケースをサポートするには、グラフィックスに最適化されたインスタンスを使用します。この種のインスタンスは、インスタンス名が「g」で始まり、ゲーム開発やゲームストリーミングなどのグラフィックスのユースケースをサポートするための専用の GPU を使用して構築します。
エンドユーザーが通常必要とするのと同じツールを使用して、さまざまなグラフィックス最適化インスタンスタイプにわたってパフォーマンスを評価およびベンチマークします。例えば、AMD や NVIDIA など、メーカーの異なる GPU を搭載したさまざまなグラフィックス最適化インスタンスを使用します。これらのインスタンスをベンチマークする場合は、使用するソフトウェアが、サポートされている GPU および関連ドライバーと互換性があることを確認してください。グラフィカルアーティストのユースケースでは、 Amazon Nimble Studio
EC2 を使用して独自のカスタム仮想ワークステーションを開発する場合は、これらの仮想ワークステーションにエンドユーザーがアクセスする方法を検討する必要があります。さまざまな接続オプションがありますが、 NICE DCV
詳細については、以下を参照してください。
GAMEPERF_BP08 - レイテンシーの影響を受けないコンピューティングタスクを非同期ワークフローにプッシュします。
ゲームのパフォーマンスを最適化する場合、クライアントとゲームバックエンドとの間のインタラクションを必ずしも同期的に実行する必要はないことを覚えておくことが重要です。プレイヤーエクスペリエンスの観点から各機能を検討し、特定のインタラクションで同期通信 (ブロッキング型で必要でリソースを集中的に消費する) が必要かどうか、各機能を非同期的に実装できるかどうかを判断する必要があります。ネットワーク呼び出しを実装する場合は、非同期のノンブロッキング型アプローチを使用するようにします。さらに、タスクをキューにオフロードし、できる限りクライアントへの高速応答を優先することで、作業を効率的に実行するようにゲームバックエンドを設定する必要があります。
例えば、リーダーボードの更新は、プレイヤーセッションの終了時に非同期で実行できるため、クライアントはリーダーボードの更新が完了するのを待機する必要はありません。代わりに、これをゲームクライアントで非同期に実行します。また、この種のオペレーションは Amazon SQS などのキューにプッシュするようにバックエンドサービスを設計することを検討してください。このアーキテクチャでは、リクエストを受け入れ、SQS (非同期処理のためにメッセージを永続的に保存する) のキューにリクエストを追加し、クライアントに迅速に返信するように、バックエンドを設定する必要があります。リーダーボードの更新が完了すると、バックエンドはゲームクライアントに更新を送信して、プレイヤーのリーダーボードのビューを更新します。または、プレイヤーはゲームのリーダーボード画面にアクセスするだけで最新データを取得できます。アクセスに伴って、バックエンドにウェブリクエストが発行され、キャッシュから最新データが取得されます。
詳細については、以下のドキュメントを参照してください。
