Tornar todas as coisas redundantes

Criar redundância no seu aplicativo, evite ter pontos únicos de falha

Um aplicativo resiliente contorna a falha. Identifique os caminhos críticos em seu aplicativo. Há redundância em cada ponto no caminho? Se um subsistema falhar, o aplicativo fará failover para algo diferente?

Recomendações

Considere os requisitos de negócios. A quantidade de redundância incorporada em um sistema pode afetar o custo e a complexidade. Sua arquitetura deve ser informada pelos requisitos de negócios, como o objetivo de tempo de recuperação (RTO) e o objetivo de ponto de recuperação (RPO). Você também deve considerar os requisitos de desempenho e a capacidade da sua equipe de gerenciar conjuntos complexos de recursos.

Considere arquiteturas de várias zonas e várias regiões. Certifique-se de entender como as zonas e regiões de disponibilidade oferecem resiliência e diferentes conjuntos de compensações arquitetônicas.

As zonas de disponibilidade do Azure são conjuntos isolados de data centers em uma região. Ao usar zonas de disponibilidade, você pode ser resiliente a falhas de um único data center ou de toda uma zona de disponibilidade. Você pode usar as zonas de disponibilidade para fazer compensações entre custo, redução de riscos, desempenho e capacidade de recuperação. Por exemplo, quando você usa serviços redundantes de zona em sua arquitetura, o Azure fornece replicação automática de dados e failover entre instâncias geograficamente separadas, o que reduz muitos tipos diferentes de riscos.

Se você tiver uma carga de trabalho de missão crítica e precisar reduzir o risco de uma interrupção em toda a região, considere uma implantação em várias regiões. Embora as implantações em várias regiões o protejam contra desastres regionais, elas têm um custo. As implantações em várias regiões são mais caras do que uma implementação em uma única região e são mais complicadas de gerenciar. Você precisará de procedimentos operacionais para lidar com failover e failback. Dependendo dos seus requisitos de RPO, talvez seja necessário aceitar um desempenho ligeiramente inferior para permitir a replicação de dados entre regiões. O custo e a complexidade adicionais podem ser justificados em alguns cenários comerciais.

Dica

Para muitas cargas de trabalho, uma arquitetura redundante por zona oferece o melhor conjunto de compensações. Considere uma arquitetura multirregional se seus requisitos de negócios indicarem que você precisa atenuar o risco improvável de uma interrupção em toda a região e se estiver preparado para aceitar as compensações envolvidas nessa abordagem.

Para saber mais sobre como projetar sua solução para usar zonas e regiões de disponibilidade, consulte Recomendações para usar zonas de disponibilidade e regiões.

Posicione as VMs por trás de um balanceador de carga. Não use uma única VM para cargas de trabalho de missão crítica. Em vez disso, posicione várias VMs atrás de um balanceador de carga. Se qualquer VM ficar indisponível, o balanceador de carga distribuirá o tráfego para as VMs íntegras restantes. Para saber como implantar essa configuração, consulte [Várias VMs para escalabilidade e disponibilidade][multi-vm-blueprint].

Replique os bancos de dados. O Banco de Dados SQL do Azure e o Azure Cosmos DB replicam automaticamente os dados em uma região e podem ser configurados para replicar em zonas de disponibilidade para maior resiliência. Você também pode optar por ativar a replicação geográfica entre regiões. A replicação geográfica para o Banco de Dados SQL do Azure e o Azure Cosmos DB cria réplicas secundárias legíveis de seus dados em uma ou mais regiões secundárias. Se ocorrer uma interrupção na região primária, o banco de dados poderá fazer o failover para a região secundária para gravações. Dependendo da configuração de replicação, você poderá sofrer alguma perda de dados de transações não replicadas.

Se você usar uma solução de banco de dados IaaS, escolha uma que ofereça suporte à replicação e ao failover, como os Grupos de Disponibilidade Always On do SQL Server.

Partição para disponibilidade. O particionamento do banco de dados geralmente é usado para melhorar a escalabilidade, mas também pode melhorar a disponibilidade. Se um fragmento falhar, os outros fragmentos ainda poderão ser acessados. Uma falha em um fragmento interromperá apenas um subconjunto do total de transações.

Soluções para várias regiões

O diagrama a seguir mostra um aplicativo de várias regiões que usa o Gerenciador de Tráfego do Azure para controlar o failover.

Se você usar o Gerenciador de Tráfego em uma solução multirregional, considere as seguintes recomendações:

Sincronize o failover de front e back-end. Use o Gerenciador de Tráfego para fazer o failover do front-end. Se o front-end não puder ser acessado em uma região, o Gerenciador de Tráfego direcionará novas solicitações para a região secundária. Dependendo dos componentes de backend e da solução de banco de dados, talvez seja necessário coordenar a falha nos serviços de backend e nos bancos de dados.

Use o failover automático, mas o failback manual. Use o Gerenciador de Tráfego para o failover automático, mas não para failback automático. O failback automático traz um risco de você alternar para a região primária antes de a região estar completamente íntegra. Em vez disso, verifique se todos os subsistemas de aplicativo estão íntegros antes de realizar o failback. Além disso, dependendo do banco de dados, você precisará verificar a consistência de dados antes do failback.

Para isso, desative o ponto de extremidade primário do Gerenciador de Tráfego após o failover. Observe que, se o intervalo de monitoramento das sondas for curto e o número tolerado de falhas for pequeno, o failover e o failback ocorrerão em pouco tempo. Em alguns casos, a desativação não será concluída a tempo. Para evitar um failback não confirmado, considere também implementar um endpoint de integridade que possa verificar se todos os subsistemas estão íntegros. Consulte o padrão Monitoramento do Ponto de Extremidade de Integridade.

Inclua redundância para o Gerenciador de Tráfego. O Gerenciador de Tráfego é um possível ponto de falha. Examine o SLA do Gerenciador de Tráfego e determine se usar apenas o Gerenciador de Tráfego atende aos seus requisitos de negócios para alta disponibilidade. Caso contrário, considere adicionar outra solução de gerenciamento de tráfego como um failback. Se o serviço do Gerenciador de Tráfego do Azure falhar, altere os registros CNAME no DNS para apontar para outro serviço de gerenciamento de tráfego.