Awaria lutowania 29 kwietnia: co się stało, dlaczego do tego doszło i jak reagujemy

Zrozumienie architektury usług platformy Braze

Braze utrzymuje oddzielne zestawy serwerów dla każdego z ośmiu naszych klastrów w USA. Klastry Braze US 01 do 07 są hostowane w serwisie Amazon Web Services (AWS), natomiast klaster Braze US 08 jest hostowany na platformie Microsoft Azure. W każdym z tych środowisk Braze korzysta z wielu stref dostępności i zapewnia redundancję dla każdej części naszego systemu. W przypadku awarii strefy dostępności rutynowo i przejrzyście wyłączamy routing i przetwarzanie stref o obniżonej dostępności. Dzięki temu możemy niezawodnie utrzymać dostarczalność usług w przypadku awarii dostawcy usług w chmurze.

Z nielicznymi wyjątkami każdy z klastrów w USA ma własną dedykowaną infrastrukturę i poza kilkoma komponentami używanymi we wszystkich środowiskach w danym regionie chmury, klastry te są silnie odizolowane od siebie, aby zmniejszyć ryzyko że zakłócenie w jednym klastrze będzie miało wpływ na inne klastry.

Ze względu na intensywność obciążenia platformą Braze przetwarzaniem w czasie rzeczywistym, od 2013 roku uzupełniliśmy wykorzystanie AWS i Azure, współpracując z firmą Rackspace w celu hostowania niestandardowo skonfigurowanego sprzętu do uruchamiania baz danych MongoDB. Nasze środowiska AWS i Azure są skonfigurowane za pomocą łączników chmury prywatnej AWS Direct Connect i Azure ExpressRoute, łączących środowisko chmury z naszą siecią wewnętrzną utrzymywaną w centrach danych Rackspace za pomocą dedykowanego kabla światłowodowego. To szyfrowane połączenie, obsługiwane przez łącza sieciowe obsługujące wiele interfejsów przesyłających ruch sieciowy z szybkością ponad 100 gigabitów na sekundę, zapewnia wysoce wydajny dostęp między naszą chmurą a środowiskami Rackspace.

Nasze niestandardowe środowisko w Rackspace obejmuje setki serwerów fizycznych przechowywanych w szafach dedykowanych Braze. Konfiguracja ta obejmuje nadmiarowe zasilacze i nadmiarowe przełączniki montowane na górze szafy. Przełączniki montowane na górze szafy to urządzenia sieciowe instalowane w szafie serwerowej i łączące urządzenia i serwery w tej samej szafie serwerowej. Przełączniki te są testowane co najmniej raz w roku pod kątem bezawaryjnego przełączania awaryjnego; ubiegłoroczny test odbył się pomyślnie 3 sierpnia 2023 roku. W tym niestandardowym środowisku utrzymujemy dziesiątki tysięcy zwirtualizowanych kontenerów dla baz danych MongoDB. Podobnie jak w przypadku naszych środowisk chmurowych, utrzymujemy wysoki poziom fizycznej izolacji pomiędzy kontenerami w różnych klastrach w USA, aby zminimalizować zakłócenia i zmniejszyć ryzyko, że jeden kontener może mieć wpływ na inne kontenery w naszych bazach danych.

Przyczyna awarii 29 kwietnia i nasza reakcja

Początkowa częściowa awaria przełącznika

W dniu 29 kwietnia o godzinie 09:15 UTC nastąpiła częściowa awaria głównego przełącznika sieciowego Cisco Nexus podłączonego do naszych szaf serwerowych Rackspace. Nieprawidłowo działający przełącznik uległ awarii w sposób, który nie aktywował automatycznie dodatkowego przełącznika sieciowego w wyniku przełączenia awaryjnego, a zamiast tego pozostawił nieprawidłowo działający przełącznik jako główny.

Przełączniki sieciowe kierują ruchem, przekazując pakiety sieciowe — zwane „ramkami” — do miejsca docelowego. Aby robić to skutecznie, przełączniki te rozumieją topologię sieci, która łączy ze sobą urządzenia. Trasy sieciowe często zmieniają się dynamicznie w odpowiedzi na awarie poszczególnych komponentów lub spowolnienie. Kiedy te zmiany nastąpią, przełączniki i inne urządzenia sieciowe komunikują się ze sobą, aby zachować dokładne zrozumienie topologii sieci.

