費用対効果の高いリソース

GAMECOST01 - ゲームサーバーに適したコンピューティングソリューションは、どのようにして選んでいますか?

他の種類のワークロードと比べて、ゲームワークロードに特有である要素の 1 つは、プレイヤーエクスペリエンスに不可欠なゲームサーバーです。プレイヤーはゲームクライアントからゲームサーバーに接続してゲームセッションをプレイするため、ゲームサーバーはマルチプレイヤーゲームの運用に伴う最大のコスト要因の 1 つでもあります。そのため、ゲームのコンピューティングインフラストラクチャの利用方法を最適化してコストを削減することが重要です。

GAMECOST_BP01: ゲームサーバーを複数のコンピューティングタイプでベンチマークします。

ゲーム開発の初期計画とテスト段階では、ベンチマークを実行して、ゲームに使用する適切なコンピューティングタイプを決定する必要があります。通常、セッションベースのマルチプレイヤーゲームやその他の低レイテンシーのゲームでは、Amazon EC2 インスタンスを使用してゲームサーバーをホストします。各 EC2 インスタンスタイプには、異なるワークロードプロファイルごとに最適化したコンピューティングリソースの組み合わせがあります。ゲームサーバーコードのベンチマークを実行して、ゲームセッションで使用する CPU、メモリ、ネットワーク帯域幅などのリソースを特定するとともに、最小限のコストでパフォーマンスについて適切なバランスが得られるオプションを選択する必要があります。一般的な市販ゲームエンジン (Unreal Engine、Unity、Lumberyard など) のほとんどには、エンジンエディタで利用できるパフォーマンスプロファイリングユーティリティが用意されているため、ゲームサーバービルドから出力されるログやメトリクスデータを活用してパフォーマンスやリソース使用率をベンチマークできます。このテレメトリは、適切な EC2 インスタンスタイプを評価および選択して使用するために役立ちます。

複数の EC2 インスタンスタイプにわたってゲームサーバーをベンチマークする一環として、ゲームを実行するために必要なオペレーティングシステムの種類やプロセッサ要件を判断する必要があります。最善のコスト最適化を行うには、ゲームコンピューティングインフラストラクチャを Linux インスタンスで実行して、Windows で発生するライセンスコストを排除することをお勧めします。また、 Graviton インスタンス は 64 ビットの Arm ベースの EC2 インスタンスであり、 Unreal Engine の専用サーバーを含むゲームサーバーの実行に使用できます。

GAMECOST_BP02 - 各ゲームサーバーインスタンスでホストするゲームセッションの数を最適化してコストを削減します。

サーバーインスタンスごとにホストするゲームセッションの数を最適化して、コンピューティングの使用率を向上させ、コンピューティングインフラストラクチャのコストを削減します。

ゲームデベロッパーは、コストを削減するために、同一の物理サーバーや仮想サーバーでホストするゲームセッションの数を最大化する必要があります。これは、ゲームサーバーのパッキング密度とも呼ばれます。これを達成するには、EC2 インスタンスで同時にホストできるゲームサーバープロセスの数を増やします。通常は、1 つのゲームサーバープロセスが EC2 インスタンスで利用可能なすべてのリソースを占有しないようにします。これは、ゲームのコンピューティングコストを削減する最も重要な方法の 1 つであり、EC2 インスタンス上の複数のサーバープロセスを別々のポートで起動および管理できるソフトウェアを使用する必要があります。例えば、Amazon GameLift には、 インスタンスあたりのゲームサーバープロセスの最大数に対するクォータがあります。このクォータを活用することで、ホスティングコストを削減できます。インスタンスあたりのゲームサーバープロセスの最大数に対する現在のクォータの詳細については、Amazon GameLift のドキュメントを参照してください。

ゲームサーバーのプロセスを EC2 インスタンスなどの仮想マシン上にデプロイする代わりに、ゲームデベロッパーがゲームサーバーをコンテナベースのアプリケーションとして実行する方法が一般的になりつつあります。そのために、Amazon Elastic Container Service (Amazon ECS) や Amazon Elastic Kubernetes Service (Amazon EKS) などのコンテナオーケストレーションプラットフォームを使用したり、 Fargate を使用してゲームサーバーをホストしたりします。コンテナプラットフォームには、ジョブスケジューリング機能があり、リソース要件やその他の指定した配置ロジックに基づいて、ゲームサーバーコンテナをホストするために使用できるコンテナインスタンスをクラスター内で自動的に検出できます。ただし、このレンズの信頼性の柱で説明しているように、スケーリングとプレイヤー配置の動作をどのように管理すれば、アクティブなプレイヤーセッションを妨げずに済むかを検討することが重要です。

