Em 3 e 4 de fevereiro de 2018, o Fortnite Battle Royale atingiu um pico de 3,4 milhões de jogadores simultâneos — acima do pico anterior de 60 mil apenas alguns meses antes — e o fim de semana se tornou uma sequência contínua de quedas. O próprio postmortem da Epic, publicado em 8 de fevereiro de 2018, contabiliza seis incidentes distintos, com uma mistura de interrupções parciais e totais do serviço.
Os cortes mais profundos ocorreram no serviço de perfis MCP, apoiado por nove shards do MongoDB que processavam 318 mil leituras e 132 mil gravações por segundo. O shard de matchmaking começou a enfileirar gravações, elevando operações individuais a mais de 40.000 milissegundos e bloqueando todas as threads do MCP; ele nunca se recuperou sozinho, então os operadores realizaram failovers manuais de primário várias vezes por hora. Uma segunda ferida: uma mudança de empacotamento havia limitado silenciosamente a contagem de threads do serviço abaixo do valor seguro pretendido, e a recente "correção" — revertê-la — esgotou os pools de conexão com o banco de dados apenas no pico de produção, forçando um rollback.
No domingo, o Serviço de Contas caiu das 18h30 às 20h20 UTC: a instabilidade do Memcached fez o Nginx bloquear em timeouts de 100 ms até esgotar suas threads de trabalho, as verificações de integridade afogaram e o balanceador de carga removeu todos os nós — o login ficou bloqueado no mundo inteiro. Naquela noite, a camada social XMPP falhou durante um failover emergencial blue/green: a corrida de reconexão esmagou o balanceador de carga do Serviço de Amigos, que não conseguiu provisionar substitutos porque sua sub-rede havia esgotado os IPs livres. Os jogadores se conectavam, mas viam todos os amigos como offline — uma "sala escura".
Os limites da nuvem pioraram a situação: milhares de instâncias c4.8xlarge se aproximaram do limite de instâncias da região, e sub-redes /24 que ofereciam 251 IPs utilizáveis haviam sido esgotadas, prolongando a recuperação do balanceador de carga. A Epic trouxe especialistas em MongoDB ao local, prometeu uma re-arquitetura da pilha de mensagens e do MCP, e encerrou o postmortem com uma chamada de recrutamento — uma pequena equipe de desenvolvedores online veteranos havia mantido no ar o maior jogo de PC/console do mundo até que os números a superassem.
Seis interrupções parciais e totais em 3 e 4 de fevereiro de 2018: logins bloqueados, matchmaking congelado, amigos exibidos como offline; failovers manuais executados a cada hora.
O estado do matchmaking vivia em um único shard compartilhado; quando seu gravador enfileirava, toda operação do MCP bloqueava, e a única recuperação era um failover manual de primário.
Uma mudança de empacotamento havia limitado as threads do serviço MCP abaixo do padrão seguro; a própria correção esgotou os pools de conexão com o banco de dados apenas no pico de produção e teve de ser revertida.
Todo o tráfego do Serviço de Contas passava por um proxy Nginx cujas threads de trabalho bloqueavam em timeouts de 100 ms do Memcached; as threads saturadas falhavam nas verificações de integridade e o balanceador de carga removia todos os nós.
O caminho de failover do Serviço de Amigos precisava de IPs livres em uma sub-rede /24 — 251 endereços — e a corrida de reconexão os esgotou no meio do incidente.
O XMPP rodava um cluster full-mesh (101 nós, ~1.000 sockets cada apenas para links de cluster) com um teto rígido de nós, de modo que a capacidade da camada social não podia simplesmente ser adicionada.
A lição
O crescimento supera a arquitetura mais rápido do que a contratação consegue corrigir: em escala 50×, uma configuração de threads não testada, uma sub-rede de 251 IPs e um único shard sobrecarregado tornam-se, cada um, uma queda.
A lista de correções do postmortem parece um programa de re-arquitetura: encontrar a causa raiz da fila de gravação do MongoDB com especialistas no local, mover as sessões de matchmaking para armazenamento em memória, encaminhar o tráfego que não é de verificação para fora do par Nginx/Memcached, corrigir a capacidade da sub-rede e reduzir o raio de impacto distribuindo os serviços centrais entre regiões e nuvens. A Epic continuou publicando atualizações do serviço do Fortnite à medida que o jogo seguia crescendo, e o postmortem se tornou uma citação padrão de como o crescimento viral converte cada configuração incorreta latente em uma queda.
CONFIRA AS EVIDÊNCIAS
As fontes
- Postmortem of Service Outage at 3.4M CCU Epic Games (Fortnite news) · epicgames.com ·
- Postmortem of Service Outage at 3.4M CCU (archived copy) Internet Archive Wayback Machine · web.archive.org ·
- Postmortem of Service Outage at 3.4M Concurrent Users (discussion) Hacker News · news.ycombinator.com