翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# GAMEPERF02-BP02 レイテンシーの影響を受けやすいゲームインフラストラクチャをプレイヤーの近くに配置してパフォーマンスを向上させることをサポートするアプローチを設計する
ゲームサーバーなどのレイテンシーの影響を受けやすいインフラストラクチャを個別に配置することで、長いネットワークルートの影響を最小限に抑えることができます。反復可能なデプロイにより、プレイヤーにとってパフォーマンスの高い複数の場所を簡単に維持できます。Ping はゲーム UI に表示される一般的なメトリクスであり、低い ping は差別化機能になる可能性があります。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
最初にゲームを起動するときに、プレイヤーベースに関する十分な情報がまだない場合があり、ゲームのプレイに最も関心のあるプレイヤーに最も近いインフラストラクチャをデプロイする最適な場所を十分に把握できます。これは一般的な課題であり、ホスティング配置戦略を迅速に調整して、必要なサーバーをプレイヤーの近くにデプロイできるアーキテクチャを設計することで、このシナリオに備える必要があります。ゲーム開発者は、ゲームインフラストラクチャのデプロイを定期的な起動後分析として定期的に評価し、反復的なアプローチで時間の経過とともに改善に段階的に投資するのが一般的です。
ベストプラクティスは、VPC、サブネット設定 VPCs 、重要なゲームサービスの起動に必要な依存関係などのインフラストラクチャの設定に、 AWS CloudFormation や Hashicorp の Terraform などの infrastructure-as-code テンプレートを使用することです。これにより、これらのテンプレートを参照し、必要に応じてすばやくカスタマイズして、プレイヤーをサポートするために追加のインフラストラクチャが必要な場所にデプロイできます。
また、将来の拡張を可能にするために、現在のデプロイ戦略をどのように進化させるかを理解しておく必要があります。IaC テンプレートは繰り返し可能ですが、ネットワーク計画に代わるものではありません。[IPAM](https://docs.aws.amazon.com/vpc/latest/ipam/what-it-is-ipam.html) は VPCsを管理します。サブネットのサイズ設定、アベイラビリティーゾーンの選択、IP インベントリとクロスアカウントアベイラビリティーゾーンの調整。ネットワークは考慮すべき重要であり、変更されるとプレイヤーにとって破壊的になる可能性があります。複数の地理的ロケーションにデプロイされたゲームサーバーは、ゲームバックエンドに接続します。これは、プライベート接続をサポートするために追加の設定が必要になる可能性がある単一または複数のホームリージョンでホストされることがより一般的です。これらの考慮事項は、ゲームの要件の進化やプレイヤーの要件の変化に応じてゲームホスティング戦略を変更できるように、時間の経過とともに継続的に評価する必要があります。
ゲームに使用するゲームホスティングロケーションの数を決定するときは、次の要素を考慮してください。
+ **プレイヤーエクスペリエンスの質の向上:** ゲームホスティングロケーションを追加することで、プレイヤーエクスペリエンスをどの程度改善できますか? そうすることで達成できる増分パフォーマンスの向上は何ですか? このパフォーマンス向上をどのように測定しますか?
+ **優先するプレイヤーの人数:** ゲームホスティングロケーションを追加すると、何人のプレイヤーのエクスペリエンスを向上させることができますか? どのプレイヤー母集団または地理的場所を優先しますか?
+ **変更によるダウンストリームへの影響:** ゲームホスティング戦略を変更すると、プレイヤーのマッチメーキング待機時間にどのように影響しますか? プレイヤープール内のマッチングサイズ、スキルバランス、またはプレイヤー数は、ゲームホスティングロケーション戦略を変更できますか? より多くのロケーションをサポートすると、プレイヤープールがフラグメント化され、コストと複雑さが増加する可能性があります。
これらの各考慮事項は、ゲームホスティングの場所を追加または削除する際に評価する必要があります。例えば、パフォーマンスの低いゲームプレイエクスペリエンスを持つ地理的な場所のプレイヤー、または最も声の高いパブリックフィードバックを表現するプレイヤーのエクスペリエンスの改善を優先できます。また、プレイヤーの収益化を優先順位に含めることもできます。例えば、ゲームの収益源が大きくなる地理的な場所のプレイヤーのエクスペリエンスの向上に重点を置き、パフォーマンスの向上を導入すると増分収益を生み出す可能性があります。
でのインフラストラクチャのホスティングに加えて AWS リージョン、 の拡張機能である [Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) を使用して AWS リージョン、ゲームサーバーやプレイヤーに近い音声チャットサーバーなどのレイテンシーの影響を受けやすいアプリケーションをホストできます。ゲーム開発チームのエクスペリエンスを向上させるために、Local Zones でゲーム開発インフラストラクチャを実行することもできます。例えば、Local Zones を使用すると、ゲーム開発者の近くでセルフマネージドソースコントロールサーバーのレプリカをホストしたり、Amazon EC2 インスタンス、EBS ボリューム、および開発スタジオの近くにある 1 つ以上の Local Zones にデプロイされた Amazon FSx ファイルシステムを使用して、ユーザーにゲーム開発仮想ワークステーションとコンテンツストレージを提供したりするなどのユースケースに対応できます。オンプレミスでインフラストラクチャをホストする必要はありません。
[Outposts](https://aws.amazon.com/outposts/) は、リージョンまたはローカルゾーンが同じ地理的エリアで利用できない場合に適しています。ゲームサーバーがシステムの信頼性をバックエンドにできるように、データセンターから への接続を考慮 AWS する必要があります。 AWS Outposts および Outpost Server は、同じサービスと API を使用してデータセンター AWS で実行するように専用に構築されており、ゲームを実行する場所を問わず一貫したデプロイモデルを作成できます。 APIs 複数のラックを論理 Outpost に結合し、インフラストラクチャを共有できます AWS アカウント。ハードウェアライフサイクルは によって管理 AWS され、リードタイムは最短で 3 か月です。
コンテナを使用してゲームを構築し、独自のオンプレミスインフラストラクチャにデプロイできるオープンソースソフトウェアを使用してハイブリッドデプロイアーキテクチャを柔軟に採用したい場合は、 または Local Zones の代わりに [ECS Anywhere](https://aws.amazon.com/ecs/anywhere/) AWS Outposts または [EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/) を使用できます。Amazon GameLift でホストする場合、[Amazon GameLift Anywhere を使用してローカルハードウェアでサーバービルドを実行できます](https://aws.amazon.com/blogs/gametech/hybrid-game-server-hosting-with-amazon-gamelift-anywhere/)。これにより、開発プロセスが高速化され、ローカルゾーンを使用したり、フリートの一部として独自のメタルを登録したりできます。
### 実装手順
+ AWS CloudFormation や Terraform などの infrastructure-as-code ツールを反復可能なデプロイに使用して、プレイヤーのニーズに基づいてゲームホスティングロケーションをすばやくカスタマイズおよびスケーリングできます。
+ ゲームホスティングロケーションを追加または削除するときに、プレイヤーエクスペリエンスの改善、プレイヤー母集団の優先順位、マッチメーキング時間などのダウンストリームへの影響を評価します。
+ AWS Local Zones、Outposts、または ECS Anywhere、EKS Anywhere、GameLift Anywhere などのハイブリッドオプションを使用して、レイテンシーの影響を受けやすいインフラストラクチャを最適化し、多様なデプロイニーズに対応します。