作者丨Prince Mahajan

編譯丨諾亞

出品 | 51CTO技術(shù)棧（微信號：blog51cto）

如何通過云原生設(shè)計提升Apache Kafka引擎的性能、可用性和成本效率？本文作者圍繞這一中心議題，介紹了一項名為Kora的事件流處理平臺的重新設(shè)計過程及關(guān)鍵技術(shù)創(chuàng)新。文章首先指出成功云原生平臺的必備特性，包括多租戶支持、易于擴(kuò)展、數(shù)據(jù)驅(qū)動管理、跨客戶安全隔離以及支持快速創(chuàng)新。Kora的設(shè)計旨在滿足這些需求，同時保持與現(xiàn)有Kafka協(xié)議的兼容性，并在多云環(huán)境下提供一致體驗。

當(dāng)我們著手重建托管Apache Kafka服務(wù)核心的引擎時，我們知道必須滿足成功云原生平臺的幾個獨特要求。這些系統(tǒng)需要從底層開始就是多租戶的，能夠輕松擴(kuò)展以服務(wù)于成千上萬的客戶，并且主要由數(shù)據(jù)驅(qū)動的軟件而非人工操作員來管理。它們還應(yīng)確保在工程師可以持續(xù)快速創(chuàng)新的環(huán)境中，跨客戶具有強(qiáng)大的隔離性和安全性，即使工作負(fù)載不可預(yù)測。

去年，我們展示了Kafka引擎的重新設(shè)計。我們設(shè)計和實施的大部分內(nèi)容也將適用于其他構(gòu)建大規(guī)模分布式云系統(tǒng)的團(tuán)隊，如數(shù)據(jù)庫或存儲系統(tǒng)。我們希望與更廣泛的社區(qū)分享我們的經(jīng)驗，希望這些經(jīng)驗?zāi)軐氖缕渌椖康娜擞兴鶐椭?/p>

1.Kafka引擎重新設(shè)計的關(guān)鍵考慮因素

我們的高層級目標(biāo)可能與你自己基于云的系統(tǒng)的目標(biāo)相似：提高性能和彈性，增加對我們自己和客戶的成本效率，并在多個公有云上提供一致的體驗。我們還有一個額外的要求，即與當(dāng)前版本的Kafka協(xié)議保持100%兼容。

我們重新設(shè)計的Kafka引擎名為Kora，是一個事件流處理平臺，在AWS、Google Cloud和Azure的70多個區(qū)域運(yùn)行著數(shù)萬個集群。你可能不會立即達(dá)到這樣的規(guī)模，但下面描述的許多技術(shù)仍然適用。

以下是我們在新的Kora設(shè)計中實施的五個關(guān)鍵創(chuàng)新。如果你想深入了解其中任何一個，我們在這個主題上發(fā)表了一篇白皮書，該白皮書在2023年的國際超大數(shù)據(jù)庫會議(VLDB)上獲得了最佳行業(yè)論文獎。

2.使用邏輯“單元”實現(xiàn)可擴(kuò)展性和隔離性

要構(gòu)建高可用性和水平可擴(kuò)展的系統(tǒng)，你需要一個使用可擴(kuò)展和可組合構(gòu)建塊構(gòu)建的架構(gòu)。具體來說，一個可擴(kuò)展系統(tǒng)所做的工作應(yīng)隨著系統(tǒng)規(guī)模的增加而線性增長。原始的Kafka架構(gòu)沒有滿足這個標(biāo)準(zhǔn)，因為許多負(fù)載方面的增長與系統(tǒng)規(guī)模的增加是非線性的。

例如，隨著集群規(guī)模的增加，連接數(shù)呈二次方增長，因為所有客戶端通常都需要與所有代理通信。類似地，由于每個代理通常在所有其他代理上都有跟隨者，復(fù)制開銷也呈二次方增長。最終結(jié)果是，添加代理會導(dǎo)致開銷的不成比例增加，相對于它們帶來的額外計算/存儲能力。

第二個挑戰(zhàn)是確保租戶之間的隔離。特別是，一個表現(xiàn)不佳的租戶可能會對集群中每個其他租戶的性能和可用性產(chǎn)生負(fù)面影響。即使有有效的限制和節(jié)流，可能總會有一些負(fù)載模式是有問題的。即使客戶端表現(xiàn)良好，節(jié)點的存儲也可能會被降級。在集群中的隨機(jī)分布，這將影響所有租戶和潛在的所有應(yīng)用程序。

