Date d'expiration : 06/04/2021

Le 6 avril 2021, un de nos certificats TLS wildcard a expiré de manière inattendue. C'est un peu gênant, mais nous pensons qu'il est important de partager notre expérience en espérant que d'autres pourront profiter de ce que nous avons appris et améliorer leurs systèmes. Si vous et votre entreprise utilisez un contrôle des certificats, il serait peut-être prudent de vérifier d'éventuelles failles dans ces systèmes.

Le certificat qui a expiré était utilisé pour de nombreux services internes d'Epic. Pour trop de services internes, en fait. Malgré nos efforts pour bien contrôler l'expiration des certificats, nous n'avons pas couvert toutes les zones où les certificats étaient utilisés. Après l'expiration et le renouvellement du certificat, une série d'événements inattendus se sont déroulés et ont prolongé la panne. Nous vous présentons plus de détails dans cet article.

Des éléments essentiels tels que nos systèmes d'authentification et d'identification ont été impactés, et ces services touchent de nombreux autres services dans tout notre écosystème. Les conséquences suivantes ont été signalées :

Échec de connexion aux comptes Epic depuis tous les produits utilisant cette forme d'authentification, notamment Fortnite, Rocket League, Houseparty, Epic Online Services ou l'Epic Games Store
Déconnexion lors de parties en diffusion ou de services sur toutes les plateformes
Échec d'achats d'objets à partir du lanceur Epic Games
Comportement inattendu du lanceur Epic Games. Par exemple, le contenu ne charge pas ou le mode hors ligne ne marche pas
Produits Epic Games et sites web marketing indisponibles ou dégradés, y compris les sites Unreal Engine
De nombreux problèmes d'outils internes empêchant les employées d'Epic de résoudre ou gérer des problèmes

Cet article vous donne un aperçu détaillé de ce qu'il s'est passé, ce que nous avons appris et les étapes que nous allons suivre pour éviter cela dans le futur.

Que s'est-il passé ?

Trois séquences d'événements majeures se sont produites :

L'expiration d'un certificat a causé une panne sur une grande partie de la communication en back-end de service à service et des outils de gestion en interne
Une augmentation significative et inattendue du trafic sur le lanceur Epic Games, ce qui a perturbé le service du lanceur Epic Games et les fonctionnalités de distribution de contenu
Une mauvaise version du site de l'Epic Games Store référençant des artefacts et éléments invalides a été déployée à cause de l'adaptation automatique, diminuant l'expérience utilisateur sur l'Epic Games Store

1) Expiration du certificat

Le 6 avril à 14h CEST (12h UTC), un certificat TLS a expiré. Ce certificat était utilisé pour une grande partie de notre communication interne sur toute la plateforme back-end d'Epic. Nous utilisons un chiffrement TLS entre nos services en back-end pour la communication API entre les services et les outils de gestion internes. Ce certificat est destiné à une zone DNS interne non publique.

À 14h CEST (12h UTC), le trafic entre les systèmes en back-end s'est arrêté. Six minutes plus tard, à 14h06 CEST (12h06 UTC), l'incident a été signalé et notre processus de gestion d'incident a commencé. Malgré nos nombreuses alarmes, nous encourageons tout le monde dans l'entreprise à signaler tout problème pouvant avoir des conséquences importantes. Chaque incident est pris en charge par notre équipe Live Ops 24h/24 7j/7, qui initie le processus de gestion d'incident. Lorsque le premier rapport interne est arrivé, nos outils et processus de gestion d'incident ont immédiatement ouvert une chaîne sur Slack, et les parties concernées ont été sollicitées.

À 14h12 CEST (12h12 UTC), nous avons confirmé l'expiration d'un certificat qui était très certainement la source des problèmes et nous avons commencé le processus de renouvellement. À 14h37 CEST (12h37 UTC), le certificat a été à nouveau délivré avant d'être déployé dans nos services back-end. Pendant les 15 minutes qui ont suivi, les équilibreurs de charge ont commencé à déployer automatiquement le nouveau certificat dans les terminaux internes et notre communication HTTPS de service à service ainsi que nos interfaces de gestion se sont rétablies.