GAMECOST_BP03 - 適切なコンピューティング料金を選択してコストを削減します。

ゲームサーバーソフトウェアのパフォーマンステストをさまざまなインスタンスタイプとコンピューティングオプションで実行し、どのオプションがゲームにとって最も費用対効果が高いかを判断します。

ワークロードに適した EC2 インスタンスタイプを効率的に利用することに加えて、コスト最適化の目標に対してどのコンピューティング料金オプションが最もふさわしいかを検討してください。オンデマンドインスタンス、スポットインスタンス、リザーブドインスタンス、Savings Plans など、いくつかの料金オプションが用意されています。

スポットインスタンスは、コンピューティングの割引率が最大で、使用量のコミットメントが不要であり、予測不能で急増する種類のワークロードにも柔軟に対応できるため、ゲームサーバーの実行に理想的です。ただし、スポットインスタンスは中断される可能性が高いため、ゲームセッション時間が短いゲームサーバーのワークロードや、中断に対する許容度が高い状況に最適です。例えば、 「Running your game servers at scale for up to 90% lower compute cost (ゲームサーバーを大規模に実行してコンピューティングコストを最大 90% 削減)」というブログ記事 では、EC2 スポットインスタンスによって Amazon EKS で Kubernetes を使用してゲームサーバーを実行するためのガイダンスを提供しています。スポットを使用する場合は、ゲームサーバーのワークロードを AWS リージョン内の複数の EC2 インスタンスタイプやアベイラビリティーゾーンで実行し、容量の利用を分散して中断リスクを低減することもお勧めします。また、スポットインスタンスとオンデマンドインスタンスを組み合わせて使用することで、アクティブなゲームセッションに対する中断の影響の可能性を最小限に抑え、容量最適化割り当て戦略を使用して中断のリスクをさらに低減するのもよいでしょう。その他のベストプラクティスについては、「 EC2 スポットを利用するうえでのベストプラクティス 」を参照してください。Amazon EC2 Auto Scaling キャパシティーの再調整 を使用すると、容量を未然にモニタリングして、スポットインスタンスの中断の可能性が高くなったときに容量を追加できます。 Amazon GameLift FleetIQ は、スポットインスタンスと統合して低コストのスポットインスタンスの使用を最適化するとともに、中断のリスクを低減します。Amazon GameLift を使用してゲームをホストする場合は、 Amazon GameLift のドキュメント を参照してコンピューティングリソースを選択してください。

EC2 リザーブドインスタンス を使用すると、特定のリージョンやインスタンスタイプでの使用をコミットすることでコンピューティングの割引を受けることができます。また、リザーブドインスタンス (RI) の代わりに Savings Plans を使用すると、RI と同様の割引を、リージョン、インスタンスファミリー、オペレーティングシステム、テナンシー全体にわたって柔軟に適用したり、Fargate や Lambda などの他のコンピューティングサービスに適用したりできます。Savings Plans は、リージョンごとに柔軟に対応できるため、新しいゲームの発売時など、複数の地域にわたる使用量が予測できない場合に特に適しています。オンデマンド料金と比べて大幅な割引が得られ、1 年間または 3 年間の予想使用量を予測できるシナリオに最適です。

さまざまなコンピューティングサービスに割引を柔軟に適用できることは、大きなメリットであり、EC2 インスタンスで動作しているゲームサーバーや、Lambda などの他のサービスでの運用が考えられるゲームバックエンドサービスに対して、インフラストラクチャ全体にわたってコメットメントベースの使用料割引を適用できます。中断される可能性があるスポットインスタンスとは異なり、Savings Plans とリザーブドインスタンスは、課金に関する直接的なメリットが得られ、オンデマンド容量と同じ使用特性を利用できます。通常、ゲームサーバーのワークロードでは、ゲームを本番稼働環境で長期間 (少なくとも数週間から数か月) 運用し、日々の使用パターンが十分に明らかになった後で、リザーブドインスタンスを導入します。リザーブドインスタンスと Savings Plans には使用量のコミットメントが必要なため、事前に購入したリザーブドインスタンスと Savings Plans の使用率を最大化することをお勧めします。オンデマンドインスタンスやスポットインスタンスなど、他の購入オプションを追加すると、ゲームサーバーの予測できない使用量の急増に対する柔軟性を高めることができます。

