AutoMQ Kafka 云上十倍成本節(jié)約的奧秘(一): SPOT 實(shí)例

近年來，無論是海外還是國內(nèi)，雖然受疫情影響，公有云的市場規(guī)模增速有所放緩，但是云的市場總規(guī)模仍然是持續(xù)增長的。公有云作為一個(gè)各個(gè)國家重點(diǎn)布局的戰(zhàn)略方向和其本身萬億級(jí)市場的定位[1]，我們學(xué)習(xí)用好云是非常有必要的。

AutoMQ Kafka 充分認(rèn)識(shí)到“云優(yōu)先”的重要性，圍繞公有云具備規(guī)?；б婧图夹g(shù)紅利的云基礎(chǔ)設(shè)施重新設(shè)計(jì)了 Kafka。在保證 100% 兼容 Apache Kafka 的基礎(chǔ)上帶來了極致的云成本優(yōu)勢(shì)和彈性能力，云上綜合有 10 倍以上的成本節(jié)約[2]。今天就和大家分享下 AutoMQ Kafka 云上成本節(jié)約的利器之一，Spot 實(shí)例。

01

Spot 實(shí)例應(yīng)用的挑戰(zhàn)

Spot 實(shí)例本質(zhì)上是一種實(shí)例購買類型。Spot 實(shí)例是云計(jì)算實(shí)例規(guī)模化成本紅利的產(chǎn)物，通過機(jī)器的分時(shí)復(fù)用來提升利用率，從而推出更加廉價(jià)的實(shí)例購買類型。這本身也是云廠商相比私有 IDC 自建機(jī)房固定資源預(yù)留帶來的規(guī)?；瘍?yōu)勢(shì)。Spot實(shí)例本身的硬件能力和正價(jià)的按需實(shí)例別無二致，但是其價(jià)格可以低至按需實(shí)例的價(jià)格的1折。用好Spot實(shí)例將使得軟件系統(tǒng)在云上獲得極大的成本節(jié)約。

使用Spot實(shí)例本質(zhì)就是薅云廠商的羊毛。Spot實(shí)例誘人的價(jià)格令人心動(dòng)，但是其存在的一個(gè)最大的問題就是——不確定性。云廠商不會(huì)對(duì)Spot實(shí)例的可用性提供SLA，根據(jù)云廠商的規(guī)則，在必要的時(shí)候云廠商會(huì)直接發(fā)起Spot實(shí)例的回收流程，終止Spot實(shí)例。對(duì)于AutoMQ來說，如何以一種確定性的方式來使用Spot實(shí)例，為用戶提供有SLA、可靠的Kafka服務(wù)，是我們面臨的主要挑戰(zhàn)。AutoMQ Kafka 通過大量應(yīng)用 Spot 實(shí)例來降低總體計(jì)算成本[3]。在經(jīng)過諸多實(shí)踐后，我們得出一些在 Spot 實(shí)例上提供可靠 Kafka 服務(wù)的方法。

02

在不可靠的 Spot 實(shí)例上提供可靠的服務(wù)

Broker 無狀態(tài)化

由于 Spot 本身隨時(shí)會(huì)中斷的特性， 云廠商的 Spot 實(shí)例最佳實(shí)踐基本[4]都會(huì)強(qiáng)調(diào) Spot 實(shí)例適用于無狀態(tài)的應(yīng)用。因此一個(gè)軟件系統(tǒng)“無狀態(tài)”完成得越徹底， 則 Spot 實(shí)例則會(huì)被利用得更徹底。

有狀態(tài)引用最大的問題在于其狀態(tài)數(shù)據(jù)的遷移、恢復(fù)。以 Apache Kafka 為例，即使在 3.6.0 版本以后支持了分級(jí)存儲(chǔ)（非 GA）的特性[5]，其 broker 仍然是有狀態(tài)的設(shè)計(jì)，對(duì)于每個(gè) broker 上的分區(qū)數(shù)據(jù)要求最后一個(gè) logsegment 必須在一級(jí)存儲(chǔ)上。當(dāng)這個(gè) logsegment 非常大時(shí)，占用的一級(jí)存儲(chǔ)空間將會(huì)非常大，當(dāng)其關(guān)聯(lián)的 broker 下線時(shí)，這些狀態(tài)數(shù)據(jù)遷移是非常耗時(shí)的。如果不采用分級(jí)存儲(chǔ)，這種遷移花費(fèi)數(shù)小時(shí)甚至數(shù)天[6]都是很常見的。

