Estratégias de arquitetura para autorrecuperação e autopreservação

Aplica-se a esta recomendação da lista de verificação de Fiabilidade do Azure Well-Architected Framework:

RE:07 Fortaleça a resiliência de sua carga de trabalho implementando medidas de autopreservação e autorrecuperação. Use recursos integrados e padrões de nuvem bem estabelecidos para ajudar sua carga de trabalho a permanecer funcional durante e se recuperar de incidentes.

Este guia descreve as recomendações para criar recursos de autopreservação e autorrecuperação em sua arquitetura de aplicativos para otimizar a confiabilidade.

Os recursos de autopreservação adicionam resiliência à sua carga de trabalho. Eles reduzem a probabilidade de uma interrupção total e permitem que sua carga de trabalho opere normalmente, ou em um estado degradado, quando ocorrem falhas. Os recursos de autorrecuperação ajudam a evitar o tempo de inatividade, incorporando a deteção de falhas e ações corretivas automáticas para responder a falhas.

Definições

Term Definition
Autorrecuperação A capacidade de sua carga de trabalho de resolver problemas automaticamente recuperando componentes afetados e, se necessário, fazendo failover para a infraestrutura redundante.
Autopreservação A capacidade da sua carga de trabalho de ser resiliente contra possíveis problemas.

Conceber com redundância

Uma das estratégias mais eficazes para proteger sua carga de trabalho contra mau funcionamento é criar redundância em todos os seus componentes e evitar pontos únicos de falha. Poder transferir componentes ou toda a carga de trabalho para recursos redundantes fornece uma maneira eficiente de lidar com a maioria das falhas no seu sistema.

Crie redundância em diferentes níveis, considere componentes de infraestrutura redundantes, como computação, rede e armazenamento, e considere a implantação de várias instâncias de sua solução. Dependendo dos seus requisitos de negócios, você pode criar redundância dentro de uma única região ou entre regiões. Você também pode decidir se precisa de um design ativo-ativo ou ativo-passivo para atender aos seus requisitos de recuperação. Para obter mais informações, consulte Estratégias de arquitetura para projetar redundância e Estratégias de arquitetura para usar zonas e regiões de disponibilidade.

Design para autopreservação

Para projetar sua carga de trabalho para autopreservação, siga os padrões de design de infraestrutura e arquitetura de aplicativos para otimizar a resiliência da carga de trabalho. Para minimizar a chance de ocorrer uma interrupção completa do aplicativo, aumente a resiliência de sua solução eliminando pontos únicos de falha e minimizando o raio de explosão de falhas. As abordagens de design neste artigo fornecem várias opções para fortalecer a resiliência da carga de trabalho e atender às metas de confiabilidade definidas pela carga de trabalho.

Diretrizes e padrões de projeto de infraestrutura

Ao nível da infraestrutura, utilize um design de arquitetura redundante para suportar os seus fluxos críticos. Mobilizar recursos através de zonas de disponibilidade ou regiões. Implemente o dimensionamento automático quando possível. O dimensionamento automático ajuda a proteger sua carga de trabalho contra picos imprevistos de atividade, reforçando ainda mais sua infraestrutura.

Utilize o padrão Deployment Stamps ou o padrão Bulkhead para minimizar o raio de impacto quando surgirem problemas. Estes padrões ajudam a manter a sua carga de trabalho disponível caso um componente individual não esteja disponível. Use os seguintes padrões de design de aplicativo em combinação com sua estratégia de dimensionamento automático.

  • Padrão de carimbos de implantação: provisione, gerencie e monitore um grupo variado de recursos para hospedar e operar várias cargas de trabalho ou locatários. Cada cópia individual é chamada de carimbo ou, às vezes, unidade de serviço, unidade de escala ou célula.

  • Padrão de antepara: particione instâncias de serviço em diferentes grupos, conhecidos como pools, com base nos requisitos de carga e disponibilidade do consumidor. Este design ajuda a isolar falhas e permite manter a funcionalidade do serviço para alguns consumidores, mesmo durante uma falha.

Diretrizes e padrões de design de aplicativos