W dużych sieciach często istnieje więcej niż jedna ścieżka między urządzeniami, co może powodować „pętle” routingu (tzn. stan, w którym pakiety nie zatrzymują się w zamierzonym miejscu docelowym i zamiast tego wracają do miejsca pochodzenia). Pętle mogą powodować „burze rozgłoszeniowe”, w wyniku których ruch zapętla się w nieskończoność, nasycając łącza sieciowe i powodując awarie. Aby temu zapobiec, przełączniki są zaprogramowane tak, aby wysyłać komunikaty pomagające zidentyfikować zbędne łącza. Komunikaty te nazywane są jednostkami danych protokołu mostu drzewa opinającego (BPDU) i stanowią część protokołu sieciowego zwanego protokołem drzewa opinającego (STP). Przełączniki wykorzystują następnie te informacje do blokowania portów ruchu, aby zapobiec występowaniu pętli podczas kierowania ruchem. W przypadku awarii łącza fizycznego lub przełącznika protokół STP pomaga zapewnić redundancję, ponieważ można go wykorzystać do identyfikacji innych łączy fizycznych, którymi może być przesyłany ruch, i promowania wcześniej pasywnego (tj. zablokowanego) łącza do aktywnego w celu utrzymania połączeń.

Na początku zdarzenia z 29 kwietnia, kiedy przełącznik zaczął działać nieprawidłowo, zaczął w sposób ciągły przesyłać powiadomienia o zmianach topologii i jednostki BPDU, zalewając sieć tymi powiadomieniami. Pakiety te rozprzestrzeniły się do przełączników dystrybucyjnych i innych przełączników, powodując pętlę przełączania drzewa opinającego, która doprowadziła do całkowitej awarii sieci. Chociaż protokół STP ma na celu ograniczenie pętli sieciowych poprzez blokowanie portów sieciowych, w których wykryto pętle, podczas incydentu z 29 kwietnia nieprawidłowo przekazany ruch drzewa opinającego z nieprawidłowo działającego przełącznika spowodował, że inne przełączniki w sieci ponownie przeanalizowały topologie drzewa opinającego. Następnie, ponieważ te inne przełączniki wykryły, że z nieprawidłowo działającego przełącznika pochodzi pakiet BPDU o wysokim priorytecie, przełączniki dystrybucyjne rozpoczęły przekazywanie dalej na wcześniej zablokowanych portach, co spowodowało pętlę przełączania, która przeciążyła sieć i ją wyłączyła.

Rekultywacja Rackspace

W wyniku tych działań inżynierowie centrum danych firmy Rackspace otrzymali około godziny 09:20 czasu UTC alerty dotyczące nieoczekiwanych problemów z łącznością sieciową i zaczęli rozwiązywać problem. Między godziną 09:39 a 10:03 czasu UTC inżynierowie centrum danych firmy Rackspace zawiesili przełącznik sieciowy, włączyli i ponownie włączyli przełącznik główny oraz wymusili przełączenie kart interfejsu sieciowego (NIC) w szafie serwerowej na przełącznik pomocniczy. Po przełączeniu awaryjnym karty sieciowej łączność z serwerami fizycznymi w środowisku Braze została przywrócona.

Jak działają bazy danych Braze MongoDB

Bazy danych MongoDB używane przez Braze umożliwiają przechowywanie danych na wielu serwerach baz danych, zwanych „fragmentami”. MongoDB udostępnia usługę routingu o nazwie „mongoS”, która przetwarza zapytania z usług platformy Braze, określa lokalizację odpowiednich danych w klastrze podzielonym na fragmenty, a następnie kieruje zapytanie do odpowiedniej bazy danych MongoDB. Braze ma setki różnych baz danych MongoDB, zawierających ponad 15 000 procesów „mongoD”, czyli programów uruchamiających bazę danych i przechowujących dane dla konkretnego fragmentu MongoDB.

Każdy fragment bazy danych składa się z jednego głównego procesu mongoD i co najmniej dwóch wtórnych procesów mongoD, co zapewnia wysoką dostępność w przypadku awarii. Każdy serwer mongoS utrzymuje połączenie sieciowe z każdym mongoD, do którego może kierować zapytania. Te procesy mongoD łączą się również z pierwotną i wtórną konfiguracją; nazywa się to zestawem replik. Jeśli mongoS nie może połączyć się z danym mongoD, oznaczy ten proces jako offline i zaplanuje ponowną próbę. Podobnie, jeśli mongoD nie może połączyć się z innymi członkami mongoD w swoim zestawie replik w ciągu jednej sekundy, przekroczy limit czasu, oznaczy te procesy jako offline i zaplanuje ponowną próbę.