我們使用一種稱為單元的邏輯構(gòu)建塊解決了這些挑戰(zhàn)。我們將集群劃分為一組跨越可用性區(qū)域的單元。租戶被隔離到單個單元中，這意味著該租戶擁有的每個分區(qū)的副本都被分配到該單元中的代理上。這也意味著復(fù)制被限制在該單元內(nèi)的代理之間。向單元中添加代理在單元級別上帶來了與以前相同的問題，但現(xiàn)在我們有了一個選項，即在不增加開銷的情況下在集群中創(chuàng)建新的單元。此外，這為我們提供了一種處理嘈雜租戶的方法。我們可以將租戶的分區(qū)移動到隔離單元中。

為了衡量這個解決方案的有效性，我們設(shè)置了一個包含24個代理和六個代理單元的實驗性集群（有關(guān)完整配置的詳細(xì)信息，請參見我們的白皮書）。當(dāng)我們運(yùn)行基準(zhǔn)測試時，集群負(fù)載——我們?yōu)楹饬縆afka集群負(fù)載而設(shè)計的一個自定義指標(biāo)——在使用單元時為53%，而不使用單元時為73%。

3.通過分層架構(gòu)優(yōu)化不同存儲類型使用

通過將架構(gòu)分層以優(yōu)化不同存儲類型的使用，我們在提高性能和可靠性的同時降低了成本。這源于我們分離計算和存儲的方式，主要是兩方面：使用對象存儲保存冷數(shù)據(jù)，以及使用塊存儲代替實例存儲保存更頻繁訪問的數(shù)據(jù)。

這種分層架構(gòu)使我們能夠增強(qiáng)彈性——當(dāng)只需要重新分配熱數(shù)據(jù)時，分區(qū)的重新分配變得容易得多。使用EBS卷而不是實例存儲也提高了持久性，因為存儲卷的生命周期與相關(guān)虛擬機(jī)的生命周期解耦。

最重要的是，分層允許我們顯著改善成本和性能。成本降低是因為對象存儲是存儲冷數(shù)據(jù)更經(jīng)濟(jì)實惠和可靠的選擇。而性能提高是因為一旦數(shù)據(jù)被分層，我們可以將熱數(shù)據(jù)置于高性能存儲卷中，如果沒有分層，這將是成本高昂的。

4.使用抽象統(tǒng)一多云體驗

對于計劃在多個云上運(yùn)營的任何服務(wù)來說，提供統(tǒng)一且一致的跨云客戶體驗至關(guān)重要，但這在幾個方面都是具有挑戰(zhàn)性的。云服務(wù)復(fù)雜，即使它們遵循標(biāo)準(zhǔn)，不同云和實例之間仍存在差異。實例類型、實例可用性和甚至對于類似云服務(wù)的計費(fèi)模式都可能以微妙但重要的方式有所不同。例如，Azure塊存儲不允許獨立配置磁盤吞吐量/IOPS，因此需要配置大容量磁盤來擴(kuò)展IOPS。相比之下，AWS和GCP允許你獨立調(diào)整這些變量。

許多SaaS提供商回避這種復(fù)雜性，讓客戶自己擔(dān)心實現(xiàn)一致性能所需的配置細(xì)節(jié)。顯然，這并不理想，因此在Kora中，我們開發(fā)了抽象化的方法來消除這些差異。

我們引入了三種抽象，使客戶能夠遠(yuǎn)離實現(xiàn)細(xì)節(jié)，專注于更高層次的應(yīng)用程序?qū)傩浴＿@些抽象可以幫助大幅簡化服務(wù)并限制客戶需要自行回答的問題。

5.自動化緩解循環(huán)對抗性能退化

故障處理對于可靠性至關(guān)重要。即便是在云端，由于云提供商中斷、軟件錯誤、磁盤損壞、配置錯誤或其他原因，故障也是不可避免的。這些可能是完全或部分故障，但無論哪種情況，都必須迅速解決，以免影響性能或系統(tǒng)訪問。

不幸的是，如果你正在大規(guī)模運(yùn)營云平臺，手動檢測和處理這些故障是不可能的。它會占用過多的操作員時間，并且意味著可能無法快速解決問題以維持服務(wù)水平協(xié)議。

