推特最近把原本內部開發的Pub/Sub系統EventBus更換成Apache Kafka,除了在成本上,當有許多使用者都要轉推發文的情況下(資料處理上稱為fan-out),能節省高達75%的資源外,由於Kafka龐大社群的資源,修復錯誤和增加新功能更快,也更容易找到系統維護工程師人選。

Apache Kafka是一個開源分散式串流平臺,能以高吞吐量低延遲方式傳輸資料。Kafka的核心是基於日誌建構的Pub/Sub系統,具有可水平伸縮和容錯性,是用來打造即時新聞系統的理想選擇。但其實推特在幾年前就已經使用過Kafka,推特發現當時Kafka 0.7版本,有幾個不適合他們使用情境的缺點,主要是在追趕讀取(Catchup Reads)期間的I/O操作數限制,也欠缺耐久性和複製功能。

由於當時使用Kafka的這些限制,推特基於Apache DistributedLog,打造了自己的Pub/Sub系統EventBus,以應付推特快速發布突發新聞、對使用者提供相關廣告,以及其他即時使用案例的需求。

時至今日,硬體和Kafka專案在經過時間的發展,推特之前遇到的問題,都已經獲得解決。SSD的價格已經足夠低廉,有助於解決之前在HDD上遇到隨機讀取先前I/O的問題,而且伺服器NICs具有更大的頻寬,使得EventBus的分割服務和儲存層的好處消失。新版的Kafka現在還支援資料複製,提供推特需要的資料耐久性保證。推特表示,驅動他們把Pub/Sub系統從EventBus搬遷到Kafka上,主要是考量成本以及社群兩個原因。

在推特決定要搬遷Pub/Sub系統到Kafka之前,團隊花了數個月評估,他們在Kafka上運作相近於EventBus上的工作負載,包括耐久寫入、長尾讀取(Tailing reads)、追趕讀取以及高扇出讀取(High Hanout Reads),還有一些灰色故障的情境。從資料串流消費者讀取訊息的時間戳差異來衡量,無論吞吐量如何,Kafka的延遲都明顯較低,推特提到,這可以歸因成三個原因,第一個,由於在推特原本使用的EventBus,服務層和存儲層是分離的,因此產生額外的跳躍(Hop),而Kafka只用一個程序處理儲存和請求服務。

第二個原因,EventBus明顯地阻止對fsync()呼叫寫入,但是Kafka卻仰賴作業系統背景進行fsync()呼叫。第三個原因是,Kafka使用零複製(Zero-copy)。因此從成本的角度來看,EventBus需要服務層和存儲層的硬體,分別針對高網路吞吐量和硬碟進行最佳化,但Kafka只需要使用單一主機,推特提到,顯然EventBus需要更多的機器才能達到和Kafka相同的工作負載。

單一資料串流消費者的使用案例,Kafka可以節省68%的資源,當有多個使用者發文並轉推給他們所有友人時的fan-out情況下,推特估計,則能節省高達75%的資源。推特表示,由於他們使用案例fan-out效應不夠極端,在實作中不值得分離服務層,特別是考慮到現代硬體上的可用頻寬,否則在理論上EventBus應該更有效率。

除了成本上的考量,Kafka龐大的支援社群也是一大優勢。在推特中,維護EventBus系統的只有8名工程師,但是Kafka專案現在卻有數百人進行維護,幫忙修復錯誤和增加新功能。推特預計在EventBus增加的新功能,像是串流函式庫、至少一次HDFS工作管線以及一次性處理都已經在Kafka中具備了。

此外,在客戶端或是伺服器發生問題時,開發人員可以參考其他團隊的經驗,快速的解決問題,而且也因為Kafka是一個熱門專案,因此了解Kafka的工程師數量也比較多,方便招聘系統工程師。在接下來的幾個月內,推特計畫開始把使用者從EventBus遷移到Kafka上,以降低營運成本,並且讓使用者獲得Kafka提供的其他功能。


Advertisement

更多 iThome相關內容