Regiões e zonas de disponibilidade

O data center que nunca falha não existe

Imagine os servidores de uma loja online rodando dentro de um único prédio. Esse prédio perde energia bem no dia da maior liquidação do ano, e todos os servidores apagam ao mesmo tempo. Não importa quão bom seja o código nem quanto tráfego os servidores aguentariam em outra situação: a loja fica fora do ar até alguém restaurar a energia naquele único lugar. Os provedores de nuvem enfrentam exatamente a mesma física desse prédio. Um único data center ainda pode pegar fogo, alagar ou perder energia, não importa o logo na porta. O que os provedores construíram foi uma estrutura que impede que o azar de um local vire o azar de todo mundo: regiões e zonas de disponibilidade.

Regiões: onde no mundo seus recursos vivem

Uma região é uma área geográfica separada, como US East (N. Virginia) ou Europe (Ireland). Quando você cria uma máquina virtual ou um bucket de armazenamento, você escolhe uma região, e essa escolha decide em que país ou continente os seus dados ficam fisicamente e quanto tempo o tráfego de rede leva até chegar aos seus usuários. A AWS opera hoje 39 regiões geográficas no mundo, cada uma isolada das demais, para que uma falha em uma não tenha como alcançar as outras.

Regiões existem por 2 motivos práticos: latência e legislação. Um usuário em São Paulo recebe respostas mais rápidas de uma região no Brasil do que de uma na Virgínia, e alguns setores e governos exigem que certos dados nunca saiam das fronteiras de um país específico. Escolher a região é normalmente a primeira decisão de infraestrutura em qualquer plataforma de nuvem, e ela costuma ser guiada por essas 2 restrições.

Zonas de disponibilidade: isolamento dentro da região

Uma região sozinha não protege nada, ela é só um local. A proteção vem um nível abaixo, dentro da região, onde os provedores dividem várias zonas de disponibilidade. Cada zona é formada por 1 ou mais data centers distintos, cada um com sua própria energia redundante, resfriamento e segurança física, instalados em prédios fisicamente separados dos outros zonas da mesma região. A AWS garante no mínimo 3 zonas por região, hoje somando 123 zonas de disponibilidade no total. As zonas ficam perto o bastante umas das outras, geralmente dentro de 100 km, para que uma conexão de fibra dedicada, de baixa latência e alta largura de banda, mantenha o tráfego entre elas rápido.

A AWS nomeia as zonas a partir da região: us-east-2a, us-east-2b e us-east-2c são as 3 zonas da região us-east-2. Essa letra final é a única coisa que muda: tudo antes dela identifica a região, e a letra escolhe a zona específica.

Exemplo prático: 1 zona versus 3

Imagine um varejista rodando o serviço de checkout em 6 máquinas virtuais. Coloque as 6 numa única zona, e uma falha de energia naquele data center derruba todas ao mesmo tempo, exatamente como o prédio único da cena inicial. Distribua essas mesmas 6 máquinas entre 3 zonas, 2 por zona, e o cenário muda por completo: se 1 zona perde energia, as outras 4 máquinas nas 2 zonas restantes continuam atendendo os pedidos de checkout. A zona que falhou fica fora do ar, mas o serviço de checkout, como um todo, não fica.

Nada no código mudou entre esses 2 cenários. A única diferença é onde as 6 máquinas ficam fisicamente, e essa é justamente a razão de existir das zonas de disponibilidade: não como uma funcionalidade que você programa, mas como uma decisão que você toma na hora de implantar.

A armadilha: multi-AZ não é multi-região

É tentador tratar "distribuído entre zonas de disponibilidade" e "protegido contra qualquer interrupção" como a mesma coisa. Não são. Multi-AZ protege você de uma falha local a 1 data center: energia, resfriamento, incêndio, enchente. Isso não ajuda em nada contra um evento que afete uma área geográfica inteira de uma vez, como um desastre natural de grande escala ou uma falha de rede regional. Sobreviver a isso exige rodar em mais de 1 região, replicando dados e tráfego por uma distância bem maior, um compromisso de custo e complexidade acima de multi-AZ. A maioria das aplicações só precisa de multi-AZ. Multi-região é para cargas em que perder uma área geográfica inteira, por qualquer período, não é aceitável.

Como os 3 principais provedores se comparam

O conceito é universal, mesmo que o vocabulário mude um pouco entre provedores.

Vale conhecer uma diferença estrutural: se uma região inteira da Azure sofre uma falha, todas as zonas de disponibilidade dentro dela podem ser afetadas, porque a Azure constrói uma região a partir de suas zonas. AWS e Google Cloud desenham as regiões para serem isoladas entre si, então uma falha específica de 1 região não deveria se espalhar para outra região. É um detalhe de arquitetura, não algo que muda o seu dia a dia com multi-AZ, mas explica por que "quais regiões usar" às vezes também é uma decisão de disponibilidade, não só de latência.

Onde isso deixa você

Uma região escolhe onde os seus recursos vivem; as zonas de disponibilidade dentro dela são o que de fato protege você do azar de um único data center. Implante em pelo menos 2, de preferência 3, zonas sempre que uma aplicação precisar ficar no ar, e recorra a várias regiões só quando perder uma área geográfica inteira for um risco inaceitável. Agora que você sabe como os provedores organizam o mapa físico por trás da nuvem, a próxima lição cobre o que você realmente aluga dentro desse mapa: computação.