Arquitetura ativa-ativa multin região

Mesmo com zonas de disponibilidade, uma carga de trabalho implantada em uma única região do Azure pode ser afetada por uma interrupção regional — um evento raro, mas possível, causado por um grande desastre, uma tempestade severa ou uma falha de infraestrutura em larga escala. Para obter os níveis mais altos de disponibilidade, as empresas implantam cargas de trabalho em duas ou mais regiões do Azure, permitindo que o aplicativo continue atendendo aos usuários mesmo que uma região inteira fique offline.

Há dois padrões principais para várias regiões:

• Ativa-Ativa — os recursos em ambas as regiões atendem ao tráfego ativo simultaneamente. Isso maximiza a disponibilidade e também pode reduzir a latência, encaminhando os usuários para a região mais próxima.
• Ativa-Passiva — os recursos na região secundária ficam em espera e só recebem tráfego após um evento de failover. Essa opção custa menos, mas tem um tempo de recuperação maior.

Para obter a maior disponibilidade, a abordagem ativa-ativa é a preferida.

O Azure Traffic Manager é um balanceador de carga global baseado em DNS que distribui o tráfego entre pontos de extremidade em diferentes regiões do Azure (ou no local). Ele usa sondas de integridade para monitorar cada ponto de extremidade e métodos de roteamento (desempenho, ponderado, prioridade, geográfico e vários valores) para decidir para onde enviar o tráfego. Em uma configuração ativa-ativa, use o método de roteamento de desempenho para enviar os usuários à região íntegra mais próxima.

O Traffic Manager é compatível com vários métodos de roteamento adaptados a diferentes cenários:

• Desempenho — encaminha para o ponto de extremidade com menor latência (melhor para ativa-ativa)
• Ponderado — distribui o tráfego de acordo com uma porcentagem de peso (útil para lançamentos graduais)
• Prioridade — envia todo o tráfego para o ponto de extremidade primário, com alternativa para o secundário (ativa-passiva)
• Geográfico — encaminha os usuários com base na localização geográfica deles (soberania de dados)

Em uma arquitetura ativa-ativa, os dados precisam ser replicados entre as regiões para que os usuários de qualquer uma delas leiam dados consistentes. As opções incluem:

• Azure SQL Database com replicação geográfica — secundário legível em outra região
• Azure Cosmos DB com gravações em várias regiões — todas as regiões aceitam gravações simultaneamente
• Azure Storage com GRS — replicação assíncrona para uma região secundária

A escolha depende dos seus requisitos de consistência e disponibilidade de gravação.

O Azure Cosmos DB é especialmente adequado para arquiteturas ativas-ativas porque é compatível com gravações em várias regiões — todas as regiões configuradas podem aceitar operações de gravação simultaneamente. O Cosmos DB usa níveis de consistência configuráveis (de forte a eventual) para gerenciar a sincronização das réplicas. Em cenários ativos-ativos, a consistência de sessão ou a desatualização limitada são escolhas comuns que equilibram desempenho e correção.

Tanto o Traffic Manager quanto o Azure Front Door fornecem balanceamento de carga global, mas em níveis diferentes:

• Traffic Manager é baseado em DNS — ele redireciona o cliente para o ponto de extremidade regional correto, mas a conexão segue diretamente para esse ponto de extremidade. Ele opera na camada DNS.
• Azure Front Door é um proxy anycast — ele encerra a conexão do cliente em um PoP global e encaminha a solicitação para a origem. Além do roteamento, fornece WAF, descarregamento de SSL e armazenamento em cache.

A Microsoft designa pares de regiões para cada região do Azure — uma região secundária na mesma geografia, distante o suficiente para sobreviver a desastres regionais. Ao projetar arquiteturas para várias regiões, use, sempre que possível, a região emparelhada como região secundária. Durante a manutenção planejada da plataforma, somente uma região do par é atualizada por vez, reduzindo a interrupção simultânea.

Em implantações ativas-ativas, a solicitação de um usuário pode ser atendida por regiões diferentes em solicitações distintas. Se o aplicativo armazenar o estado da sessão na memória do servidor Web, isso causará problemas quando o usuário mudar de região. A solução é usar um armazenamento de sessão distribuído — como o Azure Cache for Redis com replicação geográfica — para que os dados da sessão possam ser acessados de qualquer região.

Uma arquitetura ativa-ativa é mais cara do que uma implantação em uma única região porque você executa uma cópia completa da infraestrutura em pelo menos duas regiões. Os custos adicionais incluem a transferência de dados entre regiões, a replicação geográfica de bancos de dados e as cobranças do Traffic Manager ou do Front Door. Faça uma análise de custo-benefício: para cargas de trabalho essenciais à missão, o custo do tempo de inatividade normalmente supera em muito o custo da segunda região.

Uma arquitetura ativa-ativa deve ser testada regularmente para garantir que funcione quando necessário. Ferramentas de engenharia do caos, como o Azure Chaos Studio, permitem injetar falhas — por exemplo, parar todas as máquinas virtuais em uma região — e observar como o sistema responde. Os testes regulares confirmam que as sondas de integridade do Traffic Manager detectam falhas, que o failover ocorre dentro do seu RTO e que os dados permanecem consistentes entre as regiões.

Teste sua compreensão dos conceitos do Microsoft Azure Fundamentals (AZ-900) apresentados nesta lição.

Nesta lição, você aprendeu que: a arquitetura ativa-ativa implanta recursos ativos em várias regiões simultaneamente para maximizar a disponibilidade; o Azure Traffic Manager encaminha o tráfego usando métodos de desempenho, prioridade, ponderado ou geográfico; e a replicação de dados (gravação em várias regiões do Cosmos DB e replicação geográfica do SQL) é essencial para manter a consistência entre regiões. A seguir, exploraremos sondas de integridade e padrões de degradação controlada.