AutoMQ Kafka 雖然在架構(gòu)上除了依賴對(duì)象存儲(chǔ)以外還依賴 EBS 塊存儲(chǔ)，但是其本質(zhì)上是采用了一個(gè)無狀態(tài)的架構(gòu)，一級(jí)存儲(chǔ)是松耦合的，充當(dāng)一個(gè)緩沖區(qū)的角色。下圖可以揭示 Apache Kafka 的多級(jí)存儲(chǔ)和 AutoMQ 存儲(chǔ)架構(gòu)的區(qū)別。AutoMQ Kafka 使用的 EBS 寫入緩沖區(qū)默認(rèn)值為固定的 3GB，在擴(kuò)縮容場景可以完成秒級(jí)甚至毫秒級(jí)下線（取決于具體采用的機(jī)型）。

大量應(yīng)用 Spot 實(shí)例，會(huì)存在集群中計(jì)算實(shí)例的頻繁上下線，如果采用 Apache Kafka，不僅需要人為介入處理 Spot 實(shí)例的替換，同時(shí)這種頻繁的上下線、分區(qū)數(shù)據(jù)移動(dòng)將會(huì)造成系統(tǒng)明顯抖動(dòng)，對(duì)數(shù)據(jù)的生產(chǎn)、消費(fèi)產(chǎn)明顯的影響。而 AutoMQ Kafka 由于其無狀態(tài)的設(shè)計(jì)，很好的規(guī)避了這種問題，即使使用大量的 Spot 實(shí)例，也可以將這種實(shí)例替換帶來的系統(tǒng)抖動(dòng)降低到最小，以業(yè)務(wù)無感的方式完成 Spot 實(shí)例的替換。

極速的彈性與 Serverless

AutoMQ Kafka 是天然支持 serverless 的。系統(tǒng)本身的彈性速度和質(zhì)量決定過了其所能提供的 Serverless 服務(wù)質(zhì)量。Spot 實(shí)例的大量應(yīng)用，由于不可預(yù)期的回收行為，會(huì)導(dǎo)致整個(gè)系統(tǒng)使用的計(jì)算實(shí)例經(jīng)常性地被置換。在這個(gè)過程中，AutoMQ Kafka 所在計(jì)算實(shí)例接受實(shí)例終止信號(hào)到新的 Spot 實(shí)例被替換后啟動(dòng) AutoMQ Kafka 并且重新接受流量整個(gè)冷啟動(dòng)過程的耗時(shí)長短決定著 AutoMQ Kafka 彈性的效率。

以 Apache Kafka 為例，如果使用 Spot 實(shí)例并且產(chǎn)生了實(shí)例的置換，其整個(gè)冷啟動(dòng)的過程如下。從圖上我們可以非常清晰的看到，當(dāng)數(shù)據(jù)規(guī)模較大時(shí)（TB 級(jí)）或者存在分區(qū)熱點(diǎn)時(shí)，Apache Kafka 整個(gè)冷啟動(dòng)時(shí)間中執(zhí)行手動(dòng)完成分區(qū)遷移、數(shù)據(jù)拷貝、流量重新均衡的過程耗時(shí)十分長，可達(dá)小時(shí)甚至是天級(jí)別[6]，而采用 AutoMQ Kafka 由于其采用可靠性和可用性分離的設(shè)計(jì)，單副本即高可靠，整個(gè)分區(qū)移動(dòng)過程無任何數(shù)據(jù)拷貝[7]。下圖可以清晰看到，如果采用 Apche Kafka 在數(shù)據(jù)規(guī)模較大的場景下是完全沒法應(yīng)用 Spot 實(shí)例并且提供 serverless 能力的，因?yàn)樵诶鋯?dòng)的整個(gè)時(shí)間軸上，Apache Kafka 在分區(qū)移動(dòng)和流量重平衡兩個(gè)過程的耗時(shí)占據(jù)著總耗時(shí)絕對(duì)的比重。不將這兩塊耗時(shí)降低到與其他冷啟動(dòng)階段相同數(shù)量級(jí)下，spot 實(shí)例的應(yīng)用和 serverless 也無從談起。

與之相反的是，AutoMQ Kafka 憑借其秒級(jí)分區(qū)遷移[9]和持續(xù)流量重平衡[8]等殺手锏特性，不僅將高危的、重運(yùn)維的分區(qū)移動(dòng)和重平衡的耗時(shí)降低到秒級(jí)，同時(shí)整個(gè)過程還是自動(dòng)化的，相比 Apache Kafka 而言，有了跨時(shí)代的進(jìn)步。當(dāng)軟件系統(tǒng)本身有較短的冷啟動(dòng)時(shí)間以后，圍繞冷啟動(dòng)的其他階段進(jìn)行優(yōu)化才有意義。在 AutoMQ 內(nèi)核不再成為冷啟動(dòng)瓶頸的情況下，AutoMQ 也將不斷探索利用容器技術(shù)、GraalVM AOT 編譯等手段提升整個(gè)端到端冷啟動(dòng)的效率，給大家?guī)砀?、更好的彈性能力?/p>

