Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
À 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
Os testes contínuos são um processo complexo que requer uma preparação adequada. O que é 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.
Sugestão
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.
De seguida, utilize os valores para definir um teste de carga que gere tráfego realista para testar o desempenho de base da aplicação e para validar as operações de escala esperadas. 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 introduçã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 você estiver desenvolvendo uma carga de trabalho de missão crítica, aproveite as orientações detalhadas fornecidas como parte do Azure Well-Architected Framework.
Uma opção é executar o teste de carga diretamente no pipeline de ponta a ponta (e2e), que é utilizado para criar ambientes de desenvolvimento individuais (específicos de ramo):
O pipeline executa 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 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.
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.
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 doWell-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.