View a markdown version of this page

Considerações sobre design - Teste de carga distribuída na AWS
Aplicações compatíveisTipos de testeModos de formato de tráfegoAgendamento de testesTestes simultâneosGerenciamento de usuáriosFederação do provedor de identidadeImplantação regional

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á.

Considerações sobre design

Esta seção descreve importantes decisões de design e opções de configuração para a solução Distributed Load Testing na 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 oferece suporte a APIs que usam protocolos HTTP ou HTTPS.

Tipos de teste

O teste de carga distribuída na AWS oferece suporte a vários tipos de teste: testes simples de endpoint HTTP, JMeter, k6 e Locust. Cada tipo de teste, exceto o endpoint HTTP simples, pode ser executado em qualquer modo de formato de tráfego. Para obter mais informações, consulte Modos de formato de tráfego.

nota

A solução distribui o JMeter, o k6 e o Locust como componentes de terceiros sem modificação. Para considerações de segurança, opções de patches e informações sobre licenças, consulte as estruturas de Third-party teste.

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 de solicitação personalizados e cargas corporais. 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.

Quando você configura um endpoint HTTP, a solução converte sua configuração em um plano de teste que é executado pelo binário Apache JMeter incluído por meio da estrutura Taurus. Testes simples de HTTP Endpoint não aceitam um arquivo de teste, portanto, não podem substituir o binário ou os plug-ins do JMeter incluídos. Se você precisar executar testes de endpoint HTTP com um JMeter corrigido, use o tipo de teste JMeter. Para considerações de segurança, consulte Apache JMeter.

Como a solução gera o plano de teste para esse tipo de teste, os testes de endpoint HTTP simples são executados somente no modo Padrão. O modo nativo requer um script que você carrega. Para obter mais informações, consulte Modos de formato de tráfego.

Testes JMeter

Ao criar um cenário de teste usando o console web, você pode carregar um script de teste do JMeter. A solução faz o upload do script para o bucket do S3 de cenários. Quando as tarefas do Amazon ECS são executadas, elas baixam o script JMeter do S3 e executam o teste.

Importante

No modo Padrão, seu script JMeter pode definir simultaneidade (usuários virtuais), taxas de transação (TPS), tempos de aceleração e outros parâmetros de carregamento. A solução substitui todos eles pelos valores que você especifica na tela Traffic Shape durante a criação do teste. Essa configuração 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.

No modo nativo, a solução é jmeter -n -t executada em seu script e não passa parâmetros de carregamento. Seus grupos de tópicos e temporizadores funcionam exatamente como foram criados. Para obter mais informações, consulte Modos de formato de tráfego.

Se você tiver arquivos de entrada do JMeter, poderá compactar os arquivos de entrada junto com o script JMeter. 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 extensões do JMeter e estarão disponíveis para teste de carga.

nota

Se você incluir arquivos de entrada do JMeter no arquivo de script do JMeter, deverá incluir o caminho relativo dos arquivos de entrada no arquivo de script do JMeter. Além disso, os arquivos de entrada devem estar no caminho relativo. Por exemplo, quando os arquivos de entrada e o arquivo de script do JMeter estão no home/user diretório/e você se refere aos arquivos de entrada no arquivo de script do JMeter, o caminho dos arquivos de entrada deve ser. /ARQUIVOS_ENTRADAS. Se você usar/home/user/INPUT_FILES em vez disso, o teste falhará porque não conseguirá encontrar os arquivos de entrada.

Se você incluir plug-ins do JMeter, 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_PLUGIN.jar.

Para obter mais informações sobre como usar os scripts do JMeter, consulte o Manual do usuário do JMeter.

testes k6

A solução oferece suporte a testes baseados na estrutura k6. Você pode carregar o arquivo de teste k6 junto com todos os arquivos de entrada necessários em um arquivo compactado. O console web exibe uma mensagem de confirmação de licença quando você cria um novo teste k6. Para obter detalhes de licença e segurança, consulte Grafana k6.