充分利用云 Spot 實(shí)例的終止信號(hào)

Spot 實(shí)例回收的一般流程遵循如下流程，先發(fā)送終止信號(hào)，然后等待若干秒后再強(qiáng)制終止機(jī)器。不同云廠商的 Spot 實(shí)例的終止流程基本是如下流程的變種，核心路徑基本相同。AutoMQ Kafka 的架構(gòu)上使用了一塊非常小（默認(rèn) 3GB）的云盤 SSD （AWS 上即 EBS，下文皆以 EBS 表示云盤 SSD）來充當(dāng)緩沖區(qū)的角色，以保證 AutoMQ Kafka 追尾讀的低延遲。得益于 AutoMQ Kafka 無狀態(tài)的 Broker 設(shè)計(jì)，EBS 上只會(huì)殘留約幾百 MB 左右的少量緩存數(shù)據(jù)，只要保證 Spot 實(shí)例在接收到終止信號(hào)的等待期間將這部分?jǐn)?shù)據(jù)刷到對(duì)象存儲(chǔ)上，即可完成優(yōu)雅停機(jī)。

AutoMQ 充分利用了這個(gè)實(shí)例終止信號(hào)，通過感知這個(gè)實(shí)例終止信號(hào)，然后在實(shí)例接收到終止信號(hào)的這段等待時(shí)間內(nèi)提前執(zhí)行刷出 EBS 緩存數(shù)據(jù)的操作來完成優(yōu)雅停機(jī)。不同云廠商開放給用戶去感知這個(gè)終止信號(hào)的方式會(huì)有差異，但是基本都會(huì)預(yù)留至少 10 秒以上的等待時(shí)間來讓應(yīng)用執(zhí)行優(yōu)雅下線，而這預(yù)留的時(shí)間對(duì)于 AutoMQ 來說是完全足夠的。

Spot 實(shí)例友好的容災(zāi)機(jī)制

前面小節(jié)提到了 AutoMQ Kafka 利用 Spot 實(shí)例終止信號(hào)后的一小段等待時(shí)間來完成優(yōu)雅停機(jī)，這時(shí)候一定會(huì)有聰明的小伙伴提出質(zhì)疑：我們應(yīng)該考慮面向失敗的設(shè)計(jì)，最壞情況下例如網(wǎng)絡(luò)異常、系統(tǒng)負(fù)載異?？D導(dǎo)致 AutoMQ  來不及將數(shù)據(jù)在終止信號(hào)后的這段等待時(shí)間及時(shí)刷出怎么辦呢？其實(shí)，這種情況 AutoMQ 也已經(jīng)考慮到了，因此專門設(shè)計(jì)了 Spot 實(shí)例友好的容災(zāi)機(jī)制[10]。

下圖是整個(gè)容災(zāi)機(jī)制的簡單示意圖，總體上概括起來就是：

1. AutoMQ 通過探測及時(shí)發(fā)現(xiàn)由于 Spot 實(shí)例回收而遺留的游離數(shù)據(jù)卷，通過云盤管理的 API 將其掛載到一臺(tái)合適的新的計(jì)算實(shí)例上

2. 將游離數(shù)據(jù)卷殘留的少量數(shù)據(jù)刷出到對(duì)象存儲(chǔ)

3. 刪除已經(jīng)為空的數(shù)據(jù)卷

通過這種容災(zāi)機(jī)制，即使在最壞情況下，AutoMQ Kafka 仍然可以完成自動(dòng)化的容災(zāi)，整個(gè)過程業(yè)務(wù)無感。

按需實(shí)例與 Spot 實(shí)例混部

AutoMQ Kafka 雖然大量應(yīng)用了 Spot 實(shí)例來降低成本，但是仍然在兩個(gè)緯度上保留了少量按需實(shí)例的使用，從而確保 AutoMQ 可以給用戶提供可靠的 Kafka 服務(wù)。

KRaft 節(jié)點(diǎn)使用 on-demand 實(shí)例：

AutoMQ 的核心能力依賴的重要元數(shù)據(jù)依靠 KRaft，為了保證元數(shù)據(jù)的可靠性，參與 Raft 選舉和保障元數(shù)據(jù)一致性的節(jié)點(diǎn)仍然使用的是 on-demand 實(shí)例，確保他們保持穩(wěn)定。

Broker 集群支持 on-demand 和 Spot 實(shí)例混布：

