Roblox 2021: 73 Horas de Indisponibilidade, Consul e o Efeito de Carga

O Roblox opera uma infraestrutura massiva e predominantemente on-premise. Ao contrário da maioria das plataformas de escala similar que migraram para cloud pública, o Roblox mantém datacenters próprios e colocados, o que significa que toda a camada de service discovery, orquestração e coordenação distribuída é de responsabilidade interna. No centro dessa infraestrutura está o HashiCorp Consul — usado tanto para service discovery quanto para health checking de milhares de serviços.

Nos dias que antecederam o incidente, a equipe de infraestrutura do Roblox ativou um novo recurso do Consul: o streaming de telemetria, projetado para reduzir a carga de polling nos agentes e servidores do Consul substituindo o modelo pull por um modelo push baseado em streaming. A intenção era boa — reduzir overhead. O timing foi fatal.

O contexto de tráfego importa aqui. O final de outubro coincide com o Halloween, um dos picos sazonais mais significativos para o Roblox. A plataforma estava processando um volume de sessões e eventos substancialmente acima da média. Mais sessões significam mais registros de serviço, mais health checks, mais operações de leitura e escrita no estado distribuído mantido pelo Consul.

O Consul, em sua configuração padrão de produção para clusters grandes, usa o BoltDB como backend de storage para o estado Raft. O BoltDB é um banco de dados key-value embutido, escrito em Go, com uma característica arquitetural fundamental: ele usa um modelo de single writer, multiple readers com locking explícito. Writes adquirem um lock exclusivo sobre o arquivo de banco de dados inteiro. Isso funciona bem sob cargas normais, mas sob contenção elevada — muitas escritas concorrentes ou escritas longas bloqueando leituras — o throughput degrada de forma não-linear.

O streaming de telemetria, ao ser ativado, aumentou significativamente o volume de operações de escrita no BoltDB. Combinado com o tráfego elevado de Halloween gerando mais eventos de health check e registro de serviço, o cluster Consul começou a experimentar latências crescentes nas operações Raft. Latências altas no Raft significam que os health checks começam a falhar por timeout. Health checks falhando fazem com que serviços sejam marcados como unhealthy. Serviços marcados como unhealthy são removidos do DNS do Consul. E aí o efeito cascata se torna irreversível sem intervenção manual.

Uma pergunta legítima é: por que um cluster Consul não pode simplesmente ser reiniciado? A resposta revela a complexidade real de operar infraestrutura de coordenação distribuída em escala.

Primeiro, o estado do Consul é o estado da plataforma. Milhares de serviços dependem do Consul para saber onde estão seus peers, quais instâncias estão saudáveis e como rotear tráfego. Um restart abrupto do cluster sem um plano de recuperação de estado pode resultar em uma situação ainda pior: serviços tentando se registrar simultaneamente, gerando uma tempestade de escritas que reproduziria exatamente o problema original.

Segundo, o diagnóstico não foi imediato. A equipe do Roblox precisou correlacionar o comportamento do BoltDB com o streaming de telemetria recém-ativado. Isso não é trivial em um ambiente com centenas de variáveis. Os logs de contenção do BoltDB não são, por padrão, expostos de forma proeminente. A latência do Raft é um sintoma que pode ter múltiplas causas — problemas de rede, CPU saturada, disco lento. Isolar o streaming como o fator amplificador exigiu investigação cuidadosa.

Terceiro, a recuperação precisou ser gradual. Uma vez identificada a causa e desativado o streaming, o cluster Consul precisou ser reconstruído de forma controlada. Isso significa trazer os nós um a um, verificar a convergência do estado Raft, e só então permitir que os serviços comecem a se registrar novamente — em uma ordem que não reproduza a tempestade de escritas. Com milhares de serviços e workloads gerenciados pelo Nomad, esse processo é inerentemente lento.

Finalmente, há o fator humano e organizacional. Um incidente de 73 horas exige rotação de equipes, comunicação constante com stakeholders, decisões sob pressão e fadiga acumulada. A qualidade das decisões técnicas em um incidente prolongado é diretamente afetada por esses fatores. O Roblox, a crédito da equipe, publicou um post-mortem detalhado e honesto — o que é raro e valioso.

O post-mortem publicado pelo Roblox em janeiro de 2022 detalha um conjunto robusto de ações corretivas. Vou analisá-las criticamente, porque nem toda ação de remediação é igualmente eficaz.

Migração do BoltDB para bbolt com melhorias de concorrência: O BoltDB original foi arquivado; o projeto bbolt (fork mantido pela etcd/CoreOS community) oferece melhorias incrementais, mas a limitação fundamental de single-writer persiste. A remediação real aqui é a migração para backends alternativos — o Consul suporta backends como o etcd ou pode usar WAL-based storage. O Roblox também avaliou e implementou mudanças na configuração do Consul para reduzir a frequência de operações de escrita desnecessárias.

Desativação do streaming de telemetria e revisão do processo de feature rollout: Esta é a ação mais direta e correta. O streaming foi desativado e o processo de ativação de novos recursos em produção foi revisado para incluir avaliação de impacto em operações de I/O e testes de carga específicos para o backend de storage.

Melhoria do observability do cluster Consul: Antes do incidente, as métricas de contenção do BoltDB não eram monitoradas de forma proeminente. Pós-incidente, alertas específicos para latência de operações Raft, tamanho da fila de escritas do BoltDB e tempo de aquisição de locks foram adicionados. Isso é essential — você não pode responder ao que não vê.

Revisão da arquitetura de dependência do Consul: O incidente expôs que o Consul era um single point of failure para a plataforma inteira. Pós-incidente, o Roblox trabalhou para reduzir a superfície de dependência crítica — implementando caching de DNS mais agressivo nos clientes, circuit breakers para serviços que dependem de service discovery, e planos de degradação graceful para quando o Consul está degradado mas não completamente indisponível.

O que eu faria diferente: A migração para um backend de storage com melhor modelo de concorrência deveria ser a prioridade número um — não uma melhoria incremental no bbolt. Para um cluster Consul do tamanho do Roblox, o backend ideal seria baseado em WAL com suporte a escritas concorrentes. Adicionalmente, implementaria chaos engineering específico para o Consul — injeção de latência no BoltDB, simulação de contenção de locks — antes de qualquer feature rollout que afete o volume de I/O.