Experimentos de caos de design
Seu aplicativo de missão crítica 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 do caos permite que você conduza experimentos de falha em um ambiente controlado para identificar problemas que provavelmente surgirão durante o desenvolvimento e a implantação. Você deliberadamente injeta falhas do mundo real e observa como o sistema reage.
Nesta unidade, usaremos o Azure Chaos Studio. O serviço irá ajudá-lo a medir, compreender e melhorar a resiliência da sua aplicação na nuvem e do seu serviço. Você estará preparado para responder rapidamente se essa falha ocorrer em condições adversas na produção.
Realizar análise de modo de falha
Quando você projeta um experimento de caos, a primeira etapa é conduzir a análise de modo de falha (FMA) dos componentes do aplicativo para identificar possíveis cenários de falha.
Liste todos os componentes relevantes para um fluxo de usuários que precisam estar disponíveis e funcionais. Por exemplo, o fluxo de usuário de check-out usa os Serviços de Aplicativo do Azure, o Functions e o banco de dados do Cosmos DB.
Para cada componente, liste possíveis casos de falha, seu impacto e possíveis mitigações.
Vamos ver o resultado do FMA feito para os componentes do exemplo de fluxo de usuário de checkout da Contoso Shoes.
Serviço de Aplicativo do Azure para hospedar o aplicativo front-end
| Risco | Impacto | Possível atenuaçã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 a carga extra nas instâncias restantes e forneça espaço suficiente para esse cenário enquanto ainda atinge as metas de desempenho. |
| Exaustão da porta SNAT | Não é possível criar conexões de saída. Como resultado, as chamadas downstream, como chamadas para o banco de dados, falham. | Use pontos de extremidade privados para se conectar aos componentes a jusante. |
| Instância individual tornando-se insalubre | O tráfego de usuário roteado para uma instância não íntegra pode ter um desempenho ruim ou até mesmo falhar completamente. | O recurso de verificação de integridade do Serviço de Aplicativo fará 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 atenuação |
|---|---|---|
| Desempenho de arranque lento (a frio) | Como o plano de Consumo do Azure Functions é usado, as novas instâncias não terão garantias de desempenho. A alta demanda no serviço (de "vizinhos barulhentos") pode fazer com que a função de checkout experimente uma longa duração de inicialização que afeta as metas de desempenho. | Atualize para o plano Azure Functions Premium. |
| Interrupção de armazenamento subjacente | Se a conta de armazenamento subjacente ficar indisponível, a função deixará de funcionar. | Use computação com balanceamento de carga com armazenamento regional ou computação com balanceamento de carga com armazenamento compartilhado GRS. |
Base de dados do Azure Cosmos DB
| Risco | Impacto | Possível atenuação |
|---|---|---|
| Renomeando um banco de dados ou coleção | Devido à incompatibilidade na configuração, pode haver perda de dados. O aplicativo não poderá acessar nenhum dado até que a configuração seja atualizada e seus componentes sejam reiniciados. | Impeça essa situação usando bloqueios de banco de dados e de nível de coleção. |
| Gravar interrupção de região | Se a região primária (ou região de gravação) encontrar uma interrupção, a conta do Azure Cosmos DB promoverá automaticamente uma região secundária para ser a nova região de gravação primária quando o failover automático (gerenciado por serviço) for configurado na conta do Azure Cosmos DB. O failover ocorrerá em outra região na ordem de prioridade de região especificada. | Configure a conta de banco de dados com várias regiões e failover automático. Se houver uma falha, o serviço fará failover automaticamente e evitará quaisquer problemas contínuos no aplicativo. |
| Limitação extensiva devido à falta de unidades de solicitação (RUs) | Certos carimbos podem ser executados em alta na utilização do Azure Cosmos DB, enquanto outros ainda podem atender solicitações. | Use uma melhor distribuição de carga para mais carimbos ou adicione mais RUs. |
Projete um experimento de caos
Para projetar um experimento de caos, escolha alguns casos de falha. A escolha pode basear-se na probabilidade de a falha acontecer ou no possível impacto.
O objetivo do experimento é validar as medidas de resiliência que você implementou em seu aplicativo. Para uma hipótese de exemplo, suponha que você execute seu aplicativo no Serviço de Aplicativo com a redundância de zona habilitada. Se todas as instâncias subjacentes em uma zona ficarem inativas, você espera que seu aplicativo ainda esteja em execução.
Use o Chaos Studio para injetar as falhas nos componentes relevantes. Chaos Studio oferece uma biblioteca de falhas para você escolher. No entanto, como a biblioteca de falhas não cobre tudo, talvez seja necessário ajustar o cenário. Ou poderá ter de encontrar mais ferramentas para o ajudar a injetar a falha.
Importante
Direcione apenas um ambiente de não produção com seus experimentos. Injetar falhas em seu 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 por serviço não deve resultar em nenhum impacto sustentado no aplicativo. Se essa hipótese se provar verdadeira, você validou que sua medida de resiliência de replicação para várias regiões tem o efeito positivo desejado na confiabilidade do aplicativo.
Para simular essa falha, use a falha do Azure Cosmos DB da biblioteca de falhas do Chaos Studio.
Este exemplo é para um failover do Azure Cosmos DB que é executado por 10 minutos (PT10M) e 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"
}
]
}
Depois que o experimento termina, o Chaos Studio alterna a região de gravação de volta ao seu valor original.
Antes de injetar uma falha em um recurso do Azure, você deve habilitar a configuração de destinos e recursos correspondente para esse recurso. Essa configuração controla as falhas que podem ser executadas em relação aos recursos habilitados para injeção de falhas. Ao usar alvos e recursos com outras medidas de segurança, você pode evitar a injeção acidental ou maliciosa de falhas.
Agora que você projetou testes de carga e experimentos de caos, precisa automatizá-los em seus pipelines para que sejam executados de forma consistente e regular. Na próxima unidade, você aprenderá sobre como adicionar os testes de seus pipelines de CI/CD.