Der Braze-Ausfall am 29. April: Was geschah, warum er auftrat und wie wir reagieren

Verständnis der Servicearchitektur der Braze-Plattform

Braze unterhält separate Serversätze für jeden unserer acht US-Cluster. Die Cluster Braze US 01 bis 07 werden auf Amazon Web Services (AWS) gehostet, während der Cluster Braze US 08 auf Microsoft Azure gehostet wird. In jeder dieser Umgebungen nutzt Braze mehrere Verfügbarkeitszonen und verfügt über Redundanzen für jeden Teil unseres Systems. Im Falle eines Ausfalls einer Verfügbarkeitszone deaktivieren wir routinemäßig und transparent beeinträchtigte Verfügbarkeitszonen für die Weiterleitung und Verarbeitung. Dadurch ist es uns möglich, die Servicebereitstellung auch während eines Ausfalls eines Cloud-Service-Providers zuverlässig aufrechtzuerhalten.

Mit wenigen Ausnahmen verfügt jeder der US-Cluster über eine eigene dedizierte Infrastruktur und bis auf eine Handvoll Komponenten, die in allen Umgebungen einer bestimmten Cloud-Region verwendet werden, sind diese Cluster stark voneinander isoliert, um das Risiko zu verringern dass eine Störung in einem Cluster Auswirkungen auf andere Cluster hat.

Aufgrund der hohen Echtzeitverarbeitungslast der Braze-Plattform haben wir seit 2013 unsere Nutzung von AWS und Azure durch eine Partnerschaft mit Rackspace ergänzt, um individuell konfigurierte Hardware für die Ausführung von MongoDB-Datenbanken zu hosten. Unsere AWS- und Azure-Umgebungen sind mit privaten Cloud-Anschlüssen von AWS Direct Connect und Azure ExpressRoute konfiguriert und verbinden die Cloud-Umgebung über ein dediziertes Glasfaserkabel mit unserem internen Netzwerk, das in den Rackspace-Rechenzentren verwaltet wird. Diese verschlüsselte Verbindung, die über Netzwerkverbindungen betrieben wird, die mehrere Schnittstellen unterstützen und über 100 Gigabit Netzwerkverkehr pro Sekunde übertragen, ermöglicht einen hochleistungsfähigen Zugriff zwischen unserer Cloud und den Rackspace-Umgebungen.

Unsere maßgeschneiderte Umgebung in Rackspace beherbergt Hunderte von physischen Servern, die in Braze-Schränken untergebracht sind. Dieses Setup umfasst redundante Netzteile und redundante Top-of-Rack-Switches. Top-of-Rack-Switches sind Netzwerkgeräte, die in einem Server-Rack sitzen und die Geräte und Server im selben Server-Rack miteinander verbinden. Diese Switches werden mindestens einmal jährlich auf einen reibungslosen Failover getestet. Der letztjährige Test wurde am 3. August 2023 erfolgreich durchgeführt. In dieser benutzerdefinierten Umgebung verwalten wir Zehntausende virtualisierte Container für MongoDB-Datenbanken. Ähnlich wie in unseren Cloud-Umgebungen halten wir ein hohes Maß an physischer Isolation zwischen Containern in verschiedenen US-Clustern aufrecht, um Störungen zu minimieren und das Risiko zu verringern, dass ein Container andere Container in unseren Datenbanken beeinträchtigen könnte.

Die Ursache des Ausfalls am 29. April und wie wir reagiert haben

Der erste teilweise Switch-Fehler

Am 29. April um 09:15 UTC kam es zu einem teilweisen Ausfall eines primären Cisco Nexus-Netzwerk-Switches, der mit unseren Rackspace-Serverschränken verbunden war. Der fehlerhafte Switch ist auf eine Weise ausgefallen, die dazu geführt hat, dass der sekundäre Netzwerk-Switch nicht automatisch über ein Failover aktiviert wurde und stattdessen der fehlerhafte Switch als primärer Switch beibehalten wurde.

Netzwerk-Switches leiten den Datenverkehr weiter, indem sie Netzwerkpakete – sogenannte „Frames“ – an ihr Ziel weiterleiten. Um dies effizient zu tun, behalten diese Switches ein Verständnis der Netzwerktopologie bei, die Geräte miteinander verbindet. Es kommt häufig vor, dass sich Netzwerkrouten als Reaktion auf den Ausfall oder die Verlangsamung einzelner Komponenten dynamisch ändern. Wenn diese Änderungen auftreten, kommunizieren Switches und andere Netzwerkgeräte miteinander, um ein genaues Verständnis der Netzwerktopologie zu gewährleisten.

