Fortnite de Epic se doblegó bajo 3,4 millones de jugadores simultáneos: seis caídas en un fin de semana

El 3 y 4 de febrero de 2018, Fortnite Battle Royale alcanzó un pico de 3,4 millones de jugadores simultáneos —frente a un pico anterior de 60 000 apenas unos meses antes— y ese fin de semana se convirtió en una sucesión continua de caídas. El propio postmortem de Epic, publicado el 8 de febrero de 2018, contabiliza seis incidentes distintos con una mezcla de interrupciones parciales y totales del servicio.

Los cortes más profundos estuvieron en el servicio de perfiles MCP, respaldado por nueve shards de MongoDB que gestionaban 318 000 lecturas y 132 000 escrituras por segundo. El shard de emparejamiento empezó a encolar escrituras, disparando operaciones individuales a más de 40 000 milisegundos y bloqueando todos los hilos de MCP; nunca se recuperó por sí solo, así que los operadores realizaron conmutaciones manuales del primario varias veces por hora. Una segunda herida: un cambio de empaquetado había limitado silenciosamente el número de hilos del servicio por debajo del valor seguro previsto, y la reciente «corrección» —revertirlo— dejó sin recursos los pools de conexiones a la base de datos solo en el pico de producción, lo que obligó a revertirla.

El domingo, el servicio de cuentas cayó de 18:30 a 20:20 UTC: la inestabilidad de Memcached hizo que Nginx se bloqueara en tiempos de espera de 100 ms hasta agotar sus hilos de trabajo, las comprobaciones de estado se ahogaron y el balanceador de carga retiró todos los nodos —el inicio de sesión quedó bloqueado en todo el mundo—. Esa noche, la capa social XMPP falló durante una conmutación de emergencia blue/green: la avalancha de reconexiones desbordó el balanceador de carga del servicio de amigos, que no pudo aprovisionar reemplazos porque su subred se había quedado sin IP libres. Los jugadores se conectaban pero veían a todos sus amigos como desconectados: una «sala oscura».

Los límites de la nube lo empeoraron: miles de instancias c4.8xlarge se acercaron al límite de instancias de la región, y las subredes /24, que ofrecen 251 IP utilizables, se habían agotado, lo que alargó la recuperación de los balanceadores de carga. Epic trajo expertos en MongoDB al sitio, prometió una rearquitectura de la pila de mensajería y de MCP, y cerró el postmortem con una oferta de empleo: un pequeño equipo de desarrolladores veteranos de servicios en línea había mantenido en línea el mayor juego de PC y consola del mundo hasta que las cifras los desbordaron.

Seis interrupciones parciales y totales entre el 3 y el 4 de febrero de 2018: inicios de sesión bloqueados, emparejamiento congelado, amigos mostrados como desconectados; las conmutaciones manuales se ejecutaban cada hora.

El estado del emparejamiento residía en un único shard compartido; cuando su escritor encolaba, toda operación de MCP se bloqueaba, y la única recuperación era una conmutación manual del primario.

Un cambio de empaquetado había limitado los hilos del servicio MCP por debajo del valor seguro predeterminado; la propia corrección dejó sin recursos los pools de conexiones a la base de datos en el pico exclusivo de producción y tuvo que revertirse.

Todo el tráfico del servicio de cuentas pasaba por un proxy Nginx cuyos hilos de trabajo se bloqueaban en tiempos de espera de 100 ms de Memcached; los hilos saturados fallaban las comprobaciones de estado y el balanceador de carga retiraba todos los nodos.

La ruta de conmutación del servicio de amigos necesitaba IP libres en una subred /24 —251 direcciones— y la avalancha de reconexiones las agotó en pleno incidente.

XMPP ejecutaba un clúster de malla completa (101 nodos, ~1000 sockets cada uno solo para los enlaces del clúster) con un techo fijo de nodos, así que la capacidad de la capa social no podía simplemente añadirse.

El crecimiento supera a la arquitectura más rápido de lo que la contratación puede arreglarlo: a escala 50×, un ajuste de hilos no probado, una subred de 251 IP y un único shard sobrecargado se convierten cada uno en una caída.

La lista de correcciones del postmortem se lee como un programa de rearquitectura: hallar la causa raíz de la cola de escrituras de MongoDB con expertos en el sitio, trasladar las sesiones de emparejamiento a almacenamiento en memoria, desviar el tráfico que no sea de verificación lejos del par Nginx/Memcached, corregir la capacidad de las subredes y reducir el radio de impacto distribuyendo los servicios centrales entre regiones y nubes. Epic siguió publicando actualizaciones del servicio de Fortnite mientras el juego seguía creciendo, y el postmortem se convirtió en una cita estándar sobre cómo el crecimiento viral convierte cada configuración errónea latente en una caída.