Notre équipe Live Ops, qui a pris en charge l'incident, le gérait également à ce stade en communiquant avec les employés et en mobilisant les bonnes personnes. À 14h38 CEST (12h38 UTC), un appel Zoom a été lancé pour coordonner les personnes qui collaboraient sur Slack. Slack est un bon outil de communication, mais dans une situation urgente, rien ne vaut la communication en temps réel par voix ou vidéo. Des actualisations au sujet de l'incident étaient envoyées régulièrement aux parties prenantes internes par le biais de nos outils et processus pour garder tout le monde au courant de ce qui se passait. À ce moment-là, plus de 25 personnes étaient directement impliquées et travaillaient sur le problème et de nombreuses personnes se plaçaient en observateurs : l'Assistance, la Communauté, le Développement et la Production, tous venant de différentes équipes et produits.

Un graphique des demandes a analysé le microservice unique par minute, avec une baisse pendant la panne du certificat et une augmentation au moment du rétablissement.

Facteurs déterminants

Les zones DNS de cette communication de service à service interne n'étaient pas contrôlées activement par nos services de contrôle de certificat, ce qui fut une erreur de notre part. Nos services de contrôle de certificat se basent sur des espaces de noms DNS entiers et non sur des points de terminaison ou certificats individuels, et la configuration de cette zone interne était absente. Depuis, nous avons déplacé cette zone vers notre nouvelle solution de contrôle mise en place en réponse à cette faille. Avant cet incident, nous avions commencé un projet pour activer et configurer AWS Config sur l'intégralité de nos nombreux comptes. Avec cette configuration, nous pouvons ajouter une règle AWS Config facilement, activant une alarme de défense en profondeur pour signaler l'expiration d'un certificat.

Les renouvellements automatiques n'étaient pas activés pour ce certificat interne et le travail nécessaire pour ce faire n'était pas prioritaire au moment de son identification plus tôt dans l'année. Des systèmes et services adéquats sont en place pour faciliter le renouvellement automatique, mais la migration vers l'utilisation de ces fonctionnalités n'a pas été effectuée avant cet incident. Avec nos systèmes de contrôle en place, nous pensions être mieux protégés que nous ne l'étions face aux dangers d'une expiration de certificat. Nous allons travailler au renouvellement automatique de ce certificat et des autres. En attendant, nous avons effectué un contrôle manuel de tous nos certificats.

Le certificat wildcard de service à service concerné était installé sur des centaines de services de production différents, c'est pour cela que les conséquences ont été très importantes. Nous utilisons ACM (AWS Certificate Manager) d'AWS pour gérer ce certificat, ce qui nous permet de renouveler rapidement et d'appliquer ce certificat sur des centaines de services de production en quelques minutes. Le problème d'expiration n'a rien à voir avec ACM d'AWS lui-même, mais avec la gestion de notre propre certificat. Nous allons travailler sur la séparation du rayon d'action de nos certificats, et cela mettra à jour nos processus pour l'utilisation des certificats avec ACM d'AWS.

2) Augmentation significative du trafic du service du lanceur Epic Games

Tandis que la plupart des services reprenaient immédiatement après le rafraîchissement des certificats, ceux du lanceur Epic Games restaient indisponibles.

À 14h46 CEST (12h46 UTC), après la délivrance du certificat, un pic du taux de requêtes a submergé le service du lanceur Epic Games, un système en back-end clé du client du lanceur Epic Games. Cette augmentation du taux de requêtes a été causée par une logique inattendue de nouvelle tentative, que l'on constate uniquement dans les scénarios de défaillance. Bien que nous ayons effectué un gros travail de résilience sur le lanceur Epic Games pendant des années, ce scénario d'augmentation des requêtes était inattendu. Les limites de suivi de la connexion ont été atteintes sur nos serveurs, et des paquets ont été rejetés à travers les flottes, rendant la récupération plus difficile encore alors que notre flotte d'application back-end est montée à 250%. Les services du lanceur Epic Games ont essuyé des échecs en cascade et une panne complète, et il a été nécessaire de limiter le trafic sur le système back-end, puis d'augmenter de façon incrémentielle le trafic sur le système tout en augmentant simultanément les limites de nos suivis de connexion.

Notre large empreinte sur les clients du lanceur Epic Games a généré des dizaines de millions de connexions sur le service back-end du lanceur Epic Games, et les éléments des systèmes du lanceur Epic Games ont été détériorés par la charge. Nous avons dû purger le trafic du système back-end pour lui permettre de se rétablir. Bien que nous disposions normalement d'une capacité de rafale pour ce service, cela ne lui a pas permis de gérer la multiplication par 28 de la charge que nous avons observée au début de la panne.

