Interruzione di Braze del 29 aprile: cosa è successo, perché si è verificata e come stiamo rispondendo

Comprendere l'architettura dei servizi della piattaforma Braze

Braze mantiene set di server separati per ciascuno dei nostri otto cluster statunitensi. I cluster Braze US da 01 a 07 sono ospitati su Amazon Web Services (AWS), mentre il cluster Braze US 08 è ospitato su Microsoft Azure. In ciascuno di questi ambienti, Braze utilizza più zone di disponibilità e presenta ridondanze per ciascuna parte del nostro sistema. In caso di guasto di una zona di disponibilità, disabilitiamo in modo sistematico e trasparente le zone di disponibilità compromessa dall'instradamento e dall'elaborazione. Ciò ci consente di mantenere in modo affidabile la fornitura del servizio durante un'interruzione del servizio cloud.

Con poche eccezioni, ciascuno dei cluster statunitensi ha la propria infrastruttura dedicata e, ad eccezione di una manciata di componenti utilizzati in tutti gli ambienti in una determinata regione cloud, questi cluster sono fortemente isolati gli uni dagli altri, al fine di ridurre il rischio che un'interruzione in un cluster influenzerà altri cluster.

A causa dell'intensità del carico di lavoro di elaborazione in tempo reale della piattaforma Braze, dal 2013 abbiamo integrato il nostro utilizzo di AWS e Azure collaborando con Rackspace per ospitare hardware configurato su misura per eseguire i database MongoDB. I nostri ambienti AWS e Azure sono configurati con connettori cloud privati ​​AWS Direct Connect e Azure ExpressRoute, che collegano l'ambiente cloud alla nostra rete interna mantenuta nei data center Rackspace tramite un cavo in fibra ottica dedicato. Questa connessione crittografata, alimentata da collegamenti di rete che supportano più interfacce che spingono oltre 100 gigabit di traffico di rete al secondo, fornisce un accesso altamente performante tra il nostro cloud e gli ambienti Rackspace.

Il nostro ambiente personalizzato in Rackspace ospita centinaia di server fisici conservati in armadi dedicati a Braze. Questa configurazione include alimentatori ridondanti e switch top-of-rack ridondanti. Gli switch top-of-rack sono dispositivi di rete che si trovano in un server rack e collegano insieme dispositivi e server nello stesso server rack. Questi switch vengono testati almeno una volta all'anno per il failover senza impatto; il test dell'anno scorso si è svolto con successo il 3 agosto 2023. In questo ambiente personalizzato, manteniamo decine di migliaia di contenitori virtualizzati per i database MongoDB. Analogamente ai nostri ambienti cloud, manteniamo elevati livelli di isolamento fisico tra i contenitori su diversi cluster statunitensi per ridurre al minimo le interruzioni e ridurre il rischio che un contenitore possa influenzare altri contenitori all'interno dei nostri database.

La causa dell'interruzione del 29 aprile e il modo in cui abbiamo risposto

Il guasto iniziale del passaggio parziale

Il 29 aprile alle 09:15 UTC si è verificato un guasto parziale di uno switch di rete Cisco Nexus primario collegato ai nostri armadi server Rackspace. Lo switch malfunzionante si è guastato in modo tale da non attivare automaticamente lo switch di rete secondario tramite un failover, mantenendo invece lo switch malfunzionante come primario.

Gli switch di rete instradano il traffico inoltrando i pacchetti di rete, chiamati "frame", alla loro destinazione. Per fare ciò in modo efficiente, questi switch mantengono la comprensione della topologia di rete che collega insieme i dispositivi. È comune che i percorsi di rete cambino dinamicamente in risposta a guasti o lentezza dei singoli componenti. Quando si verificano questi cambiamenti, gli switch e gli altri dispositivi di rete comunicano tra loro per mantenere una comprensione accurata della topologia della rete.

