Recomendações de autorrecuperação e auto-preservação

  • Artigo

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

RE:07 Reforce a resiliência e a capacidade de recuperação da sua carga de trabalho ao implementar medidas de auto-preservação e autorrecuperação. Crie capacidades na solução com padrões de fiabilidade baseados na infraestrutura e padrões de conceção baseados em software para lidar com falhas de componentes e erros transitórios. Crie capacidades no sistema para detetar falhas de componentes da solução e iniciar automaticamente a ação corretiva enquanto a carga de trabalho continua a funcionar com funcionalidades completas ou reduzidas.

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

Este guia descreve as recomendações para criar capacidades de autorrecuperação e auto-preservação na arquitetura da sua aplicação para otimizar a fiabilidade.

As capacidades de auto-preservação adicionam resiliência à carga de trabalho. Reduzem a probabilidade de uma indisponibilidade total e permitem que a carga de trabalho funcione num estado degradado enquanto os componentes com falhas são recuperados. As capacidades de autorrecuperação ajudam a evitar períodos de indisponibilidade ao criar ações de deteção de falhas e correção automática para responder a diferentes tipos de falhas.

Este guia descreve padrões de conceção que se focam na auto-preservação e na autorrecuperação. Incorpore-os na sua carga de trabalho para reforçar a resiliência e a capacidade de recuperação. Se não implementar padrões, as suas aplicações estão em risco de falha quando surgem problemas inevitáveis.

Definições

Termo Definição
Autorrecuperação A capacidade da carga de trabalho para resolver automaticamente problemas ao recuperar componentes afetados e, se necessário, efetuar a ativação pós-falha para a infraestrutura redundante.
Auto-preservação A capacidade da carga de trabalho para ser resiliente contra potenciais problemas.

Principais estratégias de conceção

Documentação de orientação sobre a auto-preservação

Para conceber a sua carga de trabalho para auto-preservação, siga os padrões de conceção da arquitetura da infraestrutura e da aplicação para otimizar a resiliência da sua carga de trabalho. Para minimizar a probabilidade de ocorrer uma indisponibilidade total da aplicação, aumente a resiliência da sua solução ao eliminar pontos únicos de falha e minimizar o raio de explosão das falhas. As abordagens de conceção neste artigo fornecem várias opções para reforçar a resiliência da carga de trabalho e cumprir os objetivos de fiabilidade definidos da carga de trabalho.

Padrões e orientações de conceção da infraestrutura

Ao nível da infraestrutura, uma estrutura de arquitetura redundante deve suportar os seus fluxos críticos, com recursos implementados em zonas ou regiões de disponibilidade. Implemente o dimensionamento automático sempre que possível. O dimensionamento automático ajuda a proteger a carga de trabalho contra picos inesperados de atividade, reforçando ainda mais a sua infraestrutura.

Utilize o padrão Carimbos de Implementação ou o padrão Bulkhead para minimizar o raio de explosão quando surgirem problemas. Estes padrões ajudam a manter a carga de trabalho disponível se um componente individual não estiver disponível. Utilize os seguintes padrões de conceção de aplicações em combinação com a sua estratégia de dimensionamento automático.

  • Padrão de Selos de Implementação: aprovisione, faça a gestão e monitorize um grupo variado de recursos para alojar e operar várias cargas de trabalho ou inquilinos. Cada cópia individual é denominada selo ou, por vezes, unidade de serviço, unidade de escala ou célula.

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

Padrões e orientações de conceção de aplicações