Evite criar aplicativos monolíticos em seu design de aplicativo. Utilize serviços frouxamente acoplados ou microserviços que comunicam entre si através de padrões bem definidos para reduzir o risco de problemas extensos quando ocorrem avarias num único componente. Por exemplo, pode padronizar o uso de um barramento de serviços para gerir toda a comunicação assíncrona. A padronização dos protocolos de comunicação garante que o design da aplicação seja consistente e simplificado, tornando a carga de trabalho mais fiável e mais fácil de diagnosticar quando ocorrem falhas. Quando possível, prefira comunicação assíncrona entre componentes em vez de comunicação síncrona para minimizar problemas de timeout.

Use padrões comprovados pelo setor para ajudá-lo a desenvolver seus padrões de projeto e simplificar aspetos da arquitetura. Os padrões de design que podem ajudar a suportar a confiabilidade podem ser encontrados no artigo Padrões de confiabilidade .

Projeto para auto-cura

Para projetar sua carga de trabalho para autorrecuperação, implemente a deteção de falhas para que as respostas automáticas sejam acionadas e os fluxos críticos se recuperem normalmente. Habilite o registro em log para fornecer informações operacionais sobre a natureza da falha e o sucesso da recuperação. As abordagens que adota para alcançar a auto-cura para um fluxo crítico dependem dos objetivos de fiabilidade que define para esse fluxo e dos componentes e dependências do fluxo.

Diretrizes de projeto de infraestrutura

Ao nível da infraestrutura, apoie os seus fluxos críticos com um design de arquitetura redundante. Ative o failover automatizado nos componentes que o suportam. Você pode habilitar o failover automatizado para os seguintes tipos de serviços:

  • Recursos de computação: os Conjuntos de Escala de Máquina Virtual do Azure e a maioria dos serviços de computação de plataforma como serviço (PaaS) podem ser configurados para failover automático.

  • Bancos de dados: os bancos de dados relacionais podem ser configurados para failover automático com soluções como clusters de failover do SQL do Azure, grupos de disponibilidade Always On ou recursos internos com serviços PaaS. Os bancos de dados NoSQL têm recursos de clustering semelhantes e recursos internos para serviços PaaS.

  • Armazenamento: Use opções de armazenamento redundantes com failover automático.

Diretrizes de design de aplicativos

Para além de utilizar padrões de design que apoiem a fiabilidade, considere estas estratégias para o ajudar a desenvolver mecanismos de auto-cura:

  • Use pontos de controlo para transações de longa duração: Os pontos de controlo proporcionam resiliência caso uma operação de longa duração falhe. Quando a operação é reiniciada, por exemplo, quando outra máquina virtual assume a operação, pode ser retomada a partir do último ponto de verificação. Considere a implementação de um mecanismo que registre informações de estado sobre a tarefa em intervalos regulares. Guarde este estado num armazenamento durável que qualquer instância do processo a executar a tarefa possa aceder. Se o processo for encerrado, outra instância poderá retomar o trabalho a partir do último ponto de verificação. Bibliotecas como NServiceBus e MassTransit fornecem esta funcionalidade. Persistem de forma transparente no estado, onde os intervalos se alinham com o processamento de mensagens das filas no Azure Service Bus.

  • Implemente ações automáticas de auto-cura: Use ações automáticas que a sua solução de monitorização acione ao detetar alterações pré-determinadas no estado de saúde.

    Por exemplo, se o monitoramento detetar que um aplicativo Web não está respondendo às solicitações, você poderá criar automação por meio de um script do PowerShell para reiniciar o serviço do aplicativo. Dependendo do conjunto de habilidades da sua equipe e das tecnologias de desenvolvimento preferidas, use um webhook ou função para criar ações de automação mais complexas. O uso de ações automatizadas pode ajudá-lo a se recuperar rapidamente e minimizar a necessidade de intervenção humana.

    Utilize padrões e funcionalidades de auto-cura específicas da tecnologia. Por exemplo, em vez de uma mensagem corrompida numa fila ser processada repetidamente, potencialmente impedindo o processamento futuro de mensagens, projete estratégias de remediação como usar uma fila de mensagens mortas. Pode automatizar a transferência de mensagens problemáticas para a fila, mas o tratamento desses itens normalmente envolve uma avaliação manual, seguida de uma etapa de remediação específica para o cenário.

Implementar um modo de degradação controlada