In großen Netzwerken gibt es oft mehr als einen Pfad zwischen Geräten, was zu Routing-„Schleifen“ führen kann (d. h. ein Zustand, bei dem Pakete nicht an ihrem beabsichtigten Ziel anhalten und stattdessen zu ihrem Ursprungsort zurückkehren). Schleifen können zu „Broadcast-Stürmen“ führen, bei denen der Datenverkehr endlos in Schleifen endet, Netzwerkverbindungen überlastet und Ausfälle verursacht. Um dies zu verhindern, sind Switches so programmiert, dass sie Nachrichten senden, die dabei helfen, redundante Verbindungen zu identifizieren. Diese Nachrichten werden Spanning Tree Bridge Protocol Data Units (BPDUs) genannt und sind Teil eines Netzwerkprotokolls namens Spanning Tree Protocol (STP). Switches verwenden diese Informationen dann, um Verkehrsports zu blockieren, um das Auftreten von Schleifen beim Weiterleiten des Datenverkehrs zu verhindern. Wenn eine physische Verbindung oder ein Switch ausfällt, trägt das STP zur Bereitstellung von Redundanz bei, da es verwendet werden kann, um andere physische Verbindungen zu identifizieren, über die Datenverkehr gesendet werden kann, und die zuvor passive (dh blockierte) Verbindung in eine aktive Verbindung umzuwandeln, um die Verbindungen aufrechtzuerhalten.

Zu Beginn des Vorfalls vom 29. April, als der Switch eine Fehlfunktion aufwies, begann er kontinuierlich Topologie-Änderungsbenachrichtigungen und BPDUs weiterzuleiten und überschwemmte das Netzwerk mit diesen Änderungsbenachrichtigungen. Diese Pakete breiteten sich zu Verteilungs-Switches und anderen Switches aus und verursachten eine Spanning-Tree-Switching-Schleife, die zu einem vollständigen Netzwerkausfall führte. Während das STP vorhanden ist, um Netzwerkschleifen zu reduzieren, indem es Netzwerkports blockiert, an denen Schleifen erkannt werden, führte der falsch weitergeleitete Spanning-Tree-Verkehr vom fehlerhaften Switch während des Vorfalls vom 29. April dazu, dass andere Switches im Netzwerk ihre Spanning-Tree-Topologien erneut analysierten. Da diese anderen Switches dann erkannten, dass ein BPDU-Paket mit hoher Priorität von dem fehlerhaften Switch kam, begannen die Verteilungs-Switches mit der Weiterleitung an zuvor blockierten Ports, was zu einer Switching-Schleife führte, die das Netzwerk überlastete und lahmlegte.

Die Rackspace-Sanierung

Aufgrund dieser Aktivität erhielten die Rechenzentrumstechniker von Rackspace um ca. 09:20 UTC eine Benachrichtigung über die unerwarteten Netzwerkkonnektivitätsprobleme und begannen mit der Behebung des Problems. Zwischen 09:39 und 10:03 UTC setzten die Ingenieure des Rackspace-Rechenzentrums den Netzwerk-Switch außer Betrieb, schalteten den primären Switch aus und wieder ein und zwangen die Netzwerkschnittstellenkarten (NIC) im Serverschrank zum Failover auf den sekundären Switch. Nach dem NIC-Failover wurde die Konnektivität zu den physischen Servern in der Braze-Umgebung wiederhergestellt.

Wie Braze MongoDB-Datenbanken funktionieren

Die von Braze verwendeten MongoDB-Datenbanken ermöglichen die Speicherung von Daten auf mehreren Datenbankservern, die als „Shards“ bezeichnet werden. MongoDB stellt einen Routing-Dienst namens „mongoS“ bereit, der Anfragen von den Diensten der Braze-Plattform verarbeitet, den Speicherort der relevanten Daten in einem Sharded-Cluster bestimmt und dann eine Anfrage an die entsprechende MongoDB-Datenbank weiterleitet. Braze verfügt über Hunderte verschiedener MongoDB-Datenbanken, die über 15.000 „MongoD“-Prozesse umfassen. Dabei handelt es sich um Programme, die die Datenbank ausführen und Daten für einen bestimmten MongoDB-Shard speichern.

Jeder Datenbank-Shard besteht aus einem primären MongoD- und mindestens zwei sekundären MongoD-Prozessen, was im Falle eines Ausfalls eine hohe Verfügbarkeit gewährleistet. Jeder MongoS-Server unterhält eine Netzwerkverbindung zu jedem MongoD, an den er Abfragen weiterleiten kann. Diese MongoD-Prozesse stellen in ihrer Konfiguration auch eine Verbindung zu den primären und sekundären Prozessen her; Dies wird als Replikatsatz bezeichnet. Wenn ein mongoS keine Verbindung zu einem bestimmten mongoD herstellen kann, markiert es diesen Prozess als offline und plant einen Wiederholungsversuch. Wenn ein mongoD nicht innerhalb einer Sekunde eine Verbindung zu anderen mongoD-Mitgliedern seines Replikatsatzes herstellen kann, tritt eine Zeitüberschreitung auf, diese Prozesse werden als offline markiert und ein erneuter Versuch geplant.

