大規模Kafka集群的管理利器：LinkedIn最新開源的Cruise Control帶來了什麼？

在過去幾年中 Apache Kafka[1] 受歡迎程度日益高漲。 LinkedIn 部署的 Kafka 集群每天處理超過 2 萬億條消息。 雖然 Kafka 已被證明是非常穩定的，但運行如此大規模的 Kafka 仍然存在運維上的挑戰。 Broker 每天都會失敗，導致我們集群工作負載不均衡。 因此， SRE 花費大量時間和精力重新分配分區，以保證 Kafka 群集均衡。

智能自動化在這種情況下至關重要，這就是為什麼我們開發了 Cruise Control[2] 。 Cruise Control 是一個用於持續監視 Kafka 集群並根據配置自動調整分配資源的系統。用戶指定目標， Cruise Control 負責監控是否違反這些目標，分析群集現有工作負載，並自動執行管理操作以滿足這些目標。 在去年秋天的流處理會議上，您可以看到有關 Cruise Control 的視頻 [3]。

今天我們很高興地宣布，我們開源了 Cruise Control，現在可以在 Github 上獲得 [3] 該軟體 。 在本文中，我們將描述 Cruise Control 在 LinkedIn 的使用，其架構以及創建時遇到的一些獨特挑戰。 如果對本文中使用的 Kafka 術語不理解，這份參考資料 [4] 將對您很有幫助。

當我們設計Cruise Control時，我們有一些重要的要求：

• 可靠的自動化：Cruise Control應該能夠準確地分析集群工作負載並生成可信賴的執行計劃，而無需任何人為干預。

• 資源效率：Cruise Control應該足夠聰明，在執行操作時會避免對集群可用性產生不利影響。

• 可擴展性：Kafka用戶對其Kafka部署的可用性和性能有不同的要求，而且會使用各種部署工具，管理節點和數據收集機制。 Cruise Control必須能夠滿足任意用戶定義的目標並執行用戶定義的操作。

• 通用性：我們在早期就意識到，其他分散式系統也可以受益於類似的運維自動化（需要完成應用感知監控分析 - 動作周期）。 雖然現有的類似產品有助於均衡集群中的資源利用率，但大多數與應用無關，並通過遷移整個應用程序達到目的。 雖然這對於無狀態系統來說工作的很好，但當涉及到有狀態系統（例如Kafka）時，這些產品通常就無計可施了。 因此，我們希望Cruise Control成為在任何分散式系統中都可以使用的通用框架。

LinkedIn的Cruise Control

Cruise Control旨在解決以下關鍵的運維目標：

1. Kafka集群必須在磁碟，網路和CPU利用率方面持續均衡節點。

2. 當broker失敗時，我們需要自動將該broker上的副本重新分配給群集中的其他broker，並恢復原始的複製因子。

3. 我們需要能夠識別消耗群集最多資源的分區。

4. 我們需要支持低接觸集群擴展和broker停用。 從集群添加或刪除代理程序後需要手動重新分配分區，這些操作非常繁瑣。

5. 能夠使用異構硬體運行群集（例如，在缺少相同的硬體時快速修復硬體故障）。 然而，異構硬體增加運維開銷，因為在均衡集群時，SRE需要精確地識別硬體差異。 Cruise Control應該能夠支持異構機器的Kafka群集和單機運行多個broker。

它是如何工作的？

Cruise Control遵循監控/分析/操作 這樣的工作周期。 下圖描述了Cruise Control的架構。 許多組件是可插拔的，如圖所示（例如，度量取樣器，分析器等）。

REST API

Cruise Control提供了REST API，允許用戶與之進行交互。 REST API支持查詢Kafka群集的工作負載和優化建議，並支持觸發運維操作。

負載監視器

負載監視器從集群收集標準Kafka指標，並且可以獲取每個分區資源指標（例如，每個分區的估計CPU利用率）。 然後生成一個集群工作負載模型，以準確捕獲集群資源利用率，其中包括磁碟利用率，CPU利用率，位元組輸入和輸出速率。 然後將模型反饋到檢測器和分析器。

分析器

分析器是Cruise Control的「大腦」。 它使用啟發式方法基於用戶提供的優化目標和來自負載監視器的集群工作負載模型生成優化方案。

優化目標基於用戶配置的優先順序。 優先順序較高的目標首先被保證。低優先順序目標不能導致違反高優先順序目標。

Cruise Control還允許指定硬性目標和軟性目標。 硬性目標是必須滿足的目標（例如，副本放置必須做到機架可識別）。 另一方面，如果可以滿足所有硬性目標，那麼軟性目標可以不必達成。 如果優化結果違反了一個硬性目標，優化將會失敗。 硬性目標將比軟性目標具有更高的優先順序。 到目前為止，我們實現了以下硬性/軟性目標：

硬目標

1. 副本配置必須是機架可識別的。 相同分區副本放在不同的機架上，這樣當某個機架停機時，任何分區最多會有一個副本丟失。 這有助於控制故障邊界，並使Kafka更加健壯。

2. broker資源利用率必須在預定義的閾值內。

3. 即使broker上的所有副本都成為leader，也不能允許網路利用超出預先定義的容量。在這種情況下，所有的消費者流量將被重定向到該broker，這將導致比平常更高的網路利用率。

軟目標

1. 試圖在所有broker之間實現一致的資源利用率。

2. 試圖在broker之間實現leader分區的均勻位元組輸入速率（來自客戶端而非來自複製的位元組輸入速率）。

3. 試圖將特定主題的分區均勻分配到所有broker上。

4. 試圖將副本均勻分配到所有broker上。

