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

テストシナリオの作成

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

ステップ 1: 全般設定

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

テストの識別

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

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

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

スケジュールオプション

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

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

    [今すぐ実行] オプションが選択されています

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

    日付と時刻のピッカーを使用した 1 回実行オプション

  • スケジュールに従って実行 - cron ベースのスケジューリングを使用して、定期的にテストを自動的に実行します。一般的なパターン (毎時間、毎日、毎週) から選択することも、カスタム cron 式を定義することもできます。

    cron パターンセレクタを使用した [スケジュールに従って実行] オプション

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

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

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

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

  • 1 回限りのテスト (1 回実行) の場合、CloudWatch Events ルールは指定された日に実行し、api-services Lambda 関数はテストを実行します。

  • 定期的なテスト (スケジュールに従って実行) の場合、CloudWatch Events ルールは指定された日付にアクティブ化され、api-services Lambda 関数は指定された頻度に基づいてすぐに、かつ繰り返し実行される新しいルールを作成します。

ライブデータ

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

  • 平均応答時間。

  • 仮想ユーザー数。

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

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

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

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

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

テストタイプの選択

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

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

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

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

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

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

HTTP エンドポイント設定 image::images/test-types.png[Select the test type to run] 「単一の HTTP エンドポイント」を選択した場合は、以下の設定を行います。

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: トラフィックシェイプ

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

Traffic Shape の設定画面

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

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 制限に基づいて作成できるタスクの最大数 (デフォルト: 2000)。

  • 使用可能な DLT タスク - リージョンで現在、使用可能なタスクの数 (デフォルト: 2000)。

リージョンごとに使用可能なタスクを示す表

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

テスト期間

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

ランプアップ

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

ホールド

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

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

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

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

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

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

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

テストシナリオの管理

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

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

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

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

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

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

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