Întreruperea Braze din 29 aprilie: ce s-a întâmplat, de ce s-a întâmplat și cum răspundem

Înțelegerea arhitecturii serviciilor platformei Braze

Braze menține seturi separate de servere pentru fiecare dintre cele opt clustere din SUA. Clusterele Braze US 01 până la 07 sunt găzduite pe Amazon Web Services (AWS), în timp ce clusterul Braze US 08 este găzduit pe Microsoft Azure. În fiecare dintre aceste medii, Braze utilizează mai multe zone de disponibilitate și are redundanțe pentru fiecare parte a sistemului nostru. În cazul unei eșecuri a zonei de disponibilitate, dezactivăm în mod obișnuit și transparent zonele de disponibilitate afectate de rutare și procesare. Acest lucru ne face posibil să menținem în mod fiabil capacitatea de livrare a serviciilor în timpul unei întreruperi a furnizorului de servicii cloud.

Cu puține excepții, fiecare dintre clusterele din SUA are propria infrastructură dedicată și, cu excepția câtorva componente care sunt utilizate în toate mediile dintr-o anumită regiune cloud, aceste clustere sunt puternic izolate unele de altele, pentru a reduce riscul. că o întrerupere a unui cluster va afecta alte clustere.

Datorită intensității volumului de lucru de procesare în timp real a platformei Braze, din 2013 ne-am suplimentat utilizarea AWS și Azure prin parteneriatul cu Rackspace pentru a găzdui hardware configurat personalizat pentru a rula bazele de date MongoDB. Mediile noastre AWS și Azure sunt configurate cu conectori cloud privat AWS Direct Connect și Azure ExpressRoute, legând mediul cloud la rețeaua noastră internă menținută în centrele de date Rackspace printr-un cablu de fibră optică dedicat. Această conexiune criptată, care este alimentată de legături de rețea care acceptă mai multe interfețe care împing peste 100 de gigabiți de trafic de rețea pe secundă, oferă acces foarte performant între cloud-ul nostru și mediile Rackspace.

Mediul nostru personalizat din Rackspace găzduiește sute de servere fizice ținute în cabinete dedicate Braze. Această configurație include surse de alimentare redundante și comutatoare redundante din partea de sus a rackului. Comutatoarele top-of-rack sunt dispozitive de rețea care se află într-un rack de server și conectează dispozitivele și serverele împreună în același rack de server. Aceste comutatoare sunt testate cel puțin anual pentru failover fără impact; Testul de anul trecut a avut loc cu succes pe 3 august 2023. În acest mediu personalizat, menținem zeci de mii de containere virtualizate pentru bazele de date MongoDB. Similar cu mediile noastre cloud, menținem niveluri ridicate de izolare fizică între containere din diferite clustere din SUA pentru a minimiza întreruperile și a reduce riscul ca un container să afecteze alte containere din bazele noastre de date.

Cauza întreruperii din 29 aprilie și modul în care am răspuns

Eșecul inițial al comutatorului parțial

Pe 29 aprilie, la 09:15 UTC, a avut loc o defecțiune parțială a unui comutator de rețea Cisco Nexus primar conectat la cabinetele noastre de server Rackspace. Comutatorul defectuos a eșuat într-un mod care nu a activat automat comutatorul de rețea secundar printr-un failover și, în schimb, a păstrat comutatorul defectuos ca principal.

Rețeaua schimbă traficul prin redirecționarea pachetelor de rețea – numite „cadre” – către destinația lor. Pentru a face acest lucru eficient, aceste comutatoare mențin o înțelegere a topologiei rețelei care conectează dispozitivele între ele. Este obișnuit ca rutele de rețea să se schimbe dinamic ca răspuns la defecțiunile componentelor individuale sau încetinirea. Când apar aceste modificări, comutatoarele și alte dispozitive de rețea comunică între ele pentru a menține o înțelegere exactă a topologiei rețelei.

