Post-mortem da falha de 73 horas da Roblox no ano passado

Resumo da falha

• A falha durou 72 horas

• Houve duas causas-raiz

  • Em uma situação com carga de leitura/gravação anormalmente alta, a ativação do novo recurso de streaming do Consul causou contenção excessiva e degradação de desempenho

  • Em certas condições de carga, isso desencadeou um problema de desempenho no BoltDB de código aberto, usado pelo Consul para gerenciar o write-ahead log de eleição de líder e replicação de dados

• Um único cluster Consul agravou o impacto desses problemas

• A interrupção foi prolongada porque levou tempo para encontrar esses dois problemas aparentemente não relacionados, escondidos na implementação do Consul

• Foi ainda mais difícil identificar a causa porque o sistema de monitoramento, que deveria oferecer melhor visibilidade sobre a origem da falha, dependia de sistemas afetados como o próprio Consul

Ambiente de cluster e HashiStack

• A Roblox opera 18.000 servidores e 170.000 contêineres

• Usa Nomad, Consul e Vault, geralmente chamados de HashiStack

Na época, a Roblox atualizou o Consul da versão 1.9 para a 1.10 para usar o recurso de streaming.

Detecção inicial (28/10 13:37)

Na tarde de 18 de outubro, o desempenho do Vault caiu e a carga de CPU de um dos servidores Consul aumentou.

Classificação inicial (28/10 13:37 – 29/10 02:00)

• A latência de gravação aumentou nas métricas do cluster Consul

• Suspeitou-se inicialmente de degradação de hardware, e a troca de um dos nós do cluster Consul foi iniciada

• Funcionários da HashiCorp entraram para trabalhar junto na investigação

• Mesmo após a troca do hardware, o desempenho do Consul continuou caindo, e às 16:35 o número de jogadores caiu para 50% do normal

• Como o Consul era usado para service discovery e tanto o Nomad quanto o Vault dependiam dele, o Consul era um SPoF

• Nesse momento, surgiu uma nova hipótese de que a causa era o tráfego. A equipe concluiu que o Consul não conseguia mais lidar com a carga elevada

• Todos os nós do cluster Consul foram trocados por sistemas mais potentes (dobro de núcleos, SSD NVMe mais rápido)

• A migração do Consul estava quase concluída, mas o cluster não voltou ao normal

Tentativa de recuperação do serviço #1 (29/10 02:00 – 04:00)

• Foi decidido voltar para um snapshot do cluster Consul anterior à falha

• Considerou-se aceitável perder parte dos dados do sistema, já que os dados de usuário estavam intactos

• Após restaurar o snapshot, o acesso foi bloqueado com iptables, para evitar que a carga causada por sistemas que se comunicavam continuamente com o Consul gerasse novos problemas na recuperação

• Depois da restauração do snapshot, os indicadores pareciam melhores, mas quando o bloqueio do iptables foi removido, tudo voltou ao estado original da falha

Tentativa de recuperação do serviço #2 (29/10 04:00 – 30/10 02:00)

• O tráfego externo foi bloqueado e usos não essenciais foram removidos, reduzindo serviços que rodavam em centenas de instâncias para apenas um dígito de instâncias

• A recuperação do serviço foi tentada novamente, mas o Consul voltou a ficar em estado anormal

• Percebeu-se que havia algo além dos fatores de degradação de desempenho considerados no início, e a investigação passou a olhar o interior do Consul, não apenas o Consul sob a ótica da Roblox

Análise de contenção (30/10 02:00 – 30/10 12:00)

• Após mais 10 horas de análise, descobriu-se que as gravações no Consul estavam sendo bloqueadas por longos períodos

• Embora a causa da contenção ainda fosse desconhecida, concluiu-se que a mudança inicial de CPU de 64 para 128 núcleos havia piorado ainda mais a contenção

• Decidiu-se voltar para 64 núcleos, mas isso não ajudou

Descoberta da causa-raiz (30/10 12:00 – 30/10 20:00)

• O recurso de streaming do Consul vinha sendo ativado há alguns meses e estava sendo adotado gradualmente porque reduzia o uso de CPU e a largura de banda de rede.

• Um dia antes da falha, às 14:00 do dia 27, esse recurso foi ativado no backend de roteamento de tráfego.

• Como ele havia sido ativado no dia anterior e parecia funcionar bem, não foi considerado como causa no início

• Após análise de desempenho, foram encontradas evidências de que o código de streaming causava alto uso de CPU

• Depois de desativar o streaming e concluir o deploy, foi confirmada a redução da latência de gravação no KV do Consul (finalmente!)

• A HashiCorp explicou que, embora o streaming fosse mais eficiente, sua implementação usava um número menor de elementos de controle de concorrência (canais de Go) do que o long polling -> sob carga alta, isso agravou a contenção em um único canal de Go e reduziu a eficiência

• Embora houvesse um avanço, ainda foram observadas eleições de líder intermitentes, e alguns líderes apresentavam problemas de latência semelhantes aos anteriores

• Partindo do entendimento de que o cluster estaria normal desde que determinados líderes não fossem eleitos, o foco passou a ser restaurar o serviço ao estado normal

• Depois disso, a HashiCorp continuou investigando a causa-raiz e descobriu que a lentidão de alguns líderes era causada pelo BoltDB

Recuperação do serviço de cache (30/10 20:00 – 31/10 05:00)

• Após 54 horas de interrupção, a equipe estava pronta para restaurar o serviço

• Durante a falha, o banco de dados permaneceu normal, mas o sistema de cache, que processa 1 bilhão de requisições por segundo, estava em estado anormal.

• Depois de restaurar esse cache e confirmar sua normalidade, já haviam se passado 61 horas desde o início da falha.

Retorno dos usuários (31/10 05:00 – 31/10 16:00)

• Às 5h do dia 31, começaram os preparativos para o retorno do serviço, finalizados às 10h.

• O número de jogadores acessando via DNS foi controlado e aumentado gradualmente, com monitoramento contínuo

• Após 73 horas, todos os jogadores puderam voltar a acessar.

Análise adicional e mudanças após a falha

• HashiCorp e Roblox desenvolveram um processo de "compactação" para resolver o problema de desempenho

• Melhoria de telemetria: havia uma dependência circular entre o sistema de telemetria e o Consul, então, quando o Consul tinha problemas, faltavam dados. A dependência circular foi removida para que o sistema de telemetria não dependesse dos sistemas que monitora

• Expansão de zonas de disponibilidade e data centers

• Limpeza de dados KV desnecessários ou armazenados no Consul apesar da existência de outros storages.

• Está sendo testada uma nova versão do Consul que substitui o BoltDB por seu sucessor, o bbolt

• Como o processo de bootstrap atrasou a recuperação, ele está sendo automatizado e novas ferramentas e processos estão sendo desenvolvidos

[xguru]

Obrigado pela tradução.

Uma indisponibilidade de 72 horas nessa escala parece realmente assustadora.