主頁
2024 年 4 月 29 日星期一，Braze 平台的美國叢集幾乎完全中斷，全部或部分中斷持續了近 11 個小時，影響了客戶對我們儀表板的存取以及資料處理和訊息發送。 在 Braze 13 年的歷史中，這是我們第一次也是唯一一次如此嚴重的事件。 我們與客戶的關係建立在信任的基礎上，我們始終對建立彈性系統感到非常自豪，這些系統使我們的平台即使在苛刻的工作負載下也能保持可用性和效能。 在這次中斷期間，我們未能兌現這項承諾，對於這對我們每位客戶造成的影響，我們深表歉意。
為了幫助您更好地了解發生的情況和原因，我將提供有關我們的架構的一些重要背景信息，詳細描述中斷的原因，引導您完成我們已經做出的更改，並概述我們將要開展的工作並在近期和未來實施。
Braze 為我們的八個美國叢集中的每一個叢集維護獨立的伺服器群組。 Braze US 01 至 07 叢集託管在 Amazon Web Services (AWS) 上，而 Braze US 08 叢集託管在 Microsoft Azure 上。 在每種環境中，Braze 都使用多個可用區，並且系統的每個部分都有冗餘。 如果出現可用區故障，我們會定期、透明地停用受損可用區的路由和處理。 這使得我們能夠在雲端服務供應商中斷期間可靠地維持服務交付能力。
除少數例外，美國的每個集群都有自己的專用基礎設施，除了在給定雲區域的所有環境中使用的少數組件之外，這些集群彼此之間高度隔離，以降低風險一個集群的中斷會影響其他集群。
由於 Braze 平台即時處理工作負載的強度，自 2013 年以來，我們與 Rackspace 合作託管定製配置的硬體來運行 MongoDB 資料庫，以補充對 AWS 和 Azure 的使用。 我們的 AWS 和 Azure 環境配置了 AWS Direct Connect 和 Azure ExpressRoute 私有雲連接器，透過專用光纖電纜將雲端環境連接到 Rackspace 資料中心維護的內部網路。 這種加密連接由支援多個介面的網路連結提供支援，每秒傳輸超過 100 GB 的網路流量，可在我們的雲端和 Rackspace 環境之間提供高效能的存取。
我們在 Rackspace 中的自訂環境是數百台實體伺服器的所在地，這些伺服器存放在專用於 Braze 的機櫃中。 此設定包括冗餘電源和冗餘架頂交換器。 架頂式交換器是位於伺服器機架中的網路設備，並將同一伺服器機架中的設備和伺服器連接在一起。 這些交換機至少每年進行一次故障轉移測試，不會產生影響； 去年的測試於2023年8月3日成功舉行。 與我們的雲端環境類似，我們在不同美國叢集上的容器之間保持高度的實體隔離，以最大程度地減少中斷並降低一個容器可能影響資料庫中其他容器的風險。
世界標準時間 4 月 29 日 09:15，連接到我們的 Rackspace 伺服器機櫃的主 Cisco Nexus 網路交換器出現部分故障。 故障交換機發生故障時，不會透過故障轉移自動啟動輔助網路交換機，而是將故障交換機保留為主交換器。
網路交換器透過將網路封包（稱為「訊框」）轉送到目的地來路由流量。 為了有效地做到這一點，這些交換器保持對將設備連接在一起的網路拓撲的了解。 網路路由經常會根據各個組件的故障或速度緩慢而動態變化。 當這些變化發生時，交換器和其他網路設備會相互通訊以保持對網路拓撲的準確了解。
在大型網路中，設備之間通常會存在多條路徑，這可能會導致路由「環路」（即封包無法在其預期目的地停止，而是環回其起源地的情況）。 循環可能會造成“廣播風暴”，流量最終無限循環，使網路鏈路飽和並導致中斷。 為了防止這種情況發生，交換器被編程為發送有助於識別冗餘鏈路的訊息。 這些訊息稱為生成樹橋協定資料單元 (BPDU)，並且是稱為生成樹協定 (STP) 的網路協定的一部分。 然後，交換器使用此資訊來阻止流量端口，以防止在路由流量時出現環路。 如果實體連結或交換器發生故障，STP 有助於提供冗餘，因為它可用於識別可發送流量的其他實體鏈路，並將先前的被動（即阻塞）鏈路提升為主動，以維持連接。
4 月 29 日事件發生時，交換器開始出現故障，它開始不斷轉送拓撲變更通知和 BPDU，使這些變更通知充斥網路。 這些資料包傳播到分佈交換器和其他交換機，導致生成樹交換環路，從而導致網路完全中斷。 雖然STP 已到位，透過阻止偵測到環路的網路連接埠來減少網路環路，但在4 月29 日的事件中，來自故障交換器的生成樹流量錯誤轉送導致網路中的其他交換器重新分析其生成樹拓撲。 然後，由於其他交換器偵測到來自故障交換器的高優先級 BPDU 封包，分佈交換器開始在先前阻塞的連接埠上轉發，導致交換環路，導致網路過載並導致網路癱瘓。
由於此活動，Rackspace 資料中心工程師於世界標準時間 09:20 左右收到有關意外網路連線問題的警報，並開始解決此問題。 在世界標準時間 09:39 到 10:03 之間，Rackspace 資料中心工程師暫停了網路交換機，重新啟動主交換機，並強制伺服器機櫃中的網路介面卡 (NIC) 故障轉移到輔助交換機。 NIC 故障轉移後，Braze 環境中的實體伺服器的連線已恢復。
Braze 使用的 MongoDB 資料庫允許資料跨多個資料庫伺服器存儲，這些伺服器被稱為「分片」。 MongoDB 提供了名為「mongoS」的路由服務，該服務處理來自 Braze 平台服務的查詢，確定分片叢集中相關資料的位置，然後將查詢路由到適當的 MongoDB 資料庫。 Braze 擁有數百個不同的 MongoDB 資料庫，包括超過 15,000 個「mongoD」進程，這些進程是運行資料庫並儲存特定 MongoDB 分片資料的程式。
每個資料庫分片由一個主 mongoD 進程和至少兩個輔助 mongoD 進程組成，可在發生故障時提供高可用性。 每個 mongoS 伺服器都與它可以將查詢路由到的每個 mongoD 保持網路連接。 這些 mongoD 進程也連接到其配置中的主進程和輔助進程； 這稱為副本集。 如果 mongoS 無法連接到給定的 mongoD，它將將該進程標記為離線並安排重試。 同樣，如果 mongoD 無法在一秒鐘內連接到其副本集的其他 mongoD 成員，它將逾時，將這些進程標記為離線，並安排重試。
在網路循環期間，由於我們的 MongoDB 進程無法正常連接，因此每個進程都將其所有關聯進程標記為離線。 也就是說，每個 mongoS 進程將其所有關聯的 mongoD 進程標記為離線，每個 mongoD 進程將其相關的副本集成員標記為離線。 然而，即使 Rackspace 恢復了與實體伺服器的網路連接，mongoS 或 mongoD 進程也沒有重新建立與其他已標記為離線的進程的所有連接。
此時，為了協助我們的 Rackspace 資料庫管理員 (DBA) 團隊的修復工作，Braze DevOps 團隊開始快速除錯和測試恢復連線的方法。 我們的調查確定，唯一可用的選擇是重新啟動虛擬化容器中近 16,000 個 mongoD 和 6,000 多個 mongoS 進程中的每一個。 考慮到這項工作的規模龐大，而且事實上不存在自動化來快速重啟如此多的容器，Rackspace 工程師在事件期間編寫了新程式碼來創建動態自動化功能。
不幸的是，隨著重新啟動進程的加快，網域系統 (DNS) 系統中出現了另一個問題。 當 mongoS 和 mongoD 程序上線時，它們會在稱為 DNS 查找的過程中向 DNS 解析器請求資訊。 由於重新啟動速度驅動的連續 DNS 查找，DNS 伺服器負載過重，導致 mongoS 層在重新連接到 mongoD 進程時出現連線逾時。 為了適應這種不斷增長的負載，我們的 Rackspace 團隊增加了 DNS CPU 容量，但隨後被迫再次重新啟動 mongoS 層，以便創建從每個 mongoS 到其關聯的 mongoD 進程的健康連接。
世界標準時間 17:05 左右，重啟過程允許一些群集開始恢復線上狀態。 隨著資料庫效能恢復和叢集穩定，Braze 持續提高資料處理和訊息傳遞能力； 然而，由於先前無法提供，導致大量積壓，使這項工作變得複雜。
考慮到我們的Rackspace 資料庫環境（由數百個不同的資料庫組成）的規模和複雜性、中斷的持續時間以及由此產生的積壓量（代表數十億個訊息和數十億個攝取的資料點），恢復過程需要-我們正常恢復過程的即時調整。 這是必要的，以確保資料庫資源與持續的處理需求保持平衡，包括引入大量的整體處理能力。
然而，在這樣做時，Braze 達到了 AWS 對我們能夠配置的虛擬 CPU 數量的限制，阻止我們添加任何額外的伺服器容量。 Braze 團隊與我們的AWS 團隊迅速升級了這種情況，並獲得了增長，使我們的工程師能夠將我們的伺服器處理能力擴展到創紀錄的水平，這比我們之前在Black 上達到的最大容量高出50% 以上2023 年星期五。
到 UTC 時間 20:30，除 US 01、US 03 和 US 08 之外的所有美國集群均已完成積壓處理，其餘集群的處理速度達到或高於事件前一天的峰值速度。 幾個小時內，所有叢集都恢復到即時處理狀態，我們宣布事件已解決。
在此類事件中，清晰、頻繁的溝通至關重要。 雖然技術問題一般很少發生，而且如此嚴重的問題對於 Braze 來說是聞所未聞的，但我們始終盡力與受影響的各方進行清晰、快速的溝通。
在這種情況下，我們溝通策略的指導原則是誠實、透明和信任。 我們知道，我們只有一次機會對正在發生的事情誠實和直率，而事件的透明度（無論是在當時還是在事件解決後）對於維持信任至關重要。 歸根結底，我們希望客戶相信 Braze 將始終盡我們所能解釋、補救並防止任何事件再次發生。
在事件發生期間，我們使用狀態頁面來管理通訊並定期提供有關情況的更新； 我強烈鼓勵客戶從該頁面註冊更新，以便跟上最新情況。 在 4 月 29 日的中斷期間，我們透過我的聯合創始人兼執行長 Bill Magnuson 的電子郵件對這些頻繁的狀態頁面更新進行了補充。 該訊息已發送給所有 Braze 儀表板用戶，並提供給我們的客戶團隊，以便根據需要與其他客戶利害關係人共用。
在這次事件之前，我們的經驗使我們相信，由於我們有冗餘的網路交換機，我們的網路具有彈性。 然而，這次中斷表明我們的網路拓撲（十多年來一直為我們提供了良好的支援）很容易發生災難性故障。 現在很明顯，未來必須加強它。
自事件發生以來，Braze 和 Rackspace 已更換並更換了故障交換機，而 Rackspace 工程團隊已完成了對 Braze 服務所依賴的網路基礎架構的全面審核。 雖然硬體故障非常難以預測，尤其是在保固期內的設備，但可以透過監控來檢測異常情況並確保快速回應。 兩個團隊現在正在合作做出改變，以防止未來的網路循環，即使在設備故障的情況下也是如此。 一些網路變更需要時間來實施，因為我們計劃對網路拓撲進行有意義的更改，以進一步提高對環路的保護。 我們也向 Cisco 和 MongoDB 開立了支援票證，以更好地了解我們經歷的故障場景，並提高 mongoD 和 mongoS 進程在網路故障後自我修復的能力。
自事件發生以來，我們一直與 Rackspace 保持日常聯繫，以針對近期變化採取行動並進行更大規模的網路增強，並將繼續這樣做，直到我們確信已經實現了改進的、更具彈性的網路設計。
我想再次對此事件及其對您的業務以及您與客戶的關係的影響表示歉意。 Braze 不可用的時間是不可接受的。 我們的工程領導和執行團隊完全致力於做出所有必要的改變，以盡可能快速有效地識別和解決中斷漏洞，以便我們能夠再次贏得您作為可靠和高效合作夥伴的信任。
— 喬恩