Compartilhar via

Recomendações para autocura e autopreservação

  • Artigo

Aplica-se a esta recomendação da 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 componentes e erros transitórios. Crie recursos no sistema para detectar falhas de componentes da solução e iniciar automaticamente a ação corretiva enquanto a carga de trabalho continua a operar com funcionalidade total ou reduzida.

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

Este guia descreve as recomendações para criar recursos de autocorreçã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. Elas 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. As funcionalidades de autorrecuperação ajudam você a evitar tempo de inatividade fornecendo 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 autocorreção. 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 surgirem problemas inevitáveis.

Definições

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

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 arquitetura de infraestrutura e aplicativo para otimizar a resiliência de sua carga de trabalho. Para minimizar a chance de sofrer uma interrupção total 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 de sua carga de trabalho e atender às metas de confiabilidade definidas de sua 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 seus fluxos críticos, com recursos implantados em 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 intermitências imprevistas de atividade, reforçando ainda mais sua infraestrutura.

Use o padrão Selos de Implantação ou o padrão Anteparo 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 selo ou, às vezes, uma unidade de serviço, unidade de escala ou célula.

  • Padrão de 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 do serviço para alguns consumidores, mesmo durante uma falha.

Diretrizes e padrões de design de aplicativos

Evite criar aplicativos monolíticos no design do aplicativo. Use serviços ou microsserviços fracamente acoplados que se comunicam entre si por meio de padrões bem definidos para reduzir o risco de problemas extensos quando ocorrem mau funcionamento 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 fácil de solucionar problemas quando ocorrem avarias. Quando possível, prefira a comunicação assíncrona entre os 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 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 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 solicitação-resposta assíncrono: desacople o processamento de back-end de um host 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: 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 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 verificação de declaração e uma carga. Envie a verificação de declaraçã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 seja 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 geralmente são definidos como 30 segundos.

  • Padrão de 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 limpa 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 na disponibilidade e na capacidade de resposta da tarefa e do 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 funcionando e atendendo aos SLAs (contratos de nível de serviço), mesmo quando um aumento na demanda sobrecarrega os recursos.

  • Padrão de tratamento de falhas transitórias 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 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 repetição, consulte o guia de tratamento de falhas transitórias nesta série.

Trabalhos em segundo plano

Os trabalhos em segundo plano são uma maneira eficaz de aumentar a confiabilidade de um sistema desacoplando 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:

  • Trabalhos com uso intensivo de CPU, como realizar 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 lotes, como atualizar dados regularmente ou processar tarefas em um momento específico.
  • Fluxos de trabalho de longa duração, como concluir um pedido ou provisionar serviços e sistemas.

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

Design para autorrecuperação

Para projetar sua carga de trabalho para autocorreção, implemente a detecçã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 insights operacionais sobre a natureza da falha e o sucesso da recuperação. As abordagens que você adota para obter a autocorreção de um fluxo crítico dependem das metas de confiabilidade definidas 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 o suportam. Você pode habilitar o failover automatizado para os seguintes tipos de serviços:

  • Recursos de computação: os Conjuntos de Dimensionamento de Máquinas Virtuais do Azure e a maioria dos serviços de computação de 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 do 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 PaaS.

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

Diretrizes e padrões de design de aplicativos

  • Bloqueie maus atores: se você limitar um cliente, isso não significa que ele estava agindo de forma maliciosa. 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 de disjuntor: se uma falha persistir após o início do mecanismo de repetição, 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 com probabilidade de 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 das etapas falharem, você poderá usar esse padrão para desfazer o trabalho que as etapas executaram.

  • Degradar normalmente: Às vezes, você não pode contornar 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 uma réplica devido a um problema com a instância primária, o desempenho é degradado por um curto período.

  • 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 único ponto 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 podem fornecer resiliência se uma operação de execução longa falhar. Quando a operação é reiniciada, por exemplo, se for selecionada por outra máquina virtual, ela pode ser retomada a partir do último ponto de verificação. Considere implementar 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 ele estava executando poderá ser retomado a partir do último ponto de verificação usando outra instância. Há bibliotecas que fornecem essa funcionalidade, como NServiceBus e MassTransit. Elas persistem de forma transparente e os intervalos são alinhados com o processamento de mensagens de filas no Barramento de Serviço do Azure.

Ações automatizadas de autocorreção

Outra abordagem para a autocorreção é o uso de ações automatizadas que são acionadas 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 a automação por meio de um script do PowerShell para reiniciar o serviço de 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 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 eles 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 de uma falha, dispare 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 de cada padrão. Certifique-se de que o padrão seja 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