# テストシナリオの作成
テストシナリオの作成の主なステップには、全般設定の構成、シナリオの定義、トラフィックパターンの形成、設定の確認の 4 つが含まれます。
## ステップ 1: 全般設定
テスト名、説明、全般設定オプションなど、負荷テストの基本的なパラメータを設定します。
**テストの識別**
+ **テスト名** (必須) - テストシナリオのわかりやすい名前
+ **テストの説明** (必須) - テストの目的と設定に関する追加の詳細
+ **タグ** (オプション) - 最大 5 つのタグを追加して、テストシナリオを分類および整理します。
**スケジュールオプション**
テストを実行するタイミングを設定します。
+ **今すぐ実行** - 作成後すぐにテストを実行します。
![[今すぐ実行] オプションが選択されています](http://docs.aws.amazon.com/ja_jp/solutions/latest/distributed-load-testing-on-aws/images/schedule-run-now.png)
+ **1 回実行** - 特定の日時にテストを実行するようにスケジュールします。
+ **スケジュールに従って実行** - cron ベースのスケジューリングを使用して、定期的にテストを自動的に実行します。一般的なパターン (毎時間、毎日、毎週) から選択することも、カスタム cron 式を定義することもできます。
![cron パターンセレクタを使用した [スケジュールに従って実行] オプション](http://docs.aws.amazon.com/ja_jp/solutions/latest/distributed-load-testing-on-aws/images/schedule-run-recurring.png)
**スケジューリングワークフロー**
テストをスケジューリングすると、次のワークフローが発生します。
+ スケジュールパラメータは、Amazon API Gateway を介してソリューションの API に送信されます。
+ API はパラメータを Lambda 関数に渡し、スケジュールされた CloudWatch Events ルールを作成して、指定した日付に実行されるようにします。
+ 1 回限りのテスト (1 回実行) の場合、CloudWatch Events ルールは指定された日に実行し、`api-services` Lambda 関数はテストを実行します。
+ 定期的なテスト (スケジュールに従って実行) の場合、CloudWatch Events ルールは指定された日付にアクティブ化され、`api-services` Lambda 関数は指定された頻度に基づいてすぐに、かつ繰り返し実行される新しいルールを作成します。
**ライブデータ**
テストの実行中にリアルタイムのメトリクスを表示するには、**[ライブデータを含める]** チェックボックスをオンにします。有効にすると、以下をモニタリングできます。
+ 平均応答時間。
+ 仮想ユーザー数。
+ 成功したリクエストカウント。
+ 失敗したリクエストカウント。
ライブデータ機能は、1 秒間隔で集計されたデータをリアルタイムでグラフ表示します。詳細については、「[ライブデータを使用したモニタリング](run-test-scenario.md#monitoring-live-data)」を参照してください。
## ステップ 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 `
+ `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 人以下のユーザーでテストを作成します。
1. テストの実行中に、[CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch/home)を使用して CPU とメモリをモニタリングします。
1. 左側のナビゲーションペインの **[Container Insights]** で、**[パフォーマンスのモニタリング]** を選択します。
1. **[パフォーマンスのモニタリング]** ページで、左側のドロップダウンメニューから **[ECS クラスター]** を選択します。
1. 右側のドロップダウンメニューから、Amazon Elastic Container Service (Amazon ECS) クラスターを選択します。
1. モニタリング中は、CPU とメモリを監視します。CPU が 75% を超えない、またはメモリが 85% を超えない (1 回限りのピークは無視) 場合は、より多くのユーザー数で別のテストを実行できます。
テストがリソースの制限を超えなかった場合は、手順の 1～3 を繰り返します。オプションで、コンテナのリソースを増やして、同時実行ユーザー数を増やすことができます。ただし、これによりコストが高くなります。詳細については、「デベロッパーガイド」を参照してください。
**注記**
正確な結果を得るには、同時ユーザー制限を決定する際に一度に 1 つのテストのみを実行してください。すべてのテストでは同じクラスターを使用し、CloudWatch Container Insights ではクラスターに基づいてパフォーマンスデータを集計します。これにより、両方のテストが CloudWatch Container Insights に同時にレポートされるため、単一テストでのリソース使用率のメトリクスが不正確になります。
エンジンごとのユーザー調整に関する詳細については、BlazeMeter ドキュメントの「[Calibrating a Taurus Test](https://guide.blazemeter.com/hc/en-us/articles/360000864389-Calibrating-a-Taurus-Test-Calibrating-a-Taurus-Test)」を参照してください。
**注記**
このソリューションでは、各リージョンの使用可能な容量情報が表示され、使用可能な制限内でテスト設定を計画するのに役立ちます。
**使用可能なタスクの表**
**[使用可能なタスクの表]** には、選択した各リージョンのリソースの可用性が表示されます。
+ **リージョン** - AWS リージョン名。
+ **タスクあたりの vCPU** - 各タスクに割り当てられた仮想 CPU の数 (デフォルト: 2)。
+ **DLT タスク制限** - アカウントの Fargate 制限に基づいて作成できるタスクの最大数 (デフォルト: 2000)。
+ **使用可能な DLT タスク** - リージョンで現在、使用可能なタスクの数 (デフォルト: 2000)。
タスクごとに使用可能なタスクまたは vCPU の数を増やすには、デベロッパーガイドを参照してください。
**テスト期間**
負荷テストの実行期間を定義します。
**ランプアップ**
ターゲットの同時実行数に達するまでの時間。この期間、負荷は 0 から設定された同時実行レベルまで徐々に増加します。
**ホールド**
ターゲット負荷を維持する期間。この期間中、テストは完全な同時実行で続行されます。
## ステップ 4: 確認して作成する
テストシナリオを作成する前に、すべての設定を確認してください。検証:
+ 全般設定 (名前、説明、スケジュール)。
+ シナリオ設定 (テストタイプ、エンドポイント、またはスクリプト)。
+ トラフィックシェイプ (タスク、ユーザー、期間、リージョン)。
確認後、**[作成]** を選択してテストシナリオを保存します。
**テストシナリオの管理**
テストシナリオを作成したら、次のことができます。
+ **編集** - テスト設定を変更します。一般的ユースケースには以下が含まれます。
+ トラフィックシェイプを調整して、希望するトランザクションレートを実現します。
+ **コピー** - 既存のテストシナリオを複製してバリエーションを作成します。一般的ユースケースには以下が含まれます。
+ エンドポイントの更新またはヘッダー/本文パラメータの追加。
+ テストスクリプトの追加または変更。
+ **削除** - 不要になったテストシナリオを削除します。