如何找到Kafka集群的吞吐量極限? n

2021-09-17 03:04:45 字數 3055 閱讀 8609

kafka是非常流行的分布式流式處理和大資料訊息佇列解決方案,在技術行業已經得到了廣泛採用,在dropbox也不例外。kafka在dropbox的很多分布式系統資料結構中發揮著重要的作用:資料分析、機器學習、監控、搜尋和流式處理,等等。在dropbox,kafka集群由jetstream團隊負責管理,他們的主要職責是提供高質量的kafka服務。他們的乙個主要目標是了解kafka在dropbox基礎設施中的吞吐量極限,這對於針對不同用例做出適當的配置決策來說至關重要。最近,他們建立了乙個自動化測試平台來實現這一目標。這篇文章將分享他們所使用的方法和一些有趣的發現。

上圖描繪了本文所使用的測試平台的設定。我們在spark中使用kafka客戶端,這樣就可以以任意規模生成和消費流量。我們搭建了三個不同大小的kafka集群,要調整集群大小,只需要將流量重定向到不同的集群。我們建立了乙個kafka主題,用於生成測試流量。為簡單起見,我們將流量均勻地分布在kafka broker之間。為實現這一目標,我們建立了測試主題,分割槽數量是broker數量的10倍,這樣每個broker都是10個分割槽的首領。因為寫入單個分割槽是序列的,所以如果每個broker的分割槽太少會導致寫入競爭,從而限制了吞吐量。根據我們的實驗,10是乙個恰到好處的數字,可以避免寫入競爭造成吞吐量瓶頸。

由於基礎設施的分布式特性,客戶端遍布在美國的不同地區。因為測試流量遠低於dropbox網路主幹的限制,所以我們可以安全地假設跨區域流量的限制也適用於本地流量。

有一系列因素會影響kafka集群的工作負載:生產者數量、消費者群組數量、初始消費者偏移量、每秒訊息數量、每條訊息的大小,以及所涉及的主題和分割槽的數量,等等。我們可以自由地設定引數,因此,很有必要找到主導的影響因素,以便將測試複雜性降低到實用水平。

我們研究了不同的引數組合,最後得出結論,我們需要考慮的主要因素是每秒產生的訊息數(mps)和每個訊息的位元組大小(bpm)。

我們採取了正式的方法來了解kafka的吞吐量極限。特定的kafka集群都有乙個相關聯的流量空間,這個多維空間中的每乙個點都對應乙個kafka流量模式,可以通過引數向量來表示:\u0026lt;mps、bpm、生產者數量、消費者群組數量、主題數量……\u0026gt;。所有不會導致kafka過載的流量模式都形成了乙個封閉的子空間,其表面就是kafka集群的吞吐量極限。

對於初始測試,我們選擇將mps和bpm作為吞吐量極限的基礎,因此流量空間就降到二維平面。這一系列可接受的流量形成了乙個封閉的區域,找到kafka的吞吐量極限相當於繪製出該區域的邊界。

為了以合理的精度繪製出邊界,我們需要用不同的設定進行數百次實驗,通過手動操作的方式是不切實際的。因此,我們設計了一種演算法,無需人工干預即可執行所有的實驗。

我們需要找到一系列能夠以程式設計方式判斷kafka健康狀況的指標。我們研究了大量的候選指標,最後鎖定以下這些:

同步副本集變化超過50%:這意味著在50%的時間內至少有乙個broker無法及時複製首領的資料。

jetstream團隊還使用這些指標來監控kafka執行狀況,當集群承受過大壓力時,這些指標會首當其衝發出訊號。

為了找到乙個邊界點,我們讓bpm維度固定,並嘗試通過更改mps值來讓kafka過載。當我們有乙個安全的mps值和另乙個導致集群接近過載的mps值時,邊界就找到了。我們將安全的值視為邊界點,然後通過重複這個過程來找到整條邊界線,如下所示:

