View a markdown version of this page

設計上の考慮事項 - AWS での分散負荷テストソリューション
サポートされているアプリケーションテストタイプテストのスケジューリング同時テストユーザー管理ID プロバイダーフェデレーションリージョンデプロイ

設計上の考慮事項

このセクションでは、サポートされているアプリケーション、テストタイプ、スケジュールオプション、デプロイに関する考慮事項など、AWS での分散負荷テストソリューションの設計に関する重要な決定事項と設定オプションについて説明します。

サポートされているアプリケーション

このソリューションは、AWS アカウントからアプリケーションへのネットワーク接続があれば、クラウドベースのアプリケーションとオンプレミスのアプリケーションのテストをサポートします。ソリューションでは、HTTP または HTTPS プロトコルを使用する API をサポートしています。

テストタイプ

AWS での分散負荷テストは、シンプルな HTTP エンドポイントテスト、JMeter、K6、Locust の複数のテストタイプをサポートしています。

注記

このソリューションは、JMeter、K6、Locust をサードパーティーコンポーネントとして変更を加えることなく配布します。セキュリティ上の考慮事項、パッチ適用オプション、ライセンス情報については、「サードパーティーのテストフレームワーク」を参照してください。

シンプルな HTTP エンドポイントテスト

ウェブコンソールは、カスタムスクリプトを記述せずに HTTP または HTTPS エンドポイントをテストできる HTTP エンドポイント設定インターフェイスを提供しています。エンドポイント URL を定義し、ドロップダウンメニューから HTTP メソッド (GET、POST、PUT、DELETE など) を選択し、オプションでカスタムリクエストヘッダーと本文ペイロードを追加します。この設定により、アプリケーションに必要なカスタム認可トークン、コンテンツタイプ、またはその他の HTTP ヘッダーやリクエスト本文を使用して API をテストできます。

HTTP エンドポイントを設定すると、ソリューションは設定をテストプランに変換し、Taurus フレームワークを介してバンドルされた Apache JMeter バイナリによって実行されます。シンプルな HTTP エンドポイントテストはテストアーカイブを受け入れないため、バンドルされた JMeter バイナリまたはプラグインを上書きすることはできません。パッチが適用された JMeter で HTTP エンドポイントテストを実行する必要がある場合は、代わりに JMeter テストタイプを使用します。セキュリティ上の考慮事項については、「Apache JMeter」を参照してください。

JMeter テスト

ウェブコンソールを使用してテストシナリオを作成する場合、JMeter のテストスクリプトをアップロードできます。このソリューションは、シナリオ S3 バケットにスクリプトをアップロードします。Amazon ECS タスクを実行すると、S3 から JMeter スクリプトをダウンロードしてテストを実行します。

重要

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

JMeter 入力ファイルがある場合は、JMeter スクリプトと一緒に入力ファイルを zip 圧縮できます。テストシナリオを作成するときに、zip ファイルを選択できます。

プラグインを含めると、バンドルされた zip ファイルの /plugins サブディレクトリ内のすべての .jar ファイルが JMeter 拡張ディレクトリにコピーされ、負荷テストに利用できるようになります。

注記

JMeter 入力ファイルを JMeter スクリプトファイルに含める場合は、JMeter スクリプトファイルに入力ファイルの相対パスを含める必要があります。さらに、入力ファイルは必ず相対パスである必要があります。例えば、JMeter の入力ファイルとスクリプトファイルが /home/user ディレクトリにあり、JMeter スクリプトファイル内の入力ファイルを参照する場合、入力ファイルのパスは ./INPUT_FILES である必要があります。代わりに /home/user/INPUT_FILES を使用すると、入力ファイルを見つけることができないため、テストは失敗します。

JMeter プラグインを含める場合は、.jar ファイルを zip ファイルのルート内の /plugins という名前のサブディレクトリにバンドルする必要があります。zip ファイルのルートを基準にして、jar ファイルへのパスは、./plugins/BUNDLED_PLUGIN.jar でなければなりません。

JMeter スクリプトの使用方法の詳細については、「JMeter User's Manual」を参照してください。

K6 テスト

このソリューションは、K6 フレームワークベースのテストをサポートしています。アーカイブファイルに必要な入力ファイルと共に K6 テストファイルをアップロードできます。新しい K6 テストを作成すると、ウェブコンソールにライセンス確認メッセージが表示されます。ライセンスとセキュリティの詳細については、「Grafana K6」を参照してください。

重要

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

Locust テスト

このソリューションは、Locust フレームワークベースのテストをサポートしています。アーカイブファイルに必要な入力ファイルと共に Locust テストファイルをアップロードできます。