以 AWS Spot 實(shí)例的實(shí)際使用情況來看，一個(gè) 30 臺(tái)機(jī)器的 AutoMQ Kafka 集群，一天內(nèi)會(huì)有若干次實(shí)例置換，這種零碎時(shí)刻的實(shí)例置換，在 AutoMQ 這種無狀態(tài)和極致彈性的設(shè)計(jì)下對(duì)業(yè)務(wù)基本是無感的。Spot 實(shí)例的置換僅僅會(huì)導(dǎo)致部分分區(qū)數(shù)據(jù)的讀寫有秒級(jí)的 RT 抖動(dòng)，這可以滿足絕大部分 Kafka 的應(yīng)用場景。即使如此，AutoMQ 也充分考慮到一部分對(duì)成本不敏感，但是對(duì) RT 抖動(dòng)要求非?？量痰挠脩舻脑V求，允許用戶調(diào)節(jié) Broker 集群中 on-demand 實(shí)例的比例，權(quán)衡成本與延遲抖動(dòng)頻率。

回退按需實(shí)例

Spot 實(shí)例除了存在會(huì)中斷的問題，還存在容易庫存不足的問題。對(duì)于云廠商而言，按需實(shí)例是有 SLA 的并且要最高優(yōu)先級(jí)保障庫存余量充足。如果一個(gè)地域某個(gè)可用區(qū)下的計(jì)算實(shí)例庫存不足，則會(huì)優(yōu)先用于滿足按需實(shí)例的供給。在這種規(guī)則下，一些冷門地域或者可用區(qū)的 Spot 實(shí)例庫存容量容易產(chǎn)生不足，當(dāng)需要發(fā)生實(shí)例替換時(shí)，會(huì)存在無法購買到競價(jià)實(shí)例的情況。

AutoMQ Kafka 為了應(yīng)對(duì)可能出現(xiàn)的 Spot 實(shí)例庫存不足的情況，提供了回退按需實(shí)例（后文簡稱該特性為 fallback）的能力。Fallback 本質(zhì)就是探測并識(shí)別 Spot 實(shí)例庫存不足的情況，然后在這種情況下重新購買按需實(shí)例來補(bǔ)充容量。并且 fallback 支持當(dāng) Spot 實(shí)例可以重新購買時(shí)，自動(dòng)將集群中的按需實(shí)例重新替換成按需實(shí)例。該功能的總體實(shí)現(xiàn)主要是利用了彈性伸縮組本身容量管理的特性來達(dá)到的，因篇幅原因，后續(xù)會(huì)專門出一篇文章來介紹 fallback 能力的實(shí)現(xiàn)。

03

穩(wěn)定性與成本之間的權(quán)衡

Spot 實(shí)例本身不可預(yù)期的中斷、庫存問題使得很多系統(tǒng)設(shè)計(jì)與開發(fā)者對(duì)其應(yīng)用望而卻步，持有過度的偏見。其實(shí)這種疑慮本質(zhì)上源于不了解。正如世間沒有絕對(duì)的安全一樣，也不存在絕對(duì)的穩(wěn)定性。穩(wěn)定性的定義因應(yīng)用場景而異，因?yàn)椴煌瑘鼍皩?duì)于“穩(wěn)定”的標(biāo)準(zhǔn)各不相同。在軟件系統(tǒng)設(shè)計(jì)中，關(guān)鍵在于做出恰當(dāng)?shù)臋?quán)衡。

以 AutoMQ 提供的 Kafka 為例，如果你可以容忍因 Spot 實(shí)例替換帶來的某些時(shí)刻部分分區(qū)上秒級(jí)的 RT 抖動(dòng)，那么你可以放心的使用較大比例的 Spot 實(shí)例從而獲取巨大的成本節(jié)約；但是如果你是一個(gè)對(duì) RT 抖動(dòng)極度敏感的用戶，那你也仍然可以全部采用按需實(shí)例，僅僅享受 AutoMQ 帶來的極致彈性能力。簡單而言，適合自己的才是最好的，也歡迎大家真正來體驗(yàn) AutoMQ ，看看我們到底幾斤幾兩。AutoMQ Kafka 核心代碼均已在 GitHub 開源，歡迎來社區(qū)一起交流。

參考資料

[1] 中國通信院 云計(jì)算白皮書 2023

[2] AutoMQ Kafka 云原生重塑 Kafka 架構(gòu)

[3] AutoMQ Kafka 成本分析報(bào)告

[4] EC2 Spot 的最佳實(shí)踐

[5] Kafka Tiered Storage Early Access Release Notes

[6]Making Apache Kafka Serverless: Lessons From Confluent Cloud

[7] AutoMQ 單副本高可用

[8] AutoMQ 持續(xù)重平衡

[9] AutoMQ 秒級(jí)分區(qū)遷移

[10] AutoMQ Kafka issue 447