LinkedIn開源Cruise Control：一個Kafka集羣自動化運維新利器

 

http://www.infoq.com/cn/news/2017/09/LinkedIn-open-Cruise-Control-Kaf

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主要解決如下幾個問題。

1. 保證Kafka集羣資源的均衡：磁盤、網絡和CPU。
2. 若是有broker崩潰，自動將副本從新分配給其餘broker，並重置複製係數。
3. 識別出消耗資源最多的主題分區。
4. 在擴展集羣或broker退役時只須要少許的人工介入。
5. 支持異構的Kafka集羣以及單臺主機部署多個broker實例。

Cruise Control的工做原理

Cruise Control遵循的是「監控——分析——行動」這樣的工做流程。下圖是Cruise Control的架構圖。大部分組件都是可插拔的，如度量指標取樣器（metric sampler）、分析器（analyzer）等。

REST API

Cruise Control爲用戶提供了一組REST API，能夠用於查詢Kafka集羣的工做負載狀況或觸發管理操做。

負載監控器

負載監控器從集羣收集Kafka的度量指標和每一個分區的資源度量指標，並生成集羣工做負載模型，包括磁盤使用狀況、CPU使用狀況、流量流入速率、流量流出速率等，而後把模型發送給探測器和分析器。

分析器

分析器是Cruise Control的「大腦」，它根據用戶提供的優化目標和來自負載監控器的工做負載模型來生成優化計劃。用戶能夠配置優化計劃的優先級，還能夠分別設定硬性目標和軟性目標。硬性目標是指必須達成的目標（例如必須根據機架來分配副本的位置），軟性目標是指在優先知足硬性目標的前提下有可能得不到知足的目標。

硬性目標

1. 根據機架來安排副本的位置，即同一個分區的副本必須被放在不一樣的機架上，這樣能夠減小硬件崩潰給Kafka集羣帶來不利的影響。
2. broker的資源使用必須處在預約義的閾值內。
3. 網絡使用不能超過預約義的容量。若是一個broker的全部副本都成爲首領，那麼全部的消費者流量都會被重定向到這個broker上，致使網絡流量膨脹。

軟性目標

1. 讓集羣全部的broker使用相同的資源。
2. 讓全部broker的首領分區達到相同的流量流入速率。
3. 讓主題的分區均勻地分佈在全部broker上。
4. 在全部broker上均勻地分佈分區副本。

探測器

探測器主要用於探測兩種類型的異常。

1. broker失效：好比一個非空閒的broker離開集羣，致使分區不一樣步。由於這種狀況在集羣正常重置時也會發生，因此探測器在觸發告警以前會預留一段時間，若是不是正常重置，就會觸發告警並進行修復。
2. 偏離目標：若是啓用了自愈功能，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組件一樣適用於其餘分佈式系統。從長遠來看，咱們想把這些核心組件抽象出來，用在其餘的項目上。