Nelle reti di grandi dimensioni, spesso esiste più di un percorso tra i dispositivi, il che può causare "loop" di routing (ovvero una condizione in cui i pacchetti non riescono a fermarsi alla destinazione prevista e tornano invece al punto di origine). I loop possono creare "tempeste di trasmissione", in cui il traffico finisce per ripetersi indefinitamente, saturando i collegamenti di rete e causando interruzioni. Per evitare che ciò accada, gli interruttori sono programmati per inviare messaggi che aiutano a identificare i collegamenti ridondanti. Questi messaggi sono chiamati spanning tree bridge protocol data unit (BPDU) e fanno parte di un protocollo di rete chiamato Spanning Tree Protocol (STP). Gli switch utilizzano quindi queste informazioni per bloccare le porte di traffico al fine di evitare che si verifichino loop quando instradano il traffico. Se un collegamento fisico o uno switch si guasta, l'STP aiuta a fornire ridondanza, poiché può essere utilizzato per identificare altri collegamenti fisici su cui può essere inviato il traffico e promuovere il collegamento precedentemente passivo (cioè bloccato) ad attivo per mantenere le connessioni.

All'inizio dell'incidente del 29 aprile, quando lo switch ha iniziato a funzionare male, ha iniziato a inoltrare continuamente notifiche di modifica della topologia e BPDU, inondando la rete con tali avvisi di modifica. Questi pacchetti si propagavano agli switch di distribuzione e ad altri switch, causando un loop di commutazione dello spanning tree che ha provocato un'interruzione completa della rete. Mentre l'STP è in atto per ridurre i loop di rete bloccando le porte di rete in cui viene rilevato il loop, durante l'incidente del 29 aprile il traffico spanning tree inoltrato in modo errato dallo switch malfunzionante ha causato la rianalisi delle topologie spanning tree da parte di altri switch nella rete. Quindi, poiché gli altri switch hanno rilevato che un pacchetto BPDU ad alta priorità proveniva dallo switch malfunzionante, gli switch di distribuzione hanno iniziato a inoltrare su porte precedentemente bloccate e hanno provocato un loop di commutazione che ha sovraccaricato la rete e l'ha bloccata.

La bonifica di Rackspace

Come risultato di questa attività, i tecnici del data center Rackspace hanno ricevuto avvisi intorno alle 09:20 UTC riguardanti problemi imprevisti di connettività di rete e hanno iniziato ad affrontare il problema. Tra le 09:39 e le 10:03 UTC, i tecnici del data center Rackspace hanno sospeso lo switch di rete, spento e riacceso lo switch primario e forzato le schede di interfaccia di rete (NIC) nell'armadietto del server al failover sullo switch secondario. Dopo il failover della scheda NIC, la connettività è stata ripristinata sui server fisici nell'ambiente Braze.

Come funzionano i database Braze MongoDB

I database MongoDB utilizzati da Braze consentono di archiviare i dati su più server di database noti come "shard". MongoDB fornisce un servizio di routing chiamato "mongoS", che elabora le query dai servizi della piattaforma Braze, determina la posizione dei dati rilevanti in un cluster frammentato, quindi instrada una query al database MongoDB appropriato. Braze ha centinaia di database MongoDB distinti, comprendenti oltre 15.000 processi "mongoD", che sono i programmi che eseguono il database e memorizzano i dati per un particolare frammento MongoDB.

Ogni frammento di database è costituito da un processo mongoD primario e almeno due processi mongoD secondari, che garantiscono elevata disponibilità in caso di guasto. Ogni server mongoS mantiene una connessione di rete a ogni mongoD a cui può instradare le query. Questi processi mongoD si collegano anche ai primari e ai secondari nella sua configurazione; questo è noto come set di repliche. Se un mongoS non riesce a connettersi a un determinato mongoD, contrassegnerà il processo come offline e pianificherà un nuovo tentativo. Allo stesso modo, se un mongoD non riesce a connettersi ad altri membri mongoD del suo set di repliche entro un secondo, scadrà, contrassegnerà tali processi come offline e pianificherà un nuovo tentativo.