Evite criar aplicações monolíticas na estrutura da sua aplicação. Utilize serviços ou microsserviços relativamente acoplados que comunicam entre si através de normas bem definidas para reduzir o risco de problemas extensos quando ocorrem avarias num único componente. Por exemplo, pode uniformizar a utilização de um service bus para processar todas as comunicações assíncronas. A uniformização dos protocolos de comunicação garante que a estrutura das aplicações é consistente e simplificada, o que torna a carga de trabalho mais fiável e fácil de resolver problemas quando ocorrem avarias. Quando prático, prefira uma comunicação assíncrona entre componentes em vez de comunicações síncronas para minimizar problemas de tempo limite, como mensagens não entregues. Os seguintes padrões de conceção ajudam-no a organizar a sua carga de trabalho e a definir as comunicações entre componentes de uma forma que melhor cumpra os seus requisitos empresariais.

  • Padrão ambassador: separe a lógica de negócio 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. Pode utilizar este padrão para implementar mecanismos de repetição ou interrupção do circuito.

  • Padrão de Request-Reply assíncrono: desassociar o processamento de back-end de um anfitrião de front-end se o processamento de back-end tiver de ser assíncrono, mas o front-end precisa de uma resposta clara.

  • Padrão Cache-Aside: carregue dados a pedido de um arquivo de dados para uma cache. Este padrão pode melhorar o desempenho e ajudar a manter a consistência entre os dados mantidos na cache e os dados que estão no arquivo de dados subjacente.

  • Padrão de Disjuntor Automático: utilize disjuntores para determinar proativamente se uma operação deve continuar ou devolver uma exceção com base no número de falhas recentes.

  • Padrão de Verificação de Afirmações: divida uma mensagem grande numa verificação de afirmações e num payload. Envie a verificação de afirmações para a plataforma de mensagens e armazene o payload num serviço externo. Este padrão permite que as mensagens grandes sejam processadas enquanto protege o barramento de mensagens e impede que o cliente fique sobrecarregado ou abrandado.

  • Padrão consumidores concorrentes: permita que vários consumidores simultâneos processem mensagens recebidas no mesmo canal de mensagens. Um sistema pode processar várias mensagens em simultâneo, o que otimiza o débito, melhora a escalabilidade e a disponibilidade e equilibra a carga de trabalho.

  • Configurar tempos limite de pedidos: configure tempos limite de pedidos para chamadas para serviços ou bases de dados. Normalmente, os tempos limite da ligação da base de dados são definidos para 30 segundos.

  • Padrão do Controlador de Chamadas: proteja aplicações e serviços com uma instância de anfitrião dedicada para mediar pedidos entre clientes e a aplicação ou serviço. O mediador valida e limpa os pedidos e pode fornecer uma camada adicional de segurança para limitar a superfície de ataque do sistema.

  • Padrão de Redistribuição de Carga Baseada na Fila: desassociar as tarefas do serviço na sua solução através de uma fila entre as mesmas para que possam ser executadas de forma assíncrona. Utilize uma fila como memória intermédia entre uma tarefa e um serviço que invoca para ajudar a suavizar cargas pesadas intermitentes que podem fazer com que o serviço falhe ou que a tarefa exceda o tempo limite. Este padrão pode ajudar a minimizar o efeito dos picos de procura na disponibilidade e capacidade de resposta da tarefa e do serviço.

  • Padrão de limitação: controle o consumo de recursos que são utilizados por uma instância de uma aplicação, um inquilino individual ou um serviço completo. Este padrão permite que o sistema continue a funcionar e a cumprir contratos de nível de serviço (SLAs), mesmo quando um aumento da procura coloca uma carga extrema nos recursos.

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

Tarefas em segundo plano

As tarefas em segundo plano são uma forma eficaz de melhorar a fiabilidade de um sistema ao desassociar as tarefas da interface de utilizador (IU). Implemente uma tarefa como uma tarefa em segundo plano se não precisar de comentários ou entradas do utilizador e se não afetar a capacidade de resposta da IU.

Exemplos comuns de tarefas em segundo plano são:

  • Tarefas com utilização intensiva da CPU, como a realização de cálculos complexos ou a análise de modelos estruturais.
  • Tarefas de E/S intensivas, como executar várias operações de armazenamento ou indexar ficheiros grandes.
  • Tarefas em lote, como atualizar dados regularmente ou processar tarefas num momento específico.
  • Fluxos de trabalho de execução prolongada, como concluir uma encomenda ou aprovisionar serviços e sistemas.

Para obter mais informações, veja Recomendações para tarefas em segundo plano.

Documentação de orientação para a autorrecuperação

Para conceber a carga de trabalho para recuperação automática, implemente a deteção de falhas para que as respostas automáticas sejam acionadas e os fluxos críticos recuperem corretamente. Ative o registo para fornecer informações operacionais sobre a natureza da falha e o êxito da recuperação. As abordagens que adotar para alcançar a autorrecuperação de um fluxo crítico dependem dos destinos de fiabilidade definidos para esse fluxo e dos componentes e dependências do fluxo.

Documentação de orientação de conceção da infraestrutura

