View a markdown version of this page

トラブルシューティング - AWS での分散負荷テストソリューション

トラブルシューティング

既知の問題解決には、既知のエラーを軽減するための手順が記載されています。これらの手順で問題が解決しない場合は、「AWS サポートにお問い合わせる」に、このソリューションに関する AWS サポートのケースを開く方法が記載されています。

既知の問題解決

問題: 既存 VPC を使用していて、テストのステータスが Failed で失敗し、次のエラーメッセージが表示されます。

Test might have failed to run.

  • 解決:

指定した VPC にサブネットが存在し、インターネットゲートウェイまたは NAT ゲートウェイのいずれかを使用するインターネットへのルートがあることを確認してください。AWS Fargate は、テストを正常に実行するために、パブリックリポジトリからコンテナイメージを取り込むためのアクセス権が必要です。

問題: テストの実行に時間がかかりすぎている、または、いつまで経っても実行されない

  • 解決:

テストをキャンセルし、AWS Fargate をチェックしてすべてのタスクが停止していることを確認します。停止していない場合は、すべての Fargate タスクを手動で停止します。ご自身のアカウントでオンデマンドの Fargate タスクの制限をチェックして、必要な数のタスクが起動されていることを確認します。また、task-runner Lambda 関数用の CloudWatch のログを確認して、Fargate タスクの起動時の障害を詳しく確認することもできます。実行中の Fargate のコンテナで何が起こっているかの詳細については、CloudWatch の ECS のログを確認してください。

問題: テストが開始しているが未完了であるか、ECS タスクの状態が不明

  • 解決:

ソリューションをデプロイしたアカウントで既存の VPC を指定するオプションを選択した場合は、テスト入力で指定したタスク数を開始するのに十分な空き IP アドレスが、ECS タスクで使用する VPC にあることを確認してください。ECS タスク定義では、インターネットゲートウェイまたはインターネットへのルートを必要とする ECR イメージを使用して、ECS サービスが aws-solutions/distributed-load-testing-on-aws-load-tester からソリューション ECR イメージをダウンロードしてタスクをプロビジョニングできるようにします。VPC 内のすべてのサブネットがプライベートであるためにインターネットへのルートを指定できない場合は、ECR プルスルーキャッシュを使用してアカウントで ECR イメージをホストできます。新しい ECR イメージ URI でタスク定義を更新し、新しいリビジョンを作成します。タスク定義が更新されたら、DynamoDB テーブルのソリューション設定を更新して新しいリビジョンを使用する必要があります。DynamoDB テーブル名は、CloudFormation の [スタック出力] タブのキー ScenariosTable で確認できます。項目の属性 taskDefinition をキー testId と値 region-[SOLUTION-DEPLOYED-REGION] で更新します。

問題: テストで使用するエンドポイントはプライベートである必要があり、インターネットゲートウェイ経由では利用できない

  • 解決:

インターネットゲートウェイ経由でアクセスできないプライベート API エンドポイントをテストする場合は、以下のアプローチを検討してください。

  1. ネットワーク設定: ECS タスクで使用するサブネットルートテーブルが、テスト対象のプライベートエンドポイントの IP アドレス範囲へのルートで更新されていることを確認します。これにより、テストトラフィックは VPC 内のプライベートエンドポイントに到達できます。

  2. DNS 解決: カスタムドメインの場合は、プライベートエンドポイントのドメイン名を解決するように VPC の DNS 設定を構成します。詳細な手順については、VPC DNS に関するドキュメントを参照してください。

  3. VPC エンドポイント: AWS サービスをテストする場合は、VPC エンドポイント (AWS PrivateLink) を使用してプライベート接続を確立することを検討してください。例えば、プライベート API Gateway をテストするには、API Gateway の VPC エンドポイントを作成できます。プライベート API Gateway に関するドキュメントを参照してください。

  4. VPC ピアリング: プライベートエンドポイントが別の VPC にある場合は、ソリューションのデプロイ先の VPC とプライベートエンドポイントがある VPC の間に VPC ピアリングを確立します。両方の VPC に適切なルートテーブルを設定します。VPC ピアリングに関するドキュメントを参照してください。

  5. Transit Gateway: より複雑なネットワークシナリオで複数の VPC が関わる場合は、ソリューションの VPC とプライベートエンドポイントがある VPC 間のトラフィックをルーティングするために AWS Transit Gateway の使用を検討してください。Transit Gateway に関するドキュメントを参照してください。

  6. セキュリティグループ: ECS タスクに関連付けられたセキュリティグループがプライベートエンドポイントへのアウトバウンドトラフィックを許可し、プライベートエンドポイントのセキュリティグループが ECS タスクからのインバウンドトラフィックを許可していることを確認します。