L'impatto del loop di rete sui nostri processi MongoDB e il modo in cui abbiamo risposto

Durante il loop di rete, poiché i nostri processi MongoDB non potevano connettersi normalmente, ognuno ha contrassegnato tutti i processi associati come offline. Cioè, ogni processo mongoS ha contrassegnato tutti i processi mongoD associati come offline e ogni processo mongoD ha contrassegnato i relativi membri del set di repliche come offline. Tuttavia, anche dopo che la connettività di rete è stata ripristinata sui nostri server fisici da Rackspace, né i processi mongoS né mongoD hanno ristabilito tutte le connessioni agli altri processi che erano stati contrassegnati offline.

A questo punto, al fine di assistere negli sforzi di riparazione del nostro team di amministratori di database (DBA) di Rackspace, i team di Braze DevOps hanno iniziato a eseguire rapidamente il debug e a testare metodi per ripristinare tale connettività. La nostra indagine ha stabilito che l'unica opzione disponibile era riavviare ciascuno dei quasi 16.000 processi mongoD e degli oltre 6.000 mongoS nei rispettivi contenitori virtualizzati. Considerata la portata di questa impresa e il fatto che non esisteva l’automazione per riavviare rapidamente così tanti container, gli ingegneri di Rackspace hanno scritto un nuovo codice durante l’incidente per creare funzionalità di automazione al volo.

Sfortunatamente, con l'accelerazione del processo di riavvio, si è verificato un altro problema nel sistema DNS (Domain Name System). Quando i processi mongoS e mongoD diventano online, richiedono informazioni dai risolutori DNS in un processo noto come ricerca DNS. Con le continue ricerche DNS guidate dalla velocità dei riavvii, i server DNS sono stati sottoposti a carichi pesanti, con conseguenti timeout della connettività sui livelli mongoS mentre si riconnettevano ai processi mongoD. Per far fronte a questo carico crescente, il nostro team Rackspace ha aumentato la capacità della CPU DNS, ma è stato poi costretto a riavviare il livello mongoS una seconda volta per creare connessioni integre da ciascun mongoS ai processi mongoD associati.

Intorno alle 17:05 UTC, il processo di riavvio ha consentito ad alcuni cluster di iniziare a tornare online. Con il recupero delle prestazioni del database e la stabilizzazione dei cluster, Braze ha continuato ad aumentare la capacità di elaborazione dei dati e di invio di messaggi; tuttavia, tale sforzo è stato complicato dall'enorme arretrato derivante da una precedente indisponibilità.

Date le dimensioni e la sofisticatezza del nostro ambiente database Rackspace, che consiste di centinaia di database distinti, la durata dell'interruzione e il volume risultante del nostro arretrato (che rappresenta miliardi di messaggi e miliardi di punti dati acquisiti), il processo di ripristino richiesto in -adattamento immediato dei nostri normali processi di recupero. Ciò era necessario per garantire che le risorse del database rimanessero in equilibrio con le richieste di elaborazione in corso, inclusa l’introduzione di un’enorme quantità di capacità di elaborazione complessiva.

Tuttavia, così facendo, Braze ha raggiunto un limite AWS sul numero di CPU virtuali che potevamo fornire, impedendoci di aggiungere ulteriore capacità del server. Il team Braze ha rapidamente intensificato questa circostanza con il nostro team AWS e ha ricevuto un aumento, consentendo ai nostri ingegneri di aumentare la capacità di elaborazione dei nostri server a un livello record, che era superiore di oltre il 50% rispetto alla nostra precedente capacità massima, che era stata raggiunta su Black Venerdì 2023.

Entro le 20:30 UTC, tutti i nostri cluster statunitensi tranne US 01, US 03 e US 08 avevano terminato l'elaborazione dei rispettivi arretrati e i cluster rimanenti stavano elaborando a velocità di picco o superiori rispetto al giorno prima dell'incidente. Nel giro di poche ore, tutti i cluster sono stati ripristinati per l'elaborazione in tempo reale e abbiamo dichiarato risolto l'incidente.