În rețelele mari, de multe ori vor exista mai multe căi între dispozitive, ceea ce poate provoca „bucle” de rutare (adică o condiție în care pachetele nu se opresc la destinația dorită și, în schimb, se întorc înapoi la locul de origine). Buclele pot crea „furtuni de difuzare”, în care traficul ajunge să circule pe o perioadă nedeterminată, saturând legăturile de rețea și provocând întreruperi. Pentru a împiedica acest lucru, comutatoarele sunt programate să trimită mesaje care ajută la identificarea legăturilor redundante. Aceste mesaje sunt numite spanning tree bridge protocol data units (BPDU) și fac parte dintr-un protocol de rețea numit Spanning Tree Protocol (STP). Switch-urile folosesc apoi aceste informații pentru a bloca porturile de trafic pentru a preveni apariția buclelor atunci când direcționează traficul. Dacă o legătură fizică sau un comutator eșuează, STP-ul ajută la asigurarea redundanței, deoarece poate fi folosit pentru a identifica alte legături fizice prin care traficul poate fi trimis și pentru a promova legătura anterior pasivă (adică blocată) la activă pentru a menține conexiunile.

La debutul incidentului din 29 aprilie, când comutatorul a început să funcționeze defectuos, a început să transmită continuu notificări de modificare a topologiei și BPDU-uri, inundând rețeaua cu acele notificări de modificare. Aceste pachete s-au propagat la comutatoarele de distribuție și la alte comutatoare, provocând o buclă de comutare a arborelui care a dus la o întrerupere completă a rețelei. În timp ce STP-ul este în vigoare pentru a reduce buclele de rețea prin blocarea porturilor de rețea în care este detectată bucla, în timpul incidentului din 29 aprilie, traficul spanning tree redirecționat incorect de la comutatorul defectuos a determinat alte switch-uri din rețea să-și reanalizeze topologiile spanning tree. Apoi, pentru că acele alte comutatoare au detectat că un pachet BPDU cu prioritate înaltă provine de la comutatorul defect, comutatoarele de distribuție au început să redirecționeze pe porturi blocate anterior și au dus la o buclă de comutare care a supraîncărcat rețeaua și a dezactivat-o.

Remedierea Rackspace

Ca urmare a acestei activități, inginerii centrului de date Rackspace au primit alerte la aproximativ 09:20 UTC cu privire la problemele neașteptate de conectivitate la rețea și au început să rezolve problema. Între 09:39 și 10:03 UTC, inginerii centrului de date Rackspace au suspendat comutatorul de rețea, au oprit comutatorul principal și au forțat cardurile de interfață de rețea (NIC) din cabinetul serverului să treacă la comutatorul secundar. După failoverul NIC, conectivitatea a fost restabilită la serverele fizice din mediul Braze.

Cum funcționează bazele de date Braze MongoDB

Bazele de date MongoDB utilizate de Braze permit stocarea datelor pe mai multe servere de baze de date cunoscute ca „shards”. MongoDB oferă un serviciu de rutare numit „mongoS”, care procesează interogări de la serviciile platformei Braze, determină locația datelor relevante într-un cluster fragmentat, apoi direcționează o interogare către baza de date MongoDB corespunzătoare. Braze are sute de baze de date MongoDB distincte, cuprinzând peste 15.000 de procese „mongoD”, care sunt programele care rulează baza de date și stochează date pentru un anumit fragment MongoDB.

Fiecare fragment de bază de date constă dintr-un proces mongoD primar și cel puțin două procese mongoD secundare, care oferă o disponibilitate ridicată în cazul unei eșecuri. Fiecare server mongoS menține o conexiune de rețea la fiecare mongoD către care poate direcționa interogări. Aceste procese mongoD se conectează, de asemenea, la primar și secundar în configurația sa; acesta este cunoscut ca un set de replică. Dacă un mongoS nu se poate conecta la un anumit mongoD, va marca acel proces ca offline și va programa o reîncercare. În mod similar, dacă un mongoD nu se poate conecta la alți membri mongoD ai setului său de replică în decurs de o secundă, acesta va expira, va marca acele procese ca offline și va programa o reîncercare.

