Servir dados a partir de vários data centers

01 · CONTEXTO

Por que sair de um datacenter só

Servir dados a partir de vários datacenters tem nome: multihoming, operar a partir de vários datacenters ao mesmo tempo. O desafio aparece na lista de perguntas adicionais de entrevista do System Design Primer e é um tema de arquitetura multi-região.

Há duas razões para fazer isso. A primeira é a falha: datacenters falham por vários motivos. A segunda é o desempenho: a geolocalidade permite aproximar as operações do usuário, e estar mais perto só é possível se os dados também estão perto dele.

O resumo da palestra que serve de fonte lembra que operar em um único datacenter é fácil, e que o difícil é aceitar escritas em mais de um lugar.

1. O ponto de partida: usuários, um balanceador, o serviço e o banco, todos no mesmo datacenter.

2. Essa é a opção mais fácil de operar.

02 · LEVAR O USUÁRIO ATÉ O DATACENTER

DNS, latência e geolocalização

A primeira decisão é como cada usuário chega a um datacenter. O DNS traduz um nome de domínio em um endereço IP, e alguns serviços de DNS conseguem rotear o tráfego por vários métodos, entre eles a latência e a geolocalização.

No roteamento por latência, o serviço de DNS descobre qual região dá a menor latência ao usuário e responde com o valor do registro dela. A própria documentação avisa que a latência real pode variar bastante dos dados da AWS quando os recursos não estão numa região da AWS.

No roteamento por geolocalização, a escolha do recurso vem de onde o usuário está. Isso funciona mapeando endereços IP a localizações, e é possível criar um registro padrão para os IPs que não têm mapeamento.

1. O usuário pergunta ao DNS pelo nome do serviço e recebe um endereço IP.

2. Com roteamento por latência, o DNS escolhe a região de menor latência para aquele usuário e responde com o endereço dela.

3. Com roteamento por geolocalização, a escolha parte de onde o usuário está.

4. Com o endereço em mãos, o usuário fala com o balanceador da região indicada, que repassa a um serviço.

Uma CDN faz algo parecido para conteúdo: serve de locais mais próximos do usuário.

03 · OS DADOS ENTRE DATACENTERS

As opções de replicação e o que cada uma custa

Levar o usuário até um datacenter é a parte fácil. Difícil é decidir o que acontece com os dados. O resumo da palestra lista as opções de multihoming: backups, mestre e réplica, multi-master, commit em duas fases (2PC) e Paxos. Para compará-las, vale olhar a consistência: na forte, qualquer leitura depois de uma escrita devolve o que foi escrito; na eventual, você acaba vendo o que escreveu, mas não de imediato.

No mestre único, um datacenter mestre recebe as escritas e os demais replicam dele. A replicação costuma ser assíncrona, o que traz risco de perda de dados se o mestre falhar antes de as escritas novas chegarem aos outros nós.

1. O datacenter A tem o banco mestre; o B tem uma réplica que recebe cópias dele.

2. A replicação costuma ser assíncrona, e há risco de perda de dados se o mestre falhar antes de as escritas novas chegarem à réplica.

3. A geolocalização serve as leituras perto do usuário, mas as escritas continuam limitadas a um datacenter.

4. Se o mestre sai do ar, o failover pode ficar só leitura até o mestre ser movido para outro datacenter.

No multi-master, todos os datacenters servem leituras e escritas. Em troca, é preciso mesclar as escritas depois, e o melhor que se obtém é consistência eventual. Para mesclar, é preciso impor uma ordem a todas as escritas, e não há relógio global.

1. Os dois bancos aceitam leituras e escritas locais.

2. As escritas de um lado são enviadas ao outro e mescladas depois; o melhor resultado possível é consistência eventual.

3. Mesclar exige impor uma ordem a todas as escritas, e não há relógio global.

4. Se um datacenter sai do ar, o failover é fácil porque o outro já aceita escritas.

Em sistemas multi-master, a resolução de conflitos pesa mais conforme se adicionam nós de escrita e a latência cresce, e a maioria é fracamente consistente ou tem latência de escrita maior por causa da sincronização. O resumo ainda diz que usar mais de dois datacenters é fundamentalmente mais difícil.

No commit em duas fases, grava-se em todos os datacenters ou em nenhum, com consistência forte e transações. O preço é que as transações passam serializadas por um coordenador. O Paxos é totalmente distribuído, ao contrário do commit em duas fases, e basta a maioria dos nós concordar para considerar um dado persistido; mesmo assim, as escritas têm latência alta pelas rodadas extras de coordenação.

04 · UMA DECISÃO REAL

O que o Google App Engine escolheu, segundo a palestra

O resumo de que partimos descreve uma palestra de Ryan Barrett, líder do datastore do Google App Engine, na conferência Google I/O de 2009. Os números abaixo são os do resumo, da época, e não valores atuais.

A meta central era um modelo de consistência forte para quem programa. Além disso, o App Engine queria sobreviver a falhas de datacenter e ter desempenho de escrita não muito distante do de um banco relacional típico.

Com essas metas, o 2PC nunca foi considerado a sério porque a vazão de escrita era muito importante; as escritas poderiam ficar na casa dos duzentos milissegundos. O Paxos também ficou de fora: o resumo diz que não queriam pagar o custo de cerca de cento e cinquenta milissegundos nas escritas.

A escolha foi mestre e réplica entre datacenters: multihoming de verdade adiciona latência pelo salto extra entre datacenters, e mestre e réplica dá a maior parte dos benefícios das formas melhores, mantendo escritas de menor latência. Na época, o datastore usava esse mecanismo, com escritas entre trinta e quarenta milissegundos.

05 · NA ENTREVISTA

Como organizar a resposta

Uma resposta forte separa três perguntas. Primeiro, como o usuário chega a um datacenter, o que é uma decisão de roteamento. Segundo, onde as escritas são aceitas, o que define a consistência possível. Terceiro, o que acontece quando um datacenter cai, o que mostra o custo real da escolha anterior.

Quem escolhe mestre e réplica deve falar da janela de perda de dados e do modo só leitura no failover. Quem escolhe multi-master deve falar de como as escritas conflitantes são ordenadas e mescladas. Quem escolhe consenso ou commit em duas fases deve falar do preço em latência.