Recomendações para autorrecuperação e autopreservação

  • Artigo

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

RE:07 Fortaleça a resiliência e a capacidade de recuperação de sua carga de trabalho implementando medidas de autopreservação e autorrecuperação. Crie recursos na solução usando padrões de confiabilidade baseados em infraestrutura e padrões de design baseados em software para lidar com falhas de componente e erros transitórios. Crie recursos no sistema para detectar falhas de componente da solução e iniciar automaticamente a ação corretiva enquanto a carga de trabalho continua operando com funcionalidade completa ou reduzida.

Guias relacionados:Falhastransitóriasde trabalhos | em segundo plano

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

As funcionalidades de autopreservação adicionam resiliência à sua carga de trabalho. Eles reduzem a probabilidade de uma interrupção completa e permitem que sua carga de trabalho opere em um estado degradado enquanto componentes com falha são recuperados. Os recursos de autorrecuperação ajudam você a evitar o tempo de inatividade criando na detecção de falhas e ações corretivas automáticas para responder a diferentes tipos de falha.

Este guia descreve padrões de design que se concentram na autopreservação e na autorrecuperação. Incorpore-os em sua carga de trabalho para fortalecer sua resiliência e capacidade de recuperação. Se você não implementar padrões, seus aplicativos correrão o risco de falhar quando surgirem problemas inevitáveis.

Definições

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

Principais estratégias de design

Diretrizes de autopreservação

Para projetar sua carga de trabalho para autopreservação, siga padrões de design de infraestrutura e arquitetura de aplicativo para otimizar a resiliência da carga de trabalho. Para minimizar a chance de sofrer 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 da carga de trabalho.

Diretrizes e padrões de design de infraestrutura

No nível da infraestrutura, um design de arquitetura redundante deve dar suporte aos fluxos críticos, com recursos implantados entre zonas ou regiões de disponibilidade. Implemente o dimensionamento automático quando possível. O dimensionamento automático ajuda a proteger sua carga de trabalho contra intermitências inesperadas na atividade, reforçando ainda mais sua infraestrutura.

Use o padrão Selos de Implantação ou o padrão Bulkhead para minimizar o raio de explosão quando surgirem problemas. Esses padrões ajudam a manter sua carga de trabalho disponível se um componente individual não estiver 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 Selos 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, uma unidade de serviço, uma unidade de escala ou uma célula.

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

Diretrizes e padrões de design do aplicativo