Un graphique du compte de requêtes par minute de notre équilibreur de charge back-end du lanceur Epic Games. Le trafic a été multiplié par 28 initialement et la rafale finale à 17h12 CEST (15h12 UTC) était 40 fois supérieure au taux normal.

Alors que notre compte de requêtes était plus de 28 fois supérieur à la normale, le nombre élevé de connexions au service back-end du lanceur Epic Games a épuisé l'espace de suivi de connexion, provoquant une perte de paquets et finissant par dégrader la connectivité des nœuds en back-end. La charge de notre connexion back-end a été multipliée par 3200, comparée à notre taux normal. L'augmentation des connexions TCP a été considérablement plus haute que la quantité des requêtes.

Un graphique du nombre de nouvelles connexions par minute à notre équilibreur de charge back-end du lanceur Epic Games principal avec une augmentation multipliée par 3200 comparée au pic normal.

Facteurs déterminants

Le certificat TLS qui a expiré a créé une panne qui a déclenché un comportement inattendu de la part de notre client de lanceur. Notre enquête a révélé que la relance de notre client utilisait une logique de relance linéaire au lieu de l'algorithme de repli exponentiel que nous avions prévu. Un bug inattendu supplémentaire a également entraîné la configuration de requêtes de millions de clients du lanceur Epic Games qui ont réessayé en permanence jusqu'à ce qu'une réponse positive soit reçue. Ces deux bugs de notre base d'installation du client ont créé un processus d'appel inattendu et imprévu. Nous avons subi une attaque par déni de service (DDoS) de nos propres clients et nous avons travaillé en urgence pour corriger ces bugs dans une mise à jour du lanceur Epic Games.

Un facteur intéressant dans cette partie de l'incident est la durée de la panne initiale. Plus la panne a duré, plus haute était la probabilité d'une augmentation des clients utilisant la logique erronée de nouvelle tentative et appelant continuellement notre service en back-end. Si la panne initiale avait été plus courte, nous n'aurions peut-être pas accumulé assez de clients faisant des appels de relance continus pour surcharger le système, et seule une panne de cette durée aurait entraîné le problème. Nous allons le résoudre par le biais de changements de configuration d'appel.

Notre alarme de suivi de connexion n'a pas été bien comprise. Cette alarme s'est déclenchée durant l'incident pour le service du lanceur Epic Games, et bien que plusieurs équipes connaissent bien la signification de cette alarme, sa description et sa notification n'étaient pas assez explicites. Nous ne savons pas si cet état aurait causé une perte de paquets pour n'importe laquelle des connexions que ces hôtes auraient opérées, y compris la connectivité à un cluster Redis interne. Ce fut un moment stressant pour l'équipe qui a enquêté sur ce qui se passait alors que la connectivité au cluster Redis était détériorée. Nous avons soupçonné que nos mécanismes de mise en cache étaient en cause. Et cela s'est avéré être dû à la perte de paquets, car le tableau de suivi des connexions était plein, avec des centaines de milliers de connexions en utilisation. Plus tard lors de l'incident, nous avons augmenté les limites de notre suivi de connexion jusqu'à plus d'un million par nœud, mais les augmentations de suivi de connexion dans notre infrastructure ne sont pas instantanées et prennent du temps. Nous allons travailler à la mise à jour de notre alarme pour être plus clairs en ce qui concerne les problèmes majeurs de réseau causés jusqu'à leur résolution.

L'augmentation a créé de nouveaux nœuds qui ont instantanément atteint les limites de suivi de connexion. Notre flotte étant surchargée de connexions, causant de graves pertes de paquets, nous devions réduire le trafic général vers la flotte et augmenter lentement le trafic autorisé. Nous avons d'abord tenté d'utiliser WAF (Web Application Firewall) d'AWS pour limiter le sous-ensemble de trafic entrant, cependant, notre configuration n'a pas limité suffisamment ce trafic. Ce n'était pas un problème lié à WAF d'AWS, mais à l'ensemble de règles que nous nous sommes imposées. Pour gagner du temps, nous avons ensuite utilisé les poids ciblés de notre équilibreur de charge AWS pour déplacer le trafic, ce qui, en combinaison avec l'augmentation de nos limites de suivi de connexion, a finalement réussi. L'utilisation de WAF dans ce scénario a retardé la récupération de nos services du lanceur Epic Games, mais n'était en aucun cas la faute d'AWS. Nous allons développer un processus standard pour délester en urgence le trafic dans les situations critiques comme celles-ci à l'aide de WAF d'AWS, des poids cibles de l'équilibreur de charge, et des autres technologies AWS.

