Multi-AZ e arquiteturas tolerantes a falhas

Tudo no tópico anterior partia do princípio de que a infraestrutura fica onde você colocou. Escalar uma frota, adicionar readers, aquecer um cache: nada disso ajuda se o prédio onde as instâncias moram perder energia. A skill 2.2 do exam guide é sobre esse princípio, e ela começa pela menor unidade de falha que a AWS batizou com um nome.

Uma Availability Zone é um lugar de verdade

Uma Availability Zone é um ou mais data centers separados dentro de uma Região, com energia, refrigeração, rede e conectividade física próprias. Não é uma partição lógica nem um rótulo de rack. A AWS opera mais de 100 delas pelo mundo.

Dois números definem como as AZs se comportam, e os dois são decisão de projeto, não acaso:

• Até cerca de 100 km de distância. Longe o bastante para uma enchente, um incêndio, um tornado, uma queda da concessionária ou um rompimento de fibra dificilmente atingirem duas ao mesmo tempo. AZs não compartilham geradores, equipamento de refrigeração nem subestações, e a AWS escalona as próprias implantações de serviço entre as AZs de uma Região para um rollout ruim não cair em todo lugar de uma vez.
• Latência de milissegundos de um dígito entre elas. Perto o bastante para você replicar uma escrita de banco de forma síncrona para outra zona e ainda commitar rápido o suficiente para uma carga OLTP.

Esse par é a razão inteira de o Multi-AZ funcionar. Se as AZs estivessem a 5 km, uma tempestade regional derrubaria várias juntas. Se estivessem a 1.000 km, a replicação síncrona somaria dezenas de milissegundos a cada commit e ninguém ligaria isso. A distância foi escolhida para a redundância entre zonas ser ao mesmo tempo significativa e viável.

O nome de uma AZ também é por conta. us-east-1a na sua conta e us-east-1a na conta de um colega normalmente são zonas físicas diferentes, porque a AWS embaralha o mapeamento para distribuir carga. O identificador estável é o AZ ID (use1-az1), que é o que você compara quando compartilha subnets entre contas com o AWS RAM.

Zonal, regional, global: a classificação que decide tudo

Aqui está a confusão que causa a maior parte das indisponibilidades surpresa: "a AWS é altamente disponível, então minha carga é altamente disponível." A AWS roda os serviços dela em várias AZs. Isso não quer dizer que os recursos específicos que você criou morem em mais de uma.

Todo recurso da AWS fica em exatamente um de três escopos, e o escopo diz o que uma falha de AZ faz com ele.

Leia essa tabela como checklist operacional, não como curiosidade. Todo recurso zonal na sua arquitetura é uma pergunta: o que acontece quando a AZ dele desaparecer? Um serviço regional já respondeu essa pergunta por você. Um zonal, não.

Duas linhas merecem atenção extra porque pegam bastante gente:

• Um volume EBS é zonal, mas o snapshot dele é regional. Você não anexa um volume de us-east-1a a uma instância em us-east-1b. Mas cria um volume novo em us-east-1b a partir do snapshot daquele volume, porque o dado do snapshot é replicado por todas as AZs da Região. Essa assimetria é como se move block storage entre zonas, e é detalhe predileto de prova.
• Um load balancer é regional, mas os nodes dele são zonais. Você habilita um ALB ou NLB em subnets específicas, e a AWS coloca um node de load balancer em cada uma dessas AZs. Habilite em uma AZ só e você construiu uma dependência de zona única com nome de coisa regional. Um ALB exige subnets em pelo menos 2 AZs exatamente por isso.

Fazer a camada de computação sobreviver: roteamento não é capacidade

Coloque um Auto Scaling group em três AZs atrás de um ALB e você resolveu o problema de roteamento. Quando uma zona cai, o ALB para de mandar requisição para os targets não saudáveis, e o ASG marca aquelas instâncias como não saudáveis e repõe. Essa parte é automática.

