La panne de brasage du 29 avril : que s'est-il passé, pourquoi cela s'est produit et comment nous y réagissons

Comprendre l'architecture des services de la plateforme Braze

Braze gère des ensembles de serveurs distincts pour chacun de nos huit clusters américains. Les clusters Braze US 01 à 07 sont hébergés sur Amazon Web Services (AWS), tandis que le cluster Braze US 08 est hébergé sur Microsoft Azure. Dans chacun de ces environnements, Braze utilise plusieurs zones de disponibilité et dispose de redondances pour chaque partie de notre système. En cas de défaillance d'une zone de disponibilité, nous désactivons systématiquement et de manière transparente les zones de disponibilité dégradées du routage et du traitement. Cela nous permet de maintenir de manière fiable la délivrabilité des services en cas de panne d'un fournisseur de services cloud.

À quelques exceptions près, chacun des clusters américains possède sa propre infrastructure dédiée et, à l'exception d'une poignée de composants utilisés dans tous les environnements d'une région cloud donnée, ces clusters sont fortement isolés les uns des autres, afin de réduire les risques. qu'une perturbation dans un cluster affectera d'autres clusters.

En raison de l'intensité de la charge de travail de traitement en temps réel de la plateforme Braze, depuis 2013, nous avons complété notre utilisation d'AWS et d'Azure en nous associant à Rackspace pour héberger du matériel configuré sur mesure pour exécuter les bases de données MongoDB. Nos environnements AWS et Azure sont configurés avec les connecteurs cloud privés AWS Direct Connect et Azure ExpressRoute, reliant l'environnement cloud à notre réseau interne maintenu dans les centres de données Rackspace via un câble à fibre optique dédié. Cette connexion cryptée, alimentée par des liaisons réseau prenant en charge plusieurs interfaces poussant plus de 100 gigabits de trafic réseau par seconde, offre un accès hautement performant entre notre cloud et les environnements Rackspace.

Notre environnement personnalisé dans Rackspace héberge des centaines de serveurs physiques conservés dans des armoires dédiées à Braze. Cette configuration comprend des alimentations redondantes et des commutateurs top-of-rack redondants. Les commutateurs haut de rack sont des périphériques réseau installés dans un rack de serveur et connectent les périphériques et les serveurs entre eux dans le même rack de serveur. Ces commutateurs sont testés au moins une fois par an pour un basculement sans impact ; le test de l'année dernière s'est déroulé avec succès le 3 août 2023. Dans cet environnement personnalisé, nous maintenons des dizaines de milliers de conteneurs virtualisés pour les bases de données MongoDB. À l'instar de nos environnements cloud, nous maintenons des niveaux élevés d'isolation physique entre les conteneurs sur différents clusters américains afin de minimiser les perturbations et de réduire le risque qu'un conteneur puisse affecter d'autres conteneurs au sein de nos bases de données.

La cause de la panne du 29 avril et comment nous y avons réagi

La défaillance partielle initiale du commutateur

Le 29 avril à 09h15 UTC, une panne partielle d'un commutateur réseau Cisco Nexus principal connecté à nos armoires de serveurs Rackspace s'est produite. Le commutateur défectueux est tombé en panne d'une manière qui n'a pas activé automatiquement le commutateur réseau secondaire via un basculement, mais a plutôt conservé le commutateur défectueux comme commutateur principal.

Les commutateurs réseau acheminent le trafic en transmettant les paquets réseau, appelés « trames », vers leur destination. Pour y parvenir efficacement, ces commutateurs maintiennent une compréhension de la topologie du réseau qui connecte les appareils entre eux. Il est courant que les routes réseau changent de manière dynamique en réponse à des pannes ou à des lenteurs de composants individuels. Lorsque ces changements se produisent, les commutateurs et autres périphériques réseau communiquent entre eux pour maintenir une compréhension précise de la topologie du réseau.