Importante

No modo Padrão, seu script k6 pode definir simultaneidade (usuários virtuais), estágios, limites e outros parâmetros de carregamento. A solução substitui todos eles pelos valores que você especifica na tela Traffic Shape durante a criação do teste. Essa configuração 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.

No modo nativo, a solução é k6 run executada em seu script e não passa parâmetros de carregamento. O k6 aplica seu bloco de opções, cenários, estágios e limites exatamente como está escrito. Para obter mais informações, consulte Modos de formato de tráfego.

testes de gafanhotos

A solução oferece suporte aos testes baseados na estrutura Locust. Você pode fazer o upload do arquivo de teste do Locust junto com os arquivos de entrada necessários em um arquivo.

Importante

No modo Padrão, seu script Locust pode definir simultaneidade (contagem de usuários), taxa de geração e outros parâmetros de carregamento. A solução substitui todos eles pelos valores que você especifica na tela Traffic Shape durante a criação do teste. Essa configuração 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.

No modo nativo, a solução é locust --headless executada em seu script e não passa parâmetros de carregamento. O Locust aplica suas LoadTestShape classes e conjuntos de tarefas ponderadas exatamente como estão escritos. Seu script não deve ser definidoprocesses, pois a solução contabiliza as solicitações somente quando o Locust é executado como um único processo. Para obter mais informações, consulte Modos de formato de tráfego.

Nomeação do script de teste

Quando você carrega um único .py arquivo, a solução o armazena sob a ID do teste e faz referência a ele diretamente, para que o arquivo possa ter qualquer nome. Quando você carrega um .zip arquivo, a solução procura no arquivo um arquivo chamadolocustfile.py. Se o arquivo contiver um script Python com qualquer outro nome, o teste falhará durante a inicialização do contêiner com a mensagemNo test script (.py) in zip file.

Dependências personalizadas do Python

O contêiner de teste de carga inclui o Locust e suas dependências. Ele não inclui pacotes Python de terceiros. Se seu script Locust importar um pacote que não está presente no contêiner, o teste falhará comModuleNotFoundError. Para disponibilizar pacotes adicionais, inclua um requirements.txt arquivo na raiz do seu .zip arquivo. O contêiner instala os pacotes listados requirements.txt antes do início do teste.

Você pode fornecer dependências de duas maneiras:

Instale a partir do PyPI

Inclua somente um requirements.txt arquivo. O contêiner instala os pacotes listados no PyPI na inicialização requirements.txt da tarefa. Isso requer acesso de saída à Internet a partir das sub-redes em que as tarefas de teste de carga são executadas.

Instale a partir de rodas incluídas (offline)

Inclua um requirements.txt arquivo e um packages subdiretório contendo arquivos Python wheel (.whl). O contêiner é instalado apenas a partir das rodas incluídas e não entra em contato com o PyPI. Essa opção funciona em ambientes sem acesso externo à Internet. O agrupamento de rodas também fixa as versões exatas do pacote, portanto, uma nova versão do PyPI não pode alterar seu ambiente de teste entre as execuções.

O exemplo a seguir mostra o layout do arquivo:

my-test.zip
├── locustfile.py         # Required — must use this name
├── requirements.txt      # Optional — packages to install
└── packages/             # Optional — wheels, for offline install only
    └── *.whl

Ambos requirements.txt e o packages subdiretório devem estar na raiz do arquivo, ao ladolocustfile.py. Omita ambos se seu script importar somente pacotes que o contêiner já fornece. O packages subdiretório entra em vigor somente junto com um requirements.txt arquivo; sozinho, ele é ignorado e nenhum pacote é instalado.

Dependências transitivas

Quando você agrupa rodas, requirements.txt deve listar todos os pacotes que suas dependências exigem, não apenas os pacotes que você importa diretamente. A instalação off-line não entra em contato com o PyPI. A ausência de uma dependência transitiva faz com que a instalação falhe e a tarefa seja interrompida antes do início do teste.