Evite criar aplicativos monolíticos no design do aplicativo. Use serviços ou microsserviços flexívelmente acoplados que se comunicam entre si por meio de padrões bem definidos para reduzir o risco de problemas extensivos quando ocorrerem falhas em um único componente. Por exemplo, você pode padronizar o uso de um barramento de serviço para lidar com toda a comunicação assíncrona. A padronização dos protocolos de comunicação garante que o design de aplicativos seja consistente e simplificado, o que torna a carga de trabalho mais confiável e fácil de solucionar problemas quando ocorrem falhas. Quando prático, prefira a comunicação assíncrona entre componentes em vez da comunicação síncrona para minimizar problemas de tempo limite, como mensagens mortas. Os padrões de design a seguir ajudam você a organizar sua carga de trabalho e definir as comunicações entre componentes de uma maneira que atenda melhor aos seus requisitos de negócios.

  • Padrão de embaixador: separe sua lógica de negócios do código de rede e da lógica de resiliência. Crie serviços auxiliares que enviam solicitações de rede em nome de um consumidor de serviço ou aplicativo. Você pode usar esse padrão para implementar mecanismos de repetição ou quebra de circuito.

  • Padrão de Request-Reply assíncrono: desacoplar o processamento de back-end de um host de front-end se o processamento de back-end precisar ser assíncrono, mas o front-end precisar de uma resposta clara.

  • Padrão Cache-Aside: carregar dados sob demanda de um armazenamento de dados em um cache. Esse padrão pode melhorar o desempenho e ajudar a manter a consistência entre os dados mantidos no cache e os dados que estão no armazenamento de dados subjacente.

  • Padrão de disjuntor: use disjuntores para determinar proativamente se uma operação deve continuar ou retornar uma exceção com base no número de falhas recentes.

  • Padrão de verificação de declaração: divida uma mensagem grande em uma marcar de declaração e um conteúdo. Envie o marcar de declaração para a plataforma de mensagens e armazene o conteúdo em um serviço externo. Esse padrão permite que mensagens grandes sejam processadas enquanto protege o barramento de mensagens e impede que o cliente seja sobrecarregado ou desacelerado.

  • Padrão consumidores concorrentes: habilite vários consumidores simultâneos para processar mensagens recebidas no mesmo canal de mensagens. Um sistema pode processar várias mensagens simultaneamente, o que otimiza a taxa de transferência, melhora a escalabilidade e a disponibilidade e equilibra a carga de trabalho.

  • Configurar tempos limite de solicitação: configure tempos limite de solicitação para chamadas a serviços ou bancos de dados. Os tempos limite de conexão do banco de dados normalmente são definidos como 30 segundos.

  • Padrão gatekeeper: proteja aplicativos e serviços usando uma instância de host dedicada para intermediar solicitações entre clientes e o aplicativo ou serviço. O agente valida e higieniza as solicitações e pode fornecer uma camada extra de segurança para limitar a superfície de ataque do sistema.

  • Padrão de Nivelamento de Carga Baseado em Fila: desacoplar as tarefas do serviço em sua solução usando uma fila entre elas para que cada uma possa ser executada de forma assíncrona. Use uma fila como um buffer entre uma tarefa e um serviço que ele invoca para ajudar a suavizar cargas pesadas intermitentes que podem fazer com que o serviço falhe ou que a tarefa tenha um tempo limite. Esse padrão pode ajudar a minimizar o efeito dos picos de demanda sobre a disponibilidade e a capacidade de resposta para a tarefa e o serviço.

  • Padrão de limitação: controle o consumo de recursos que são usados por uma instância de um aplicativo, um locatário individual ou um serviço inteiro. Esse padrão permite que o sistema continue funcionando e atenda aos SLAs (contratos de nível de serviço), mesmo quando um aumento na demanda coloca uma carga extrema nos recursos.

  • Padrão transitório de tratamento de falhas e padrão de repetição: implemente uma estratégia para lidar com falhas transitórias para fornecer resiliência em sua carga de trabalho. Falhas transitórias são ocorrências normais e esperadas em ambientes de nuvem. As causas típicas de falhas transitórias incluem a perda momentânea de conectividade de rede, uma conexão de banco de dados descartada ou um tempo limite quando um serviço está ocupado. Para obter mais informações sobre como desenvolver uma estratégia de repetição, consulte o guia transitório de tratamento de falhas nesta série.

Trabalhos em segundo plano

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

Exemplos comuns de trabalhos em segundo plano são:

  • Trabalhos com uso intensivo de CPU, como executar cálculos complexos ou analisar modelos estruturais.
  • Trabalhos com uso intensivo de E/S, como executar várias operações de armazenamento ou indexar arquivos grandes.
  • Trabalhos em lote, como atualizar dados regularmente ou processar tarefas em um momento específico.
  • Fluxos de trabalho de execução longa, como concluir um pedido ou provisionar serviços e sistemas.

Para obter mais informações, consulte Recomendações para trabalhos em segundo plano.

Diretrizes de autorrecuperação

Para projetar sua carga de trabalho para autorrecuperação, implemente a detecção de falhas para que as respostas automáticas sejam disparadas e os fluxos críticos se recuperem normalmente. Habilite o registro em log para fornecer insights operacionais sobre a natureza da falha e o sucesso da recuperação. As abordagens que você adota para alcançar a autorrecuperação para um fluxo crítico dependem dos destinos de confiabilidade definidos para esse fluxo e dos componentes e dependências do fluxo.

Diretrizes de design de infraestrutura

No nível da infraestrutura, seus fluxos críticos devem ser suportados por um design de arquitetura redundante com failover automatizado habilitado para componentes que dão suporte a ele. Você pode habilitar o failover automatizado para os seguintes tipos de serviços:

  • Recursos de computação: o Azure Conjuntos de Dimensionamento de Máquinas Virtuais e a maioria dos serviços de computação paaS (plataforma como serviço) 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 SQL do Azure, grupos de disponibilidade Always On ou recursos internos com serviços de PaaS. Os bancos de dados NoSQL têm recursos de clustering semelhantes e recursos internos para serviços de PaaS.

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

