文章概覽
一、背景介紹
二、術語介紹
三、KAFKA生産痛點
四、優化過程
五、方案驗證及上線
六、優化效果：所有叢集節省2000核CPU
作者介紹
餘東，去哪兒旅行大資料運維。主要負責KAFKA以及FLINK叢集的開發和運維，以及自動化運維平台的建設。
賈建東，2015年加入去哪兒旅行資料保障團隊，大資料技術委員會成員。熱愛鑽研技術，對hadoop生态、隊列服務、日志收集等領域有實戰經驗。
徐偉，去哪兒旅行大資料開發工程師，主要負責日志收集平台的開發維護工作；為業務和數倉提供離線和實時基礎資料支撐。
一、背景介紹
1.叢集概況
- 去哪兒旅行目前KAFKA日志叢集節點145台。單機配置：3TSSD盤，40核，128G記憶體。
2.業務背景
- 日志KAFKA叢集承載了全司的APPCODE日志，比如我們常用的QTRACE日志，以及實時離線數倉資料，體量非常大。
- 春節高峰每分鐘流量1.3TP，每分鐘接收20億條資料。
- 每天資料流量1.5PB，每天接收消息條數超過兩萬億。
3.日志叢集架構圖
二、術語介紹
1.KAFKA術語
- Broker：kafka叢集中的一個節點。
- 網絡閑置率：是kafka服務的一個重要名額，即網絡線程池線程平均的空閑比例，通常用于衡量叢集的繁忙程度。叢集沒有流量時為最大值1，随着叢集壓力變大會逐漸變小，達到0.3以下叢集性能就會達到瓶頸，就表明你的網絡線程池非常繁忙，叢集無法保證讀寫請求的及時處理，造成生産丢數已經消費堆積的問題。需要通過增加網絡線程數或将負載轉移給其他伺服器的方式，來給該 Broker 減負。
- 請求隊列：用戶端發起的請求首先存放在這個隊列，服務端拉取請求并進行處理。主要包含了消費以及生産請求。
2.kubernetes術語
- kubernetes 是個基于容器技術的分布式叢集管理系統，或者說是容器編排、管理的編排平台。
- pod 是 k8s 中的最小排程單元，應用以此作為載體排程運作。pod 内可以隻有一個容器也可以包含多個容器，共享網絡命名空間、存儲資源等，我們的filebeat 運作環境便是随着業務 pod 中注入一個 filebeat sidecar 容器來進行業務日志收集。
三、KAFKA生産痛點
痛點一
- 無法抗住23年春節壓測，在壓測高峰期，部分用戶端無法正常消費，出現堆積，并且也無法正常生産資料，壓測期間采取了降級措施來保證叢集的穩定。
- 節日高峰期，整個叢集的處理能力大幅縮減，需要人工對高壓力機器進行負載均衡。
痛點二
- 公司壓測期間叢集網絡閑置率已經降低到0.4以下，部分機器閑置率接近于0，叢集處于壓力瓶頸的邊緣，已經無法通過增加機器來解決叢集本身的性能問題了。
- 下圖是叢集高峰期的網絡閑置率，每條線代表一台伺服器。
個别機器閑置率接近于0，代表目前KAFKA機器處理能力已經達到上限了。
四、優化過程
從現象及後面的測試發現，增加節點可以解決，但會産生巨大的成本。同時，機器層面還未達到瓶頸，這說明是服務本身需要優化，是以我們着重去優化kafka本身。
綜合考慮後發現有兩個外界因素在影響這個名額，一個是資料量變大，另一個是高峰期pod擴充較多，網絡連結數變大。但具體什麼問題需要精确定位，我們準備從日志、機器硬體名額、應用名額逐個排查。
1.排查日志
通過對網絡閑置率低的機器進行排查，服務端并沒有明顯的日志報錯，日志無法定位具體問題。
2.硬體層面排查
閑置率低的機器排查機器本身的資源使用，發現網卡流量、磁盤使用率、記憶體使用、cpu使用都沒有達到上限、下面是各個名額的監控圖：
網絡流量監控，壓測期間入口流量有所上漲，出口流量上漲不明顯。
磁盤IO監控，可以發現壓測期間IO使用率有所上漲，但并沒有達到上限。
記憶體監控，記憶體沒有明顯的變化。
cpu在壓測期間反而在下降，充分說明叢集性能此時已經出現問題。
tcp連結數沒有明顯變化，說明長連結并沒有大的變化。
3.參數優化
影響網絡閑置率最直接的兩個參數就是io線程數和網絡線程數。
系統預設值 num.io.threads=3、num.network.threads=8 這兩個參數分别是代表磁盤IO的線程數量、處理網絡請求的線程數量。這兩個值叢集已經做過優化，繼續調大之後并沒有效果。
原參數
num.io.threads=32
num.network.threads=64
修改後參數
num.io.threads=128
num.network.threads=64 4. 網絡架構分析
深入分析KAFKA架構，從用戶端發起請求，到用戶端處理邏輯流程進行深入分析。其中包含了用戶端的發起請求後，服務端如何接收請求，以及如何處理請求後，回報給用戶端。
基于此分析，發現了KAFKA叢集缺失了很多重要的監控資訊，比如請求隊列大小，請求耗時，用戶端請求量。于是我們根據網絡架構進行必要的監控添加，用于發現瓶頸。
5.增加監控
kafka服務的各項名額，都是從jmx中擷取，由于jmx中有大量名額，我們平時擷取隻關注了重點部分名額，這次準備把可能有關聯的相關名額都打出來觀察。
增加了下面這些名額：RequestQueueSize大小，ResponseQueueSize大小 ，日志刷盤持續時長，BROKER生産請求數，Produce耗時名額 P999，FetchFollower耗時名額 P999，FetchConsumer耗時名額P999，TotalFetchRequestsPerSec，TotalProduceRequestsPerSec。
添加名額後經過觀察，趨勢有相關的名額有 RequestQueueSize大小、日志刷盤持續時長、BROKER生産請求數，下面重點排查這些名額。
6.刷盤時間名額驗證
當閑置率低的時候，發現刷盤時間也在增長，刷盤時間有兩部分因素控制，一部分是Kafka本身的參數，另一部分就是磁盤的IO。我們通過兩部分的測試來驗證是否有關聯。
Kafka 的刷盤時間指的是将資料從記憶體重新整理到持久儲存設備（如硬碟）所需的時間。Kafka 的性能直接影響其可以處理的消息量，而這個時間就是影響這一性能的一個關鍵因素。刷盤時間相關重要的兩個參數為：
- log.flush.interval.messages：在日志檔案的緩沖區中積累指定數量的消息後，觸發一次刷盤操作。
- log.flush.interval.ms：在日志檔案的緩沖區中積累指定時間後，觸發一次刷盤操作。
通過對這兩個參數的不同數值的調整，最後發現對閑置率沒有影響。
log.flush.interval.messages=10000
log.flush.interval.ms=1000 對于磁盤IO的影響，線上我們都是用單盤提供服務，如果我們改用雙盤，兩個盤理論上是單盤IO兩倍的性能，但是加盤之後，同樣的壓測資料，對閑置率沒有影響。
- 單盤閑置率0.67
- 雙盤閑置率0.68
7.請求數名額驗證
kafka每個broker會有一個請求隊列，這個隊列有一個預設值大小。當隊列打滿的時候說明服務端無法快速消化大量打過來的請求，這個名額和【BROKER生産請求數】名額可以對應上。同時也可以解釋外部的兩個因素，流量上漲和pod擴容。
通過測試環境确認，當broker請求量達到一定值以後，請求隊列逐漸打滿，閑置率開始下降，cpu使用率開始下降，複現了線上的現象。
确認了問題的關鍵是請求量之後，需要想辦法降低請求量，kafka的請求在filebeat用戶端。我們需要研究filebeat的參數配置。
從filebeat官網确認，涉及到批次發送的有兩個參數bulk_flush_frequency 和 bulk_max_size，線上使用的filebeat沒有配置這兩個參數。
其中含義如下：
- bulk_flush_frequency 批量發送kafka request需要等待的時間，預設0不等待；
- bulk_max_size 單次kafka request請求批量的消息數量，預設2048。
針對這兩個參數我們做了測試：
- 測試結果
由于單條資料量不同會産生不同的效果，我們對不同的的資料長度做了測試，針對我司日志特點（單條日志大小），最後得到一個最優的組合如下，增加了這倆參數後，KAFKA TOPIC在不丢數的情況下，請求數降低了10倍左右。
- 相關參數
bulk_flush_frequency: 0.1
bulk_max_size: 1024 - 資料樣本1測試結果 平均資料長度: 1.62KB
- 資料樣本2測試結果 平均資料長度: 606KB
- SNAPPY壓縮測試
從上面測試結果可以看到不同的批次下，網卡流量會有變化，這個現象最初我們了解為kafka性能的下降。通過測試發現，批次提高後壓縮比會提高，網絡層面也是一個間接的優化效果。而且不光是網絡，磁盤也會有節約，下面是不同批次下的壓縮資料測試。
通過測試可以發現，條數超過50條的時候壓縮比基本保持一緻。這裡的資料單條1KB。
五、方案驗證及上線
1.線上灰階測試
找到線上的一些代表性的topic進行測試，測試結果符合預期，生産請求數降到原來的1/10，所在機器閑置率提高0.02-0.06，同時分區所在機器CPU使用降低了5個點。
2.上線
灰階測試沒問題後，開始釋出線上版本，但線上應用，需要重新釋出才能生效。釋出一周後效果明顯，cpu、網絡流量、磁盤都有不同程度的資源節約。
下面是上線一周後的資料：
- CPU從52%掉到34%
- 請求數從6億掉到3.5億
六、優化效果，所有叢集節省2000核CPU
- 日志叢集：節省了1334核CPU
日志叢集CPU明細圖， 降低了145*40*23%=1334核
- 網絡閑置率：從最低0.72提升到0.93，提升了23%。閑置率提高，代表了KAFKA的處理性能得到了提升。
- 用戶端請求量：從6億降到2.3億
- 磁盤使用率：從44%降到35%
- 網絡流量：從2.5G降到2G
七、最終效果
3個KAFKA叢集一起優化後，最終節約2000核。
後續動作
經過上述優化後，cpu不再是單機的性能瓶頸，轉而變成網卡和磁盤。
- 磁盤方面：目前叢集的主流磁盤是3T，高峰時期磁盤使用率叢集均值已經達到60%，單機已經達到85%，我們準備每台機器再添加一塊3T盤來擴充存儲能力和IO的壓力。
- 網絡方面：目前叢集網卡平均出口流量峰值已經超過4G，單機最大會超過8G，如果流量繼續上升，網卡會成為新的瓶頸，我們準備把10G網卡提升到25G或改為雙通道20G。
在不改變CPU和記憶體的情況下，通過這兩方面的改造後，預計可以繼續提升叢集50%以上的性能。
作者丨餘東&賈建東&徐偉
來源丨公衆号：Qunar技術沙龍（ID：QunarTL）
dbaplus社群歡迎廣大技術人員投稿，投稿郵箱：[email protected]