Die Auswirkungen der Netzwerkschleife auf unsere MongoDB-Prozesse und wie wir reagiert haben

Da unsere MongoDB-Prozesse während der Netzwerkschleife keine normale Verbindung herstellen konnten, markierte jeder einzelne alle zugehörigen Prozesse als offline. Das heißt, jeder MongoS-Prozess hat alle zugehörigen MongoD-Prozesse als offline markiert, und jeder MongoD-Prozess hat seine zugehörigen Replikatsatzmitglieder als Offline markiert. Doch selbst nachdem Rackspace die Netzwerkkonnektivität zu unseren physischen Servern wiederhergestellt hatte, stellten weder die mongoS- noch die mongoD-Prozesse alle Verbindungen zu den anderen Prozessen wieder her, die als offline markiert wurden.

Um die Behebungsbemühungen unseres Rackspace-Datenbankadministratorteams (DBA) zu unterstützen, begannen die DevOps-Teams von Braze zu diesem Zeitpunkt mit der schnellen Fehlerbehebung und dem Testen von Methoden zur Wiederherstellung dieser Konnektivität. Unsere Untersuchung ergab, dass die einzige verfügbare Option darin bestand, jeden der fast 16.000 MongoD- und über 6.000 MongoS-Prozesse in ihren virtualisierten Containern neu zu starten. Angesichts des Ausmaßes dieses Unterfangens und der Tatsache, dass es keine Automatisierung gab, um so viele Container schnell neu zu starten, schrieben die Rackspace-Ingenieure während des Vorfalls neuen Code, um eine Automatisierungsfunktion im laufenden Betrieb zu schaffen.

Leider trat mit zunehmender Dauer des Neustartvorgangs ein weiteres Problem im Domain Name System (DNS)-System auf. Wenn mongoS- und mongoD-Prozesse online gehen, fordern sie Informationen von DNS-Resolvern in einem Prozess an, der als DNS-Suche bezeichnet wird. Aufgrund der kontinuierlichen DNS-Suchvorgänge, die durch die Geschwindigkeit der Neustarts bedingt waren, waren die DNS-Server stark ausgelastet, was zu Konnektivitäts-Timeouts auf den MongoS-Ebenen führte, als diese sich wieder mit den MongoD-Prozessen verbanden. Um dieser wachsenden Last gerecht zu werden, erhöhte unser Rackspace-Team die DNS-CPU-Kapazität, war dann aber gezwungen, die mongoS-Ebene ein zweites Mal neu zu starten, um gesunde Verbindungen von jedem mongoS zu den zugehörigen mongoD-Prozessen herzustellen.

Gegen 17:05 UTC ermöglichte der Neustartvorgang, dass einige Cluster wieder online gingen. Als sich die Datenbankleistung erholte und sich die Cluster stabilisierten, steigerte Braze die Datenverarbeitungs- und Messaging-Versandkapazität weiter. Diese Bemühungen wurden jedoch durch den massiven Rückstand aufgrund der vorherigen Nichtverfügbarkeit erschwert.

Angesichts der Größe und Komplexität unserer Rackspace-Datenbankumgebung, die aus Hunderten unterschiedlicher Datenbanken besteht, der Länge des Ausfalls und des daraus resultierenden Volumens unseres Rückstands (der Milliarden von Nachrichten und Milliarden aufgenommener Datenpunkte darstellt) ist der Wiederherstellungsprozess erforderlich -Momentane Anpassung unserer normalen Genesungsprozesse. Dies war notwendig, um sicherzustellen, dass die Datenbankressourcen im Gleichgewicht mit den laufenden Verarbeitungsanforderungen blieben, einschließlich der Einführung einer enormen Gesamtverarbeitungskapazität.

Dabei stieß Braze jedoch an eine AWS-Grenze hinsichtlich der Anzahl virtueller CPUs, die wir bereitstellen konnten, und hinderte uns daran, zusätzliche Serverkapazität hinzuzufügen. Das Braze-Team hat diesen Umstand schnell mit unserem AWS-Team eskaliert und eine Erhöhung erhalten, die es unseren Ingenieuren ermöglichte, die Verarbeitungskapazität unseres Servers auf ein Rekordniveau zu steigern, das mehr als 50 % höher war als unsere bisherige maximale Kapazität, die auf Black erreicht worden war Freitag 2023.

Um 20:30 UTC hatten alle unsere US-Cluster außer US 01, US 03 und US 08 die Verarbeitung ihrer Rückstände abgeschlossen, und die verbleibenden Cluster verarbeiteten die Spitzengeschwindigkeiten vom Tag vor dem Vorfall oder übertrafen sie. Innerhalb weniger Stunden konnten alle Cluster wieder in Echtzeit verarbeitet werden und wir erklärten den Vorfall für behoben.