在高層次上，目標優化邏輯如下：

For each goal g in the goal list ordered by priority* {
For each broker b {
while b does not meet g』s requirement {
For each replica r on b sorted by the resource utilization density** {
Move r (or the leadership of r) to another eligible broker b』 so b』 still satisfies g and all the satisfied goals
Finish the optimization for b once g is satisfied.
}
Fail the optimization if g is a hard goal and is not satisfied for b
}
}
Add g to the satisfied goals
}
* The high priority goals are optimized first
**The utilization density is Resource_Utilization / Partition_Size

異常檢測器

異常檢測器識別兩種異常：

1. broker故障：即非空代理離開集群，導致分區副本數不足。 因為這可能會在正常的群集恢復期間發生，所以異常檢測器在觸發通知並修復群集之前提供可配置的寬限期。

2. 目標違反：即違反優化目標。 如果啟用自愈功能，Cruise Control將主動嘗試通過自動分析工作負載並執行優化方案來解決目標違反。

執行器

執行器負責執行來自分析器的優化方案。 重新均衡Kafka集群通常涉及重新分配分區。 執行程序確保執行是資源可感知的，並不會壓跨任何代理。 重新分配分區可能是一個長期運行的過程（在一個大的Kafka集群中可能需要幾天的時間才能最終完成）。 有時，用戶可能希望停止正在進行的分區重新分配。 執行器的設計就考慮到了在執行方案時安全中斷。

我們在開發和使用Cruise Control時遇到許多有趣的挑戰。 下面列出其中幾個。

為Kafka構建可靠的集群工作負載模型

這並非像聽起來那樣簡單。 有很多細微之處要注意。 例如，從broker收集CPU利用率指標非常簡單，但是我們如何量化每個分區對CPU利用率的影響？ 這個wiki頁面[5]解釋了我們是回答這個問題的。

您願意為優化方案等待多久？

分析器組件已經取得了長足進步。 我們最初使用具有複雜參數化損耗函數的通用優化器。 在中型Kafka群集上獲取優化方案需要幾周時間。 後來我們切換到當前的啟發式優化器，這可以在幾分鐘之內得到相當不錯的優化方案。

內存還是速度？

因為我們必須保存一段時間（例如一個星期）的度量指標，以便分析Kafka群集中分區的流量模式，並且由於生成優化方案需要進行大量計算，所以Cruise Control同時是內存密集型和CPU密集型的程序。 但是這是相互矛盾的。 為了加快優化方案生成，我們希望使用更多的緩存和並行計算，但這樣做會增加內存和CPU的使用。 我們最終做出了一些設計決策，以在兩者之間取得平衡。 例如，我們預先計算優化方案並緩存起來，以避免用戶查詢到時的長時間等待。 另一方面，我們還錯開了內存密集型任務的執行（例如，方案預計算和異常檢測等），以避免高內存消耗操作同時執行。

更多Kafka集群優化目標！

由於Cruise Control的優化目標是可插拔的，因此用戶可能會根據需要提出精密的目標來優化自己的Kafka群集。 例如，我們使用LinkedIn的Kafka Monitor[6]來監控我們的集群可用性。 由於Kafka Monitor根據其向「監控」主題發送消息的能力來報告每個broker的可用性，因此我們需要確保該主題分區的leader能夠覆蓋所有broker。 作為一個開源項目，我們也鼓勵用戶創造自己的目標，並為社區做貢獻。

與雲管理系統（CMS）集成

目前，Cruise Control系統通過遷移壞掉的分區代理來治癒集群。 我們設想，Cruise Control可以與其他CMS集成，以便在利用率達到一定閾值時自動擴展群集，必要時也可以從備用池用一個新代理替換故障代理。 如上所述，我們歡迎社區的加入和對未來功能的貢獻。

通過深入了解操作

Cruise Control有助於深入分析從Kafka收集的指標。 我們相信，它將使SRE能夠量化各種資源使用指標的影響，並獲得有助於容量規劃和性能調優。

概括我們開發Cruise Control時認識到動態負載平衡器對任何分散式系統來說都是實用工具。 Cruise Control的度量指標聚合，資源利用率分析和優化方案的生成同樣適用於其他分散式系統。我們想抽象出這些核心組件，並提供給其他項目。 我們對Cruise Control的願景是以允許與任何分散式系統直接集成的方式構建，以促進特定於應用程序的性能分析，優化和執行。

Cruise Control開始於Efe Gencer[7]的實習項目。 Kafka開發團隊的許多成員都參加了頭腦風暴，設計和評論。 Cruise Control還收到了來自LinkedIn的Kafka SRE團隊的許多寶貴貢獻和見解。

[1]https://kafka.apache.org

[2]https://github.com/linkedin/cruise-control

[3]https://www.youtube.com/watch?v=lf31udm9cYY

[4]https://github.com/jet/kafunk/wiki/Kafka-Crash-Cource

[5]https://github.com/linkedin/cruise-control/wiki/Build-the-cluster-workload-model

[6]https://engineering.linkedin.com/blog/2016/05/open-sourcing-kafka-monitor

[7]https://www.linkedin.com/in/efegencer/

[8]https://www.meetup.com/Stream-Processing-Meetup-LinkedIn/

[9]http://samza.apache.org

英文原文：https://engineering.linkedin.com/blog/2017/08/open-sourcing-kafka-cruise-control

本文作者 Jiangjie Qin，由 Jesse 翻譯，轉載譯文請註明出處，技術原創及架構實踐文章，歡迎通過公眾號菜單「聯繫我們」進行投稿。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！