Roblox out/2021: 73 h fora do ar por contenção no Consul

01 · CONTEXTO

Uma plataforma inteira apoiada em um registro de serviços

Entre 28 e 31 de outubro de 2021, a Roblox ficou fora do ar por 73 horas. A plataforma serve dezenas de milhões de jogadores por dia sobre centenas de serviços internos. O post-mortem oficial afirma que não houve perda de dados de usuários nem acesso não autorizado; a duração, e não o dano aos dados, é o que torna o caso um clássico de resposta a incidentes.

A infraestrutura é própria, com mais de 18 mil servidores e 170 mil contêineres. O Nomad agenda os contêineres, o Vault entrega segredos e o Consul faz service discovery, health checks, locks de sessão e ainda serve de KV store. Os serviços só se encontram entre si por meio desse registro.

O Consul roda como um cluster com 5 votantes e 5 não votantes. Os votantes guardam o estado autoritativo e os não votantes são réplicas de leitura. Um líder é eleito com o algoritmo Raft e é ele quem replica as escritas.

1. O tráfego dos jogadores chega pelo DNS e vai aos serviços de backend.

2. Cada serviço consulta o Consul para saber onde estão os serviços de que depende.

3. O agendador e o cofre de segredos também dependem do Consul, então ele fica no caminho de quase tudo.

4. Abaixo dos serviços ficam os caches e os bancos. Os bancos não foram afetados pela queda, mas o sistema de cache ficou doente.

02 · A INVESTIGAÇÃO

Três hipóteses razoáveis, três falhas

Em 28 de outubro à tarde, o Vault ficou lento e um único servidor Consul mostrava CPU alta, sem impacto aos jogadores. As métricas apontavam latência de escrita elevada no KV, e a primeira hipótese foi hardware degradado, com a troca de um nó. Mesmo com hardware novo o desempenho não voltou, e às 16:35 os jogadores online caíram a 50% do normal.

A razão da queda total é estrutural: sem um Consul saudável, os serviços não se localizam, o agendador não cria contêineres e o cofre não entrega segredos. O próprio post conclui que o Consul era um ponto único de falha. Nesse ponto entrou o raciocínio sobre disponibilidade de uma camada que todas as outras supõem estar de pé.

03 · A CAUSA RAIZ

Um recurso novo e um defeito de armazenamento

Ao olhar por dentro do Consul, em vez de olhar a partir dos serviços que dependem dele, a equipe viu escritas no KV bloqueadas por longos períodos: contenção.

Meses antes, a Roblox migrou do Consul 1.9 para o 1.10 para usar um recurso de streaming, desenhado para reduzir CPU e banda ao distribuir atualizações. Um dia antes da queda, em 27 de outubro às 14:00, o recurso foi ativado em um serviço de roteamento de tráfego, e o número de nós desse serviço subiu 50% para o pico de fim de ano.

1. O serviço de roteamento passa a assinar atualizações por streaming nos nós de leitura.

2. Ao mesmo tempo, os demais serviços escrevem health checks e dados no líder, numa carga alta de escrita.

3. Sob leitura e escrita muito altas, a contenção em um único canal bloqueia as escritas e o cluster perde eficiência.

4. Mesmo depois de desligar o streaming, alguns líderes seguiam lentos, e a equipe precisou impedir que eles permanecessem eleitos.

A análise da HashiCorp mostrou o efeito: o desenho do streaming concentra contenção em um único canal Go quando leitura e escrita estão ambas muito altas, e servidores de dois soquetes com memória NUMA pioram o problema, o que explica por que mais núcleos não ajudaram. O desligamento do streaming, propagado às 15:51 de 30 de outubro, trouxe a latência mediana das escritas a cerca de 300 ms.

O segundo problema ficou escondido por mais tempo. O Raft guarda seu log no BoltDB, que nunca devolve espaço ao disco depois de apagar entradas antigas, e sim reaproveita páginas livres rastreadas por uma freelist. Na carga da Roblox, um log de 4,2 GB guardava só 489 MB de dados reais, e uma freelist de 7,8 MB era regravada a cada append, mesmo para escritas de 16 kB ou menos.

04 · RECUPERAÇÃO

Sem visibilidade e sem partida a frio

A causa levou tempo para aparecer também porque o monitoramento dependia do que estava quebrado. Sistemas críticos de monitoramento dependiam de sistemas afetados, como o Consul, e havia uma dependência circular entre a telemetria e o registro.

1. Em operação normal, os serviços enviam métricas à telemetria.

2. A telemetria descobre o que coletar consultando o mesmo Consul.

3. Com o Consul doente, a telemetria perde a visão exatamente quando a equipe mais precisa dela.

Com o Consul estável depois de 54 horas, restava reconstruir o cache. O cache atendia cerca de 1 bilhão de requisições por segundo e, por guardar dados transitórios, a saída mais simples era reimplantá-lo. Os dados de agendamento do cache no KV estavam incorretos, provavelmente por causa do reset por snapshot, e um nó doente aparecia ao agendador como livre e recebia jobs que falhavam. A ferramenta de implantação servia a ajustes incrementais, não à subida de um cluster grande do zero.

Às 05:00 de 31 de outubro, 61 horas após o início, Consul e cache estavam saudáveis. Com caches frios, a Roblox usou DNS steering para limitar quantos jogadores entravam, subindo o acesso em degraus de cerca de 10% e conferindo carga do banco, desempenho do cache e estabilidade a cada degrau. Às 16:45 de domingo, 73 horas após o início, todos os jogadores tinham acesso.

1. Os jogadores voltam a tentar entrar e o DNS decide quem passa.

2. Uma fração sorteada vai aos serviços e o restante fica na página de manutenção.

3. Com os caches vazios, as leituras caem no banco até os caches se aquecerem.

4. A equipe confere as métricas antes de subir a fração para o degrau seguinte.

05 · LIÇÕES

O que mudou e o que o caso ensina

Os pontos de falha estavam em como a plataforma dependia de um único cluster Consul para vários workloads. A Roblox construiu um datacenter adicional e passou a migrar para várias zonas, separou serviços críticos em clusters dedicados, começou a tirar dados do KV para um armazenamento mais apropriado, removeu a dependência circular da telemetria e adicionou alertas direcionados a Consul e BoltDB. Uma parte do plano de recuperação de desastres passou a ser a subida de caches do zero.