Validação contínua com o Azure Load Testing e o Azure Chaos Studio
À medida que os aplicativos e serviços nativos da nuvem se tornam mais complexos, implantar alterações e novas versões para eles pode ser um desafio. As interrupções são frequentemente causadas por implantações ou lançamentos defeituosos. 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 mantidas por várias equipes de desenvolvimento. Esses ambientes exigem mais medidas de 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 (deslocar para a esquerda) e tornar conveniente para os desenvolvedores fazer testes em um ambiente próximo ao ambiente de produção.
As 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 alcançar esses objetivos.
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 limiares esperados
O teste contínuo é um processo complexo que requer preparação adequada. O que será testado e os resultados esperados devem ser claros.
Em PE:06 - Recomendações para testes de desempenho e RE:08 - Recomendações para projetar 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.
Gorjeta
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.
Em seguida, use os valores para definir um teste de carga que gere tráfego realista para testar o desempenho da linha de base do aplicativo, validar operações de escala esperadas e assim por diante. O tráfego de usuários artificiais sustentado é necessário em ambientes de pré-produção, porque sem o uso é difícil revelar problemas de tempo de execução.
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.
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, que 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 validação com Load Testing e Chaos Studio
O Microsoft Azure fornece estes 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 experimentação de caos, injetando sistematicamente falhas em componentes e infraestrutura de aplicativos.
Você pode implantar e configurar o Chaos Studio e o Teste de Carga por meio do portal do Azure, mas, no contexto da 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 autorrecuperação em resposta a falhas de infraestrutura ou aplicativos.
O vídeo a seguir mostra uma implementação combinada do Chaos e do Teste de Carga integrada no Azure DevOps:
Se estiver a desenvolver uma carga de trabalho de missão crítica, tire partido das arquiteturas de referência, orientações detalhadas, implementações de exemplo e artefactos de código fornecidos como parte do projeto de Missão Crítica do Azure e do Azure Well-Architected Framework.
A implementação de missão crítica implanta o serviço de teste de carga via Terraform e contém uma coleção de scripts wrapper do PowerShell Core para interagir com o serviço por meio de sua API. Esses scripts podem ser incorporados diretamente em um pipeline de implantação.
Uma opção na implementação de referência é executar o teste de carga diretamente de dentro do pipeline de ponta a ponta (e2e) que é usado para girar ambientes de desenvolvimento individuais (específicos da ramificação):
O pipeline executará automaticamente um teste de carga, com ou sem experimentos de caos (dependendo da seleção) em paralelo:
Nota
A execução de 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. Você notará números 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.
Dependendo se o teste de caos está habilitado e a escolha dos experimentos, as definições de linha de base podem variar, porque a tolerância a erros pode ser diferente no estado "normal" e no estado "caos".
3 – Ajustar os limiares e estabelecer uma linha de base
Finalmente, 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 tolere picos esperados nas taxas de erro e desempenho temporariamente reduzido. Esta atividade é contínua e precisa ser repetida regularmente. Por exemplo, depois de introduzir novos recursos, alterar SKUs de serviço e outros.
O serviço de Teste de Carga do Azure fornece um recurso interno chamado critérios de teste que permite especificar determinados critérios que um teste precisa passar. Esse recurso pode ser usado para implementar diferentes linhas de base.
O recurso está disponível por meio do portal do Azure e por meio da API de teste de carga, e os scripts 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 de desenvolvimento de recursos. Para obter um exemplo, consulte a implementação de exemplo na implementação de referência de missão crítica do Azure.
Em resumo, a falha é inevitável em qualquer sistema distribuído complexo e, portanto, a solução deve ser arquitetada (e testada) para lidar com falhas. As diretrizes de carga de trabalho de missão crítica e as implementações de referência do Well-Architected Framework podem ajudá-lo a projetar e operar aplicativos altamente confiáveis para obter o máximo valor da nuvem da Microsoft.
Próximo passo
Analise a área de projeto de implantação e teste para cargas de trabalho de missão crítica.