Ao nível da infraestrutura, os fluxos críticos devem ser suportados por um design de arquitetura redundante com ativação pós-falha automatizada ativada para componentes que a suportem. Pode ativar a ativação pós-falha automatizada 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 de plataforma como serviço (PaaS) podem ser configurados para ativação pós-falha automática.

  • Bases de dados: as bases de dados relacionais podem ser configuradas para ativação pós-falha automática com soluções como SQL do Azure clusters de ativação pós-falha, grupos de disponibilidade AlwaysOn ou capacidades incorporadas com serviços PaaS. As bases de dados NoSQL têm capacidades de clustering e capacidades incorporadas semelhantes para serviços PaaS.

  • Armazenamento: utilize opções de armazenamento redundantes com ativação pós-falha automática.

Padrões e orientações de conceção de aplicações

  • Bloquear maus atores: se limitar um cliente, não significa que o cliente estava a agir maliciosamente. Pode significar que o cliente excedeu a quota de serviço. No entanto, se um cliente exceder consistentemente a quota ou se se comportar mal, poderá bloqueá-lo. Defina um processo fora de banda para um cliente pedir que seja desbloqueado.

  • Padrão de Disjuntor Automático: se uma falha persistir após o mecanismo de repetição ser iniciado, corre o risco de falhas em cascata resultantes de um registo de tarefas pendentes crescente de chamadas. Um disjuntor automático concebido para funcionar com o mecanismo de repetição limita o risco de falhas em cascata ao impedir que a aplicação tente executar repetidamente uma operação que possa falhar.

  • Padrão de Transação de Compensação: se utilizar uma operação eventualmente consistente que consiste numa série de passos, implemente o padrão Transação de Compensação. Se um ou mais dos passos falharem, pode utilizar este padrão para anular o trabalho realizado nos passos.

  • Degradar-se corretamente: por vezes, não consegue contornar um problema, mas pode fornecer funcionalidades reduzidas. 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 encomendas. A degradação correta também pode incluir operações de ativação pós-falha automáticas. Quando uma base de dados faz a ativação pós-falha automaticamente para uma 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 precisar de coordenar uma tarefa, utilize a eleição de 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 off-the-shelf, como o ZooKeeper.

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

  • Utilizar pontos de verificação para transações de execução prolongada: os pontos de verificação podem fornecer resiliência se uma operação de execução prolongada 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 implementar um mecanismo que regista informações de estado sobre a tarefa em intervalos regulares. Guarde este estado no armazenamento durável que pode ser acedido 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 com outra instância. Existem bibliotecas que fornecem esta funcionalidade, como NServiceBus e MassTransit. Persistem de forma transparente no estado em que os intervalos estão alinhados com o processamento de mensagens de filas no Azure Service Bus.

Ações de auto-recuperação automatizadas

Outra abordagem à auto-recuperação é a utilização de ações automatizadas que são acionadas pela sua solução de monitorização quando são detetadas alterações ao estado de funcionamento pré-determinadas. Por exemplo, se a monitorização detetar que uma aplicação Web não está a responder a pedidos, pode criar automatização através de um script do PowerShell para reiniciar o serviço de aplicações. Consoante o conjunto de competências da sua equipa e as tecnologias de desenvolvimento preferenciais, utilize um webhook ou uma função para criar ações de automatização mais complexas. Veja a arquitetura de referência da automatização da cloud baseada em eventos para obter um exemplo de utilização de uma função para responder à limitação da base de dados. A utilização de ações automatizadas pode ajudá-lo a 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. No entanto, diferem porque cada serviço tem características e requisitos diferentes, pelo que cada mecanismo de repetição é otimizado para um serviço específico. Para obter mais informações, veja Recomendações para processamento transitório de falhas.

Utilize grupos de ações do Azure Monitor para notificações, como e-mail, voz ou SMS, e para acionar ações automatizadas. Quando for notificado de uma falha, acione um runbook Automatização do Azure, Hubs de Eventos do Azure, uma função do Azure, uma aplicação lógica ou um webhook para executar uma ação de recuperação automatizada.

Considerações

Familiarize-se com as considerações de cada padrão. Certifique-se de que o padrão é adequado para a carga de trabalho e os requisitos empresariais antes da implementação.

Exemplo

Por exemplo, casos de utilização de alguns padrões, veja o padrão de aplicação Web fiável para .NET. Siga estes passos para implementar uma implementação de referência.

Lista de verificação de fiabilidade

Veja o conjunto completo de recomendações.

Lista de verificação de fiabilidade