翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

GAMEOPS05-BP01 目標を達成するための適切なステージ、アーキテクチャ、負荷テストフレームワークを選択する

ゲームの負荷テストのアプローチは、実行される開発プロセスの段階、負荷生成システム自体のアーキテクチャ、負荷テストフレームワークの選択など、多くの要因によって大きく異なる場合があります。初期フェーズ、反復スプリント中、本番デプロイ前、デプロイ後のいずれであっても、いつ実施されるかがテスト作業の目標と焦点を形成します。負荷生成インフラストラクチャの設計には独自の長所と短所があり、負荷テストフレームワークの選択は、テストプロセスで使用できる機能、使いやすさ、統合に大きな影響を与えます。これらの要素を慎重に調整することで、開発チームは負荷テストのアプローチをゲーム固有の特性に合わせて調整し、最も価値のあるパフォーマンスインサイトを引き出し、プレイヤーにスムーズなエクスペリエンスを提供できます。

このベストプラクティスを活用しない場合のリスクレベル: 高

実装のガイダンス

さまざまな開発段階での負荷テスト

開発フェーズの早い段階で探索的負荷テストを実施することで、基盤となるシステムアーキテクチャを検証できます。これにより、デベロッパーは、広範な実装作業を行う前に、ゲームのインフラストラクチャ、データベース設計、ネットワークトポロジーについて十分な情報に基づいた意思決定を行うことができます。負荷テストはリスクを特定し、パフォーマンスベースラインを作成するため、開発ライフサイクルの後半でコストのかかる再作業や技術的負債を最小限に抑えることができます。また、チーム間でゲームのパフォーマンス要件の理解を共有し、コラボレーションと意思決定を向上させることもできます。最終的に、初期フェーズの負荷テストは、高性能でスケーラブル、回復力のあるゲームの強力な基盤を構築し、プレイヤーエクスペリエンス全体を向上させるのに役立ちます。

負荷テストでは、各スプリントまたはイテレーションの終了時に、最新のサイクルで導入された新機能、バグ修正、その他の変更のパフォーマンスへの影響を評価できます。このターゲットを絞ったアプローチにより、開発チームは最新の更新によってもたらされるリグレッションやパフォーマンスの低下をすばやく特定できるため、パイプラインをさらに進める前にこれらの問題に対処し、一貫したレベルの品質とパフォーマンスを維持できます。

堅牢な負荷テストは、本番環境にデプロイする前に、予想される実際のトラフィックと負荷条件を処理するシステムの能力を検証するのに役立ちます。本番インフラストラクチャ内のスケーラビリティのボトルネックやリソースの制約を発見し、ゲームのパフォーマンスを最適化する機会を提供し、初日からスムーズで応答性の高いユーザーエクスペリエンスを生み出すことができます。起動前の負荷テストから得られたインサイトは、起動日のリスクを軽減し、継続的なキャパシティプランニングに役立つため、ゲームの長期的な持続可能性とスケーラビリティの基盤となります。

すでに本番稼働しているゲームの負荷テストにより、チームはゲームのパフォーマンスをモニタリングし、時間の経過とともに発生する可能性のあるパフォーマンスの低下を特定できます。これにより、プレイヤーエクスペリエンスに影響を与え、ユーザーの保持に悪影響を及ぼす前に、プロアクティブに問題に対処できます。さらに、本番環境での負荷テストでは、実装されたパフォーマンス最適化作業またはインフラストラクチャスケーリングの有効性を検証します。このプロセスは、ゲームが進化して成熟しても、プレイヤーに高品質で応答性の高いスケーラブルなゲームエクスペリエンスを提供します。

ロード生成アーキテクチャ

ゲーム負荷テスト用の負荷生成アーキテクチャの設計にはさまざまな形式があり、それぞれに独自の利点と考慮事項があります。 

最も基本的なレベルでは、セルフマネージド Amazon EC2 インスタンスをプロビジョニングして、ロードジェネレーターとして機能するように設定できます。コントロールノードとワーカーノードのアプローチでは、複数のロード生成インスタンスをセットアップできます。各インスタンスは独自のテストスクリプトを実行し、全体で 1 つのコントロールインスタンスによって管理されます。アーキテクチャは、追加のワーカーノードをスピンアップすることで複雑さを増すことなくスケールアップしてより多くの負荷を生成できますが、この実践的なアプローチでは、チームは基盤となるインフラストラクチャのプロビジョニング、設定、管理を処理する必要があります。

よりスケーラブルでオーケストレーションされたアプローチでは、Amazon EKS Kubernetes クラスターを使用して、コンテナベースのロードエージェントのフリートに負荷テストワークロードを管理および分散できます。Kubernetes 自動スケーリング機能を使用して、負荷生成ポッドのスケーリングを処理できます。一方、チーム自身がポッドをホストするクラスター内の基盤となる EC2 インスタンスを設定および管理します。 

または、 のサーバーレスな性質により、必要なスケーラビリティと柔軟性を維持しながらインフラストラクチャ管理を抽象化することで、負荷テストのセットアップを高速化および簡素化AWS Fargateできます。オンプレミスの負荷生成 Kubernetes クラスターが既に存在するが、追加の容量が必要なハイブリッドソリューションの場合、EKS Anywhere は両方のクラスターを から 1 つとして管理できます AWS マネジメントコンソール。

また、要件と目標に応じて AWS Lambda関数を使用することもできます。Lambda 関数は、追加のリソースをプロビジョニングして管理することなく、比較的簡単にセットアップしてスケーリングできます。また、他の AWS サービスとの深い統合により、より複雑で動的なテストシナリオを作成することもできます。ただし、Lambda 関数には同時関数とランタイム (15 分) に制限があるため、達成できる負荷テストのスケールと長さが制限される可能性があります。コールドスタートレイテンシーは結果の精度にも影響し、Lambda のリソース制限は要求の厳しい負荷テストワークロードには適していない可能性があります。

構築済みのソリューションの使用を希望するスタジオは、分散負荷テスト AWSを使用できます。このソリューションでは、 上の Amazon ECS AWS Fargate を使用して、数万人の接続ユーザーのシミュレーションを実行できるコンテナをデプロイします。これを使用すると、 を使用して IAC 方式で負荷テストインフラストラクチャをすばやく開始できます AWS CloudFormation。

負荷テストフレームワーク

2 つの負荷テストフレームワークが同じように構築されることはありません。テスト作成用の直感的なグラフィカルインターフェイスを持つものもあれば、コマンドラインベースのものもあります。1 つのツールは柔軟でパフォーマンスが高いものの、設定と管理に時間と労力が必要であり、もう 1 つのツールはサーバーレスですが、作成して実行できるテストには制限があります。大規模なコミュニティと多くのチュートリアルを好む人もいれば、現場では証明されていない人もいます。本番環境でバトルテストされているが、コミュニティのサポートやドキュメントがない人もいます。自分とチームに適したバランスを取るフレームワークを選択します。いくつかの一般的なオプションは次のとおりです。

実装手順