值得注意的是,我們調整了具有相同生產速率的生產者(用np表示),而不是直接調整mps。主要是因為批處理方式導致單個生產者的生產速率不易控制。相反,改變生產者的數量可以線性地縮放流量。根據我們早期的研究,單獨增加生產者數量不會給kafka帶來明顯的負載差異。

我們通過二分查詢來尋找單邊界點。二分查詢從乙個非常大的np[0,max]視窗開始,其中max是乙個肯定會導致過載的值。在每次迭代中,選擇中間值來生成流量。如果kafka在使用這個值時發生過載,那麼這個值將成為新的上限,否則就成為新的下限。當視窗足夠窄時,停止該過程。我們將對應於當前下限的mps值視為邊界。

我們在上圖中繪製了不同大小的kafka的邊界。基於這個結果,我們可以得出結論,dropbox基礎設施可以承受的最大吞吐量為每個broker 60mb/s。

值得注意的是,這只是乙個保守的極限,因為我們測試用的訊息大小完全是隨機的,主要是為了最小化kafka內部訊息壓縮機制所帶來的影響。在生產環境中,kafka訊息通常遵循某種模式,因為它們通常由相似的過程生成,這為壓縮優化提供了很大的空間。我們測試了乙個極端情況,訊息全部由相同的字元組成,這個時候我們可以看到更高的吞吐量極限。

此外,當有5個消費者群組訂閱測試主題時,這個吞吐量限制仍然有效。換句話說,當讀取吞吐量是當前5倍時,仍然可以實現這樣的寫入吞吐量。當消費者群組增加到5個以上時,隨著網路成為瓶頸,寫入吞吐量開始下降。因為dropbox生產環境中的讀寫流量比遠低於5,所以我們得到的極限適用於所有生產集群。

這個結果為將來的kafka配置提供了指導基礎。假設我們允許最多20%的broker離線,那麼單個broker的最大安全吞吐量應為60mb/s * 0.8 ~= 50mb/s。有了這個,我們可以根據未來用例的估算吞吐量來確定集群大小。

這個平台和自動化測試套件將成為jetstream團隊的一筆寶貴的財富。當我們切換到新硬體、更改網路配置或公升級kafka版本時,可以重新執行這些測試並獲得新的吞吐量極限。我們可以應用相同的方法來探索其他影響kafka效能的因素。最後,這個平台可以作為jetstream的測試平台,以便模擬新的流量模式或在隔離環境中重現問題。

在這篇文章中,我們提出了一種系統方法來了解kafka的吞吐量極限。值得注意的是,我們是基於dropbox的基礎設施得到的這些結果,因此,由於硬體、軟體棧和網路條件的不同,我們得到的數字可能不適用於其他kafka例項。我們希望這裡介紹的技術能夠幫助讀者去了解他們自己的kafka系統。

英文原文:

如何找到Kafka集群的吞吐量極限? n

kafka是非常流行的分布式流式處理和大資料訊息佇列解決方案,在技術行業已經得到了廣泛採用,在dropbox也不例外。kafka在dropbox的很多分布式系統資料結構中發揮著重要的作用 資料分析 機器學習 監控 搜尋和流式處理,等等。在dropbox,kafka集群由jetstream團隊負責管理...

如何找到Kafka集群的吞吐量極限? n

kafka是非常流行的分布式流式處理和大資料訊息佇列解決方案,在技術行業已經得到了廣泛採用,在dropbox也不例外。kafka在dropbox的很多分布式系統資料結構中發揮著重要的作用 資料分析 機器學習 監控 搜尋和流式處理,等等。在dropbox,kafka集群由jetstream團隊負責管理...

如何找到Kafka集群的吞吐量極限? n

kafka是非常流行的分布式流式處理和大資料訊息佇列解決方案,在技術行業已經得到了廣泛採用,在dropbox也不例外。kafka在dropbox的很多分布式系統資料結構中發揮著重要的作用 資料分析 機器學習 監控 搜尋和流式處理,等等。在dropbox,kafka集群由jetstream團隊負責管理...