Design para resiliência
 A carga de trabalho deve continuar operando com funcionalidade completa ou reduzida. |
|---|
Você deve esperar que falhas de componente, interrupções de plataforma, degradações de desempenho e outras falhas ocorram. Crie resiliência no sistema para que ele seja tolerante a falhas e possa se degradar normalmente.
Cenário de exemplo
Contoso Air é uma companhia aérea comercial que tem um departamento de desenvolvimento interno. O principal aplicativo LOB é uma solução de reserva que permite que os clientes reservem voos diretamente com a Contoso Air. O aplicativo é criado no Azure e usa o Serviço de Aplicativo do Azure, o Cosmos DB, o Azure Functions, os Aplicativos Lógicos do Azure e o Barramento de Serviço do Azure.
Determinar os riscos de falha.
Identifique possíveis pontos de falha no sistema, especialmente para os componentes críticos, e determine o efeito nos fluxos do usuário e do sistema.
Analise o caso de falha, o raio de ação e a intensidade da falha para cada ponto de falha potencial. Os casos de falha e sua intensidade podem variar de cenários relativamente de baixo impacto, como a perda temporária de um processo de back-end a interrupções em larga escala resultantes de desastres. A execução dessa análise ajuda você a determinar o design dos recursos de tratamento de erros no nível do componente.
O desafio da Contoso
- O aplicativo LOB fornece várias funções importantes que vão do marketing ao comércio. O fluxo de usuário de compra de tíquetes foi identificado como o fluxo mais crítico. A equipe de carga de trabalho determinou que mais medidas de confiabilidade devem ser implementadas para garantir que o fluxo seja otimizado para resiliência.
- A equipe tem tempo orçado para melhorias como desassociar componentes e reprojetar fluxos, mas deseja garantir que eles estejam usando esse tempo para se concentrar nas melhorias de mais valiosas.
Aplicando a abordagem e os resultados
- A equipe identifica o gateway de pagamento externo como um possível ponto de falha. O gateway está altamente disponível, mas há um potencial para os usuários que enfrentam falhas transitórias ocasionais resultantes de problemas de rede ou intermitências de solicitações extremamente altas. O gateway pode rejeitar algumas solicitações quando está sobrecarregado por várias solicitações simultâneas que estão sendo enviadas.
- A equipe determina que os usuários devem reenviar solicitações quando o gateway rejeita suas solicitações iniciais, causando uma experiência negativa do usuário.
Implementar mecanismos de autopreservação
Crie recursos de autopreservação usando padrões de design corretamente e modularizando o design para isolar falhas.
Ao criar recursos de autopreservação no sistema, você poderá evitar que um problema afete componentes downstream. O sistema poderá atenuar falhas transitórias e permanentes, gargalos de desempenho e outros problemas que possam afetar a confiabilidade. Você também poderá minimizar o raio da explosão.
O desafio da Contoso
- A equipe deseja minimizar o risco de falhas transitórias que fazem com que as solicitações dos usuários sejam rejeitadas pelo gateway de pagamento. Devido à natureza transitória de algumas das condições de erro, há uma grande probabilidade de que a mesma solicitação seja bem-sucedida se reenviada.
Aplicando a abordagem e os resultados
- A equipe desenvolve uma lógica personalizada no fluxo para tentar novamente a transação após um pequeno atraso quando uma falha que pode ser repetida é detectada.
- O design da solução será modificado para incorporar o Padrão de Repetição, aumentando ligeiramente o tempo de espera entre novas tentativas até que a solicitação seja processada com êxito ou o número máximo de falhas seja atingido.
- A equipe também decide separar a interação do usuário e a funcionalidade de processamento de pagamento de back-end desse fluxo usando uma abordagem controlada por eventos com o Barramento de Serviço do Azure. Quando ocorrem falhas irrecuperáveis ao processar a mensagem (após o número máximo de tentativas), o processador de back-end abandona o processamento dessa solicitação, deixando a mensagem na fila para que ela possa ser reprocessada posteriormente.
Criar redundância e resiliência abrangentes
Crie redundância em camadas e resiliência em várias camadas de aplicativo.
Aponte para redundância em utilitários físicos e replicação imediata de dados. Também visa redundância na camada funcional que abrange serviços, operações e pessoal. A redundância ajuda a minimizar pontos únicos de falha. Por exemplo, se houver uma interrupção que afete um ou mais componentes, uma zona de disponibilidade ou uma regional inteira, uma implantação redundante (ativa-ativa ou ativa-passiva) permitirá que você atenda aos destinos de tempo de atividade.
A adição de intermediários impede a dependência direta entre componentes e melhora o buffer. Ambos os benefícios endurecem a resiliência do sistema.
Desafio da Contoso
- A implementação de novas tentativas e a desassociação das chamadas de gateway de pagamento da interface do usuário usando o Barramento de Serviço aumentou drasticamente a confiabilidade desse fluxo, mas os stakeholders de negócios ainda se preocupam com a perda de dados que pode acontecer devido a uma falha catastrófica na região primária.
Aplicando a abordagem e os resultados
- A equipe decide atualizar para a camada premium do Barramento de Serviço. Ao fazer isso, eles podem aproveitar a funcionalidade de suporte das Zonas de Disponibilidade dessa camada. Com essa funcionalidade, várias cópias dos dados são armazenadas em três instalações fisicamente separadas (zonas de disponibilidade) e o serviço tem reservas de capacidade suficientes para lidar instantaneamente com a perda completa e catastrófica de um datacenter.
- Além disso, a equipe configura a recuperação de desastre geográfico do Barramento de Serviço do Azure para replicar continuamente os dados para uma região secundária que será usada no caso improvável de uma falha completa da região primária.