Apesar dos seus mecanismos de autopreservação e autocura, ainda pode encontrar situações em que um ou mais componentes avariem ao ponto de ficarem indisponíveis durante algum tempo. Nesses casos, idealmente, sua carga de trabalho pode manter funcionalidade suficiente para que os negócios continuem em um estado degradado. Para garantir esta possibilidade, desenhe e implemente um modo de degradação elegante. Este modo é um fluxo de trabalho distinto que é ativado em reação a componentes avariados. As considerações para o design e a implementação incluem:

  • Deteção de falhas e início automático: Os seus sistemas de monitorização e alerta devem detetar componentes degradados e avariados. Use esses sinais para construir um fluxo de trabalho que determine quando é necessário mudar para o modo de degradação gradual. O fluxo de trabalho deve então redirecionar automaticamente chamadas para e de componentes afetados para componentes alternativos, ou realizar outras ações semelhantes.
  • Implemente uma experiência de usuário degradada: Inclua um mecanismo de notificação para os usuários em seu modo de degradação normal para garantir que eles saibam qual funcionalidade permanece e o que mudou. Esta notificação é tipicamente refletida em mensagens associadas a diferentes funções da carga de trabalho, como um pop-up ao adicionar artigos a um carrinho, por exemplo.
  • Construa caminhos alternativos para completar as funções essenciais da sua carga de trabalho: Reflita sobre os fluxos críticos da sua carga de trabalho e determine como pode mantê-los quando os componentes centrais não estiverem disponíveis. Por exemplo, se um banco de dados estiver inativo, o aplicativo poderá alternar para um modo somente leitura usando dados armazenados em cache. Para ilustrar melhor este exemplo, se um gateway de pagamento estiver inativo, o uso de dados armazenados em cache pode permitir que os usuários salvem o carrinho e concluam a compra mais tarde.

Implementar mecanismos para lidar com falhas transitórias

Falhas transitórias, como os timeouts de rede, são um problema comum para cargas de trabalho na cloud. Ter mecanismos para os gerir pode minimizar o tempo de inatividade e os esforços de resolução de problemas enquanto opera a sua carga de trabalho em produção. Uma vez que a maioria das operações que falham devido a uma falha transitória acabam por ser bem-sucedidas se decorrer tempo suficiente antes de repetir a operação, a utilização de um mecanismo de retentativa é a abordagem mais comum para lidar com falhas transitórias. Ao projetar a sua estratégia de tentativa, considere o seguinte:

Consulte o guia de design de falhas transitórias para obter uma revisão completa das recomendações e considerações.

Implementar trabalhos em segundo plano

Os trabalhos em segundo plano são uma maneira eficaz de aumentar a confiabilidade de um sistema, separando tarefas da interface do usuário (UI). Implemente uma tarefa como um trabalho em segundo plano se ela não exigir entrada ou feedback do usuário e se não afetar a capacidade de resposta da interface do usuário.

Exemplos comuns de empregos de apoio incluem:

  • Tarefas intensivas de CPU, como a realização de cálculos complexos ou a análise de modelos estruturais.
  • Trabalhos intensivos de E/S, como a execução de várias operações de armazenamento ou a indexação de arquivos grandes.
  • Trabalhos em lote, como atualizar dados regularmente ou processar tarefas em um momento específico.
  • Fluxos de trabalho de longa duração, como a conclusão de um pedido ou o provisionamento de serviços e sistemas.

Para orientações detalhadas, consulte o guia de conceção sobre tarefas em segundo plano.

Gestão do Azure

A maioria dos serviços do Azure e SDKs de cliente incluem um mecanismo de nova tentativa. Mas eles diferem porque cada serviço tem características e requisitos diferentes, então cada mecanismo de repetição é ajustado a um serviço específico. Para obter mais informações, consulte Recomendações para tratamento de falhas transitórias.

Use grupos de ações do Azure Monitor para notificações, como email, voz ou SMS, e para ativar ações automáticas. Quando for notificado de uma falha, acione um runbook do Automatização do Azure, Hubs de Eventos do Azure, uma função Azure, uma aplicação lógica ou webhook para realizar uma ação automática de cura.

Example

Por exemplo, casos de uso de alguns padrões, consulte o padrão de aplicativo Web confiável para .NET. Siga estas etapas para implantar uma implementação de referência.

Lista de verificação de fiabilidade

Consulte o conjunto completo de recomendações.

Lista de verificação de fiabilidade

  • Última atualização a