例えば、プレイヤーの毎日の使用パターンによると、プレイヤーベースをサポートするために常時最低 20 台のサーバーが必要であり、さらに定期的な需要のために最大 40 台のサーバーが必要になるとします。この場合、使用需要は予測可能で安定しているため、20 個のリザーブドインスタンスまたは同数の Savings Plan コミットメントを購入することを検討します。これにより、購入した使用量コミットメントを最大限に活用できます。プレイヤーをサポートするために必要な追加容量は、スポットインスタンスとオンデマンドインスタンスを使用してホストできます。

次の図は、ゲームサーバーのワークロードに複数のコンピューティング料金オプションを使用する例を示しています。

ゲームサーバーのホストにおける複数の EC2 料金オプションの使用

この図では、プレイヤーの同時実行数が時間とともに変動しており、使用率の管理とコストの最適化が困難になっています。この変動に対処するには、さまざまなコンピューティング料金プランを組み合わせて使用することを検討します。例えば、リザーブドインスタンスと EC2 Savings Plans を使用して最小使用要件を満たす一方で、動的な使用には EC2 オンデマンドインスタンスと EC2 スポットインスタンスを使用します。

GAMECOST02 - ゲームインフラストラクチャのデータ転送コストは、どのように最適化していますか?

ゲームは、ゲームプレイ体験を提供するゲームインフラストラクチャとプレイヤーのゲームクライアントデバイスとの間だけでなく、ゲームインフラストラクチャのコンポーネント間でも、インターネットを介して大量のデータを転送する場合があります。データ転送が発生する場合の例としては、プレイヤーがゲームコンテンツの更新をゲームクライアントにダウンロードしたとき、ゲームの進行状況をクラウドに保存したとき、友人とリアルタイムのマルチプレイヤーゲームセッションに参加したとき、また、ゲームインフラストラクチャがリージョンとアベイラビリティーゾーンの間でデータを転送したときなどがあります。アーキテクチャの選択を最適化して、このデータ転送コストを削減するために、ゲームワークロードのどこでデータ転送が発生するかを理解することが重要です。ゲームのデータ転送コストを最適化するには、以下のベストプラクティスを検討してください。

GAMECOST_BP04: インターネットを介したデータ転送のコストを最適化します。

ゲームバックエンドからプレイヤーへのデータ転送コストを削減するソリューションを実装します。

CloudFront を使用すると、コンテンツ配信のコストと、使用頻度の高い公開ウェブアプリケーションのコストを削減できます。クラウドに保存したゲームコンテンツやアセットは、通常、Amazon S3 に保存され、S3 からゲームクライアントに直接配信されるか、Amazon EC2 でホストしているウェブサーバーから配信されます。Amazon EC2 は、Amazon S3 からコンテンツを取得してクライアントに配信します。コンテンツダウンロードのデータ転送コストを削減するには、クラウドストレージの前で Amazon CloudFront を使用してユーザーにコンテンツを配信することを検討してください。CloudFront を使用すると、コンテンツをリージョンから直接配信するよりも、CloudFront のポイントオブプレゼンスから配信する方が割安であるため、データ転送のコストを削減できます。また、CloudFront では Amazon EC2 や Amazon S3 などの AWS ベースのオリジンに対するオリジン取得に対して課金は発生しません。コンテンツがキャッシュ可能であれば、CloudFront を使用してユーザーにより近い場所にコンテンツをキャッシュできるため、コストをさらに削減できます。また、キャッシングを使用しない場合でも、CloudFront では CloudWatch ネットワーク経由でトラフィックをルーティングすることでサーバーとクライアントとの間のデータ転送コストを削減できるため、公開ウェブアプリケーションやサービスの前に配置することにはメリットがあります。 CloudWatch を使用して Amazon CloudFront の使用状況をモニタリングできます。複数のコンテンツ配信ネットワーク (CDN) を使用するユースケースの場合、CloudFront Origin Shield が追加のキャッシュレイヤーを提供し、さまざまなプロバイダーからのオリジンリクエストを統合して数を削減できます。コンテンツ配信のベストプラクティスについては、「 Content Delivery for Games (ゲーム向けのコンテンツ配信)」ホワイトペーパーを参照してください。

VPC フローログ を使用すると、環境内のネットワークトラフィックをモニタリングし、トラフィックの送信元と送信先を特定してデータ転送コストを最適化できます。