Come Braze comunica gli aggiornamenti durante gli incidenti

Una comunicazione chiara e frequente durante incidenti come questo è essenziale. Anche se i problemi tecnici in generale sono eventi rari e un problema di questa portata era inaudito in precedenza per Braze, facciamo sempre del nostro meglio per comunicare con le parti interessate con chiarezza e rapidità.

In situazioni come questa, i principi guida che informano la nostra strategia di comunicazione sono l’onestà, la trasparenza e la fiducia. Sappiamo che abbiamo solo un’opportunità per essere onesti e schietti su ciò che sta accadendo e che la trasparenza sugli incidenti, sia nel momento presente che dopo la loro risoluzione, è essenziale per mantenere la fiducia. In fin dei conti, vogliamo che i nostri clienti abbiano la certezza che Braze farà sempre tutto ciò che è in nostro potere per spiegare, rimediare e prevenire il ripetersi di qualsiasi incidente.

Durante gli incidenti, utilizziamo la nostra Pagina di stato per gestire le comunicazioni e fornire aggiornamenti regolari sulla situazione; Incoraggio vivamente i clienti a registrarsi per ricevere aggiornamenti da quella pagina per rimanere aggiornati. Durante l'interruzione del 29 aprile, abbiamo integrato questi frequenti aggiornamenti della Pagina di stato con un'e-mail del mio collega cofondatore e nostro CEO, Bill Magnuson. Questo messaggio è stato inviato a tutti gli utenti della dashboard di Braze ed è stato fornito ai nostri team account per condividerlo con le altre parti interessate dei clienti, secondo necessità.

Come Braze ha seguito l'incidente e i futuri piani di prevenzione

Prima di questo incidente, la nostra esperienza ci aveva portato a credere che la nostra rete fosse resiliente, grazie ai nostri switch di rete ridondanti. Tuttavia, l’interruzione ha rivelato che la nostra topologia di rete, che ci aveva supportato bene per oltre un decennio, era vulnerabile a guasti catastrofici. Ora è chiaro che in futuro dovrà essere potenziato.

Dopo l'incidente, Braze e Rackspace si sono scambiati e hanno sostituito lo switch difettoso, e il team di ingegneri di Rackspace ha completato un audit completo dell'infrastruttura di rete su cui fanno affidamento i servizi Braze. Sebbene i guasti hardware siano incredibilmente difficili da prevedere, soprattutto con le apparecchiature in garanzia, è in atto un monitoraggio per rilevare anomalie e garantire una risposta rapida. Entrambi i team stanno ora collaborando per apportare modifiche che impediranno futuri loop di rete, anche in caso di malfunzionamento delle apparecchiature. L'implementazione di alcune modifiche alla rete richiederà tempo, poiché prevediamo di apportare modifiche significative alla nostra topologia di rete per migliorare ulteriormente la protezione contro i loop. Abbiamo anche aperto ticket di supporto sia con Cisco che con MongoDB per comprendere meglio gli scenari di errore che abbiamo riscontrato e per migliorare la capacità dei processi mongoD e mongoS di autoripararsi in seguito a guasti di rete.

Siamo stati in contatto quotidiano con Rackspace sin dall'incidente per agire sui cambiamenti a breve termine e realizzare un miglioramento più ampio della rete, e continueremo a farlo finché non avremo la certezza che sia stato raggiunto un design di rete migliorato e più resiliente.

Voglio scusarmi nuovamente per questo incidente e per l'impatto che ha avuto sulla tua attività e sul rapporto con i tuoi clienti. Il tempo in cui Braze non è stato disponibile è inaccettabile. La nostra leadership tecnica e il nostro team esecutivo sono pienamente impegnati ad apportare tutte le modifiche necessarie per identificare e risolvere le vulnerabilità legate alle interruzioni nel modo più rapido ed efficiente possibile, in modo da poter guadagnare ancora una volta la vostra fiducia come partner affidabile e performante.

— Jon