O que não é automático é ter para onde o tráfego ir. Faça a conta.

Você roda 6 instâncias em 3 AZs, 2 por zona, e cada instância absorve 20 por cento do pico. No pico você tem 6 x 20 = 120 por cento do que precisa, o que parece uma folga confortável. Agora a AZ-B cai:

Instâncias sobreviventes: 4
Capacidade:               4 x 20% = 80% do pico
Déficit:                  20% do pico, até as substitutas subirem e passarem no health check

Por vários minutos você está derrubando ou atrasando uma requisição a cada cinco. O load balancer fez o trabalho dele perfeitamente e o site continua degradado.

A regra geral é dimensionar para a perda de uma AZ inteira, o que as pessoas escrevem como AZ+1:

Essa é a razão concreta de a AWS recomendar três AZs em vez de duas. Duas zonas fazem a redundância custar o dobro; três fazem custar metade a mais.

O princípio por trás da tabela é a estabilidade estática: o sistema deve continuar funcionando corretamente sem precisar mudar nada quando a falha acontece. Subir instâncias de reposição durante um evento de AZ é uma operação de control plane, e control planes têm metas de disponibilidade mais baixas que data planes, justamente porque fazem um trabalho mais complexo. Pior: uma falha de AZ é exatamente o momento em que todos os outros clientes daquela Região também estão pedindo capacidade. Um desenho que precisa escalar para sobreviver amarrou a própria recuperação ao minuto mais movimentado da vida do control plane. Um desenho estaticamente estável já tem a capacidade rodando.

Duas configurações decidem quão uniforme a carga cai:

• Cross-zone load balancing deixa um node de load balancer de uma AZ mandar tráfego para targets de todas as AZs, e não só da dele. Vem ligado por padrão no ALB (e dá para desligar por target group) e desligado por padrão no NLB. Com ele desligado e contagem de targets desigual por zona, uma AZ com 2 targets recebe a mesma fatia de tráfego de uma AZ com 8, e cada um daqueles 2 trabalha quatro vezes mais.
• Health checks do ELB contra health checks do ASG. Por padrão, um Auto Scaling group só olha os status checks do EC2, que dizem que a instância está ligada, não que a sua aplicação responde. Ligue os health checks do ELB no ASG para que um target reprovado no check HTTP do load balancer seja reposto em vez de ficar ali devolvendo erro.

A camada de dados: três formas de sobreviver a uma zona

Computação é descartável. Dado não é, então a camada de banco ganha uma resposta própria, e o RDS oferece três formatos com propriedades bem diferentes.

O deployment Multi-AZ DB instance é o clássico e o mais cobrado. O RDS mantém um standby em uma segunda AZ, replica todo commit para ele de forma síncrona e, na falha, vira o CNAME do DNS por trás do seu endpoint para o standby promovido. Sua aplicação mantém a mesma connection string e só precisa reconectar. Duas consequências saem de "síncrona":

• A latência de escrita e de commit sobe em relação ao Single-AZ, porque todo commit espera a segunda zona. Esse é o preço da durabilidade que você comprou.
• O standby não é um servidor reserva que você possa usar. Ele não aceita conexão. Se um cenário pede alívio de leitura, a resposta é read replica ou Multi-AZ DB cluster, nunca o standby.

O Aurora segue outro caminho: o próprio volume do cluster cobre três AZs e guarda seis cópias dos seus dados, então replicação entre instâncias nem existe. Perder uma AZ tira algumas instâncias, mas não o storage, que é por que um reader do Aurora sobe tão rápido.

As dependências de AZ única que ficam para trás

Mesmo uma arquitetura multi-AZ cuidadosa costuma ter alguns gargalos zonais. Estes valem uma auditoria:

• NAT gateway. Criado em uma subnet, logo em uma AZ. Passe toda subnet privada por um único NAT gateway e a falha de uma zona corta a saída para a internet da VPC inteira. Suba um por AZ e dê a cada subnet privada uma route table apontando para o gateway da própria zona. Isso também elimina cobrança de transferência entre AZs, então o desenho resiliente costuma ser o mais barato.
• EFS One Zone. Classe de armazenamento mais barata, e o nome é o aviso. O EFS Standard replica entre AZs; o One Zone, não.
• Volumes de instance store. Presos fisicamente ao host. Não são só zonais, são do tempo de vida da instância. Parar a instância perde o dado.
• Uma instância RDS Single-AZ com uma read replica em outra AZ. No diagrama parece Multi-AZ, mas a replica é assíncrona e a promoção é uma operação manual de minutos. É plano de recuperação, não mecanismo de failover.
• Um load balancer habilitado em uma subnet só. Já visto acima, e fácil de criar sem querer num ambiente de teste que depois vira produção.

O que o Multi-AZ não faz

O Multi-AZ protege contra falha de infraestrutura dentro de uma zona. Essa é uma promessa específica e limitada. Ele não faz nada sobre:

• Corrupção lógica. Um DELETE sem WHERE replica de forma síncrona para o standby em milissegundos. As duas cópias ficam igualmente erradas. Recuperar significa point-in-time recovery ou um snapshot.
• Exclusão acidental. Apagar a instância do banco apaga o standby junto.
• Eventos que atingem a Região inteira. Toda AZ da tabela acima mora em uma Região. Sobreviver à perda de uma Região é outra arquitetura, e a última lição deste tópico cobre as quatro formas de construí-la.
• Um deploy ruim. Código novo que devolve HTTP 500 devolve igualzinho nas três zonas.

A forma mais limpa de guardar a fronteira: Multi-AZ é alta disponibilidade e protege contra coisas quebrando. Backups e replicação entre Regiões são recuperação de desastres e protegem contra coisas estarem erradas. A prova separa os dois de forma consistente, e o seu desenho também deveria.

Dicas para a prova

• As expressões "sobreviver à falha de uma Availability Zone", "alta disponibilidade" e "failover automático" apontam para Multi-AZ. As expressões "exclusão acidental", "corrupção de dados", "restaurar para um ponto no tempo" e "indisponibilidade de Região" apontam para backups ou uma estratégia de DR, e aí Multi-AZ é a resposta errada mesmo soando protetor.
• Qualquer alternativa que leia do standby de um Multi-AZ DB instance está errada. Ela existe para ser rejeitada. Alívio de leitura é read replica ou Multi-AZ DB cluster.
• Números para carregar: failover do Multi-AZ DB instance de 60 a 120 segundos, failover do Multi-AZ DB cluster normalmente abaixo de 35 segundos, storage do Aurora com 6 cópias em 3 AZs, ALB exigindo pelo menos 2 AZs.
• Quando o enunciado descreve uma queda que afetou tudo apesar de várias AZs, procure uma dependência zonal compartilhada. Um NAT gateway único é a clássica; um load balancer em uma subnet só é a outra.
• Cross-zone load balancing: ligado por padrão no ALB, desligado por padrão no NLB. Contagem desigual de targets por AZ mais cross-zone desligado dá carga desigual.
• Se a questão pergunta quanta capacidade rodar em cada AZ, a resposta pretendida é o suficiente para as zonas restantes carregarem a carga inteira sem escalar. Isso é estabilidade estática, e a justificativa dela é que Auto Scaling é operação de control plane.

A regra de decisão para levar: para cada recurso da sua arquitetura, diga o escopo dele. Recurso zonal precisa de um irmão em outra zona e de algo que contorne a falha; recurso regional já resolveu isso. Tudo nesta lição mantém uma carga no ar durante falha de infraestrutura, e nada disso ajuda quando o próprio dado está errado. É para isso que serve a próxima lição, e ela começa pelo mecanismo por baixo de todo backup da AWS: o snapshot.