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á.
# Detalhes de arquitetura
Esta seção descreve os componentes e os [serviços da AWS que compõem essa solução](#aws-services-in-this-solution) e os detalhes da arquitetura sobre como esses componentes funcionam juntos.
A solução Distributed Load Testing on AWS consiste em três componentes de alto nível: um [front-end](front-end.md), um [back-end](back-end.md) e um servidor [MCP](MCP-Server.md) opcional.
# Front-end
O front-end fornece as interfaces para interagir com a solução e inclui:
+ Uma API de teste de carga para acesso programático
+ Um console web para criar, programar e executar testes de desempenho
+ Um servidor MCP opcional para análise assistida por IA de resultados e erros de testes
## API de teste de carga
O teste de carga distribuído na AWS configura o Amazon API Gateway para hospedar a RESTful API da solução. Os usuários podem interagir com o sistema de teste de carga de forma segura por meio do console web incluído, da RESTful API e do servidor MCP opcional. A API atua como uma “porta de entrada” para acesso aos dados de teste armazenados no Amazon DynamoDB. Você também pode usar o APIs para acessar qualquer funcionalidade estendida incorporada à solução.
Essa solução aproveita os recursos de autenticação de usuários dos grupos de usuários do Amazon Cognito. Depois de autenticar um usuário com sucesso, o Amazon Cognito emite um token web JSON que é usado para permitir que o console envie solicitações para a solução (endpoints APIs do Amazon API Gateway). As solicitações HTTPS são enviadas pelo console para o APIs com o cabeçalho de autorização que inclui o token.
Com base na solicitação, o API Gateway invoca a função apropriada do AWS Lambda para realizar as tarefas necessárias nos dados armazenados nas tabelas do DynamoDB, armazenar cenários de teste como objetos JSON no Amazon S3, recuperar imagens de métricas da CloudWatch Amazon e enviar cenários de teste para a máquina de estado do AWS Step Functions.
Para obter mais informações sobre a API da solução, consulte a seção [API de teste de carga distribuída](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/distributed-load-testing-api.html) deste guia.
## Console web
Essa solução inclui um console web que você pode usar para configurar e executar testes, monitorar testes em execução e visualizar resultados detalhados dos testes. O console é um aplicativo ReactJS criado com o [Cloudscape](https://cloudscape.design/), um sistema de design de código aberto para criar aplicativos web intuitivos. O console está hospedado no Amazon S3 e acessado pela Amazon. CloudFront O aplicativo utiliza o AWS Amplify para se integrar ao Amazon Cognito para autenticar usuários. O console web também contém uma opção para visualizar dados ao vivo para um teste em execução, no qual ele se inscreve no tópico correspondente no AWS IoT Core.
O URL do console web é o nome do domínio de CloudFront distribuição que pode ser encontrado nas CloudFormation saídas como **Console**. Depois de iniciar o CloudFormation modelo, você também receberá um e-mail contendo o URL do console web e a senha de uso único para fazer login nele.
## Servidor MCP (opcional)
O servidor opcional Model Context Protocol (MCP) fornece uma interface adicional para ferramentas de desenvolvimento de IA acessarem e analisarem dados de teste de carga por meio de interações de linguagem natural. Esse componente só será implantado se você selecionar a opção MCP Server durante a implantação da solução.
O MCP Server permite que agentes de IA consultem resultados de testes, analisem métricas de desempenho e obtenham insights sobre seus dados de teste de carga usando ferramentas como Amazon Q, Claude e outros assistentes de IA compatíveis com MCP. Para obter informações detalhadas sobre a arquitetura e a configuração do MCP Server, consulte [MCP Server](MCP-Server.md) nesta seção.
# Back-end
O back-end consiste em um pipeline de imagem de contêiner e um mecanismo de teste de carga que você usa para gerar carga para os testes. Você interage com o back-end por meio do front-end. Além disso, as tarefas do Amazon ECS no AWS Fargate lançadas para cada teste são marcadas com um identificador de teste (ID) exclusivo. Essas etiquetas de identificação de teste podem ser usadas para ajudá-lo a monitorar os custos dessa solução. Para obter informações adicionais, consulte as [tags de alocação de custos definidas pelo usuário no Guia](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html) do usuário do *AWS Billing and Cost Management*.
## Pipeline de imagens de containers
Essa solução usa uma imagem de contêiner criada com o [Amazon Linux 2023](https://aws.amazon.com/linux/amazon-linux-2023/) como imagem base com a estrutura de teste de carga [Taurus](https://gettaurus.org/) instalada. O Taurus é uma estrutura de automação de testes de código aberto que suporta K6 JMeter, Locust e outras ferramentas de teste. A AWS hospeda essa imagem em um repositório público do Amazon Elastic Container Registry (Amazon ECR). A solução usa essa imagem para executar tarefas no Amazon ECS no cluster AWS Fargate.
Para obter mais informações, consulte a seção [Personalização da imagem do contêiner](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/container-image.html) deste guia.
## Testando a infraestrutura
Além do CloudFormation modelo principal, a solução fornece um modelo regional para lançar os recursos necessários para a execução de testes em várias regiões. A solução armazena esse modelo no Amazon S3 e fornece um link para ele no console web. Cada pilha regional inclui uma VPC, um cluster AWS Fargate e uma função Lambda para processar dados ativos.
Para obter mais informações sobre como implantar a infraestrutura de teste em regiões adicionais, consulte a seção [Implantação multirregional](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/multi-region-deployment.html) deste guia.
## Motor de teste de carga
A solução Distributed Load Testing usa o Amazon Elastic Container Service (Amazon ECS) e o AWS Fargate para simular milhares de usuários simultâneos em várias regiões, gerando solicitações HTTP a uma taxa sustentada.
Você define os parâmetros de teste usando o console web incluído. A solução usa esses parâmetros para gerar um cenário de teste JSON e armazená-lo no Amazon S3. Para obter mais informações sobre scripts de teste e parâmetros de [teste, consulte Tipos de teste](design-considerations.md#test-types) nesta seção.
Uma máquina de estado do AWS Step Functions executa e monitora tarefas do Amazon ECS em um cluster do AWS Fargate. A máquina de estado do AWS Step Functions inclui uma função AWS Lambda, uma função AWS Lambda, uma função AWS Lambda, uma função task-status-checker AWS Lambda executora de tarefas, uma função AWS Lambda canceladora de tarefas e uma função AWS Lambda de análise de resultados. Para obter mais informações sobre o fluxo de trabalho, consulte a seção [Testar fluxo](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/test-workflow.html) de trabalho deste guia. Para obter mais informações sobre os resultados do [teste, consulte a seção Resultados](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/test-results.html) do teste deste guia. Para obter mais informações sobre o fluxo de trabalho de cancelamento de teste, consulte a seção [Fluxo de trabalho de cancelamento de teste](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/test-cancel-workflow.html) deste guia.
Se você selecionar dados ativos, a solução iniciará uma função real-time-data-publisher Lambda em cada região pelos CloudWatch registros que correspondem às tarefas do Fargate nessa região. Em seguida, a solução processa e publica os dados em um tópico no AWS IoT Core na região em que você lançou a pilha principal. Para obter mais informações, consulte a seção [Dados ativos](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/live-data.html) deste guia.
# Servidor MCP
A integração opcional do servidor Model Context Protocol (MCP) permite que os agentes de IA acessem e analisem programaticamente seus dados de teste de carga por meio de interações de linguagem natural. Esse componente só será implantado se você selecionar a opção MCP Server durante a implantação da solução.
O MCP Server atua como uma ponte entre as ferramentas de desenvolvimento de IA e sua implantação de DLT, fornecendo uma interface padronizada para análise inteligente dos resultados dos testes de desempenho. A arquitetura integra vários serviços da AWS para criar uma interface segura e escalável para interações com agentes de IA:
## AWS AgentCore Gateway
O AWS AgentCore Gateway é um serviço totalmente gerenciado que fornece hospedagem padronizada e gerenciamento de protocolos para servidores MCP. Nessa solução, o AgentCore Gateway serve como o endpoint público ao qual os agentes de IA se conectam ao solicitar acesso aos seus dados de teste de carga.
O serviço lida com toda a comunicação do protocolo MCP, incluindo descoberta de ferramentas, validação do token de autenticação e roteamento de solicitações. AgentCore O Gateway opera como um serviço multilocatário com proteções de segurança integradas contra ameaças comuns a endpoints públicos, ao mesmo tempo em que valida assinaturas e declarações de tokens do Cognito para cada solicitação.
## Servidor DLT MCP Lambda
A função Lambda do DLT MCP Server é um componente personalizado sem servidor que processa solicitações MCP de agentes de IA e as traduz em consultas em seus recursos de DLT.
Essa função do Lambda atua como a camada de inteligência da integração MCP, recuperando resultados de testes de tabelas do DynamoDB, acessando artefatos de desempenho armazenados em buckets do S3 e consultando registros para obter informações detalhadas de execução. CloudWatch A função Lambda implementa padrões de acesso somente para leitura e transforma dados brutos de DLT em formatos estruturados e amigáveis à IA que os agentes podem interpretar e analisar com facilidade.
## Integração de autenticação
O sistema de autenticação aproveita sua infraestrutura existente de pool de usuários do Cognito para manter controles de acesso consistentes no console web e nas interfaces do MCP Server.
Essa integração usa autenticação baseada em token OAuth 2.0. Os usuários se autenticam uma vez por meio do processo de login do Cognito e recebem tokens que funcionam tanto para interações de interface de usuário quanto para acesso ao MCP Server. O sistema mantém os mesmos limites de permissão e controles de acesso da interface da web, garantindo que os usuários só possam acessar, por meio de agentes de IA, os mesmos dados de teste de carga que podem acessar pelo console.
## Serviços da AWS nesta solução
Os seguintes serviços da AWS estão incluídos nessa solução:
| Serviço da AWS | Description |
| --- | --- |
| [Amazon API Gateway](https://aws.amazon.com/api-gateway/) | **Principal.** Hospeda endpoints da API REST na solução. |
| [AWS CloudFormation](https://aws.amazon.com/cloudformation/) | **Principal.** Gerencia implantações para a infraestrutura da solução. |
| [Amazon CloudFront](https://aws.amazon.com/cloudfront/) | **Principal.** Oferece o conteúdo da web hospedado no Amazon S3. |
| [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) | **Principal.** Armazena os registros e as métricas da solução. |
| [Amazon Cognito](https://aws.amazon.com/cognito/) | **Principal.** Lida com o gerenciamento e a autenticação de usuários para a API. |
| [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) | **Principal.** Armazena informações de implantação e detalhes e resultados do cenário de testes. |
| [Amazon Elastic Container Service](https://aws.amazon.com/ecs/) | **Principal.** Implanta e gerencia tarefas independentes do Amazon ECS em contêineres do AWS Fargate. |
| [AWS Fargate](https://aws.amazon.com/fargate/) | **Principal.** Hospeda os contêineres Amazon ECS da solução |
| [AWS Identity and Access Management](https://aws.amazon.com/iam/) | **Principal.** Lida com o gerenciamento de funções e permissões do usuário. |
| [AWS Lambda](https://aws.amazon.com/lambda/) | **Principal.** Fornece lógica para APIs implementação, análise de resultados de testes e lançamento de workers/leader tarefas. |
| [AWS Step Functions](https://aws.amazon.com/step-functions/) | **Principal.** Orquestra o provisionamento de contêineres do Amazon ECS em tarefas do AWS Fargate nas regiões especificadas |
| [AWS Amplify](https://aws.amazon.com/amplify/) | **Suporte.** Fornece um console web desenvolvido pelo [AWS Amplify](https://aws.amazon.com/amplify). |
| [ CloudWatch Eventos da Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) | **Suporte.** Agenda os testes para que comecem automaticamente em uma data especificada ou em datas recorrentes. |
| [Amazon Elastic Container Registry](https://aws.amazon.com/ecr/) | **Suporte.** Hospeda a imagem do contêiner em um repositório ECR público. |
| [AWS IoT Core](https://aws.amazon.com/iot-core/) | **Suporte.** Permite a visualização de dados ao vivo para um teste em execução ao se inscrever no tópico correspondente no AWS IoT Core. |
| [AWS Systems Manager](https://aws.amazon.com/systems-manager/) | **Suporte.** Fornece monitoramento de recursos em nível de aplicativo e visualização de operações de recursos e dados de custos. |
| [Amazon S3](https://aws.amazon.com/s3/) | **Suporte.** Hospeda o conteúdo estático da web, registros, métricas e dados de testes. |
| [Amazon Virtual Private Cloud](https://aws.amazon.com/vpc/) | **Suporte.** Contém os contêineres Amazon ECS da solução em execução no AWS Fargate. |
| [Amazon Bedrock AgentCore](https://aws.amazon.com/bedrock/agentcore/) | **Suporte, opcional.** Hospeda o servidor opcional Remote Model Context Protocol (MCP) da solução para integração do agente de IA com a API. |
# Como funciona o teste de carga distribuída na AWS
A análise detalhada a seguir mostra as etapas envolvidas na execução de um cenário de teste.
**Testar fluxos de trabalho**
![\[image3\]](http://docs.aws.amazon.com/pt_br/solutions/latest/distributed-load-testing-on-aws/images/image3.png)
1. Você usa o console web para enviar um cenário de teste que inclui os detalhes da configuração para a API da solução.
1. A configuração do cenário de teste é carregada no Amazon Simple Storage Service (Amazon S3) como um arquivo JSON (). `s3:///test-scenarios/<$TEST_ID>/<$TEST_ID>.json`
1. Uma máquina de estado do AWS Step Functions é executada usando o ID de teste, a contagem de tarefas, o tipo de teste e o tipo de arquivo como entrada da máquina de estado do AWS Step Functions. Se o teste for agendado, ele primeiro criará uma regra de CloudWatch eventos, que acionará o AWS Step Functions na data especificada. Para obter mais detalhes sobre o fluxo de trabalho de agendamento, consulte a seção [Fluxo de trabalho de agendamento de testes](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/test-scheduling-workflow.html) deste guia.
1. Os detalhes da configuração são armazenados na tabela de cenários do Amazon DynamoDB.
1. No fluxo de trabalho do executor de tarefas do AWS Step Functions, a função task-status-checker AWS Lambda verifica se as tarefas do Amazon Elastic Container Service (Amazon ECS) já estão em execução com o mesmo ID de teste. Se tarefas com o mesmo ID de teste forem encontradas em execução, isso causará um erro. Se não houver tarefas do Amazon ECS em execução no cluster do AWS Fargate, a função retornará o ID do teste, a contagem de tarefas e o tipo de teste.
1. A função executora de tarefas do AWS Lambda obtém os detalhes da tarefa da etapa anterior e executa as tarefas de trabalho do Amazon ECS no cluster AWS Fargate. A API do Amazon ECS usa a RunTask ação para executar as tarefas do trabalhador. Essas tarefas de trabalho são iniciadas e, em seguida, aguardam uma mensagem inicial da tarefa líder para iniciar o teste. A RunTask ação é limitada a 10 tarefas por definição. Se a contagem de tarefas for maior que 10, a definição da tarefa será executada várias vezes até que todas as tarefas do trabalhador tenham sido iniciadas. A função também gera um prefixo para distinguir o teste atual na função AWS Lambda de análise de resultados.
1. A função task-status-checker AWS Lambda verifica se todas as tarefas de trabalho do Amazon ECS estão sendo executadas com o mesmo ID de teste. Se as tarefas ainda estiverem sendo provisionadas, ele aguardará um minuto e verificará novamente. Depois que todas as tarefas do Amazon ECS estão em execução, ele retorna o ID do teste, a contagem de tarefas, o tipo de teste, todas as tarefas IDs e prefixos e os passa para a função executora de tarefas.
1. A função executora de tarefas do AWS Lambda é executada novamente, desta vez lançando uma única tarefa do Amazon ECS para atuar como o nó líder. Essa tarefa do ECS envia uma mensagem de início de teste para cada uma das tarefas do trabalhador para iniciar os testes simultaneamente.
1. A função task-status-checker AWS Lambda novamente verifica se as tarefas do Amazon ECS estão sendo executadas com o mesmo ID de teste. Se as tarefas ainda estiverem em execução, ele espera por um minuto e verifica novamente. Quando não há tarefas em execução do Amazon ECS, ele retorna o ID do teste, a contagem de tarefas, o tipo de teste e o prefixo.
1. Quando a função AWS Lambda executora de tarefas executa as tarefas do Amazon ECS no cluster AWS Fargate, cada tarefa baixa a configuração do teste do Amazon S3 e inicia o teste.
1. Depois que os testes são executados, o tempo médio de resposta, o número de usuários simultâneos, o número de solicitações bem-sucedidas e o número de solicitações malsucedidas para cada tarefa são registrados na Amazon CloudWatch e podem ser visualizados em um CloudWatch painel.
1. Se você incluiu dados ativos no teste, a solução filtra os resultados do teste em tempo real CloudWatch usando um filtro de assinatura. Em seguida, a solução passa os dados para uma função Lambda.
1. A função Lambda então estrutura os dados recebidos e os publica em um tópico do AWS IoT Core.
1. O console web se inscreve no tópico do AWS IoT Core para o teste e recebe os dados publicados no tópico para representar graficamente os dados em tempo real enquanto o teste está sendo executado.
1. Quando o teste é concluído, as imagens do contêiner exportam um relatório detalhado como um arquivo XML para o Amazon S3. Cada arquivo recebe um UUID para o nome do arquivo. *Por exemplo, s3://dlte-bucket/test-scenarios/ *<\$1TEST\$1ID> /results/ <\$1UUID>* .json.*
1. Quando os arquivos XML são carregados para o Amazon S3, a função AWS Lambda do analisador de resultados lê os resultados nos arquivos XML começando com o prefixo e analisa e agrega todos os resultados em um resultado resumido.
1. A função AWS Lambda do analisador de resultados grava o resultado agregado em uma tabela do Amazon DynamoDB.
## Fluxo de trabalho do servidor MCP (opcional)
Se você implantar a integração opcional do MCP Server, os agentes de IA poderão acessar e analisar seus dados de teste de carga por meio do seguinte fluxo de trabalho:
**Arquitetura do servidor MCP**
![\[Arquitetura do MCP Server mostrando integração com componentes DLT\]](http://docs.aws.amazon.com/pt_br/solutions/latest/distributed-load-testing-on-aws/images/mcp-server-architecture.png)
1. **Interação com o cliente** — O cliente interage com o MCP da DLT por meio do MCP Endpoint hospedado pelo AWS Gateway. AgentCore Os agentes de IA se conectam a esse endpoint para solicitar acesso aos dados de teste de carga.
1. **Autorização** - O AgentCore gateway processa a autorização em relação ao cliente do aplicativo de pool de usuários do Solution Cognito. O gateway valida o token Cognito do usuário para garantir que ele tenha permissão para acessar o servidor DLT MCP. Os usuários autorizados recebem acesso com o acesso à ferramenta do agente limitado a operações somente de leitura.
1. **Especificação da ferramenta** - O AgentCore gateway se conecta à função Lambda do DLT MCP Server. Uma especificação de ferramenta define as ferramentas disponíveis que os agentes de IA podem usar para interagir com seus dados de teste de carga.
1. **Acesso à API somente para leitura** - A função Lambda tem como escopo o acesso somente para leitura à API por meio dos endpoints existentes do DLT API Gateway. A função fornece quatro operações principais:
+ **Listar cenários** - Recupere uma lista de cenários de teste da tabela de cenários do DynamoDB
+ **Obtenha resultados de testes de cenários — Acesse resultados** de testes detalhados para cenários específicos do DynamoDB e do S3
+ **Obtenha executores de teste de carga do Fargate** - consulte informações sobre a execução de tarefas do Fargate no cluster do ECS
+ **Obtenha pilhas regionais disponíveis** - Recupere informações sobre a infraestrutura regional implantada em CloudFormation
A integração do MCP Server aproveita a infraestrutura DLT existente (API Gateway, Cognito, DynamoDB, S3) para fornecer acesso seguro e somente leitura aos dados de teste para análises e insights baseados em IA.
# Considerações sobre design
Esta seção descreve decisões de projeto e opções de configuração importantes para a solução Distributed Load Testing on AWS, incluindo aplicativos compatíveis, tipos de teste, opções de agendamento e considerações de implantação.
## Aplicações compatíveis
Essa solução oferece suporte ao teste de aplicativos baseados em nuvem e aplicativos locais, desde que você tenha conectividade de rede da sua conta da AWS com seu aplicativo. A solução APIs suporta o uso de protocolos HTTP ou HTTPS.
## Tipos de teste
O teste de carga distribuído na AWS oferece suporte a vários tipos de teste: testes simples de endpoint HTTP JMeter, K6 e Locust.
### Testes simples de endpoint HTTP
O console web fornece uma interface de configuração de endpoint HTTP que permite testar qualquer endpoint HTTP ou HTTPS sem escrever scripts personalizados. Você define o URL do endpoint, seleciona o método HTTP (GET, POST, PUT, DELETE etc.) em um menu suspenso e, opcionalmente, adiciona cabeçalhos e cargas de corpo de solicitação personalizados. Essa configuração permite que você teste APIs com tokens de autorização personalizados, tipos de conteúdo ou quaisquer outros cabeçalhos HTTP e corpos de solicitação exigidos pelo seu aplicativo.
### JMeter testes
Ao criar um cenário de teste usando o console web, você pode carregar um script JMeter de teste. A solução carrega o script no bucket S3 dos cenários. Quando as tarefas do Amazon ECS são executadas, elas baixam o JMeter script do S3 e executam o teste.
**Importante**
Embora seu JMeter script possa definir simultaneidade (usuários virtuais), taxas de transação (TPS), tempos de aceleração e outros parâmetros de carregamento, a solução substituirá essas configurações pelos valores especificados na tela Traffic Shape durante a criação do teste. A configuração do Traffic Shape controla a contagem de tarefas, a simultaneidade (usuários virtuais por tarefa), a duração do aumento e a duração da espera para a execução do teste.
Se você tiver arquivos JMeter de entrada, poderá compactá-los junto com o JMeter script. Você pode escolher o arquivo zip ao criar um cenário de teste.
Se você quiser incluir plug-ins, todos os arquivos.jar incluídos em um subdiretório /plugins no arquivo zip incluído serão copiados para o diretório de JMeter extensões e estarão disponíveis para teste de carga.
**nota**
Se você incluir arquivos JMeter de entrada com seu arquivo de JMeter script, deverá incluir o caminho relativo dos arquivos de entrada em seu arquivo de JMeter script. Além disso, os arquivos de entrada devem estar no caminho relativo. Por exemplo, quando os arquivos JMeter de entrada e o arquivo de script estiverem em/home/user directory and you refer to the input files in the JMeter script file, the path of input files must be ./INPUT\$1FILES. If you use /home/user/INPUT\$1FILES, o teste falhará porque não conseguirá encontrar os arquivos de entrada.
Se você incluir JMeter plug-ins, os arquivos.jar deverão ser agrupados em um subdiretório chamado /plugins na raiz do arquivo zip. Em relação à raiz do arquivo zip, o caminho para os arquivos jar deve ser. /Plugins/bundled\$1plugin.jar.
Para obter mais informações sobre como usar JMeter scripts, consulte o [Manual do JMeter usuário](https://jmeter.apache.org/usermanual/index.html).
### Testes K6
A solução oferece suporte a testes baseados na estrutura K6. O K6 é lançado sob a licença [AGPL-3.0](https://github.com/grafana/k6/blob/master/LICENSE.md). A solução exibe uma mensagem de confirmação de licença ao criar um novo teste K6. Você pode carregar o arquivo de teste K6 junto com todos os arquivos de entrada necessários em um arquivo de arquivamento.
**Importante**
Embora seu script K6 possa definir simultaneidade (usuários virtuais), estágios, limites e outros parâmetros de carga, a solução substituirá essas configurações pelos valores especificados na tela Traffic Shape durante a criação do teste. A configuração do Traffic Shape controla a contagem de tarefas, a simultaneidade (usuários virtuais por tarefa), a duração do aumento e a duração da espera para a execução do teste.
### testes de gafanhotos
A solução oferece suporte a testes baseados na estrutura Locust. Você pode carregar o arquivo de teste do Locust junto com todos os arquivos de entrada necessários em um arquivo compactado.
**Importante**
Embora seu script Locust possa definir simultaneidade (contagem de usuários), taxa de geração e outros parâmetros de carga, a solução substituirá essas configurações pelos valores que você especificar na tela do Traffic Shape durante a criação do teste. A configuração do Traffic Shape controla a contagem de tarefas, a simultaneidade (usuários virtuais por tarefa), a duração do aumento e a duração da espera para a execução do teste.
## Agendamento de testes
A solução fornece três opções de tempo de execução para executar testes de carga:
+ **Executar agora** - Execute o teste de carga imediatamente após a criação
+ **Executar uma vez** - Execute o teste em uma data e hora específicas no futuro
+ **Executar em um cronograma** - Crie testes recorrentes usando expressões cron para definir o cronograma
Ao selecionar **Executar uma vez**, você especifica o tempo de execução no formato de 24 horas e a data de execução em que o teste de carga deve começar a ser executado.
Ao selecionar **Executar em uma programação**, você pode inserir manualmente uma expressão cron ou selecionar padrões cron comuns (como a cada hora, diariamente em um horário específico, dias da semana ou mensalmente). A expressão cron usa um formato de agendamento refinado com campos para minutos, horas, dia do mês, mês, dia da semana e ano. Você também deve especificar uma data de expiração, que define quando o teste agendado deve parar de ser executado. Para obter mais informações sobre como o agendamento funciona, consulte a seção [Fluxo de trabalho de agendamento de testes](https://docs.aws.amazon.com/solutions/latest/distributed-load-testing-on-aws/test-scheduling-workflow.html) deste guia.
**nota**
Duração do teste: considere a duração total dos testes ao agendar. Por exemplo, um teste com tempo de aceleração de 10 minutos e tempo de espera de 40 minutos levará aproximadamente 80 minutos para ser concluído.
Intervalo mínimo: garanta que o intervalo entre os testes programados seja maior do que a duração estimada do teste. Por exemplo, se o teste levar cerca de 80 minutos, programe-o para ser executado no máximo a cada 3 horas.
Limitação horária: o sistema não permite que os testes sejam agendados com apenas uma hora de diferença, mesmo que a duração estimada do teste seja inferior a uma hora.
## Testes simultâneos
Essa solução cria um CloudWatch painel da Amazon para cada teste que exibe a saída combinada de todas as tarefas executadas no cluster do Amazon ECS em tempo real. O CloudWatch painel mostra o tempo médio de resposta, o número de usuários simultâneos, o número de solicitações bem-sucedidas e o número de solicitações malsucedidas. A solução agrega cada métrica por segundo e atualiza o painel a cada minuto.
## Gerenciamento de usuários
Durante a configuração inicial, você fornece um nome de usuário e endereço de e-mail que o Amazon Cognito usa para conceder acesso ao console web da solução. O console não fornece administração de usuários. Para adicionar mais usuários, você deve usar o console do Amazon Cognito. Para obter mais informações, consulte [Gerenciamento de usuários em grupos de usuários no Guia do](https://docs.aws.amazon.com/cognito/latest/developerguide/managing-users.html) *desenvolvedor do Amazon Cognito*.
Para migrar usuários existentes para grupos de usuários do Amazon Cognito, consulte o [blog da AWS Abordagens para migrar usuários para grupos de usuários do Amazon Cognito](https://aws.amazon.com/blogs/security/approaches-for-migrating-users-to-amazon-cognito-user-pools).
## Implantação regional
Essa solução usa o Amazon Cognito, que está disponível somente em regiões específicas da AWS. Portanto, você deve implantar essa solução em uma região onde o Amazon Cognito esteja disponível. Para obter a disponibilidade de serviços mais atual por região, consulte a [Lista de serviços regionais da AWS](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/).