Validação contínua com o Teste de Carga do Azure e o Azure Chaos Studio
À medida que os aplicativos e serviços nativos da nuvem se tornam mais complexos, a implantação de alterações e novas versões para eles pode ser desafiador. As interrupções são frequentemente causadas por implantações ou versões com defeito. 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ários altamente distribuídos e que são mantidos 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 (shift left) 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). É essencial implementar testes rigorosos automatizados para atingir esses objetivos.
A validação contínua depende de cada carga de trabalho e das características arquitetônicas. Este artigo fornece um guia de preparação e integração do Teste de Carga do Azure e do 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 começar identificando os principais cenários, dependências, uso esperado, disponibilidade, desempenho e destinos de escalabilidade.
Você deve definir um conjunto de valores limite mensuráveis para quantificar o desempenho esperado dos principais cenários.
Dica
Exemplos de valores 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 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 um tráfego realista a fim de testar o desempenho de linha de base do aplicativo, validar as operações de escala esperadas e assim por diante. O tráfego de usuários artificial sustentado é necessário em ambientes de pré-produção, pois sem usá-lo é difícil descobrir 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 esperados de desempenho e teste. 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). Essa 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, entre outras, estão funcionando conforme o esperado.
2 - Implementar a validação com o Teste de Carga e o Chaos Studio
O Microsoft Azure fornece estes serviços gerenciados para a implementação de testes de carga e da engenharia do 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 em componentes e infraestrutura de aplicativos.
É possível 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 maneira programática e automatizada. O uso dessas duas ferramentas juntas permite observar como o sistema reage a problemas e a 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 ao Azure DevOps:
Se você estiver desenvolvendo uma carga de trabalho de missão crítica, aproveite as arquiteturas de referência, as orientações detalhadas, as implementações de exemplo e os artefatos 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 interação com o serviço por meio de sua API. Esses scripts podem ser inseridos 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 que é usado para criar ambientes de desenvolvimento individuais (específicos da filial):
O pipeline executará automaticamente um teste de carga, com ou sem experimentos de caos (dependendo da seleção) em paralelo:
Observação
A execução de experimentos de caos durante um teste de carga pode resultar em maior latência, tempos de resposta mais altos e aumento temporário das taxas de erros. Você notará números mais altos até que uma operação de expansão ou um failover seja concluído, quando comparado a uma execução sem experimentos de caos.
Se o teste de caos estiver habilitado e, dependendo da escolha dos 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 de "caos".
3 – Ajustar os limiares e estabelecer uma linha de base
Por fim, ajuste os limites do teste de carga para execuções regulares a fim de verificar se o aplicativo (ainda) fornece o desempenho esperado e não produz erros. Tenha uma linha de base distinta para testes de caos que toleram os picos esperados nas taxas de erros e um desempenho temporariamente reduzido. Essa atividade é contínua e precisa ser repetida regularmente. Por exemplo, após a introdução de novos recursos, alterar SKUs de serviço, entre outras.
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 precisam ser atendidos em um teste. Esse recurso pode ser usado para implementar diferentes linhas de base.
O recurso está disponível no portal do Azure e na 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 do desenvolvimento de recursos. Para obter um exemplo, veja a implementação de exemplo na implementação de referência 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 do Well-Architected Framework e as implementações de referência podem ajudar a projetar e operar aplicativos altamente confiáveis para obtenção do máximo valor da nuvem da Microsoft.
Próxima etapa
Revisar a área de design de implantação e teste para cargas de trabalho de missão crítica.