GAMECOST_BP05: コストを最適化して、サービス、アベイラビリティーゾーン、リージョン間のデータ転送を削減します。

ゲームインフラストラクチャとインターネットとの間のデータ転送を最適化することに加え、ゲームインフラストラクチャ内のコンポーネント間のデータ転送も最適化して、同一リージョン内のアベイラビリティーゾーン間、およびリージョン間のトラフィック転送量を削減する必要があります。これらのデータ転送ではいずれも、データ転送コストが発生します。

内部トラフィックをアプリケーションと同じアベイラビリティーゾーン内に留めることを優先します。ゲームバックエンドサービスのデータ転送を最適化するには、インスタンスを持つデータベースクラスターとキャッシュクラスターをリージョン内の複数のアベイラビリティーゾーンにデプロイして、アプリケーションサーバーと同じアベイラビリティーゾーンにあるインスタンスからのデータ読み取りを優先するようにアプリケーションを設定できます。この設定でも、アベイラビリティーゾーン間のデータレプリケーションに伴うデータ転送コストは発生しますが、アプリケーションでデータベースやキャッシュを多用するユースケース (読み取り量の多いワークロードなど) では、同じアベイラビリティーゾーン内にデータのローカルコピーを持つことで費用対効果が高まるため、この設定をお勧めします。

特定のリージョン内にあるデータに対して、他のリージョンにあるアプリケーションから定期的にアクセスする必要がある場合は、これらの他のリージョンにデータのコピーをレプリケートします。アプリケーションがリージョンをまたいでデータにアクセスするよりも、リージョン間でデータをレプリケートしてデータのローカルコピーに必要なだけ頻繁にアクセスできるようにする方が費用対効果が高くなります。リージョンをまたいだアクセスは、規模が大きくなると費用対効果が低くなり、パフォーマンスが低下し、リージョンをまたいで適切なセキュリティコントロールを提供するためのネットワーク設定が複雑になります。

例えば、ゲームバックエンドサービスをバージニア北部リージョンにデプロイし、プレイヤー集団に最も近い複数のリージョンにグローバルにゲームサーバーをデプロイして、ゲームプレイヤーのレイテンシーを短縮することができます。ゲームサーバーからアクセスする先のオブジェクトが、バージニア北部でホストしている Amazon ElastiCache for Redis の S3 バケットまたはキャッシュデータに保存されている場合は、ゲームサーバーがあるリージョンにキャッシュデータをレプリケートすると、これらのサーバーがデータを取得するための継続的なデータ転送コストを削減できるため、費用対効果が高くなります。AWS には、データのマルチリージョンレプリケーションを簡単に設定できる機能として、 Amazon Aurora Global Database、Amazon ElastiCache Global Datastore for Redis、 Amazon DynamoDB Global Tables などが用意してあります。Amazon S3 に保存しているオブジェクトに対して別のリージョンでホストしているアプリケーションから頻繁にアクセスする必要があるユースケースでは、 Amazon S3 クロスリージョンレプリケーション (CRR) を使用してコストを削減することを検討してください。CRR を使用すると、アプリケーションをデプロイした 1 つ以上のリージョンでホストしているバケットをレプリケート先として、オブジェクトのコピーを自動的にレプリケートしてコストを削減できます。この設定でも、オブジェクトを別のリージョンにレプリケートするコストは発生しますが、同じリージョン内のレプリケート先の S3 バケットからオブジェクトを取得できるようになるため、アプリケーションがリージョンをまたいで S3 からオブジェクトを取得するたびに発生するデータ転送コストはなくなります。

VPC エンドポイントを使用してサービスと統合し、NAT ゲートウェイを経由したデータトラフィックと処理に対する課金を低減することをお勧めします。同様に、パブリックサブネットでホストしている公開アプリケーションでは、トラフィックが NAT ゲートウェイを経由する必要がない場合があり、送信トラフィックをインターネットゲートウェイに直接送信するように設定して、NAT ゲートウェイが不要な場所でのデータ処理と転送のコストを回避できます。

次の図に示すアーキテクチャを使用すると、他の複数のリージョンでホストしている複数のアプリケーションから共有データセットに低レイテンシーでアクセスする必要がある場合に、アクセスコストを削減できます。

世界中のユーザーがレイテンシーの影響を受けやすいゲームコンテンツにアクセスする場合のコストの最適化

1. ゲーム開発チームが世界中に分散していて、Amazon S3 内の同一コンテンツのコピーにアクセスする場合があります。この場合、米国東海岸に所在するゲームデベロッパーは、コンテンツを Amazon S3 バケットに直接アップロードするか、このリージョンでホストしているアプリケーションからアップロードすることができます。

