Fortnite d'Epic a plié sous 3,4 M de joueurs simultanés — six pannes en un week-end

Les 3 et 4 février 2018, Fortnite Battle Royale a atteint un pic de 3,4 millions de joueurs simultanés — contre un pic précédent de 60 000 quelques mois plus tôt — et ce week-end s'est transformé en une série de pannes. Le postmortem d'Epic lui-même, publié le 8 février 2018, recense six incidents distincts, mêlant interruptions partielles et totales du service.

Les coupures les plus profondes ont touché le service de profils MCP, adossé à neuf shards MongoDB traitant 318 K lectures et 132 K écritures par seconde. Le shard de matchmaking a commencé à mettre les écritures en file d'attente, faisant grimper des opérations individuelles à plus de 40 000 millisecondes et bloquant tous les threads MCP ; il ne s'est jamais rétabli de lui-même, si bien que les opérateurs ont procédé à des basculements manuels du primaire plusieurs fois par heure. Une seconde plaie : un changement de packaging avait silencieusement plafonné le nombre de threads du service sous la valeur sûre prévue, et le « correctif » récent — son annulation — a asséché les pools de connexions à la base de données uniquement au pic de production, forçant un retour en arrière.

Le dimanche, le service de comptes est tombé de 18 h 30 à 20 h 20 UTC : l'instabilité de Memcached a fait bloquer Nginx sur des délais d'attente de 100 ms jusqu'à épuisement de ses threads de travail, les contrôles de santé se sont noyés et le répartiteur de charge a retiré tous les nœuds — la connexion était bloquée dans le monde entier. Cette nuit-là, la couche sociale XMPP a échoué lors d'un basculement d'urgence bleu/vert : la ruée des reconnexions a écrasé le répartiteur de charge du service d'amis, qui ne pouvait pas provisionner de remplaçants car son sous-réseau n'avait plus d'IP libres. Les joueurs se connectaient mais voyaient tous leurs amis hors ligne — une « pièce noire ».

Les plafonds du cloud ont aggravé la situation : des milliers d'instances c4.8xlarge approchaient la limite d'instances de la région, et les sous-réseaux /24 offrant 251 IP utilisables étaient épuisés, ce qui allongeait le rétablissement des répartiteurs de charge. Epic a fait venir des experts MongoDB sur site, promis une réarchitecture de la pile de messagerie et du MCP, et a conclu le postmortem par un appel au recrutement — une petite équipe de développeurs en ligne chevronnés avait maintenu en ligne le plus grand jeu PC/console du monde jusqu'à ce que les chiffres la dépassent.

Six interruptions partielles et totales les 3 et 4 février 2018 : connexions bloquées, matchmaking figé, amis affichés hors ligne ; des basculements manuels toutes les heures.

L'état du matchmaking résidait sur un seul shard partagé ; lorsque son writer s'est mis en file d'attente, chaque opération MCP s'est bloquée, et le seul rétablissement possible était un basculement manuel du primaire.

Un changement de packaging avait plafonné les threads du service MCP sous la valeur par défaut sûre ; la correction elle-même a asséché les pools de connexions à la base de données au pic propre à la production et a dû être annulée.

Tout le trafic du service de comptes passait par un proxy Nginx dont les workers bloquaient sur des délais d'attente Memcached de 100 ms ; les workers saturés échouaient aux contrôles de santé et le répartiteur de charge a retiré tous les nœuds.

Le chemin de basculement du service d'amis nécessitait des IP libres dans un sous-réseau /24 — 251 adresses — et la ruée des reconnexions les a épuisées en pleine panne.

XMPP fonctionnait en cluster full-mesh (101 nœuds, environ 1 000 sockets chacun rien que pour les liens de cluster) avec un plafond de nœuds strict, si bien que la capacité de la couche sociale ne pouvait pas être simplement augmentée.

La croissance dépasse l'architecture plus vite que le recrutement ne peut y remédier : à une échelle de 50×, un réglage de threads non testé, un sous-réseau de 251 IP et un seul shard surchargé deviennent chacun des pannes.

La liste de correctifs du postmortem se lit comme un programme de réarchitecture : identifier la cause racine de la file d'attente d'écriture MongoDB avec des experts sur site, déplacer les sessions de matchmaking vers un stockage en mémoire, router le trafic hors vérification à l'écart du couple Nginx/Memcached, corriger la capacité des sous-réseaux et réduire le rayon d'impact en répartissant les services cœur entre régions et clouds. Epic a continué de publier des mises à jour du service Fortnite à mesure que le jeu grandissait, et le postmortem est devenu une référence classique pour montrer comment une croissance virale transforme chaque mauvaise configuration latente en panne.