3) Contenus invalides du site internet de l'Epic Games Store

À 17h12 CEST (15h12 UTC), avec nos certificats renouvelés et notre service du lanceur Epic Games ayant été rétabli, nous avons continué en débloquant tous les clients appelant notre Epic Games Store. En raison de la durée de la panne, il y avait considérablement plus de clients que la normale faisant des demandes de contenus de l'Epic Games Store. Nous avons commencé à évaluer les impacts restants à 17h30 CEST (15h30 UTC).

Dans un premier temps, tout semblait normal. Mais rapidement, nous avons commencé à recevoir des rapports d'erreurs et de problèmes d'affichage sur la boutique que nous avons pu confirmer et reproduire. Après vérification, nous avons remarqué que le client web (la façon dont un client qui parcourt epicgames.com interagit avec la boutique) essayait de récupérer un ID d'élément unique qui n'était pas présent dans notre CDN. Nous avons vérifié les versions de conteneur déployées parmi les flottes, et elles étaient toutes similaires. Mais si tel était le cas, comment la même application pourrait-elle renvoyer des valeurs différentes d'élément statique ?

Quelque chose ne tournait pas rond. C'était une période très déroutante lors de l'incident. Finalement, un grand nombre de signaux reçus (par les versions déployées) étaient des signaux erronés. Nous avons pu établir une corrélation entre la mise à l'échelle du back-end de l'Epic Games Store et l'augmentation des erreurs 403 sur notre RDC, ce qui nous a conduits à examiner en détail les nouvelles instances. En transférant le contenu à l'échelle locale pour les nouveaux cas, nous avons découvert que le contenu renvoyé n'était pas correct. Nous avons pu remonter jusqu'à un envoi forcé inattendu de conteneur vers un nouveau flux opérationnel CI/CD créé la veille et sinon sans aucun lien avec tout ce que nous avions rencontré jusque là pendant l'incident. Ces résultats étaient quand même surprenants, mais après avoir découvert tout cela, nous avons pu rapidement rétrograder la version du conteneur, mettre fin aux instances invalides et rétablir le trafic.

Ce problème aurait pu se produire pendant n'importe quelle extension majeure qui a eu lieu pendant cette période, mais nous gardons toujours de la place supplémentaire sur les flottes. De fait, ce problème n'est pas apparu jusqu'à l'extension majeure de l'Epic Games Store qui a eu lieu à cause du trafic sur le lanceur Epic Games.

Facteurs déterminants

La panne du certificat a causé des soucis sur le lanceur Epic Games qui, après avoir été réparé, a créé un grand nombre de demandes sur l'Epic Games Store. C'est cela qui a mené à l'extension des systèmes de l'Epic Games Store. C'est normal, et c'est même attendu.

Nos signaux et nos données sur l'état des versions de toutes nos applications nous ont fait penser à tort que leur déploiement était uniforme. Nous avons modifié notre gestion des versions pour empêcher toute erreur de diagnostic à l'avenir.

Une modification récente du pipeline CI/CD pour l'Epic Games Store souffrait d'une mauvaise configuration qui a mis à jour l'artéfact d'application à l'improviste. Cela a été corrigé par le biais d'une modification de notre approche CI/CD, ce qui nous a permis de revenir sur les changements imprévus. Notre nouvelle gestion des versions nous protègera si cela devait arriver à nouveau.

Chronologie