Preparando rodas para o contêiner

O contêiner de teste de carga executa o Linux na arquitetura x86_64 com Python 3.11. Rodas compiladas para um sistema operacional, arquitetura ou versão do Python diferentes não são instaladas. Pacotes escritos em Python puro são distribuídos como rodas independentes da plataforma e funcionam em qualquer lugar, mas pacotes contendo extensões compiladas exigem uma roda construída para a plataforma do contêiner. Como o contêiner não inclui um compilador, ele não pode criar uma distribuição de origem na inicialização da tarefa.

Execute o comando a seguir para baixar rodas compatíveis com a plataforma do contêiner. Você pode executar esse comando em qualquer sistema operacional, incluindo macOS e Windows. Em seguida, inclua o packages diretório resultante em seu arquivo:

pip download -r requirements.txt \
  --dest packages \
  --platform manylinux2014_x86_64 \
  --python-version 3.11 \
  --only-binary=:all:

As --python-version opções --platform e têm como alvo o contêiner, não a máquina na qual você executa o comando. A --only-binary=:all: opção faz com que o comando falhe em vez de retornar silenciosamente a uma distribuição de origem que o contêiner não pode criar. A manylinux2014 tag especifica uma roda compatível com glibc 2.17 e versões posteriores, que inclui a versão do contêiner.

Para agrupar um pacote que você mesmo mantém, crie uma roda a partir do diretório de origem do seu pacote e, em seguidapip wheel . --wheel-dir packages, adicione o nome do pacote. requirements.txt

Modos de formato de tráfego

Cada teste é executado em um dos dois modos de formato de tráfego, Padrão ou Nativo. O modo determina três coisas: qual lado controla a carga, qual imagem de contêiner as tarefas do Fargate usam e quais parâmetros de carga a solução envia para a estrutura de teste. Para obter orientação sobre como escolher um modo ao criar um teste, consulte Modos de formato de tráfego na seção Usar a solução.

Modo padrão

As tarefas do Fargate usam a imagem com o Taurus instalado. O Taurus recebe sua contagem de tarefas, simultaneidade, aumento e duração da espera da solução. Ele traduz esses valores nos próprios controles de carga da estrutura subjacente. O Taurus tem precedência sobre a carga declarada pelo seu script. Ele reescreve ou ignora um bloco de opções k6, um Locust ou um grupo de threads do LoadTestShape JMeter. Os usuários virtuais gerados por uma região são a contagem de tarefas multiplicada pela simultaneidade de cada tarefa. Essa forma é a mesma para todas as estruturas. Foi assim que a solução executou todos os testes antes da versão 4.3.0.

Modo nativo

As tarefas do Fargate usam a imagem dedicada para a estrutura do teste, que não inclui o Taurus. Em vez de escrever uma configuração do Taurus, a solução invoca a estrutura diretamente:jmeter -n -t,, ou. k6 run locust --headless Ele não passa parâmetros de carga. Seu script é a única autoridade sobre o tráfego que ele gera.

Duas consequências decorrem desse design e ambas afetam a forma como você dimensiona um teste:

  • As tarefas multiplicam a carga. Cada tarefa executa um processo de estrutura independente, sem coordenação entre as tarefas. Como resultado, uma região gera uma cópia completa da carga declarada do seu script para cada tarefa. Por exemplo, um script k6 com 200 usuários virtuais, executado em cinco tarefas, coloca 1.000 usuários virtuais no alvo. A contagem de tarefas é o único controle de carga que a solução oferece nesse modo. Ele se move em múltiplos inteiros do que o script declara.

  • Uma duração de segurança limita a corrida. Como o script decide quando o teste termina, a solução exige uma duração de segurança de até 24 horas. Se o teste ainda estiver em execução quando a duração terminar, a solução interromperá a estrutura. Ele coleta os resultados da parte executada e registra a execução como concluída em vez de falhada.