Dans les grands réseaux, il existe souvent plusieurs chemins entre les appareils, ce qui peut provoquer des « boucles » de routage (c'est-à-dire une condition dans laquelle les paquets ne parviennent pas à s'arrêter à leur destination prévue et reviennent à leur point d'origine). Les boucles peuvent créer des « tempêtes de diffusion », dans lesquelles le trafic finit par tourner en boucle indéfiniment, saturant les liaisons réseau et provoquant des pannes. Pour éviter que cela ne se produise, les commutateurs sont programmés pour envoyer des messages permettant d'identifier les liens redondants. Ces messages sont appelés unités de données du protocole Spanning Tree Bridge (BPDU) et font partie d'un protocole réseau appelé Spanning Tree Protocol (STP). Les commutateurs utilisent ensuite ces informations pour bloquer les ports de trafic afin d'éviter que des boucles ne se produisent lorsqu'ils acheminent le trafic. Si un lien physique ou un commutateur tombe en panne, le STP contribue à assurer la redondance, car il peut être utilisé pour identifier d'autres liens physiques sur lesquels le trafic peut être envoyé et promouvoir le lien précédemment passif (c'est-à-dire bloqué) en actif afin de maintenir les connexions.

Au début de l'incident du 29 avril, lorsque le commutateur a commencé à mal fonctionner, il a commencé à transmettre en continu des notifications de changement de topologie et des BPDU, inondant le réseau de ces avis de changement. Ces paquets se sont propagés aux commutateurs de distribution et à d’autres commutateurs, provoquant une boucle de commutation Spanning Tree qui a entraîné une panne complète du réseau. Alors que le STP est en place pour réduire les boucles réseau en bloquant les ports réseau où une boucle est détectée, lors de l'incident du 29 avril, le trafic Spanning Tree mal transmis par le commutateur défectueux a amené d'autres commutateurs du réseau à réanalyser leurs topologies Spanning Tree. Ensuite, comme ces autres commutateurs ont détecté qu'un paquet BPDU de haute priorité provenait du commutateur défectueux, les commutateurs de distribution ont commencé à transférer sur des ports précédemment bloqués, ce qui a entraîné une boucle de commutation qui a surchargé le réseau et l'a mis hors service.

La remédiation Rackspace

À la suite de cette activité, les ingénieurs du centre de données Rackspace ont reçu des alertes vers 09h20 UTC concernant des problèmes inattendus de connectivité réseau et ont commencé à résoudre le problème. Entre 09h39 et 10h03 UTC, les ingénieurs du centre de données Rackspace ont suspendu le commutateur réseau, redémarré le commutateur principal et forcé les cartes d'interface réseau (NIC) de l'armoire du serveur à basculer vers le commutateur secondaire. Après le basculement de la carte réseau, la connectivité a été restaurée sur les serveurs physiques dans l'environnement Braze.

Comment fonctionnent les bases de données Braze MongoDB

Les bases de données MongoDB utilisées par Braze permettent de stocker les données sur plusieurs serveurs de bases de données appelés « fragments ». MongoDB fournit un service de routage appelé « mongoS », qui traite les requêtes des services de la plateforme Braze, détermine l'emplacement des données pertinentes dans un cluster partitionné, puis achemine une requête vers la base de données MongoDB appropriée. Braze possède des centaines de bases de données MongoDB distinctes, comprenant plus de 15 000 processus « mongoD », qui sont les programmes qui exécutent la base de données et stockent les données d'un fragment MongoDB particulier.

Chaque fragment de base de données se compose d'un mongoD principal et d'au moins deux processus mongoD secondaires, ce qui assure une haute disponibilité en cas de panne. Chaque serveur mongoS maintient une connexion réseau avec chaque mongoD vers lequel il peut acheminer les requêtes. Ces processus mongoD se connectent également au primaire et aux secondaires dans sa configuration ; c'est ce qu'on appelle un jeu de répliques. Si un mongoS ne parvient pas à se connecter à un mongoD donné, il marquera ce processus comme hors ligne et planifiera une nouvelle tentative. De même, si un mongoD ne peut pas se connecter aux autres membres mongoD de son jeu de réplicas dans un délai d'une seconde, il expirera, marquera ces processus comme hors ligne et planifiera une nouvelle tentative.

L'impact de la boucle réseau sur nos processus MongoDB et comment nous y avons répondu

Pendant la boucle réseau, comme nos processus MongoDB ne pouvaient pas se connecter normalement, chacun a marqué tous ses processus associés comme hors ligne. Autrement dit, chaque processus mongoS a marqué tous ses processus mongoD associés comme étant hors ligne, et chaque processus mongoD a marqué ses membres du jeu de réplicas associés comme étant hors ligne. Cependant, même après la restauration de la connectivité réseau sur nos serveurs physiques par Rackspace, ni les processus mongoS ni mongoD n'ont rétabli toutes les connexions avec les autres processus marqués hors ligne.

À ce stade, afin de contribuer aux efforts de remédiation de notre équipe d'administrateur de base de données Rackspace (DBA), les équipes Braze DevOps ont commencé rapidement à déboguer et à tester des méthodes de restauration de cette connectivité. Notre enquête a déterminé que la seule option disponible était de redémarrer chacun des près de 16 000 processus mongoD et plus de 6 000 mongoS dans leurs conteneurs virtualisés. Compte tenu de l'ampleur de cette entreprise et du fait que l'automatisation n'existait pas pour redémarrer rapidement autant de conteneurs, les ingénieurs de Rackspace ont écrit un nouveau code lors de l'incident pour créer une capacité d'automatisation à la volée.

Malheureusement, à mesure que le processus de redémarrage s'accélérait, un autre problème est apparu dans le système DNS (Domain Name System). Lorsque les processus mongoS et mongoD sont mis en ligne, ils demandent des informations aux résolveurs DNS dans le cadre d'un processus appelé recherche DNS. Avec les recherches DNS continues entraînées par la vitesse des redémarrages, les serveurs DNS ont été soumis à une forte charge, entraînant des délais d'attente de connectivité sur les couches mongoS lors de leur reconnexion aux processus mongoD. Pour faire face à cette charge croissante, notre équipe Rackspace a augmenté la capacité du processeur DNS, mais a ensuite été obligée de redémarrer le niveau mongoS une seconde fois afin de créer des connexions saines de chaque mongoS vers leurs processus mongoD associés.

Vers 17h05 UTC, le processus de redémarrage a permis à certains clusters de commencer à se remettre en ligne. À mesure que les performances des bases de données se rétablissaient et que les clusters se stabilisaient, Braze a continué à augmenter la capacité de traitement des données et d'envoi de messages ; toutefois, cet effort a été compliqué par l'énorme retard résultant de l'indisponibilité préalable.

Compte tenu de l'ampleur et de la sophistication de notre environnement de base de données Rackspace, qui se compose de centaines de bases de données distinctes, de la durée de la panne et du volume de notre backlog qui en résulte (représentant des milliards de messages et des milliards de points de données ingérés), le processus de récupération requis dans -adaptation instantanée de nos processus normaux de récupération. Cela était nécessaire pour garantir que les ressources de la base de données restent en équilibre avec les demandes de traitement continues, y compris l'introduction d'une capacité de traitement globale massive.

Cependant, ce faisant, Braze a atteint une limite AWS concernant le nombre de processeurs virtuels que nous avons pu provisionner, nous empêchant d'ajouter toute capacité de serveur supplémentaire. L'équipe Braze a rapidement fait remonter cette situation à notre équipe AWS et a reçu une augmentation, permettant à nos ingénieurs d'augmenter la capacité de traitement de notre serveur à un niveau record, qui était de plus de 50 % supérieur à notre capacité maximale précédente, qui avait été atteinte sur Black. Vendredi 2023.

À 20h30 UTC, tous nos clusters américains, à l'exception de US 01, US 03 et US 08, avaient fini de traiter leurs arriérés, et les clusters restants traitaient à des taux égaux ou supérieurs à ceux de la veille de l'incident. En quelques heures, tous les clusters ont été rattrapés pour un traitement en temps réel et nous avons déclaré l'incident résolu.

Comment Braze communique les mises à jour lors d'incidents

Une communication claire et fréquente lors d’incidents comme celui-ci est essentielle. Même si les problèmes techniques en général sont rares et qu'un problème de cette ampleur était auparavant inconnu pour Braze, nous faisons toujours de notre mieux pour communiquer avec les parties concernées avec clarté et rapidité.

Dans des situations comme celle-ci, les principes directeurs qui éclairent notre stratégie de communication sont l’honnêteté, la transparence et la confiance. Nous savons que nous n’avons qu’une seule occasion d’être honnêtes et francs sur ce qui se passe, et que la transparence sur les incidents – tant sur le moment qu’après leur résolution – est essentielle pour maintenir la confiance. En fin de compte, nous voulons que nos clients soient sûrs que Braze fera toujours tout ce qui est en son pouvoir pour expliquer, remédier et empêcher la répétition de tout incident.

Lors d'incidents, nous utilisons notre page d'état pour gérer les communications et fournir des mises à jour régulières sur la situation ; J'encourage fortement les clients à s'inscrire pour recevoir les mises à jour à partir de cette page afin de rester informés. Lors de la panne du 29 avril, nous avons complété ces mises à jour fréquentes de la page de statut par un e-mail de mon collègue cofondateur et notre PDG, Bill Magnuson. Ce message a été envoyé à tous les utilisateurs du tableau de bord Braze et a été fourni à nos équipes de compte pour qu'elles puissent le partager avec d'autres parties prenantes client si nécessaire.

Comment Braze a suivi l'incident et les futurs plans de prévention

Avant cet incident, notre expérience nous avait amené à croire que notre réseau était résilient, grâce à nos commutateurs réseau redondants. Cependant, la panne a révélé que la topologie de notre réseau, qui nous avait bien soutenu pendant plus d'une décennie, était vulnérable à une panne catastrophique. Il est désormais clair qu’il faudra l’améliorer à l’avenir.

Depuis l'incident, Braze et Rackspace ont échangé et remplacé le commutateur défectueux, et l'équipe d'ingénierie de Rackspace a réalisé un audit complet de l'infrastructure réseau sur laquelle s'appuient les services Braze. Bien que les pannes matérielles soient incroyablement difficiles à prévoir, en particulier avec les équipements sous garantie, une surveillance est en place pour détecter les anomalies et garantir une réponse rapide. Les deux équipes collaborent désormais pour apporter des changements qui éviteront de futures boucles de réseau, même en cas de dysfonctionnement des équipements. La mise en œuvre de certaines modifications réseau prendra du temps, car nous prévoyons d'apporter des modifications significatives à la topologie de notre réseau afin d'améliorer encore la protection contre les boucles. Nous avons également ouvert des tickets d'assistance auprès de Cisco et de MongoDB pour mieux comprendre les scénarios de défaillance que nous avons rencontrés et pour améliorer la capacité des processus mongoD et mongoS à s'auto-réparer à la suite de pannes de réseau.

Nous sommes en contact quotidien avec Rackspace depuis l'incident pour prendre des mesures face aux changements à court terme et procéder à une amélioration plus large du réseau, et nous continuerons de le faire jusqu'à ce que nous soyons sûrs qu'une conception de réseau améliorée et plus résiliente a été obtenue.

Je tiens à nouveau à m'excuser pour cet incident et pour l'impact qu'il a eu sur votre entreprise et votre relation avec vos clients. La durée pendant laquelle Braze était indisponible est inacceptable. Notre direction technique et notre équipe de direction sont pleinement engagées à apporter tous les changements nécessaires pour identifier et résoudre les vulnérabilités en cas de panne aussi rapidement et efficacement que possible, afin que nous puissions à nouveau gagner votre confiance en tant que partenaire fiable et performant.

—Jon