Diretrizes e padrões de design do aplicativo

  • Bloquear atores ruins: se você limitar um cliente, isso não significa que o cliente estava agindo mal-intencionado. Isso pode significar que o cliente excedeu sua cota de serviço. Mas se um cliente exceder consistentemente sua cota ou se comportar mal, você poderá bloqueá-los. Defina um processo fora de banda para um cliente solicitar o desbloqueio.

  • Padrão de disjuntor: se uma falha persistir depois que o mecanismo de repetição for iniciado, você correrá o risco de falhas em cascata resultantes de uma lista de pendências crescente de chamadas. Um disjuntor projetado para funcionar com o mecanismo de repetição limita o risco de falhas em cascata, impedindo que o aplicativo tente executar repetidamente uma operação que provavelmente falhará.

  • Compensando o padrão de transação: se você usar uma operação eventualmente consistente que consiste em uma série de etapas, implemente o padrão De compensação de transação. Se uma ou mais das etapas falharem, você poderá usar esse padrão para desfazer o trabalho executado pelas etapas.

  • Degradar normalmente: às vezes, você não pode resolver um problema, mas pode fornecer funcionalidade reduzida. Considere um aplicativo que mostra um catálogo de livros. Se o aplicativo não puder recuperar a imagem em miniatura da capa, poderá mostrar uma imagem de espaço reservado. Subsistemas inteiros podem não ser críticos para o aplicativo. Por exemplo, para um site de comércio eletrônico, mostrar recomendações de produtos é provavelmente menos crítico do que processar pedidos. A degradação normal também pode incluir operações de failover automático. Quando um banco de dados faz failover automaticamente para um réplica devido a um problema com a instância primária, o desempenho é degradado por um curto período de tempo.

  • Padrão de eleição de líder: quando você precisar coordenar uma tarefa, use a eleição de líder para selecionar um coordenador para que um coordenador não seja um ponto único de falha. Se o coordenador falhar, um novo será selecionado. Em vez de implementar um algoritmo de eleição de líder do zero, considere uma solução pronta para uso, como o ZooKeeper.

  • Padrões de teste: inclua testes dos padrões que você implementa como parte de seus procedimentos de teste padrão.

  • Usar pontos de verificação para transações de longa execução: os pontos de verificação poderão fornecer resiliência se uma operação de execução longa falhar. Quando a operação é reiniciada, por exemplo, se for captada por outra máquina virtual, ela poderá ser retomada do último ponto de verificação. Considere implementar um mecanismo que registra informações de estado sobre a tarefa em intervalos regulares. Salve esse estado no armazenamento durável que pode ser acessado por qualquer instância do processo que executa a tarefa. Se o processo for desligado, o trabalho que ele estava executando poderá ser retomado do último ponto de verificação usando outra instância. Há bibliotecas que fornecem essa funcionalidade, como NServiceBus e MassTransit. Eles mantêm o estado de forma transparente, em que os intervalos são alinhados com o processamento de mensagens de filas em Barramento de Serviço do Azure.

Ações automatizadas de autorrecuperação

Outra abordagem para autorrecuperação é o uso de ações automatizadas disparadas por sua solução de monitoramento quando alterações de status de integridade predeterminadas são detectadas. Por exemplo, se o monitoramento detectar 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 de aplicativo. Dependendo do conjunto de habilidades e das tecnologias de desenvolvimento preferenciais da sua equipe, use um webhook ou uma função para criar ações de automação mais complexas. Consulte a arquitetura de referência de automação de nuvem baseada em eventos para obter um exemplo de como usar uma função para responder à limitação do banco de dados. O uso de ações automatizadas pode ajudá-lo a se recuperar rapidamente e minimizar a necessidade de intervenção humana.

Facilitação do Azure

A maioria dos serviços do Azure e SDKs do cliente inclui um mecanismo de repetição. Mas elas diferem porque cada serviço tem características e requisitos diferentes, portanto, cada mecanismo de repetição é ajustado para 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 disparar ações automatizadas. Quando você for notificado sobre uma falha, dispare um runbook Automação do Azure, Hubs de Eventos do Azure, uma função do Azure, um aplicativo lógico ou um webhook para executar uma ação de recuperação automatizada.

Considerações

Familiarize-se com as considerações para cada padrão. Verifique se o padrão é adequado para sua carga de trabalho e requisitos de negócios antes da implementação.

Exemplo

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 confiabilidade

Consulte o conjunto completo de recomendações.

Lista de verificação de confiabilidade