Braze，前身為Appboy，在我們的係統中處理了大量的規模，峰值為每秒數十萬個API調用，並運行數千個數據庫和應用服務器。這篇文章是關於我們的增長如何打破我們的物理網絡硬件，以及我們如何將我們的網絡層轉移到雲。

Braze Architecture，大約2015年

數據通過加密的HTTPS連接流向我們的api, api接收數據並將其放入作業隊列中。然後，它立即被一組服務器處理，這些服務器決定這些新信息如何改變我們對該用戶所屬受眾群體的理解，或者是否應該觸發一條消息。例如，客戶可以設置一個業務manbetx万博全站客户端規則，例如，“當用戶購買時，如果他們還沒有完成調查，一周後給他們發電子郵件提醒他們對他們的體驗進行評分。”

早在2015年，Braze平台就在Rackspace舉辦。我們在2011年創辦了這家公司，當時的雲計算領域遠沒有今天成熟。穀歌、Amazon和Azure沒有像今天這樣提供廣泛的服務器陣列。我們知道Braze有實現大規模發展的潛力。當時，我們認為最有意義的是采用物理和虛擬混合的方法，這樣我們就能夠使用純金屬單租戶服務器的一致性、性能和穩定性，同時擁有雲服務的彈性，可以根據需要進行擴展。

為了做到這一點，我們與Rackspace合作建立了我們的方法。混合模型使用了一種叫做RackConnect的東西(參見圖中對此配置的解釋)。

使用RackConnect，您有一個物理F5負載均衡器和一個物理防火牆。我們使用了一對冗餘的F5 5200V負載平衡器，它每秒可以處理21,000個SSL事務，2k個SSL密鑰，每秒約700k個連接。我們的防火牆是Cisco 5585，能夠每秒處理大約50,000個連接和大約100萬個並發連接。我們有一個每秒1gb的網絡交換機，允許每個方向的1gbps流量。

2015年，我們的產品出現了巨大的增長:在4月到11月的幾個月裏，Braze的月活躍用戶從9000多萬增長到近3億。這相當於在7個月內將整個日本和加拿大的人口添加到Braze的平台上。我們的消息量也在增加，從每天發送約2000萬條消息增加到約6000萬條。

在此之前，我們的客戶都不是一次性發送大量消息manbetx万博全站客户端的企業。我們沒有客戶在一次預定的活動中manbetx万博全站客户端發送1000萬推送通知或2000萬封電子郵件。但現在隨著增長，我們做到了。當他們發出這些信息時，我們在網絡上感受到了。

以下是我們的網絡在那段時間的日常情況。網絡流量是相當低的，直到當客戶發出一個大型活動時才會激增。

放大其中一個峰值，我們看到我們開始達到1gbps的限製，並使我們的網絡飽和。

發送大量的消息，尤其是推送通知，也會產生負麵影響thundering-herd-like效應的API調用回Braze。想象一下，500萬人收到推送通知，他們的手機震動，他們看著它，點擊通知。現在，網絡中也出現了一係列入站活動!

不僅僅是我們的網絡很難跟上，我們的防火牆在這些高峰期間也很不開心，CPU負載很高。

如果防火牆達到較高的CPU利用率，它可以停止過濾數據包，並開始丟棄新的傳入流量。我們開始看到一些這樣的例子，在這些大型活動發送期間，我們的api中出現了零星的、高度不可預測的網絡連接錯誤。

我們需要做點什麼，而且要快。Rackspace建議我們轉向更強大的硬件:Viprion係列2250刀片負載平衡器，該硬件每月的成本為51588美元。這裏有兩個問題:

• 對於一個正在成長的創業公司來說，這個價格太高了。我發現很難接受花那麼多錢買網絡設備。
• 那太花時間了。這些負載平衡器沒有庫存，所以我們必須訂購它們，然後我們必須將故障轉移到它們，這個過程可能需要大約兩周的時間。

然後我們想到了另一個想法:如果我們構建了一係列雲負載平衡器，並將一些網絡流量卸載給它們會怎麼樣?也許這樣可以減少f5和防火牆的CPU負載。

我們構建了大約20個負載均衡器，並開始將我們流量的個位數百分比卸載給它們。

在嚐試之後，第二天我們收到了Rackspace支持人員的電子郵件，說由於網絡流量，我們對他們的IAD數據中心造成了不利影響，不得不暫停6個雲負載平衡器來嚐試恢複他們的係統。

在這裏，我們感覺被逼到了一個角落——作為一名工程師，你要花很多時間考慮可伸縮性。確保您的數據庫可以擴展。關注應用服務器的性能。網絡是我沒有考慮過的一個領域，也是我當時覺得我們控製得最少的一個領域。

就在我們以為事情不會變得更糟的時候，情況變得更糟了。在另一次大型活動發送中，我們遇到了類似於大規模拒絕服務攻擊的攻擊:

我們的負載均衡器每秒超過1億次請求?!超過200萬並發連接?我們通過負載均衡器和阻塞通信來穩定一切。我們升級到F5工程團隊，卻發現我們在F5中遇到了一個bug:一旦CPU使用率足夠高，連接下降，F5的持久會話處理就會啟動，並陷入試圖重新建立連接的無限循環中。

有一件事非常明確:我們必須擺脫f5。

我們如何修複網絡

我們打電話給Fastly，一個邊緣雲平台，來幫助我們提高網絡的可擴展性。這個問題完全是由於通過f5的大量SSL通信造成的。從Braze發送和發送的所有內容都是加密的，F5使用2k加密密鑰每秒處理21,000個SSL事務。為了讓您了解SSL事務的CPU密集型，F5每秒可以處理700萬個L4 HTTP事務!

雖然2048位SSL密鑰是安全的，但我們希望在最終用戶設備和我們的網絡之間保留4096位SSL密鑰。我們提出的計劃是快速處理來自移動設備和網站的SSL終止，然後使用經過驗證的2048位SSL密鑰將流量輸送回我們的負載均衡器。我們與Fastly合作，建立了對我們證書的信任，因此他們驗證了我們的2k證書。我們將連接流水線回我們的F5，以最大限度地減少F5必須做的TLS事務，並減少到我們防火牆的連接數量。

這一策略立即減輕了f5和防火牆的負荷，這給了我們發展的喘息空間，讓我們擺脫了所有的物理硬件。45天後，我們搬到了AWS。有了Fastly和AWS，我們再也不用考慮SSL交易的數量了。

對我們的客戶的影響是我們的消息發送和amanbetx万博全站客户端pi變得更加可靠，即使我們還在繼續增長。今天，我們幫助我們的客戶每月吸引超過1manbetx万博全站客户端4億的活躍用戶，每月發送數百億條消息，所有這些都無需擔心我們的網絡規模。

對高度可伸縮的分布式係統感興趣?我們正在招聘！