Wpływ pętli sieciowej na nasze procesy MongoDB i sposób, w jaki zareagowaliśmy

Podczas pętli sieciowej, ponieważ nasze procesy MongoDB nie mogły normalnie się połączyć, każdy z nich oznaczył wszystkie powiązane z nim procesy jako offline. Oznacza to, że każdy proces mongoS oznaczył wszystkie powiązane z nim procesy mongoD jako offline, a każdy proces mongoD oznaczył powiązane elementy zestawu replik jako offline. Jednak nawet po przywróceniu łączności sieciowej z naszymi serwerami fizycznymi przez firmę Rackspace ani procesy mongoS, ani mongoD nie przywróciły wszystkich połączeń z innymi procesami, które zostały oznaczone jako offline.

W tym momencie, aby pomóc naszemu zespołowi administratora bazy danych Rackspace (DBA) w wysiłkach naprawczych, zespoły Braze DevOps rozpoczęły szybkie debugowanie i testowanie metod przywracania tej łączności. Nasze dochodzenie wykazało, że jedyną dostępną opcją było ponowne uruchomienie każdego z prawie 16 000 procesów mongoD i ponad 6000 mongoS w ich zwirtualizowanych kontenerach. Biorąc pod uwagę samą skalę tego przedsięwzięcia oraz fakt, że nie istniała automatyzacja umożliwiająca szybkie ponowne uruchomienie tak wielu kontenerów, inżynierowie firmy Rackspace napisali podczas incydentu nowy kod, aby stworzyć możliwość automatyzacji w locie.

Niestety, wraz z przyspieszeniem procesu ponownego uruchamiania, pojawił się kolejny problem w systemie systemu nazw domen (DNS). Gdy procesy mongoS i mongoD stają się online, żądają informacji od programów rozpoznawania nazw DNS w procesie znanym jako wyszukiwanie DNS. W związku z ciągłymi wyszukiwaniami DNS wynikającymi z szybkości ponownych uruchomień, serwery DNS znalazły się pod dużym obciążeniem, co doprowadziło do przekroczenia limitu czasu łączności w warstwach mongoS podczas ponownego łączenia się z procesami mongoD. Aby sprostać temu rosnącemu obciążeniu, nasz zespół Rackspace zwiększył pojemność procesora DNS, ale został następnie zmuszony do ponownego uruchomienia warstwy mongoS po raz drugi, aby utworzyć zdrowe połączenia między każdym mongoS a powiązanymi z nim procesami mongoD.

Około godziny 17:05 czasu UTC proces ponownego uruchomienia umożliwił niektórym klastrom powrót do trybu online. W miarę wzrostu wydajności bazy danych i stabilizacji klastrów Braze w dalszym ciągu zwiększał wydajność przetwarzania danych i wysyłania wiadomości; jednakże wysiłki te komplikowały ogromne zaległości wynikające z wcześniejszej niedostępności.

Biorąc pod uwagę skalę i stopień zaawansowania naszego środowiska baz danych Rackspace, które składa się z setek odrębnych baz danych, długość przerwy w działaniu i wynikającą z tego wielkość zaległości (reprezentujących miliardy wiadomości i miliardy przejętych punktów danych), proces odzyskiwania wymagany w - momentowa adaptacja naszych normalnych procesów zdrowienia. Było to konieczne, aby zapewnić równowagę zasobów bazy danych z bieżącymi potrzebami w zakresie przetwarzania, w tym wprowadzeniem ogromnej ogólnej mocy obliczeniowej.

Jednak robiąc to, Braze osiągnął limit AWS dotyczący liczby wirtualnych procesorów, które byliśmy w stanie udostępnić, uniemożliwiając nam dodanie jakiejkolwiek dodatkowej mocy obliczeniowej serwera. Zespół Braze szybko eskalował tę sytuację z naszym zespołem AWS i otrzymał podwyżkę, co pozwoliło naszym inżynierom zwiększyć moc obliczeniową naszego serwera do rekordowego poziomu, który był o ponad 50% wyższy niż nasza poprzednia maksymalna wydajność, która została osiągnięta na platformie Black Piątek 2023.

Do godziny 20:30 czasu UTC wszystkie nasze klastry w USA z wyjątkiem US 01, US 03 i US 08 zakończyły przetwarzanie swoich zaległości, a pozostałe klastry przetwarzały dane z szybkością maksymalną lub wyższą z dnia poprzedzającego incydent. W ciągu kilku godzin wszystkie klastry zostały przywrócone do przetwarzania w czasie rzeczywistym i ogłosiliśmy, że incydent został rozwiązany.