Agendamento de testes

A solução oferece 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 cronograma 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 regras de validação de agendamento, consulte a seção Restrições de agendamento deste guia.

nota

  • Duração do teste: considere a duração total dos testes ao agendar. Por exemplo, um teste com um tempo de aceleração de 10 minutos e um tempo de espera de 40 minutos levará aproximadamente 80 minutos para ser concluído.

  • Intervalo mínimo: certifique-se de que o intervalo entre os testes agendados 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

Cada vez que um teste de carga é executado, a função AWS Lambda do executor de tarefas cria um CloudWatch painel da Amazon nomeado EcsLoadTesting-<testId>-<region> em cada região em que o teste é executado. O CloudWatch painel exibe a saída combinada de todas as tarefas em execução no cluster do Amazon ECS em tempo real: tempo médio de resposta, número de usuários simultâneos, número de solicitações bem-sucedidas e número de solicitações com falha. A solução agrega cada métrica por segundo e atualiza o painel a cada minuto.

As execuções subsequentes do mesmo cenário de teste atualizam o mesmo painel, então sua conta contém um painel para cada cenário de teste em cada região. Esses painéis permanecem em sua conta após a conclusão dos testes. Eles incorrem em uma cobrança mensal até que você os exclua. A solução exclui os painéis de um cenário quando você exclui o cenário de teste (por exemplo, por meio do console web). Os painéis não são excluídos quando você exclui as CloudFormation pilhas da solução. Para obter mais informações, consulte a seção Custo e a seção Excluindo manualmente os recursos retidos deste guia.

Gerenciamento de usuários

Durante a configuração inicial, você fornece um nome de usuário e um 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 desenvolvedor do Amazon Cognito.

Para migrar usuários existentes para grupos de usuários do Amazon Cognito, consulte o blog da AWS Approaches for migrating users to Amazon Cognito user pools.

Federação do provedor de identidade

O grupo de usuários do Amazon Cognito da solução oferece suporte à federação com provedores de identidade externos (IdPs) usando os protocolos SAML 2.0 ou OpenID Connect (OIDC). A federação permite que os usuários façam login no console web usando suas credenciais corporativas ou organizacionais existentes em vez de Cognito-native credenciais. Os usuários federados recebem as mesmas permissões de acesso que os usuários criados diretamente no grupo de usuários do Cognito.

A solução já implanta o grupo de usuários, o domínio, o cliente do aplicativo e a interface de usuário hospedada do Cognito. Para ativar a federação, você só precisa registrar seu provedor de identidade e habilitá-lo no cliente de aplicativo existente.

Se você implantar a integração opcional do MCP Server, os usuários federados também poderão acessar o MCP Server usando as mesmas credenciais do grupo de usuários do Cognito.

Pré-requisitos

Antes de configurar a federação, você precisa do seguinte:

  • Um provedor de identidade externo compatível com SAML 2.0 ou OIDC

  • Acesso de administrador para configurar o IdP externo (para definir URIs de redirecionamento ou URLs do ACS)

  • O ID do grupo de usuários do Cognito da solução (disponível nos recursos da CloudFormation pilha ou no console do Amazon Cognito)

  • O prefixo de domínio Cognito da solução (disponível nas saídas da CloudFormation pilha ou no console do Cognito em Integração de aplicativos > Domínio)

Etapa 1: configurar seu provedor de identidade

Configure seu provedor de identidade externo com os seguintes valores para que ele possa se comunicar com o grupo de usuários do Cognito da solução.

Para provedores de identidade SAML:

  • ID da entidade SP: urn:amazon:cognito:sp:_<UserPoolId>_

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

Para provedores de identidade OIDC:

  • URI de redirecionamento: \https://<cognito-domain>.auth.<region>.amazoncognito.com/oauth2/idpresponse