重要

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

テストのスケジューリング

このソリューションには、負荷テストの実行のために 3 つの実行タイミングオプションがあります。

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

  • 1 回実行 - 将来の特定の日時にテストを実行します

  • スケジュールに従って実行 – cron 式を使用して定期的なテストを作成し、スケジュールを定義します

[1 回実行] を選択する場合、実行時間を 24 時間形式で指定し、負荷テストの実行を開始する実行日を指定します。

[スケジュールに従って実行] を選択する場合、cron 式を手動で入力するか、一般的な cron パターン (毎時間、特定の時刻に毎日、平日、毎月など) から選択できます。cron 式は、分、時間、日、月、曜日、年のフィールドを含むきめ細かなスケジュール形式を使用します。また、スケジュールされたテストが実行を停止するタイミングを定義する有効期限も指定する必要があります。スケジューリングの仕組みの詳細については、このガイドの「テストスケジューリングワークフロー」セクションを参照してください。

注記

  • テスト期間: スケジューリング時には、テストの合計期間を考慮します。例えば、ランプアップ時間が 10 分、保留時間が 40 分のテストは完了までに約 80 分かかります。

  • 最小間隔: スケジュールされたテストの間隔が想定されるテスト期間よりも長いことを確認します。例えば、テストに約 80 分かかる場合は、実行頻度を 3 時間は空けるようにスケジュールします。

  • 時間単位の制限: 想定されるテスト時間が 1 時間未満であっても、1 時間差でテストをスケジュールすることはできません。

同時テスト

このソリューションは各テストの Amazon CloudWatch ダッシュボードを作成し、Amazon ECS クラスターで実行されるすべてのタスクの出力がリアルタイムで組み合わされて表示されます。CloudWatch ダッシュボードには、平均応答時間、同時ユーザーの数、成功したリクエストの数、失敗したリクエストの数が表示されます。ソリューションは各メトリクスを秒単位で集計し、ダッシュボードを 1 分毎に更新します。

ユーザー管理

初期設定時に、Amazon Cognito がソリューションのウェブコンソールへのアクセスを許可するために使用するユーザー名と E メールアドレスを指定します。コンソールには、ユーザー管理機能はありません。ユーザーを追加するには、Amazon Cognito コンソールを使用する必要があります。詳細については、「Amazon Cognito デベロッパーガイド」の「ユーザープール内のユーザーを管理する」を参照してください。

Amazon Cognito ユーザープールへの既存のユーザーの移行については、AWS ブログ「Approaches for migrating users to Amazon Cognito user pools」を参照してください。

ID プロバイダーフェデレーション

このソリューションの Amazon Cognito ユーザープールは、SAML 2.0 または OpenID Connect (OIDC) プロトコルを使用した外部 ID プロバイダー (IdP)とのフェデレーションをサポートしています。フェデレーションを使用すると、ユーザーは Cognito ネイティブの認証情報の代わりに既存の企業または組織の認証情報を使用してウェブコンソールにサインインできます。フェデレーションユーザーは、Cognito ユーザープールで直接作成されたユーザーと同じアクセス許可を受け取ります。

このソリューションでは、Cognito ユーザープール、ドメイン、アプリケーションクライアント、ホストされた UI が既にデプロイされています。フェデレーションを有効にするには、ID プロバイダーを登録し、既存のアプリケーションクライアントで有効にするだけで済みます。

オプションの MCP サーバー統合をデプロイする場合、フェデレーションユーザーは同じ Cognito ユーザープール認証情報を使用して MCP サーバーにアクセスすることもできます。

前提条件

フェデレーションを設定する前に、以下が必要です。

  • SAML 2.0 または OIDC をサポートする外部 ID プロバイダー

  • 外部 IdP を設定するための管理者アクセス (リダイレクト URI または ACS URL を設定するため)

  • ソリューションの Cognito ユーザープール ID (CloudFormation スタックリソースまたは Amazon Cognito コンソールで確認できます)

  • ソリューションの Cognito ドメインプレフィックス (CloudFormation スタック出力または Cognito コンソールの [アプリの統合] > [ドメイン] で確認できます)

ステップ 1: アイデンティティプロバイダーを設定する

ソリューションの Cognito ユーザープールと通信できるように、外部 ID プロバイダーに次の値を設定します。

SAML ID プロバイダーの場合。

  • SP エンティティ ID: urn:amazon:cognito:sp:_<UserPoolId>_

  • ACS URL: \https://<cognito-domain>.auth.<region>.amazoncognito.com/saml2/idpresponse