内部 Application Load Balancer または EC2 インスタンスをテストする場合は、VPC CIDR 範囲が重複せず、必要なルートがルートテーブルに設定されていることを確認します。

問題: テストは完了しているが、結果を UI で利用できない

  • 解決:

テストは完了したが、結果を UI で利用できない場合は、テストを実行した ECS タスクから S3 バケットの結果ファイルを引き続き利用できます。これは、ソリューションの既知の制限です。現在のアーキテクチャでは、ソリューションは結果を解析する Lambda 関数を使用して複数の ECS タスクの結果を要約し、DynamoDB テーブルに 1 つの項目として保存します。DynamoDB テーブルの最大項目サイズは 400 KB に制限されています。テストスクリプトの複雑さ、同時実行数、使用しているタスクの数によっては、この制限に達します。エラーは、テストの失敗ではなく、結果を要約して CRUD オペレーションで DynamoDB テーブルに保存するプロセスの失敗を示しています。結果は、テストシナリオの S3 バケットで引き続き利用できます。

ALB + ECS Fargate デプロイの問題

問題: ACM 証明書の検証が「検証保留中」ステータスのままになっている

  • 解決:

DNS 検証を使用してパブリック ACM 証明書をリクエストした場合は、ACM が提供する CNAME レコードを DNS 設定に追加する必要があります。ACM コンソールに移動し、証明書の詳細を展開し、DNS 検証レコードをドメインの DNS プロバイダーに追加します。E メール検証を使用した場合は、ドメインに関連付けられた E メールアドレスに AWS からの検証 E メールが届いているかを確認します。詳細については、「AWS Certificate Manager ユーザーガイド」の「DNS での検証」を参照してください。

問題: デプロイ後にウェブコンソールが「502 Bad Gateway」または「503 Service Temporarily Unavailable」エラーを返す

  • 解決:

EC2 コンソールで、ALB ターゲットグループのヘルスチェックを確認します。ECS Fargate タスクに異常が表示されている場合は、ECS コンソールでタスクが実行されていることを確認し、CloudWatch のタスクログでエラーがないか確認します。ECS タスクにアタッチされたセキュリティグループが ALB セキュリティグループからのインバウンドトラフィックを許可していることを確認します。

問題: DNS は設定されているが、カスタムドメインがウェブコンソールに解決されない

  • 解決:

CNAME レコードが DNS プロバイダーで正しく設定され、カスタムドメイン (console.example.com など) が CloudFormation の出力の ALB DNS 名にマッピングされていることを確認します。DNS プロバイダーと TTL の設定によっては、DNS の伝播に最大 48 時間かかる場合があります。DNS レコードは、dig console.example.com CNAME または nslookup console.example.com を使用して検証できます。

問題: デプロイ後にウェブコンソールが「403 Forbidden」エラーを返す

  • 解決:

ALB の前にデプロイされている AWS WAF ウェブ ACL が、正当なリクエストをブロックしている可能性があります。AWS WAF コンソールを開き、ALB に関連付けられたウェブ ACL を選択し、[サンプルリクエスト] タブを確認して、トラフィックをブロックしているルールを特定します。WAF ルールを変更して、ブロックされたリクエストを許可できます。例えば、マネージドルールグループが誤検出を生成している場合、[ブロック] の代わりに特定のルールアクションを [カウント] に設定して、トラフィックを記録しながらトラフィックを許可できます。詳細については、「AWS WAF デベロッパーガイド」の「AWS WAF 保護のテストとチューニング」を参照してください。

ヘッドレス (独自のウェブサーバーを使用する) デプロイの問題

問題: API への接続時にウェブコンソールに CORS エラーが表示される

  • 解決:

Cross-Origin Resource Sharing (CORS) エラーは、ドメインでホストされているウェブコンソールが、ソリューションの API Gateway エンドポイントを呼び出そうとしたときに発生します。API Gateway エンドポイントには HTTPS が必要なため、ウェブサーバーが HTTPS 経由でコンソールを提供していることを確認します。ウェブサーバーのオリジンドメインが、API Gateway CORS 設定で設定された許可されたオリジンと一致していることを確認します。カスタムドメインを使用している場合は、API Gateway CORS 設定を更新して、そのドメインを含める必要がある場合があります。

問題: ウェブコンソールはロードされるが、認証が失敗するか、正しくリダイレクトされない

  • 解決:

ウェブコンソールアセットには、Cognito ユーザープール設定と API エンドポイント URL を含む設定ファイルが含まれています。抽出中にこの設定ファイルが変更されていないことを確認します。Cognito はコールバック URL に HTTPS を必要とするため、ウェブサーバーが HTTPS 経由でコンソールを提供していることを確認します。Cognito アプリケーションクライアントのコールバック URL にウェブサーバーのドメインが含まれていることを確認します。