Para obter detalhes sobre o que seu IdP precisa, consulte Adicionar provedores de identidade SAML a um grupo de usuários ou Adicionar provedores de identidade OIDC a um grupo de usuários no Guia do desenvolvedor do Amazon Cognito.

Etapa 2: registrar o provedor de identidade no Cognito

Adicione seu provedor de identidade externo ao grupo de usuários do Cognito existente na solução usando o console do Amazon Cognito.

Para obter instruções detalhadas, consulte Adicionar login ao grupo de usuários por meio de terceiros no Guia do desenvolvedor do Amazon Cognito.

Etapa 3: Configurar mapeamentos de atributos

Configure mapeamentos de atributos entre as declarações do seu provedor de identidade e os atributos do grupo de usuários do Cognito. No mínimo, mapeie a declaração de e-mail do usuário do provedor externo para o email atributo Cognito. Considere também mapear name ou nickname se seu provedor de identidade os fornece.

Para obter instruções, consulte Especificação de mapeamentos de atributos de provedores de identidade para seu grupo de usuários no Guia do desenvolvedor do Amazon Cognito.

Etapa 4: ativar o provedor de identidade no cliente do aplicativo

No console do Amazon Cognito, encontre o cliente do aplicativo criado pela solução e habilite seu novo provedor de identidade nas configurações da interface de usuário hospedada.

Para obter instruções, consulte Configurar um cliente de aplicativo de grupo de usuários no Guia do desenvolvedor do Amazon Cognito.

nota

A solução já configura os URLs de retorno de chamada e saída do cliente do aplicativo, os escopos do OAuth e o domínio de interface do usuário hospedado. Você não precisa modificar essas configurações — ative apenas seu provedor de identidade no cliente de aplicativo existente.

Importante

A solução omite intencionalmente a SupportedIdentityProviders propriedade da configuração do cliente do CloudFormation aplicativo. Isso permite que você adicione provedores de identidade após a implantação sem acionar a detecção de desvio. CloudFormation Se essa propriedade fosse definida no modelo, qualquer alteração manual do IdP por meio do console ou da CLI seria substituída na próxima atualização da pilha, revertendo o cliente do aplicativo somente para os provedores listados no modelo.

Como essa propriedade é omitida, não CloudFormation rastreia nem gerencia quais provedores de identidade estão habilitados no cliente do aplicativo. Depois de configurar a federação, você é responsável por gerenciar o conteúdo SupportedIdentityProviders do cliente do aplicativo. Para monitorar alterações não autorizadas, ative o registro em CloudTrail log da AWS e crie EventBridge regras da Amazon para alertar CreateIdentityProvider e fazer chamadas de UpdateUserPoolClient API direcionadas ao grupo de usuários do Cognito da solução.

nota

  • Adicionar um provedor de identidade externo não remove a capacidade de Cognito-native os usuários existentes entrarem com suas credenciais atuais.

  • Os usuários federados estão sujeitos às mesmas restrições de disponibilidade regional do grupo de usuários do Cognito. Para obter mais informações, consulte Implantação regional.

  • Teste o login federado com um pequeno grupo de usuários antes de implementá-lo em sua organização.

Desativando ou excluindo o usuário padrão do Cognito

Depois de configurar a federação, talvez você queira desativar ou excluir o usuário padrão que foi criado durante a implantação da pilha. Isso é opcional — o usuário padrão continua trabalhando junto com o login federado.

Para desabilitar um usuário, navegue até o grupo de usuários do Cognito da solução no console do Amazon Cognito, selecione a guia Usuários, escolha o usuário e selecione Desativar acesso do usuário. Para excluir um usuário, primeiro você deve desativá-lo e, em seguida, escolher Excluir usuário. Desativar um usuário revoga seus tokens e impede o login, preservando a conta; a exclusão a remove permanentemente.

Para obter mais detalhes, consulte Gerenciar e pesquisar contas de usuário no Guia do desenvolvedor do Amazon Cognito.

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 em que 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.