14h CEST (12h UTC) - Expiration du certificat interne
14h06 CEST (12h06 UTC) - Rapport de l'incident et initiation de la gestion d'incident
14h15 CEST (12h15 UTC) - Préparation du premier message client
14h21 CEST (12h21 UTC) - Confirmation de pannes de service importantes par plusieurs équipes
14h25 CEST (12h25 UTC) - Confirmation du début de la procédure de réémission du certificat
14h37 CEST (12h37 UTC) - Confirmation de la réémission du certificat
14h46 CEST (12h46 UTC) - Confirmation de la restauration de certains services
14h54 CEST (12h54 UTC) - Identification du suivi de connexion comme problème pour le lanceur Epic Games
15h41 CEST (13h41 UTC) - Redémarrage des nœuds de service du lanceur Epic Games
17h05 CEST (15h05 UTC) - Augmentation des limites du suivi de connexion pour le lanceur Epic Games
17h12 CEST (15h12 UTC) - Premiers signes de restauration du lanceur Epic Games
17h34 CEST (15h34 UTC) - Extension du service web de l'Epic Games Store
17h59 CEST (15h59 UTC) - Premiers rapports d'éléments manquants sur l'Epic Games Store
18h57 CEST (16h57 UTC) - Découverte d'un problème lié aux versions non concordantes du service web de l'Epic Games Store
19h22 CEST (17h22 UTC) - Correction de la version du service web de l'Epic Games Store
19h35 CEST (17h35 UTC) - Restauration complète

Et après ?

Dans les sections ci-dessus, nous avons traité les scénarios qui nous ont surpris et qui ont mené à la panne du 6 avril. Nous avons mentionné nos prochaines étapes, ainsi que nos facteurs déterminants, mais nous allons tout récapituler ici.

Il n'y a pas qu'une seule cause pour ces problèmes. Un grand nombre de facteurs, autant technologiques qu'organisationnels, ont contribué aux événements qui ont eu lieu. L'ampleur et la durée de la panne nous ont aidés à découvrir les bugs explicites dans nos systèmes, que nous comptons évidemment corriger, mais aussi des hypothèses non-remises en question dans certains de nos processus internes, en particulier ceux qui régulent la gestion de certificats.

Bien que nous ayons pris immédiatement des mesures pour couvrir cet aspect avec notre nouveau système de contrôle des certificats et que nous ayons effectué un contrôle sur tous les certificats connus existants, nous allons examiner de plus près toutes les autres lacunes dans notre contrôle des certificats et ajouter des mesures supplémentaires à l'avenir, par exemple avec le service AWS Config qui contrôle tous les certificats intégrés à ACM d'AWS. Nous allons également faire en sorte de réduire le rayon d'action des certificats.

Nous allons examiner de plus près les modèles d'appel de client de notre lanceur Epic Games et corriger en urgence certains des bugs qui ont été identifiés dans le cadre de ce problème. De plus, nous allons améliorer notre capacité à réagir aux situations d'augmentation significative du trafic. Avec l'augmentation permanente de nos tableaux de suivi de connexion pour ces flottes, nous devrions pouvoir gérer un flux similaire sans perte majeure de paquets. Si vous gérez un grand nombre de flottes, pensez à vérifier les limites de vos tables de suivi de connexion et les alarmes, si vous utilisez cette fonctionnalité de Netfilter. C'est aussi un bon rappel de vérifier la logique de nouvelle tentative de vos clients, en particulier leur comportement dans l'ensemble après une longue panne.

Pour l'Epic Games Store, nous avons déployé un correctif qui devrait empêcher la modification d'un objet d'application en utilisation. À ce titre, nous en avons appris davantage sur un bug présent dans notre génération d'éléments, et nous l'avons corrigé.

Nous espérons que ce rapport d'incident vous a fourni tous les détails sur ce qu'il s'est passé le 6 avril. Nous espérons que ces détails donneront un bon aperçu sur les leçons et les améliorations tirées, et qu'ils pourront aider d'autres personnes à éviter des problèmes similaires.

Rejoignez-nous !

Cet article a été rédigé par notre équipe d'ingénierie de fiabilité, avec l'aide de nombreuses autres équipes d'ingénierie incroyables d'Epic.

Vous vous intéressez à ce genre de problème ? Vous êtes un passionné de jeux et de services de jeux ? Epic est toujours à l'affût de personnes talentueuses et nous recrutons à l'échelle mondiale dans tous les domaines de compétences. Si vous cherchez nos postes à pourvoir, rendez-vous dans la section carrière d'Epic Games.

Cet article vous a-t-il aidé ? Était-il intéressant ? Dites-nous tout à public-incident-response@epicgames.com.