Recomendações para auto-cura e auto-preservação

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

Guias relacionados: Trabalhos | em segundo plano Falhas transitórias

Este guia descreve as recomendações para criar recursos de autorrecuperação e autopreservação em sua arquitetura de aplicativo 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 em um estado degradado enquanto os componentes com falha são recuperados. 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 diferentes tipos de falhas.

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

Definições

Principais estratégias de design

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

No nível da infraestrutura, um projeto de arquitetura redundante deve dar suporte aos seus fluxos críticos, com recursos implantados em 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 picos imprevistos de atividade, reforçando ainda mais sua infraestrutura.

Use o padrão Deployment Stamps ou o padrão Bulkhead para minimizar o raio de jateamento 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 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. 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 de aplicativos

Evite criar aplicativos monolíticos em seu design de aplicativo. Use serviços de acoplamento flexível ou microsserviços que se comunicam entre si por meio de padrões bem definidos para reduzir o risco de problemas extensos quando ocorrem avarias 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 dos aplicativos seja consistente e simplificado, o que torna a carga de trabalho mais confiável e mais fácil de solucionar problemas quando ocorrem avarias. 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 letras mortas. Os padrões de design a seguir ajudam você a organizar sua carga de trabalho e definir as comunicações entre os componentes da maneira que melhor atenda aos seus requisitos de negócios.

• Padrão Ambassador: Separe sua lógica de negócios do código de rede e da lógica de resiliência. Crie serviços de programa auxiliar que enviam pedidos de rede em nome de um serviço ou aplicação de consumidor. Você pode usar esse padrão para implementar mecanismos de repetição ou disjuntor.

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

• Padrão Cache-Side: carregue 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 armazenados no armazenamento de dados subjacente.

• Padrão do disjuntor: use disjuntores para determinar proativamente se deve permitir que uma operação prossiga 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 verificação de declaração e uma carga útil. Envie o cheque de reivindicação para a plataforma de mensagens e armazene a carga em um serviço externo. Esse padrão permite que mensagens grandes sejam processadas enquanto protege o barramento de mensagens e evita que o cliente fique sobrecarregado ou lento.

• Padrão de consumidores concorrentes: permita que vários consumidores simultâneos processem 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 para 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 corretor 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: Desacople 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 ela invoca para ajudar a suavizar cargas pesadas intermitentes que podem fazer com que o serviço falhe ou a tarefa atinja o tempo limite. Esse padrão pode ajudar a minimizar o efeito de 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 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 a funcionar e a cumprir os SLAs (Service Level Agreements, contratos de nível de serviço), mesmo quando um aumento na demanda coloca uma carga extrema sobre os recursos.

• Padrão de Tratamento de Falhas Transitórias e Padrão de Repetição de Falhas: 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 perda momentânea de conectividade de rede, uma conexão de banco de dados interrompida ou um tempo limite quando um serviço está ocupado. Para obter mais informações sobre como desenvolver uma estratégia de nova tentativa, consulte o guia de tratamento de falhas transitórias nesta série.

Tarefas 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 trabalhos em segundo plano são:

• 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 obter mais informações, consulte Recomendações para trabalhos em segundo plano.

Estrutura para autorrecuperação

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 você adota para alcançar a autorrecuperação para um fluxo crítico dependem das metas de confiabilidade definidas para esse fluxo e dos componentes e dependências do fluxo.

Diretrizes de projeto de infraestrutura

No nível da infraestrutura, seus fluxos críticos devem ser suportados por um projeto de arquitetura redundante com failover automatizado habilitado para componentes que oferecem suporte a ele. 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 e padrões de design de aplicativos

• Bloquear maus atores: Se você estrangular um cliente, isso não significa que o cliente estava agindo maliciosamente. 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á-lo. Defina um processo fora de banda para um cliente solicitar o desbloqueio.

• Padrão do disjuntor: Se uma falha persistir após o mecanismo de repetição ser iniciado, você corre o risco de falhas em cascata resultantes de um acúmulo 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á.

• Padrão de Transação de Compensação: Se você usar uma operação eventualmente consistente que consiste em uma série de etapas, implemente o padrão de Transação de Compensação. Se uma ou mais etapas falharem, você poderá usar esse padrão para desfazer o trabalho que as etapas executaram.

• Degradar graciosamente: às vezes você não pode contornar um problema, mas pode fornecer funcionalidade reduzida. Considere uma aplicação que mostra um catálogo de livros. Se a aplicação não conseguir obter a imagem em miniatura da capa, poderá mostrar uma imagem de marcador de posição. Subsistemas completos poderão não ser críticos para a aplicação. 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 automáticas de failover. Quando um banco de dados faz failover automaticamente para uma réplica devido a um problema com a instância principal, o desempenho é degradado por um curto período de tempo.

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

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

• Use pontos de verificação para transações de longa duração: os pontos de verificação podem fornecer resiliência se uma operação de longa duração falhar. Quando a operação é reiniciada, por exemplo, se for captada por outra máquina virtual, 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. Salve esse estado em um armazenamento durável que pode ser acessado por qualquer instância do processo que executa a tarefa. Se o processo for encerrado, o trabalho que estava a executar pode ser retomado a partir do último ponto de verificação utilizando outra instância. Existem bibliotecas que fornecem essa funcionalidade, como NServiceBus e MassTransit. Eles persistem de forma transparente, onde os intervalos são alinhados com o processamento de mensagens de filas no Barramento de Serviço do Azure.

Ações automatizadas de autorrecuperação

Outra abordagem para a autorrecuperação é o uso de ações automatizadas que são acionadas pela sua solução de monitoramento quando alterações de status de integridade pré-determinadas são detetadas. 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. Consulte a arquitetura de referência de automação de nuvem baseada em eventos para obter um exemplo de uso de uma função para responder à limitação de 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 dos SDKs do cliente incluem um mecanismo de repetição. 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 os grupos de ação do Azure Monitor para notificações, como email, voz ou SMS, e para disparar ações automatizadas. Quando você for notificado de uma falha, acione um runbook de 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 reparo automatizada.

Considerações

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

• Padrão de ambassador
• Padrão assíncrono de solicitação-resposta
• Padrão da antepara
• Padrão Cache-Aside
• Padrão de verificação de sinistro
• Padrão de Transação de Compensação
• Padrão de consumidores concorrentes
• Configurar tempos limite de solicitação
• Padrão Gatekeeper
• Padrão de eleição do líder
• Padrão de Redistribuição de Carga Baseada na Fila
• Padrão de Repetição
• Padrão de Limitação
• Padrão de tratamento de falhas transitórias

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.

Ligações relacionadas

• Padrões de fiabilidade
• Padrões de design na nuvem
• Design para autorrecuperação

Lista de verificação de fiabilidade

Consulte o conjunto completo de recomendações.