YouTube: escalando MySQL com Vitess

01 · CONTEXTO

Um MySQL que precisava crescer

O YouTube guardava no MySQL metadados como usuários, tags e descrições. O Vitess foi criado em 2010 para resolver os problemas de escala do MySQL enfrentados pela equipe do YouTube, e este caso conta a trajetória que levou até ele.

A evolução seguiu um caminho comum: um servidor único, depois um primário com várias réplicas de leitura, depois particionamento e, por fim, sharding dos dados.

02 · RÉPLICAS

Primeiro, escalar a leitura

Para aliviar o banco, o YouTube criou um primário para as escritas e uma réplica para as leituras. Como a leitura continuou a sobrecarregar a réplica, acrescentou mais réplicas, o que serviu como solução temporária.

1. O banco passa a ter um primário que recebe as escritas e réplicas que atendem as leituras.

2. Quando a leitura ainda sobrecarrega a réplica, o remédio é acrescentar mais réplicas.

3. Como a replicação é assíncrona e as réplicas rodam em máquinas mais fracas, elas podem ficar bem atrás do primário.

4. As escritas continuam todas no primário; quando passam do que ele aguenta, resta dividir os dados em shards.

Réplicas têm custo. Atualizações causam falhas de cache que vão ao disco, e o I/O lento deixa a replicação lenta; além disso, a fonte diz que, numa arquitetura de replicação, ganhos incrementais de escrita custam muito dinheiro.

Uma das soluções foi priorizar o tráfego dividindo os dados em dois clusters: um para assistir vídeos e outro geral.

03 · SHARDING NA APLICAÇÃO

Quando a escrita passa do limite

Por fim, a escrita passou do que o primário aguentava e o YouTube precisou fazer sharding dos dados. A camada de aplicação foi alterada para que, antes de qualquer operação no banco, o código identificasse o shard certo para a consulta.

1. Antes de cada operação, o código da aplicação identifica o shard certo para a consulta.

2. A consulta segue direto ao shard escolhido, que guarda só a parte dos usuários atribuída a ele.

3. Outro usuário pode estar no outro shard, e assim escritas e leituras se espalham entre os shards.

O High Scalability relata os efeitos do particionamento: melhor localidade de cache e menos I/O, uma redução de 30% do hardware e atraso de réplica reduzido a 0.

O custo desse desenho aparece na documentação do Vitess: o MySQL não tem sharding nativo, o que obriga a escrever o código de sharding e embuti-lo na aplicação.

04 · VITESS

Um proxy no meio do caminho

O Vitess tirou essa lógica do código da aplicação: um proxy entre a aplicação e o banco passou a rotear e gerenciar as interações. Segundo a documentação, desde então o YouTube escalou sua base de usuários por um fator de mais de 50, e o Vitess serviu todo o tráfego de banco do YouTube por mais de cinco anos.

Em termos gerais, o Vitess é um sistema de cluster de banco de dados de código aberto para escalar MySQL horizontalmente; o VTGate é o proxy que aceita conexões do protocolo MySQL e roteia as consultas aos shards apropriados.

1. A aplicação conecta ao VTGate como se ele fosse um servidor MySQL comum.

2. O VTGate roteia cada consulta ao tablet certo, levando em conta o esquema de sharding, a latência e a disponibilidade.

3. Cada VTTablet fica ao lado de uma instância MySQL e cuida das consultas, das conexões e da replicação dela.

4. O Topology Service mantém o estado do cluster e permite descobrir onde estão os tablets.

5. Em regime estável, nenhuma chamada ao serviço de topologia fica no caminho crítico de uma consulta.

Para a aplicação, um keyspace aparece como um único banco, mesmo quando mapeia vários bancos MySQL. Um shard é um subconjunto do keyspace e costuma ter um primário MySQL e possivelmente várias réplicas.

O Vitess ainda protege e opera o banco: reescreve consultas que podem prejudicar o desempenho e ajuda a gerenciar o ciclo de vida dos servidores, incluindo a detecção e a recuperação de falha do primário.

05 · TRADE-OFFS

O que muda com shards

Sharding traz custos de consistência, segundo a documentação do Vitess: leituras entre shards podem não ser consistentes entre si, e transações em um único shard continuam ACID. No modo de melhor esforço, transações entre shards podem falhar no meio e deixar commits parciais; o modo 2PC aumenta o custo de escrita em cerca de 50%.

Leituras que toleram dados um pouco atrasados devem ir a réplicas. O VTGate pode ser configurado para não servir dados de instâncias com atraso acima de um limite.