Kafka近年來日漸流行，LinkedIn的1800臺Kafka服務器每天處理2萬億個消息。雖說Kafka運行得十分穩定，但要大規模運行Kafka，在運維方面仍然面臨巨大的挑戰。每天都會有broker崩潰，導致集群工作負載不均衡。SRE團隊需要花費大量的時間和精力來重分配分區，以便讓集群重新恢復均衡。
自動化因此變得十分重要，這也就是為什么我們要開發Cruise Control：持續監控Kafka集群，自動調整分配給服務器的資源，達到預期的性能目標。用戶設定目標，Cruise Control對集群的工作負載進行分析，并自動執行一些操作來達成目標。
Cruise Control即日起在GitHub上開源。在這篇文章里，我們將介紹Cruise Control的使用場景、它的架構以及我們在開發Cruise Control過程中面臨的挑戰。
設計目標
可靠的自動化： Cruise Control要準確地分析集群的工作負載，生成無需人工介入的執行計劃。資源有效性： Cruise Control要智能地執行操作，不會影響集群處理正常的工作負載。可擴展性： Kafka用戶對可用性和性能會有不同的需求，還可能使用各種不同的部署工具、管理端點和度量指標收集機制。Cruise Control必須能夠滿足用戶定義的各種目標，并執行用戶定義的操作。通用性：盡管很多現有的產品可以用于均衡集群的資源，但它們大部分都與應用程序毫無關聯，需要通過遷移整個應用進程來恢復均衡。這類產品對于無狀態的系統來說是沒有問題的，但對于有狀態的系統來說就會顯得有點力不從心，因為這類系統的很多狀態與應用進程相關聯。因此，我們希望Cruise Control會是一個能夠了解應用程序的通用性框架，在恢復均衡時只需要進行一小部分狀態遷移。Cruise Control在LinkedIn的應用
Cruise Control在LinkedIn主要解決以下幾個問題。
保證Kafka集群資源的均衡：磁盤、網絡和CPU。如果有broker崩潰，自動將副本重新分配給其他broker，并重置復制系數。識別出消耗資源最多的主題分區。在擴展集群或broker退役時只需要少量的人工介入。支持異構的Kafka集群以及單臺主機部署多個broker實例。Cruise Control的工作原理
Cruise Control遵循的是“監控——分析——行動”這樣的工作流程。下圖是Cruise Control的架構圖。大部分組件都是可插拔的，如度量指標取樣器（metric sampler）、分析器（analyzer）等。
REST API
Cruise Control為用戶提供了一組REST API，可以用于查詢Kafka集群的工作負載情況或觸發管理操作。
負載監控器
負載監控器從集群收集Kafka的度量指標和每個分區的資源度量指標，并生成集群工作負載模型，包括磁盤使用情況、CPU使用情況、流量流入速率、流量流出速率等，然后把模型發送給探測器和分析器。
分析器
分析器是Cruise Control的“大腦”，它根據用戶提供的優化目標和來自負載監控器的工作負載模型來生成優化計劃。用戶可以配置優化計劃的優先級，還可以分別設定硬性目標和軟性目標。硬性目標是指必須達成的目標（例如必須根據機架來分配副本的位置），軟性目標是指在優先滿足硬性目標的前提下有可能得不到滿足的目標。
硬性目標
根據機架來安排副本的位置，即同一個分區的副本必須被放在不同的機架上，這樣可以減少硬件崩潰給Kafka集群帶來不利的影響。broker的資源使用必須處在預定義的閾值內。網絡使用不能超過預定義的容量。如果一個broker的所有副本都成為首領，那么所有的消費者流量都會被重定向到這個broker上，導致網絡流量膨脹。軟性目標
讓集群所有的broker使用相同的資源。讓所有broker的首領分區達到相同的流量流入速率。讓主題的分區均勻地分布在所有broker上。在所有broker上均勻地分布分區副本。探測器
探測器主要用于探測兩種類型的異常。
broker失效：比如一個非空閑的broker離開集群，導致分區不同步。因為這種情況在集群正常重置時也會發生，所以探測器在觸發告警之前會預留一段時間，如果不是正常重置，就會觸發告警并進行修復。偏離目標：如果啟用了自愈功能，Cruise Control會嘗試通過分析工作負載并執行優化計劃解決問題。執行器
執行器負責執行由分析器生成的優化計劃。Kafka集群的再均衡通常會涉及重新分配分區，執行器要對資源保持感知，避免拖垮broker。分區重分配可能需要很長時間，一個大型的集群可能需要幾天時間才能完成一次分區重分配。有時候，用戶希望能夠停止正在進行的分區重分配，所以執行器需要確保能夠安全地中斷執行計劃。
有趣的挑戰
在開發和使用Cruise Control時，我們遇到了很多有意思的挑戰。
為Kafka構建可靠的集群工作負載模型
這個比看上去的要難得多，需要考慮到很多細節。例如，從broker上收集CPU度量指標是很容易的，但我們該如何量化每個分區的CPU使用情況？這個Wiki頁對這個問題進行了解釋。
你們愿意花多少時間在一個優化計劃上？
分析器組件經歷了一個漫長的演化過程。我們最開始使用了一個具有復雜配置功能的通用優化器，它需要幾周的時間才能得到一個中型Kafka集群的優化計劃。后來，我們改用現在的優化器，可以在幾分鐘之內得到一個較好的結果。
內存與速度的權衡
Cruise Control是一個內存密集型的應用，因為它需要在內存里保存度量指標一段時間，以便分析流量模式。同時，它也是一個CPU密集型的應用，因為它需要大量的計算來生成優化計劃。這兩者之間存在沖突關系。為了加快生成優化計劃，我們需要緩存更多的數據，進行更多的并行計算，但這樣會使用更多的內存。我們需要在這兩者之間做出權衡。例如，我們會預計算優化計劃并緩存起來，當用戶發起查詢時就不需要等待那么長時間。另外，我們會交錯執行內存密集型的任務，避免同時消耗大量內存。
未來的工作
更多的集群優化目標
Cruise Control的優化組件是可插拔的，用戶有可能會根據實際需要提出各種復雜的優化目標。作為一個開源項目，我們鼓勵用戶創建自己的優化目標，并把它們貢獻給社區。
與云管理系統集成
目前，Cruise Control通過移動失效broker的分區讓集群保持正常運行。我們希望后續能夠與云管理系統集成起來，實現自動集群擴展，或者使用空閑實例替換失效的broker實例。
增強運維洞見
Cruise Control分析從Kafka收集而來的度量指標，幫助SRE團隊量化各種資源度量指標的影響程度，提升容量規劃和性能調優的能力。
通用性
我們在開發Cruise Control時就意識到動態負載均衡器對于分布式系統來說是非常重要的。用于聚合度量指標、分析資源使用情況、生成優化計劃的Cruise Control組件同樣適用于其他分布式系統。從長遠來看，我們想把這些核心組件抽象出來，用在其他的項目上。
查看英文原文： Open Sourcing Kafka Cruise Control
京公網安備 11010502049343號