Wie Braze Aktualisierungen bei Vorfällen kommuniziert

Bei Vorfällen wie diesem ist eine klare und häufige Kommunikation unerlässlich. Obwohl technische Probleme im Allgemeinen selten vorkommen und ein Problem dieser Größenordnung für Braze bisher unbekannt war, tun wir stets unser Bestes, um mit den betroffenen Parteien klar und schnell zu kommunizieren.

In solchen Situationen sind Ehrlichkeit, Transparenz und Vertrauen die Leitprinzipien unserer Kommunikationsstrategie. Wir wissen, dass wir nur eine Gelegenheit haben, ehrlich und offen über das Geschehen zu sprechen, und dass Transparenz über Vorfälle – sowohl im Moment als auch nach ihrer Lösung – für die Aufrechterhaltung des Vertrauens unerlässlich ist. Letztendlich möchten wir, dass unsere Kunden darauf vertrauen können, dass Braze immer alles in unserer Macht Stehende tun wird, um einen Vorfall zu erklären, zu beheben und ein erneutes Auftreten zu verhindern.

Bei Vorfällen nutzen wir unsere Statusseite, um die Kommunikation zu verwalten und regelmäßig über den aktuellen Stand der Dinge zu informieren. Ich empfehle Kunden dringend, sich auf dieser Seite für Updates anzumelden, um auf dem Laufenden zu bleiben. Während des Ausfalls am 29. April haben wir diese regelmäßigen Aktualisierungen der Statusseite durch eine E-Mail von meinem Mitbegründer und CEO Bill Magnuson ergänzt. Diese Nachricht wurde an alle Benutzer des Braze-Dashboards gesendet und unseren Account-Teams zur Verfügung gestellt, um sie bei Bedarf mit anderen Kundenbeteiligten zu teilen.

Wie Braze den Vorfall und zukünftige Präventionspläne weiterverfolgte

Vor diesem Vorfall hatten wir aufgrund unserer Erfahrungen geglaubt, dass unser Netzwerk aufgrund unserer redundanten Netzwerk-Switches ausfallsicher sei. Der Ausfall zeigte jedoch, dass unsere Netzwerktopologie – die uns über ein Jahrzehnt lang gut unterstützt hatte – anfällig für einen katastrophalen Ausfall war. Es ist jetzt klar, dass es in Zukunft verbessert werden muss.

Seit dem Vorfall haben Braze und Rackspace den fehlerhaften Switch ausgetauscht und ersetzt, und das Rackspace-Ingenieurteam hat eine vollständige Prüfung der Netzwerkinfrastruktur durchgeführt, auf die die Braze-Dienste angewiesen sind. Während Hardwareausfälle unglaublich schwer vorherzusagen sind, insbesondere bei Geräten, die unter die Garantie fallen, ist eine Überwachung vorhanden, um Anomalien zu erkennen und eine schnelle Reaktion sicherzustellen. Beide Teams arbeiten nun zusammen, um Änderungen vorzunehmen, die künftige Netzwerkschleifen verhindern, selbst im Falle einer Fehlfunktion der Ausrüstung. Die Implementierung einiger Netzwerkänderungen wird einige Zeit in Anspruch nehmen, da wir bedeutende Änderungen an unserer Netzwerktopologie vornehmen möchten, um den Schutz vor Schleifen weiter zu verbessern. Wir haben außerdem Support-Tickets sowohl bei Cisco als auch bei MongoDB geöffnet, um die aufgetretenen Fehlerszenarien besser zu verstehen und die Fähigkeit der MongoD- und MongoS-Prozesse zur Selbstheilung nach Netzwerkausfällen zu verbessern.

Wir stehen seit dem Vorfall in täglichem Kontakt mit Rackspace, um bei kurzfristigen Änderungen Maßnahmen zu ergreifen und eine größere Netzwerkerweiterung durchzuführen, und wir werden dies auch weiterhin tun, bis wir zuversichtlich sind, dass ein verbessertes, widerstandsfähigeres Netzwerkdesign erreicht wurde.

Ich möchte mich noch einmal für diesen Vorfall und die Auswirkungen entschuldigen, die er auf Ihr Unternehmen und Ihre Beziehung zu Ihren Kunden hatte. Die Zeitspanne, in der Braze nicht verfügbar war, ist inakzeptabel. Unsere technische Leitung und unser Führungsteam setzen sich voll und ganz dafür ein, alle notwendigen Änderungen vorzunehmen, um Ausfallschwachstellen so schnell und effizient wie möglich zu identifizieren und zu beheben, damit wir Ihr Vertrauen als zuverlässiger und leistungsstarker Partner erneut gewinnen können.

– Jon