View a markdown version of this page

Visão geral da arquitetura - Teste de carga distribuído na AWS
Diagrama de arquitetura

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Visão geral da arquitetura

Diagrama de arquitetura

A implantação dessa solução com os parâmetros padrão implanta os seguintes componentes em sua conta da AWS.

Teste de carga distribuído na arquitetura da AWS

Teste de carga distribuído na arquitetura da AWS
nota

Os CloudFormation recursos da AWS são criados a partir de construções do AWS Cloud Development Kit (AWS CDK).

O fluxo de processo de alto nível para os componentes da solução implantados com o CloudFormation modelo da AWS é o seguinte:

  1. (CloudFront + Opção de implantação de hospedagem S3) O usuário do console acessa o console web por meio da Amazon CloudFront, que serve o aplicativo AWS Amplify hospedado em um bucket do Amazon Simple Storage Service (Amazon S3).

  2. (Opção de implantação de hospedagem ALB + ECS Fargate) O usuário do console acessa o console web por meio de um Application Load Balancer, que direciona o tráfego para o aplicativo AWS Amplify executado no Amazon Elastic Container Service (Amazon ECS) no AWS Fargate dentro de uma AmazonVirtual Private Cloud (Amazon VPC).

  3. (Opção de implantação sem cabeçalho) Nenhum front-end público é implantado. A solução fornece o console web como um ZIP que pode ser baixado em um bucket privado do Amazon S3. O usuário do console pode acessar o console a partir de um servidor web auto-hospedado.

  4. Durante a configuração inicial, a solução cria um usuário administrador padrão no grupo de usuários do Amazon Cognito e envia um e-mail de criação de conta para o endereço de e-mail fornecido por você. O grupo de usuários do Cognito gerencia o acesso do usuário ao console web, à API REST, à CLI e ao servidor MCP.

  5. O Amazon API Gateway invoca microsserviços do AWS Lambda que fornecem a lógica de negócios para gerenciar dados de teste e executar os testes.

  6. Os microsserviços interagem com o Amazon S3, o Amazon DynamoDB e a EventBridgeAmazon para armazenar detalhes do cenário de teste e gerenciar cronogramas de testes. Quando você agenda um teste para ser executado em um horário futuro ou em um intervalo recorrente, os microsserviços criam uma EventBridge programação do Scheduler que invoca o microsserviço no horário agendado.

  7. Para executar um teste, os microsserviços invocam o AWS Step Functions, que orquestra a execução do teste.

  8. EventBridge as regras direcionam eventos de falha de tarefas e Step Functions do Amazon ECS para uma função Lambda do manipulador de falhas.

  9. Step Functions lança tarefas do Amazon Elastic Container Service (Amazon ECS) no AWS Fargate em cada região da AWS que você selecionou.

  10. Cada tarefa é executada em uma Amazon Virtual Private Cloud (Amazon VPC) na região selecionada.

  11. O contêiner de teste de carga usa uma imagem base do Amazon Linux 2023 com a estrutura de automação de testes Taurus instalada. O Taurus executa seu teste JMeter, K6, Locust ou Single HTTP Endpoint. Para obter detalhes sobre como cada estrutura de teste é provisionada, consulte Provisionamento da estrutura de teste. A opção ALB + ECS usará o contêiner de hospedagem da web. As imagens do contêiner são hospedadas pela AWS em um repositório público do Amazon Elastic Container Registry (Amazon ECR).

  12. Cada tarefa do Fargate grava seus resultados de teste por região no Amazon S3 e emite registros para a Amazon. CloudWatch Quando todas as regiões são concluídas, os microsserviços agregam os resultados no DynamoDB.

  13. Se você ativar a opção de dados ativos, uma função Lambda receberá CloudWatch registros das tarefas do Fargate durante o teste.

  14. A função Lambda publica os registros em um tópico no AWS IoT Core na região em que a pilha principal está implantada. O console da web se inscreve no tópico para exibir métricas em tempo real durante a execução do teste.

  15. (Acesso opcional à CLI) Os usuários podem instalar a interface de linha de comando (CLI) DLT localmente para interagir com a solução a partir do terminal. A CLI é autenticada por meio do Cognito e chama a API REST diretamente, permitindo automação e integração com scripts. CI/CD

    nota

    As etapas a seguir descrevem a integração opcional do MCP Server para análise de teste de AI-assisted carga. Esse componente só será implantado se você selecionar a opção MCP Server durante a implantação da solução.

  16. Um cliente MCP (ferramenta de desenvolvimento de IA) se conecta ao endpoint Amazon Bedrock AgentCore Gateway para acessar os dados da solução Distributed Load Testing por meio do Model Context Protocol. AgentCore O Gateway valida o token de autenticação Cognito do usuário para garantir o acesso autorizado ao Servidor MCP.

  17. Após a autenticação bem-sucedida, o AgentCore Gateway encaminha a solicitação da ferramenta MCP para a função Lambda do DLT MCP Server. A função Lambda retorna os dados estruturados ao AgentCore Gateway, que os envia de volta ao cliente MCP para AI-assisted análise e insights.

  18. A função Lambda processa a solicitação e consulta os recursos apropriados da AWS (tabelas do DynamoDB, buckets do S3 ou CloudWatch logs) para recuperar os dados de teste de carga solicitados.