Impactul buclei de rețea asupra proceselor noastre MongoDB și modul în care am răspuns

În timpul buclei de rețea, deoarece procesele noastre MongoDB nu s-au putut conecta normal, fiecare a marcat toate procesele asociate ca fiind offline. Adică, fiecare proces mongoS a marcat toate procesele mongoD asociate ca fiind offline și fiecare proces mongoD și-a marcat membrii setului de replici aferente ca offline. Cu toate acestea, chiar și după ce conectivitatea la rețea a fost restabilită la serverele noastre fizice de către Rackspace, nici procesele mongoS sau mongoD nu au restabilit toate conexiunile la celelalte procese care fuseseră marcate offline.

În acest moment, pentru a ajuta la eforturile echipei noastre de remediere a administratorului bazei de date Rackspace (DBA), echipele Braze DevOps au început rapid depanarea și testarea metodelor de restabilire a conectivității. Investigația noastră a stabilit că singura opțiune disponibilă a fost repornirea fiecăruia dintre cele aproape 16.000 de procese mongoD și peste 6.000 de procese mongoS din containerele lor virtualizate. Având în vedere amploarea acestei activități și faptul că automatizarea nu a existat pentru a reporni atât de multe containere rapid, inginerii Rackspace au scris un nou cod în timpul incidentului pentru a crea capacitatea de automatizare din mers.

Din păcate, pe măsură ce procesul de repornire a crescut, a apărut o altă problemă în sistemul Domain Name System (DNS). Pe măsură ce procesele mongoS și mongoD vin online, ele solicită informații de la rezolutorii DNS într-un proces cunoscut sub numele de căutare DNS. Cu căutările DNS continue determinate de viteza repornirilor, serverele DNS au fost supuse unei sarcini grele, ceea ce a dus la expirări de conectivitate pe straturile mongoS pe măsură ce se reconectau la procesele mongoD. Pentru a face față acestei sarcini în creștere, echipa noastră Rackspace a crescut capacitatea procesorului DNS, dar a fost apoi forțată să repornească a doua oară nivelul mongoS pentru a crea conexiuni sănătoase de la fiecare mongoS la procesele mongoD asociate.

În jurul orei 17:05 UTC, procesul de repornire a permis ca unele clustere să înceapă să revină online. Pe măsură ce performanța bazei de date și-a revenit și clusterele s-au stabilizat, Braze a continuat să crească capacitatea de procesare a datelor și de trimitere a mesajelor; totuși, acel efort a fost complicat de acumularea masivă rezultată din indisponibilitatea anterioară.

Având în vedere amploarea și sofisticarea mediului nostru de baze de date Rackspace, care constă din sute de baze de date distincte, durata întreruperii și volumul rezultat al restanțelor noastre (reprezentând miliarde de mesaje și miliarde de puncte de date ingerate), procesul de recuperare necesar în -adaptarea momentului a proceselor noastre normale de recuperare. Acest lucru a fost necesar pentru a se asigura că resursele bazei de date au rămas în echilibru cu cererile de procesare în curs, inclusiv introducerea unei cantități masive de capacitate generală de procesare.

Cu toate acestea, făcând acest lucru, Braze a atins o limită AWS a numărului de procesoare virtuale pe care le-am putut furniza, împiedicându-ne să adăugăm orice capacitate suplimentară de server. Echipa Braze a escaladat rapid această circumstanță cu echipa noastră AWS și a primit o creștere, permițând inginerilor noștri să crească capacitatea de procesare a serverului nostru la un nivel record, care a fost cu peste 50% mai mare decât capacitatea noastră maximă anterioară, care fusese atinsă pe Black. Vineri 2023.

Până la ora 20:30 UTC, toate clusterele noastre din SUA, cu excepția US 01, US 03 și US 08, își terminaseră procesarea restanțelor, iar acele clustere rămase procesau la rate maxime sau peste din ziua precedentă incidentului. În câteva ore, toate clusterele au fost redate la procesare în timp real și am declarat că incidentul a fost rezolvat.