W jaki sposób Braze przekazuje aktualizacje podczas incydentów

Jasna i częsta komunikacja podczas takich incydentów jest niezbędna. Chociaż problemy techniczne w ogóle zdarzają się rzadko, a problem tej skali był wcześniej niespotykany w firmie Braze, zawsze dokładamy wszelkich starań, aby komunikować się z zainteresowanymi stronami w sposób przejrzysty i szybki.

W takich sytuacjach zasadami przewodnimi, na których opiera się nasza strategia komunikacji, są uczciwość, przejrzystość i zaufanie. Wiemy, że mamy tylko jedną okazję, aby szczerze i otwarcie powiedzieć o tym, co się dzieje, oraz że przejrzystość w zakresie incydentów – zarówno w chwili obecnej, jak i po ich rozwiązaniu – jest niezbędna do utrzymania zaufania. Ostatecznie chcemy, aby nasi klienci mieli pewność, że Braze zawsze zrobi wszystko, co w naszej mocy, aby wyjaśnić, naprawić i zapobiec ponownemu wystąpieniu jakiegokolwiek incydentu.

Podczas incydentów używamy naszej Strony Stanu do zarządzania komunikacją i regularnego dostarczania aktualnych informacji o sytuacji; Gorąco zachęcam klientów do zapisywania się na aktualizacje z tej strony, aby być na bieżąco. Podczas przerwy w działaniu 29 kwietnia uzupełniliśmy te częste aktualizacje strony statusu e-mailem od mojego współzałożyciela i naszego dyrektora generalnego, Billa Magnusona. Wiadomość ta została wysłana do wszystkich użytkowników pulpitu nawigacyjnego Braze i przekazana naszym zespołom ds. kont, aby w razie potrzeby udostępnić je innym interesariuszom klientów.

Jak Braze postąpił zgodnie z incydentem i planami zapobiegania na przyszłość

Przed tym incydentem nasze doświadczenie skłoniło nas do przekonania, że ​​nasza sieć jest odporna dzięki nadmiarowym przełącznikom sieciowym. Jednak awaria ujawniła, że ​​topologia naszej sieci – która dobrze nas wspierała przez ponad dekadę – była podatna na katastrofalne awarie. Obecnie jest jasne, że w przyszłości należy je ulepszyć.

Od czasu zdarzenia firmy Braze i Rackspace wymieniły wadliwy przełącznik, a zespół inżynierów firmy Rackspace przeprowadził pełny audyt infrastruktury sieciowej, na której opierają się usługi Braze. Chociaż awarie sprzętu są niezwykle trudne do przewidzenia, szczególnie w przypadku sprzętu objętego gwarancją, stosuje się monitorowanie w celu wykrycia nieprawidłowości i zapewnienia szybkiej reakcji. Obydwa zespoły współpracują teraz nad wprowadzeniem zmian, które zapobiegną przyszłym pętlom sieci, nawet w przypadku nieprawidłowego działania sprzętu. Wdrożenie niektórych zmian sieciowych zajmie trochę czasu, ponieważ planujemy wprowadzenie znaczących zmian w topologii naszej sieci w celu dalszej poprawy ochrony przed pętlami. Otworzyliśmy także zgłoszenia do pomocy technicznej zarówno w Cisco, jak i MongoDB, aby lepiej zrozumieć scenariusze awarii, których doświadczyliśmy, oraz poprawić zdolność procesów mongoD i mongoS do samonaprawy po awariach sieci.

Od czasu zdarzenia jesteśmy w codziennym kontakcie z firmą Rackspace, aby podjąć działania w sprawie krótkoterminowych zmian i przeprowadzić większe ulepszenia sieci, i będziemy to kontynuować, dopóki nie uzyskamy pewności, że osiągnięto ulepszony, bardziej odporny projekt sieci.

Chcę jeszcze raz przeprosić za to wydarzenie i jego wpływ na Twoją firmę i relacje z klientami. Czas, w którym Braze był niedostępny, jest nie do zaakceptowania. Nasze kierownictwo inżynieryjne i zespół wykonawczy są w pełni zaangażowane we wprowadzanie wszystkich niezbędnych zmian niezbędnych do identyfikowania i usuwania luk w zabezpieczeniach tak szybko i efektywnie, jak to możliwe, abyśmy mogli ponownie zdobyć Twoje zaufanie jako niezawodnego i wydajnego partnera.

— Jon