Projetar experimentos de caos
Seu aplicativo crítico precisa ser resiliente e estar pronto para responder a falhas. No entanto, é difícil prever possíveis cenários de falha na nuvem. A engenharia de caos permite conduzir experimentos de falha em um ambiente controlado para identificar problemas que provavelmente surgirão durante o desenvolvimento e a implantação. Você injeta deliberadamente falhas reais e observa como o sistema reage.
Nesta unidade, você usará o Azure Chaos Studio. Esse serviço ajuda você a medir, entender e melhorar a resiliência do serviço e do aplicativo em nuvem. Ele prepara você para responder rapidamente caso ocorra uma falha em condições adversas na produção.
Realizar a análise do modo de falha
Ao projetar um experimento de caos, o primeiro ato é realizar a FMA (análise no modo de falha) dos componentes do aplicativo para identificar possíveis cenários de falha:
Liste todos os componentes relevantes para um fluxo de usuário que precisam estar disponíveis e funcionais. Por exemplo, o fluxo de usuário que passou pelo check-out usa o banco de dados dos Serviços de Aplicativo do Azure, do Azure Functions e do Azure Cosmos DB.
Para cada componente, liste possíveis casos de falha, o respectivo impacto e as possíveis mitigações.
Veja a seguir o resultado da FMA feita com relação aos componentes do exemplo de fluxo de usuário da Contoso Shoes submetido ao check-out.
Serviço de Aplicativo do Azure para hospedar o aplicativo de front-end
| Risco | Impacto | Possível mitigação |
|---|---|---|
| Interrupção da zona de disponibilidade | As instâncias nessa zona podem ficar indisponíveis. A interrupção total não é esperada porque a redundância de zona está habilitada no plano do Serviço de Aplicativo. |
Permita carga extra nas instâncias restantes e forneça espaço suficiente para esse cenário, além de atingir as metas de desempenho. |
| Esgotamento de porta SNAT | Não é possível criar conexões de saída. Como resultado, as chamadas downstream, como chamadas para o banco de dados, falharão. | Use pontos de extremidade privados para se conectar aos componentes downstream. |
| Instância individual tornando-se não íntegra | O tráfego do usuário roteado para uma instância não íntegra pode ter um desempenho baixo ou até mesmo falhar completamente. | Use o recurso de verificação de integridade do Serviço de Aplicativo. Esse recurso faz com que instâncias não íntegras sejam automaticamente identificadas e substituídas por novas instâncias íntegras. |
Azure Functions para lógica de check-out
| Risco | Impacto | Possível mitigação |
|---|---|---|
| Desempenho de inicialização a frio | Como o plano de consumo do Azure Functions é usado, novas instâncias não têm garantias de desempenho. A alta demanda no serviço (de "vizinhos ruidosos") pode fazer com que a função de check-out passe por uma longa duração de inicialização que afeta as metas de desempenho. |
Atualize para o plano Premium do Azure Functions. |
| Interrupção do armazenamento subjacente | Se a conta de armazenamento subjacente ficar indisponível, a função deixa de funcionar. | Use a computação com balanceamento de carga com o armazenamento regional ou a computação com balanceamento de carga com o armazenamento GRS compartilhado. |
Banco de Dados do Azure Cosmos DB
| Risco | Impacto | Possível mitigação |
|---|---|---|
| Renomear um banco de dados ou coleção | Devido à incompatibilidade na configuração, pode haver perda de dados. O aplicativo não pode acessar nenhum dado até que a configuração seja atualizada e os componentes dela reiniciados. | Evite essa situação usando bloqueios no nível do banco de dados e da coleção. |
| Paralisação da região de gravação | Quando o failover automático (gerenciado pelo serviço) for configurado na conta do Azure Cosmos DB, se a região primária (ou região de gravação) passar por uma interrupção, a conta do Azure Cosmos DB promove automaticamente uma região secundária para ser a nova região de gravação primária. O failover ocorre para outra região na ordem de prioridade da região especificada. | Configure a conta do banco de dados para usar várias regiões e failover automático. Em caso de falha, o serviço faz o failover automaticamente e evita problemas contínuos no aplicativo. |
| Limitação excessiva devido à falta de RUs (unidades de solicitação) | Certos selos podem sobrecarregar a utilização do Azure Cosmos DB, enquanto outros ainda podem atender a solicitações. | Use uma distribuição de carga melhor para mais selos ou adicione mais RUs. |
Projetar um experimento de caos
Para projetar um experimento de caos, escolha alguns casos de falha. A escolha pode ser baseada na probabilidade de que a falha aconteça ou no possível impacto dela.
O objetivo do experimento é validar as medidas de resiliência implementadas no aplicativo. Para uma hipótese de exemplo, suponha que você execute seu aplicativo no Serviço de Aplicativo com redundância de zona habilitada. Se todas as instâncias subjacentes em uma zona ficam inativas, você espera que seu aplicativo ainda permaneça em execução.
Use o Chaos Studio para injetar as falhas nos componentes relevantes. O Chaos Studio oferece uma biblioteca de falhas para sua escolha. No entanto, como ela não abrange tudo, pode ser necessário ajustar o cenário. Mais ferramentas também podem ser necessárias para que seja possível injetar a falha.
Importante
Baseie-se apenas em um ambiente de não produção durante seus experimentos. Injetar falhas no ambiente de produção pode ser arriscado e requer experiência e planejamento.
Exemplo: interrupção e failover do Azure Cosmos DB
Suponha que você escolha o cenário de falha "interrupção da região de gravação" do Azure Cosmos DB listado na tabela. A hipótese é: um failover iniciado pelo serviço não deve resultar em nenhum impacto contínuo no aplicativo. Se essa hipótese for verdadeira, você terá garantido que a medida de resiliência de replicação em diversas regiões tem o efeito positivo desejado na confiabilidade do aplicativo.
Para simular essa falha, use a falha do Azure Cosmos DB presente na biblioteca de falhas do Chaos Studio.
Este exemplo destina-se a um failover do Azure Cosmos DB executado por 10 minutos (PT10M) que usa West US 2 como a nova região de gravação. Ele assume que West US 2 já foi configurado como uma das regiões de replicação de leitura.
{
"name": "branchOne",
"actions": [
{
"type": "continuous",
"name": "urn:csci:microsoft:cosmosDB:failover/1.0",
"parameters": [
{
"key": "readRegion",
"value": "West US 2"
}
],
"duration": "PT10M",
"selectorid": "myCosmosDbResource"
}
]
}
Após o término do experimento, o Chaos Studio alterna a região de gravação de volta para o valor original.
Antes de injetar uma falha em um recurso do Azure, é necessário habilitar a configuração correspondente de destinos e recursos para ele. Essa configuração controla as falhas que podem ser executadas nos recursos habilitados para a injeção de falha. Ao usar destinos e recursos juntos com outras medidas de segurança, é possível evitar a injeção de falha acidental ou maliciosa.
Agora que você projetou os testes de carga e os experimentos de caos, precisa automatizá-los nos pipelines para que sejam executados consiste e regularmente. Na próxima unidade, você aprenderá a adicionar os testes aos pipelines de CI/CD.