OIDC ID プロバイダーの場合。

  • リダイレクト URI: \https://<cognito-domain>.auth.<region>.amazoncognito.com/oauth2/idpresponse

IdP に必要な要件の詳細については、「Amazon Cognito デベロッパーガイド」の「ユーザープールへの SAML ID プロバイダーの追加」または「ユーザープールへの OIDC ID プロバイダーの追加」を参照してください。

ステップ 2: Cognito に ID プロバイダーを登録する

Amazon Cognito コンソールを使用して、ソリューションの既存の Cognito ユーザープールに外部 ID プロバイダーを追加します。

詳しい手順については、「Amazon Cognito デベロッパーガイド」の「サードパーティー経由のユーザープールへのサインインの追加」を参照してください。

ステップ 3: 属性マッピングを設定する

ID プロバイダーのクレームと Cognito ユーザープール属性間の属性マッピングを設定します。少なくとも、外部プロバイダーからのユーザーの E メールクレームを Cognito email 属性にマッピングします。ID プロバイダーが name や nickname を提供している場合は、それらをマッピングすることも検討してください。

手順については、「Amazon Cognito デベロッパーガイド」の「ユーザープールの ID プロバイダー属性マッピングを指定する」を参照してください。

ステップ 4: アプリケーションクライアントで ID プロバイダーを有効にする

Amazon Cognito コンソールで、ソリューションによって作成されたアプリケーションクライアントを見つけ、ホストされた UI 設定で新しい ID プロバイダーを有効にします。

詳細については、「Amazon Cognito デベロッパーガイド」の「ユーザープールのアプリケーションクライアントの設定」を参照してください。

注記

このソリューションでは、アプリケーションクライアントのコールバック URL とサインアウト URL、OAuth スコープ、ホストされた UI ドメインが既に設定されています。これらの設定を変更する必要はありません。既存のアプリケーションクライアントで ID プロバイダーを有効にするだけで済みます。

重要

このソリューションは、CloudFormation アプリケーションクライアント設定から SupportedIdentityProviders プロパティを意図的に省略します。これにより、CloudFormation のドリフト検出をトリガーすることなく、デプロイ後に ID プロバイダーを追加できます。このプロパティがテンプレートで設定されている場合、コンソールまたは CLI による手動 IdP の変更は、次のスタック更新時に上書きされ、アプリケーションクライアントはテンプレートにリストされているプロバイダーのみを使用する状態に戻ります。

このプロパティは省略されるため、CloudFormation はアプリケーションクライアントで有効になっている ID プロバイダーを追跡または管理しません。フェデレーションを設定した後は、アプリケーションクライアントで SupportedIdentityProviders のコンテンツを管理する責任はお客様にあります。不正な変更をモニタリングするには、AWS CloudTrail ログ記録を有効にし、ソリューションの Cognito ユーザープールをターゲットとする CreateIdentityProvider および UpdateUserPoolClient API コールに対してアラートする Amazon EventBridge ルールを作成します。

注記

  • 外部 ID プロバイダーを追加しても、既存の Cognito ネイティブユーザーが現在の認証情報でサインインする機能は削除されません。

  • フェデレーションユーザーには、Cognito ユーザープールと同様に、リージョンの可用性制約が適用されます。詳細については、「リージョンデプロイ」を参照してください。

  • 組織にロールアウトする前に、少数のユーザーグループでフェデレーションサインインをテストします。

デフォルトの Cognito ユーザーの無効化または削除

フェデレーションの設定後、スタックのデプロイ中に作成されたデフォルトユーザーを無効化または削除できます。これはオプションです。デフォルトのユーザーは引き続きフェデレーションサインインと連携します。

ユーザーを無効にするには、Amazon Cognito コンソールでソリューションの Cognito ユーザープールに移動し、[ユーザー] タブを選択し、ユーザーを選択して、[ユーザーアクセスを無効化] を選択します。ユーザーを削除するには、まずユーザーを無効にしてから、[ユーザーを削除] を選択する必要があります。ユーザーを無効にすると、トークンが取り消され、アカウントは保持されたままサインインできなくなります。削除すると、アカウントは完全に削除されます。

詳細については、「Amazon Cognito デベロッパーガイド」の「ユーザーアカウントの管理と検索」を参照してください。

リージョンデプロイ

このソリューションでは、特定の AWS リージョンでのみ利用可能な Amazon Cognito を使用します。そのため、このソリューションを Amazon Cognito が利用可能なリージョンにデプロイする必要があります。リージョン別の現在のサービス提供状況については、AWS リージョン別のサービスのリストを参照してください。