Padrões Multi-AZ para serviços com estado

Serviços com estado — bancos de dados, caches e sistemas de arquivos — são os componentes mais difíceis de tornar altamente disponíveis, pois armazenam dados que precisam sobreviver às falhas. Se um banco de dados em uma única AZ falhar, todo o aplicativo perderá seu armazenamento de dados. A resposta da AWS são as implantações Multi-AZ, nas quais o serviço mantém uma réplica síncrona ou quase síncrona em uma segunda Availability Zone, que pode assumir o controle rapidamente quando o primário falha.

O RDS Multi-AZ mantém uma réplica em espera síncrona em uma AZ diferente. Cada gravação no primário é replicada de forma síncrona antes da confirmação de sucesso — isso significa perda zero de dados (RPO=0), mas aumenta ligeiramente a latência de gravação. Quando o primário falha, o RDS atualiza automaticamente o endpoint DNS para apontar para a instância em espera em 60 a 120 segundos. Seu aplicativo só precisa se reconectar ao mesmo endpoint — nenhuma alteração no código é necessária.

Aurora da Amazon leva o Multi-AZ além, com uma camada de armazenamento distribuído compartilhado que replica automaticamente os dados entre três AZs, em seis cópias. As instâncias do Aurora não mantêm estado — elas leem e gravam nesse armazenamento compartilhado. Quando o gravador Aurora PRIMARY falha, uma réplica de leitura em outra AZ é promovida a gravador em menos de 30 segundos. Isso é mais rápido do que o failover do RDS Multi-AZ, e os dados permanecem sempre consistentes entre as AZs, sem a necessidade de replicação explícita para uma instância Standby.

O ElastiCache para Redis oferece suporte a Multi-AZ por meio de grupos de replicação. Um nó PRIMARY aceita gravações e as replica de forma assíncrona para réplicas de leitura em outras AZs. Quando o nó PRIMARY falha, o ElastiCache promove automaticamente uma réplica a PRIMARY. No Redis com o modo de cluster habilitado, os dados são particionados entre vários grupos de nós, cada um com seu próprio nó PRIMARY e suas réplicas distribuídas entre as AZs — isso oferece HA e escalabilidade horizontal.

O sistema de arquivos elástico da Amazon (EFS) é inerentemente Multi-AZ — trata-se de um serviço regional que armazena os dados de forma redundante em várias AZs dentro de uma região. Você cria destinos de montagem na sub-rede de cada AZ, e as instâncias EC2 em qualquer AZ podem montar o sistema de arquivos por meio do destino de montagem local. Não é necessária nenhuma configuração manual de Multi-AZ. O EFS oferece armazenamento compartilhado de arquivos POSIX, acessado simultaneamente por várias instâncias em diferentes AZs.

Os balanceadores de carga elásticos também são Multi-AZ — o ALB e o NLB implantam nós de balanceador de carga em cada AZ especificada. Com o balanceamento de carga entre zonas habilitado (o padrão do ALB), cada nó do balanceador distribui o tráfego uniformemente entre todos os destinos registrados em todas as AZs, e não apenas na própria AZ. Isso garante que, mesmo que todas as instâncias de uma AZ falhem, o balanceador continue atendendo ao tráfego por meio das instâncias nas AZs restantes.

Um erro comum é implantar um único NAT Gateway em uma AZ enquanto as sub-redes privadas de outras AZs roteiam o tráfego por ele. Se essa AZ falhar, todas as instâncias privadas perderão o acesso à Internet. O padrão Multi-AZ correto é implantar um NAT Gateway por AZ e configurar a tabela de rotas privada de cada AZ para encaminhar 0.0.0.0/0 por meio de seu próprio NAT Gateway. Isso elimina o NAT Gateway como SPOF entre AZs e reduz os custos de transferência de dados entre AZs.

O DynamoDB é um serviço totalmente gerenciado que replica automaticamente os dados entre três AZs dentro de uma região — você não configura o Multi-AZ manualmente. Cada gravação é armazenada de forma durável nas três AZs antes que o sucesso seja retornado. O DynamoDB é tolerante a falhas no nível de AZ por padrão. Por isso, o DynamoDB costuma ser a opção de banco de dados recomendada quando a questão do exame enfatiza alta disponibilidade com o mínimo de sobrecarga operacional.

Durante um failover do RDS Multi-AZ, aplicações que mantêm conexões persistentes com o banco de dados podem apresentar falhas quando o endpoint muda. O RDS Proxy fica entre sua aplicação e o RDS, mantendo um conjunto de conexões com o banco de dados. Durante o failover, o RDS Proxy redireciona automaticamente as conexões para o novo PRIMARY — reduzindo o impacto do failover de 60–120 segundos para menos de 30 segundos nas aplicações que usam o endpoint do proxy. O RDS Proxy também ajuda nas funções Lambda que criam muitas conexões de curta duração.

Entender os modos de replicação é fundamental para escolher padrões Multi-AZ. A replicação síncrona (RDS Multi-AZ, EFS) garante RPO=0, pois cada gravação é confirmada nas duas AZs antes do retorno de sucesso. A desvantagem é uma latência de gravação um pouco maior. A replicação assíncrona (réplicas do ElastiCache Redis, RDS Read Replicas) oferece menor latência de gravação, mas aceita um pequeno atraso de replicação — o que significa que alguns dados podem ser perdidos se o PRIMARY falhar antes que a replicação seja concluída.

O senhor deve testar regularmente o failover Multi-AZ para validar suas premissas de RTO. No RDS, é possível acionar um failover usando a opção Reinicializar com failover do console ou a CLI. Monitore o CloudWatch em busca da métrica FailedSQLServerAgentJobsCount e observe os registros da aplicação para verificar se ela se reconecta com sucesso. Documente a duração real do failover — ela pode ser diferente da indicada na documentação da AWS, dependendo da classe da instância e da carga de trabalho.

Teste sua compreensão dos conceitos do AWS Solutions Architect (SAA-C03) apresentados nesta lição.

Nesta lição, o senhor aprendeu que: o RDS Multi-AZ usa replicação síncrona com failover automático de DNS, o Aurora usa uma camada de armazenamento compartilhado entre três AZs para realizar failover mais rapidamente, e o EFS e o DynamoDB são inerentemente Multi-AZ, sem configuração manual. Implante um NAT Gateway por AZ para evitar SPOFs entre AZs. A seguir, exploraremos padrões multi-região ativo-ativo e ativo-passivo.