View a markdown version of this page

テストシナリオの作成 - AWS での分散負荷テストソリューション
ステップ 1: 全般設定ステップ 2: シナリオ設定ステップ 3: トラフィックシェイプステップ 4: 確認して作成する

テストシナリオの作成

テストシナリオの作成の主なステップには、全般設定の構成、シナリオの定義、トラフィックパターンの形成、設定の確認の 4 つが含まれます。

ステップ 1: 全般設定

テスト名、説明、全般設定オプションなど、負荷テストの基本的なパラメータを設定します。

テストの識別

  • テスト名 (必須) - テストシナリオのわかりやすい名前

  • テストの説明 (必須) - テストの目的と設定に関する追加の詳細

  • タグ (オプション) - 最大 5 つのタグを追加して、テストシナリオを分類および整理します。

スケジュールオプション

テストを実行するタイミングを設定します。

  • 今すぐ実行 - 作成後すぐにテストを実行します。

  • 1 回実行 - 特定の日時にテストを実行するようにスケジュールします。

  • スケジュールに従って実行 - cron ベースのスケジューリングを使用して、定期的にテストを自動的に実行します。一般的なパターン (毎時間、毎日、毎週) から選択することも、カスタム cron 式を定義することもできます。受け入れられる cron 形式、サポートされているパターン、制約の詳細については、デベロッパーガイドの「Cron 式のリファレンス」を参照してください。

スケジューリングワークフロー

テストをスケジューリングすると、次のワークフローが発生します。

  • スケジュールパラメータは、Amazon API Gateway を介してソリューションの API に送信されます。

  • API はパラメータを Lambda 関数に渡し、構成された Amazon EventBridge スケジューラのスケジュールを作成して、指定した日付に実行されるようにします。

  • 1 回限りのテスト (1 回実行) の場合、EventBridge スケジューラのスケジュールは指定された日時で api-services Lambda 関数を呼び出し、テストを実行します。

  • 定期的なテスト (スケジュールに基づいて実行) の場合、EventBridge スケジューラのスケジュールは、有効期限まで cron 式または rate 式で定義された頻度で、api-services Lambda 関数を即座に呼び出します。

ライブデータ

テストの実行中にリアルタイムのメトリクスを表示するには、[ライブデータを含める] チェックボックスをオンにします。有効にすると、以下をモニタリングできます。

  • 平均応答時間。

  • 仮想ユーザー数。

  • 成功したリクエストカウント。

  • 失敗したリクエストカウント。

ライブデータ機能は、1 秒間隔で集計されたデータをリアルタイムでグラフ表示します。詳細については、「ライブデータを使用したモニタリング」を参照してください。

ステップ 2: シナリオ設定

特定のテストシナリオを定義し、希望するテストフレームワークを選択します。

テストタイプの選択

実行する負荷テストのタイプを選択します。

  • 単一の HTTP エンドポイント - シンプルな設定で単一の API エンドポイントまたはウェブページをテストします。

  • JMeter - JMeter テストスクリプト (.jmx ファイルまたは .zip アーカイブ) をアップロードします。

  • K6 - K6 テストスクリプト (.js ファイルまたは .zip アーカイブ) をアップロードします。

  • Locust - Locust テストスクリプト (.py ファイルまたは .zip アーカイブ) をアップロードします。

注記

4 つのテストタイプはすべてサードパーティーのコンポーネントに依存しています。このソリューションは、テストタイプに応じて JMeter、K6、または Locust を実行する Taurus テスト自動化フレームワークを介してテストを実行します。単一の HTTP エンドポイントテストは JMeter テストプランに変換され、バンドルされた Apache JMeter によって実行されます。テストを作成する前に、セキュリティ上の考慮事項、ライセンス情報、パッチ適用オプションについて、サードパーティーのテストフレームワークを確認してください。

HTTP エンドポイント設定

「単一の HTTP エンドポイント」を選択すると、ソリューションは設定から JMeter テストプランを生成し、バンドルされた Apache JMeter バイナリを使用してそれを実行します。これらの設定を行います。

HTTP エンドポイント (必須)

テストするエンドポイントの完全な URL を入力します。例えば、https://api.example.com/users。エンドポイントが AWS インフラストラクチャからアクセス可能であることを確認します。

HTTP メソッド (必須)

リクエストの HTTP メソッドを選択します。デフォルトは GET です。その他のオプションには、POST、PUT、DELETE、PATCH、HEAD、OPTIONS が含まれます。

リクエストヘッダー (オプション)

リクエストにカスタム HTTP ヘッダーを追加します。一般的な例には、次が含まれます。

  • Content-Type: application/json

  • Authorization: Bearer <token>

  • User-Agent: LoadTest/1.0

    [ヘッダーの追加] を選択して、複数のヘッダーを含めます。

本文ペイロード (オプション)

POST または PUT リクエストのリクエスト本文のコンテンツを追加します。JSON、XML、またはプレーンテキスト形式をサポートします。例: {"userId": 123, "action": "test"}。

フレームワークスクリプトをテストする

JMeter、K6、または Locust を使用する場合、テストスクリプトファイル、またはテストスクリプトとサポートファイルを含む .zip アーカイブをアップロードします。JMeter では、.zip アーカイブ内の /plugins フォルダにカスタムプラグインを含めることができます。

重要

