Compartilhar via


Validação contínua com o Azure Load Testing e o Azure Chaos Studio

À medida que aplicativos e serviços nativos de nuvem se tornam mais complexos, a implantação de alterações e novas versões para eles pode ser um desafio. Interrupções são frequentemente causadas por implantações ou lançamentos com falha. Mas erros também podem ocorrer após a implantação, quando um aplicativo começa a receber tráfego real, especialmente em cargas de trabalho complexas que são executadas em ambientes de nuvem multilocatário altamente distribuídos e que são mantidos por várias equipes de desenvolvimento. Esses ambientes exigem medidas de mais resiliência, como lógica de repetição e dimensionamento automático, que geralmente são difíceis de testar durante o processo de desenvolvimento.

É por isso que a validação contínua em um ambiente semelhante ao ambiente de produção é importante, para que você possa encontrar e corrigir quaisquer problemas ou bugs o mais cedo possível no ciclo de desenvolvimento. As equipes de carga de trabalho devem testar no início do processo de desenvolvimento (mudar para a esquerda) e facilitar para os desenvolvedores a realização de testes em um ambiente próximo ao ambiente de produção.

Cargas de trabalho de missão crítica têm requisitos de alta disponibilidade, com metas de 3, 4 ou 5 noves (99,9%, 99,99% ou 99,999%, respectivamente). É crucial implementar testes automatizados rigorosos para atingir essas metas.

A validação contínua depende de cada carga de trabalho e das características arquitetônicas. Este artigo fornece um guia para preparar e integrar o Azure Load Testing e o Azure Chaos Studio em um ciclo de desenvolvimento regular.

1 – Definir testes com base nos limites esperados

O teste contínuo é um processo complexo que requer a preparação adequada. O que é testado e os resultados esperados devem ser claros.

No PE:06 – Recomendações para teste de desempenho e RE:08 – Recomendações para criar uma estratégia de teste de confiabilidade, o Azure Well-Architected Framework recomenda que você comece identificando os principais cenários, dependências, uso esperado, disponibilidade, desempenho e metas de escalabilidade.

Em seguida, você deve definir um conjunto de valores de limite mensuráveis para quantificar o desempenho esperado dos principais cenários.

Dica

Exemplos de valores de limite incluem o número esperado de entradas de usuário, solicitações por segundo para uma determinada API e operações por segundo para um processo em segundo plano.

Você deve usar valores de limite para desenvolver um modelo de integridade para seu aplicativo, tanto para teste quanto para operar o aplicativo em produção.

Visualização de fluxos de sistema de chaves usando círculos conectados verdes e vermelhos.

Em seguida, use os valores para definir um teste de carga que gera tráfego realista para testar o desempenho da linha de base do aplicativo e para validar as operações de escala esperadas. O tráfego de usuário artificial sustentado é necessário em ambientes de pré-produção, pois sem uso é difícil revelar problemas de runtime.

O teste de carga garante que as alterações feitas no aplicativo ou na infraestrutura não causem problemas e que o sistema ainda atenda aos critérios de desempenho e teste esperados. Uma execução de teste com falha que não atende aos critérios de teste indica que você precisa ajustar a linha de base ou que ocorreu um erro inesperado.

Tela de resultados do teste de carga mostrando a execução do teste de carga com falha.

Embora os testes automatizados representem o uso diário, você deve executar testes de carga manuais regularmente para verificar como o sistema responde a picos inesperados.

A segunda parte da validação contínua é a injeção de falhas (engenharia do caos). Esta etapa verifica a resiliência de um sistema testando como ele responde a falhas. Além disso, todas as medidas de resiliência, como lógica de repetição, dimensionamento automático e outras, estão funcionando conforme o esperado.

2 – Implementar a validação com o Load Testing e o Chaos Studio

O Microsoft Azure fornece esses serviços gerenciados para implementar testes de carga e engenharia de caos:

  • O Teste de Carga do Azure produz carga de usuário sintética em aplicativos e serviços.
  • O Azure Chaos Studio fornece a capacidade de executar a experimentação do caos injetando falhas sistematicamente nos componentes e na infraestrutura do aplicativo.

Você pode implantar e configurar o Chaos Studio e o Load Testing por meio do portal do Azure, mas, no contexto de validação contínua, é mais importante que você tenha APIs para implantar, configurar e executar testes de forma programática e automatizada. O uso dessas duas ferramentas em conjunto permite observar como o sistema reage a problemas e sua capacidade de se auto-curar em resposta a falhas de infraestrutura ou de aplicativo.

O vídeo a seguir mostra uma implementação combinada do Chaos and Load Testing integrado no Azure DevOps:

Se você estiver desenvolvendo uma carga de trabalho crítica, aproveite as diretrizes detalhadas fornecidas como parte do Azure Well-Architected Framework.

Uma opção é executar o teste de carga diretamente dentro do pipeline de ponta a ponta (e2e) usado para inicializar ambientes de desenvolvimento individuais (específicos da ramificação):

Execute a tela de pipeline com a opção de teste de carga selecionada.

O pipeline executa automaticamente um teste de carga, com ou sem experimentos de caos (dependendo da seleção) em paralelo:

O pipeline do Azure DevOps é executado com teste de e carga e caos.

Observação

Executar experimentos de caos durante um teste de carga pode resultar em maior latência, tempos de resposta mais altos e taxas de erro temporariamente aumentadas. Espere tempos de resposta e latência mais altos até que uma operação de expansão seja concluída ou um failover seja concluído, quando comparado a uma execução sem experimentos de caos.

Gráfico mostrando o aumento do tempo de resposta durante o experimento de caos.

Dependendo se o teste de caos está habilitado e a escolha de experimentos, as definições de linha de base podem variar, pois a tolerância a erros pode ser diferente no estado "normal" e no estado "caos".

3 – Ajustar limites e estabelecer uma linha de base

Por fim, ajuste os limites de teste de carga para execuções regulares para verificar se o aplicativo (ainda) fornece o desempenho esperado e não produz erros. Tenha uma linha de base separada para testes de caos que tolera picos esperados nas taxas de erro e desempenho reduzido temporário. Essa atividade é contínua e precisa ser repetida regularmente. Por exemplo, após introduzir novos recursos, alterar SKUs de serviço e outros.

O serviço de Teste de Carga do Azure fornece uma funcionalidade interna chamada critérios de teste que permite especificar determinados critérios que um teste precisa passar. Essa funcionalidade pode ser usada para implementar linhas de base diferentes.

Tela de critérios de teste com tempo de resposta e critérios de erro marcados como Reprovado.

A funcionalidade está disponível por meio do portal do Azure e, por meio da API de teste de carga, e os scripts de wrapper desenvolvidos como parte da Missão Crítica do Azure fornecem uma opção para entregar uma definição de linha de base baseada em JSON.

É altamente recomendável integrar esses testes diretamente em seus pipelines de CI/CD e executá-los durante os estágios iniciais do desenvolvimento de recursos.

Em resumo, a falha é inevitável em qualquer sistema distribuído complexo e, portanto, a solução deve ser arquiteta (e testada) para lidar com falhas. As diretrizes de carga de trabalho críticas doWell-Architected Framework e as implementações de referência podem ajudá-lo a projetar e operar aplicativos altamente confiáveis para derivar o valor máximo da nuvem da Microsoft.

Próxima etapa

Examine a área de design de implantação e teste para cargas de trabalho críticas.