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:

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

Design para 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. Ser capaz de falhar componentes ou toda a carga de trabalho para recursos redundantes fornece uma maneira eficiente de lidar com a maioria das falhas em 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

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 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.

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 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 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

Além de usar padrões de design que suportam a confiabilidade, outras estratégias que podem ajudá-lo a desenvolver mecanismos de autorrecuperação incluem:

• 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.

• Implemente ações automatizadas de autorrecuperação: Use ações automatizadas que são acionadas pela sua solução de monitoramento quando alterações predeterminadas no status de integridade 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.

Implementar um modo de degradação normal

Apesar de seus mecanismos de autopreservação e auto-cura, você ainda pode encontrar situações em que um ou mais componentes funcionam mal a ponto de ficarem indisponíveis por 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 que isso seja possível, projete e implemente um modo de degradação gracioso. Este é um fluxo de trabalho distinto que é ativado em reação a componentes com falha. As considerações para o design e a implementação incluem:

• Deteção de falhas e iniciação automatizada: Seus sistemas de monitoramento e alerta devem detetar componentes degradados e com falha, portanto, use esses sinais para criar um fluxo de trabalho que determine quando a mudança para o modo de degradação normal é necessária. O fluxo de trabalho deve então redirecionar automaticamente as chamadas de e para os componentes afetados para componentes alternativos ou 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. Isso normalmente se reflete em mensagens vinculadas a diferentes funções da carga de trabalho, como um pop-up ao adicionar itens a um carrinho, por exemplo.
• Crie caminhos alternativos para concluir as funções essenciais da sua carga de trabalho: Reflita sobre os fluxos críticos da sua carga de trabalho e determine como você pode manter esses fluxos quando os componentes principais 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 tempos limite de rede, são um problema comum para cargas de trabalho na nuvem, portanto, ter mecanismos para lidar com elas pode minimizar o tempo de inatividade e os esforços de solução de problemas enquanto você opera sua carga de trabalho na produção. Como a maioria das operações que falham devido a uma falha transitória terá êxito se for permitido tempo suficiente antes de tentar novamente a operação, o uso de um mecanismo de repetição é a abordagem mais comum para lidar com falhas transitórias. Ao projetar sua estratégia de repetição, 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 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.

Consulte o guia de design de trabalhos em segundo plano para obter orientações detalhadas para uma revisão completa das recomendações e considerações.

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 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.

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.

Ligações relacionadas

• Padrões de fiabilidade
• Lidar com falhas transitórias
• Desenvolver trabalhos de fundo
• Padrões de design na nuvem
• Design para autorrecuperação

Lista de verificação de fiabilidade

Consulte o conjunto completo de recomendações.