テストスクリプト (JMeter、K6、または Locust) は同時実行数 (仮想ユーザー)、トランザクションレート (TPS)、ランプアップ時間、およびその他のロードパラメータを定義する場合がありますが、ソリューションはテストの作成時に [Traffic Shape] 画面で指定した値でこれらの設定を上書きします。Traffic Shape 設定は、テスト実行のタスク数、同時実行数 (タスクあたりの仮想ユーザー数)、ランプアップ時間、保留期間を制御します。

ステップ 3: トラフィックシェイプ

マルチリージョンのサポートを含め、テスト中にトラフィックを分散する方法を設定します。

マルチリージョンのトラフィック設定

1 つ以上の AWS リージョンを選択して、負荷テストを地理的に分散します。選択したリージョンごとに、次を設定します。

タスク数

テストシナリオのために Fargate クラスターで起動されるコンテナ (タスク) の数。アカウントが「Fargate リソースが制限に達しました」に達すると、追加のタスクは作成されません。

同時実行

タスクごとに生成された同時仮想ユーザーの数。推奨される制限は、タスクごとに 2 つの vCPU のデフォルト設定に基づいています。同時実行数は CPU とメモリのリソースによって制限されます。

ユーザー数を確定する

コンテナがテストでサポートできるユーザー数は、ユーザー数を徐々に増やしつつ、Amazon CloudWatch でパフォーマンスをモニタリングしながら決定することができます。CPU とメモリのパフォーマンスが限界に近づくと、コンテナがデフォルト設定 (2 vCPU と 4 GB のメモリ) でテストをサポートできる最大ユーザー数に達します。

キャリブレーションプロセス

次の例を使用して、テストの同時ユーザー制限の確定を開始できます。

  1. 200 人以下のユーザーでテストを作成します。

  2. テストの実行中に、CloudWatch コンソールを使用して CPU とメモリをモニタリングします。

    1. ナビゲーションペインの [Container Insights] で、[パフォーマンスのモニタリング] を選択します。

    2. [パフォーマンスのモニタリング] ページで、左側のドロップダウンメニューから [ECS クラスター] を選択します。

    3. 右側のドロップダウンメニューから、Amazon Elastic Container Service (Amazon ECS) クラスターを選択します。

  3. モニタリング中は、CPU とメモリを監視します。CPU が 75% を超えない、またはメモリが 85% を超えない (1 回限りのピークは無視) 場合は、より多くのユーザー数で別のテストを実行できます。

テストがリソースの制限を超えなかった場合は、手順の 1～3 を繰り返します。オプションで、コンテナのリソースを増やして、同時実行ユーザー数を増やすことができます。ただし、これによりコストが高くなります。詳細については、「デベロッパーガイド」を参照してください。

注記

正確な結果を得るには、同時ユーザー制限を決定する際に一度に 1 つのテストのみを実行してください。すべてのテストでは同じクラスターを使用し、CloudWatch Container Insights ではクラスターに基づいてパフォーマンスデータを集計します。これにより、両方のテストが CloudWatch Container Insights に同時にレポートされるため、単一テストでのリソース使用率のメトリクスが不正確になります。

エンジンごとのユーザー調整に関する詳細については、BlazeMeter ドキュメントの「Calibrating a Taurus Test」を参照してください。

注記

このソリューションでは、各リージョンの使用可能な容量情報が表示され、使用可能な制限内でテスト設定を計画するのに役立ちます。

使用可能なタスクの表

[使用可能なタスクの表] には、選択した各リージョンのリソースの可用性が表示されます。

  • リージョン - AWS リージョン名。

  • タスクあたりの vCPU - 各タスクに割り当てられた仮想 CPU の数 (デフォルト: 2)。

  • DLT タスク制限 - アカウントの Fargate オンデマンド vCPU クォータに基づいて作成できるタスクの最大数。通常、新しいアカウントではクォータが低くなります。Service Quotas コンソールで現在の制限を確認し、必要に応じて引き上げをリクエストします。

  • 使用可能な DLT タスク - リージョンで使用可能な現在のタスク数。DLT タスクの制限から、実行中の Fargate タスクによって既に使用されている vCPU を引いて計算されます。

タスクごとに使用可能なタスクまたは vCPU の数を増やすには、デベロッパーガイドを参照してください。

テスト期間

負荷テストの実行期間を定義します。

ランプアップ

ターゲットの同時実行数に達するまでの時間。この期間、負荷は 0 から設定された同時実行レベルまで徐々に増加します。

ホールド

ターゲット負荷を維持する期間。この期間中、テストは完全な同時実行で続行されます。

ステップ 4: 確認して作成する

テストシナリオを作成する前に、すべての設定を確認してください。検証:

  • 全般設定 (名前、説明、スケジュール)。

  • シナリオ設定 (テストタイプ、エンドポイント、またはスクリプト)。

  • トラフィックシェイプ (タスク、ユーザー、期間、リージョン)。

確認後、[作成] を選択してテストシナリオを保存します。

テストシナリオの管理

テストシナリオを作成したら、次のことができます。

  • 編集 - テスト設定を変更します。一般的ユースケースには以下が含まれます。

    • トラフィックシェイプを調整して、希望するトランザクションレートを実現します。

  • コピー - 既存のテストシナリオを複製してバリエーションを作成します。一般的ユースケースには以下が含まれます。

    • エンドポイントの更新またはヘッダー/本文パラメータの追加。

    • テストスクリプトの追加または変更。

  • 削除 - 不要になったテストシナリオを削除します。