為了解決這個問題，我們構(gòu)建了一個解決方案來處理所有此類基礎(chǔ)設(shè)施退化的案例。具體來說，我們構(gòu)建了一個反饋循環(huán)，包括一個退化檢測組件，該組件從集群收集指標(biāo)并使用它們來決定是否有任何組件發(fā)生故障以及是否需要采取行動。這使我們能夠在不需任何手動操作員介入的情況下，每周自動處理數(shù)百次退化。

實現(xiàn)多種反饋循環(huán)跟蹤代理性能并在必要時采取行動。當(dāng)發(fā)現(xiàn)問題時，會標(biāo)記為特定的代理健康狀態(tài)，并針對每個狀態(tài)采用相應(yīng)的緩解策略。這三個反饋循環(huán)分別解決了本地磁盤問題、外部連接問題和代理退化問題。

• 監(jiān)控：一種從外部角度跟蹤每個代理性能的方法。我們經(jīng)常進(jìn)行探測以跟蹤。
• 聚合：在某些情況下，我們聚合指標(biāo)以確保相對于其他代理，退化是可察覺的
• React：特定于 Kafka 的機(jī)制，用于將代理排除在復(fù)制協(xié)議之外或?qū)㈩I(lǐng)導(dǎo)權(quán)從復(fù)制協(xié)議中移走。

確實，我們的自動化緩解每月在所有三大云提供商中檢測并自動緩解數(shù)千次部分退化，節(jié)省了寶貴的操作員時間，同時確保對客戶的影響最小。

6.平衡有狀態(tài)服務(wù)以實現(xiàn)性能和效率

在任何有狀態(tài)服務(wù)中跨服務(wù)器平衡負(fù)載是一個難題，直接影響到客戶體驗的服務(wù)質(zhì)量。負(fù)載分布不均會導(dǎo)致客戶受到最繁忙服務(wù)器提供的延遲和吞吐量限制。有狀態(tài)服務(wù)通常有一組鍵，你需要平衡這些鍵的分布，以便總體負(fù)載均勻分布在服務(wù)器上，從而客戶能夠從系統(tǒng)中獲得最大性能和最低成本。

例如，Kafka運(yùn)行的狀態(tài)性代理負(fù)責(zé)平衡分區(qū)及其副本到各個代理的分配。根據(jù)客戶活動，這些分區(qū)上的負(fù)載可能會以難以預(yù)測的方式激增或下降。這需要一套指標(biāo)和啟發(fā)式方法來確定如何放置分區(qū)以最大化效率和利用率。我們通過一個平衡服務(wù)來實現(xiàn)這一點，該服務(wù)跟蹤來自多個代理的一套指標(biāo)，并持續(xù)在后臺工作以重新分配分區(qū)。

重新平衡分配需要謹(jǐn)慎進(jìn)行。過于積極的重新平衡會因這些重新分配產(chǎn)生的額外工作而破壞性能并增加成本。而過慢的重新平衡則會讓系統(tǒng)在修復(fù)不平衡之前明顯退化。我們必須實驗了很多啟發(fā)式方法，以收斂到一個適合各種工作負(fù)載的適當(dāng)反應(yīng)水平。

有效平衡的影響可能是巨大的。我們的一位客戶在為他們啟用重新平衡后，負(fù)載大約減少了25%。類似地，另一位客戶由于重新平衡，延遲大幅減少。

7.精心設(shè)計的云原生服務(wù)的優(yōu)勢

如果你正在為你的組織構(gòu)建云原生基礎(chǔ)設(shè)施，無論是使用新代碼還是使用像Kafka這樣的現(xiàn)有開源軟件，我們希望本文中描述的技術(shù)能幫助你實現(xiàn)性能、可用性和成本效率的目標(biāo)。

為了測試Kora的性能，我們在相同的硬件上進(jìn)行了小規(guī)模實驗，比較了Kora和我們的全云平臺與開源Kafka。我們發(fā)現(xiàn)Kora提供了更大的彈性，擴(kuò)展速度提高了30倍；相比我們自管理客戶或其他云服務(wù)的故障率，可用性提高了10倍以上；并且延遲明顯低于自管理的Kafka。雖然Kafka仍然是運(yùn)行開源數(shù)據(jù)流系統(tǒng)的最佳選擇，但對于尋求云原生體驗的人來說，Kora是一個很好的選擇。

參考鏈接：https://www.infoworld.com/article/3715426/5-tips-for-building-highly-scalable-cloud-native-apps.html