Cum comunică Braze actualizările în timpul incidentelor

Comunicarea clară și frecventă în timpul unor astfel de incidente este esențială. În timp ce problemele tehnice, în general, sunt rare, iar o problemă de această amploare nu s-a auzit anterior pentru Braze, întotdeauna facem tot posibilul să comunicăm cu părțile afectate cu claritate și rapiditate.

În astfel de situații, principiile directoare care ne informează strategia de comunicare sunt onestitatea, transparența și încrederea. Știm că avem o singură oportunitate de a fi sinceri și sinceri cu privire la ceea ce se întâmplă și că transparența cu privire la incidente – atât în ​​momentul de față, cât și după rezolvarea lor – este esențială pentru a menține încrederea. La sfârșitul zilei, dorim ca clienții noștri să aibă încredere că Braze va face întotdeauna tot ce ne stă în putere pentru a explica, remedia și preveni repetarea oricărui incident.

În timpul incidentelor, folosim Pagina noastră de stare pentru a gestiona comunicațiile și pentru a oferi actualizări regulate despre situația situației; Încurajez cu tărie clienții să se înscrie pentru actualizări de pe pagina respectivă pentru a rămâne la curent. În timpul întreruperii din 29 aprilie, am completat aceste actualizări frecvente ale paginii de stare cu un e-mail de la colegul meu cofondator și CEO-ul nostru, Bill Magnuson. Mesajul a fost trimis tuturor utilizatorilor tabloului de bord Braze și a fost furnizat echipelor noastre de cont pentru a le împărtăși altor părți interesate ale clienților, după cum este necesar.

Cum a urmărit Braze incidentul și planurile viitoare de prevenire

Înainte de acest incident, experiența noastră ne făcea să credem că rețeaua noastră este rezistentă, datorită comutatoarelor noastre redundante. Cu toate acestea, întreruperea a arătat că topologia rețelei noastre – care ne susținuse bine timp de peste un deceniu – era vulnerabilă la eșecuri catastrofale. Acum este clar că trebuie îmbunătățit în viitor.

De la incident, Braze și Rackspace au schimbat și au înlocuit comutatorul defect, iar echipa de ingineri Rackspace a finalizat un audit complet al infrastructurii de rețea pe care se bazează serviciile Braze. În timp ce defecțiunile hardware sunt incredibil de dificil de anticipat, în special cu echipamentele aflate în garanție, monitorizarea este în vigoare pentru a detecta anomaliile și pentru a asigura un răspuns rapid. Ambele echipe colaborează acum pentru a face modificări care vor preveni viitoarele bucle de rețea, chiar și în cazul unor echipamente defectuoase. Implementarea unor modificări de rețea va dura timp, deoarece intenționăm să aducem modificări semnificative topologiei rețelei noastre pentru a îmbunătăți și mai mult protecția împotriva buclelor. De asemenea, am deschis tichete de asistență atât cu Cisco, cât și cu MongoDB pentru a înțelege mai bine scenariile de eșec pe care le-am experimentat și pentru a îmbunătăți capacitatea proceselor mongoD și mongoS de a se auto-vindeca după defecțiunile rețelei.

Am fost în contact zilnic cu Rackspace de la incident pentru a lua măsuri asupra schimbărilor pe termen scurt și pentru a realiza o îmbunătățire mai mare a rețelei și vom continua să facem acest lucru până când vom avea încredere că a fost realizat un design de rețea îmbunătățit și mai rezistent.

Vreau să-mi cer scuze din nou pentru acest incident și pentru impactul pe care l-a avut asupra afacerii dumneavoastră și a relației dumneavoastră cu clienții dumneavoastră. Timpul în care Braze a fost indisponibil este inacceptabil. Conducerea noastră de inginerie și echipa executivă sunt pe deplin angajate să facă toate schimbările necesare pentru a identifica și rezolva vulnerabilitățile întrerupte cât mai rapid și eficient posibil, astfel încât să vă putem câștiga din nou încrederea ca partener de încredere și performant.

— Jon