2. S3 クロスリージョンレプリケーション は、オブジェクトのコピーを他のリージョンのバケットにレプリケートするように設定されているため、これらのリージョンでホストしているアプリケーションは、リージョンをまたいでアクセスのリクエストを送信しなくても、ローカルリージョンからオブジェクトを取得できます。レプリケーションは双方向に設定できるため、他のいずれかのリージョンで行った更新は残りのリージョンにも反映できます。

3. VPC エンドポイント が VPC から Amazon S3 へのプライベートアクセスを提供するため、アプリケーションは NAT ゲートウェイ経由でトラフィックをルーティングする必要がありません。NAT ゲートウェイは、他の高スループットのアプリケーショントラフィックで使用されている場合、輻輳を引き起こすおそれがあります。他のグローバルスタジオ、リモートワーカー、請負業者などのゲーム開発チームは、各自が最も高いパフォーマンスを得られるリージョンに接続してデータベースのコピーにアクセスできます。スタジオの所在地やデータセンターとリージョンとの間に専用接続を設定するには、 Direct Connect を使用します。リモートワーカーに VPC への安全なリモートアクセスを提供するには、 クライアント VPN を使用します。

4. プレイヤーのゲームクライアントやその他のインターネットベースのアプリケーションが CloudFront と統合することで、S3 に保存したオブジェクトのコンテンツキャッシュを CloudFront が提供し、インターネット経由の静的および動的コンテンツのデータ転送コストを削減します。

Amazon S3 のマルチリージョンアクセスポイント を使用すると、S3 バケットをホストしていないリージョンでホストされているアプリケーションのアクセスパターンを簡素化できます。アプリケーションは、マルチリージョンアクセスポイントとやり取りし、レイテンシーが最も低いバケットの所在地を特定してリクエストを処理できます。マルチリージョンアクセスポイントには追加料金がかかります。

GAMECOST03 - ゲームインフラストラクチャのデータストレージコストは、どのようにして最適化していますか?

ゲームは大量のデータを生成する可能性があり、これらのデータを保存して、デベロッパー、プレイヤー、ゲーム自体が利用できるようにする必要があります。例えば、ゲームデベロッパーが常時生成する新しいソースコード、ゲームコンテンツ、アセットを保存したり、プレイヤーが生成する新しいユーザー生成コンテンツを処理したりする必要があります。また、ゲームクライアントやサーバーが生成するゲーム分析テレメトリをデータレイクに保存して分析チームが利用できるようにする必要があります。ゲームは構造化データも生成します。

GAMECOST_BP06 - 適切なストレージタイプを選択してコストを削減します。

生成して保存するデータの種類ごとに固有の特性があります。これらの特性を考慮して、ワークロードに使用する適切なストレージソリューションを決定する必要があります。

最も費用対効果の高いストレージクラスにオブジェクトデータを保存するには、 S3 オブジェクトのライフサイクル管理 を使用します。Amazon S3 には、複数の ストレージクラス と オブジェクトのライフサイクル管理 機能が用意されており、シンプルできめ細かなポリシーを簡単に設定して、ストレージ階層間のデータ移行を自動化し、コストを削減できます。すべてのデータをデフォルトで S3 Standard ストレージクラスに単に保存するのではなく、時間の経過とともに階層間でデータを自動的に移行するようにライフサイクル設定をセットアップすることを検討してください。あるいは、不明なアクセスパターンや変化するアクセスパターンには S3 Intelligent-Tiering ストレージクラスを使用します。また、S3 Intelligent-Tiering は、費用対効果の高い方法でデータを階層間で自動的に移行できます。ライフサイクルポリシーを手動で設定しなくてもコストを最適化できるため、デフォルトのストレージクラスとしてお勧めします。現時点では、 小規模で存続期間が短いオブジェクト向けの最適な選択肢となっています。Amazon S3 の一般的なユースケースには、ゲームアセット、静的コンテンツ、ゲームログ、データレイクストレージ、バックアップの保存があります。開発中に共有ファイルシステムをワークステーションにアタッチするなど、ファイルシステムが必要なユースケースでは、 Amazon Elastic File System (Amazon EFS) を使用してさまざまなストレージクラスを提供する ことを検討してください。Amazon EFS は、ファイルの追加や削除に応じて自動的に拡大/縮小するため、インフラストラクチャの管理は不要です。