Key Takeaways
1.USENIX ATC（USENIX Annual Technical Conference) 是計算機系統(tǒng)領(lǐng)域國際頂級學(xué)術(shù)會議之一（CCF-A），在國際上享有極高的學(xué)術(shù)聲譽，2024年錄用率僅為15.8%。來自華為云中間件團隊、上海交通大學(xué)IPADS實驗室的論文《Harmonizing Efficiency and Practicability: Optimizing Resource Utilization in Serverless Computing with JIAGU》[1]成功入選ATC 2024。
2.如何提高資源利用率一直是 Serverless 領(lǐng)域乃至云平臺面臨的優(yōu)化難題之一，本文將介紹華為云Serverless在高效、高密度調(diào)度優(yōu)化方面的探索歷程，并揭秘30%+ 利用率提升背后的原理。
Serverless作為一種新的架構(gòu)范式，引領(lǐng)著云廠商基礎(chǔ)設(shè)施的變革與云服務(wù)的演進，憑借著按量付費、自動彈性、免運維的特點吸引越來越多的企業(yè)與用戶關(guān)注。主流云服務(wù)商不斷地推出 Serverless 相關(guān)的云產(chǎn)品和新功能，其中華為云對Serverless在高效、高密度調(diào)度優(yōu)化方面深入探索后，推出函數(shù)即服務(wù)(Function-As-A-Service)產(chǎn)品-FunctionGraph，作為華為云全域Serverless的核心產(chǎn)品，其覆蓋邊緣計算、車聯(lián)網(wǎng)、AI應(yīng)用等場景，此次揭秘華為云Serverless 30%+ 利用率提升的探索歷程。
1、Serverless平臺資源利用率的巨大挑戰(zhàn)
提高資源利用率一直是 Serverless 領(lǐng)域乃至云平臺面臨的優(yōu)化難題之一，華為云對平臺運行的函數(shù)實例數(shù)據(jù)進行分析，發(fā)現(xiàn)不同的Serverless函數(shù)在CPU或內(nèi)存利用率上有較大的提升空間。圖1是實例內(nèi)資源浪費的示意圖。這表明，資源利用不足的問題主要由如下兩個因素造成。
規(guī)格過配：為了保證性能與可靠性，用戶通常會考慮最壞的情況，從而指定相對較大的函數(shù)規(guī)格。即使實例滿負載也無法充分利用分配的資源。這就造成了圖1中①部分的資源浪費。
空閑實例：在實際業(yè)務(wù)應(yīng)用中，每個實例所服務(wù)的用戶負載往往會存在波動性。當(dāng)實例負載較低時會空閑出部分資源，而這些資源無法被其他實例使用，這會產(chǎn)生圖1中②部分的資源浪費。
圖1 資源利用率提升空間（源于論文）
為了提高Serverless集群利用率，現(xiàn)有方案主要針對以下兩個方向進行優(yōu)化：
一是通過超分（overcommit）減少實例資源的過量分配[2]，通過scheduler在節(jié)點上部署更多的函數(shù)實例，來減少①部分的浪費；
二是通過實例快速縮容（autoscaling）應(yīng)對負載（RPS）的動態(tài)波動[3]，盡量使每個實例的負載接近飽和負載，減少實例空閑造成的②部分的資源浪費。
然而，如何在現(xiàn)有調(diào)度系統(tǒng)中有效的使用這兩個措施存在巨大的挑戰(zhàn)：
首先，超分很有可能導(dǎo)致性能下降從而違背QoS(Quality-of-Service)，常見的作法是通過預(yù)測性能以避免違背QoS，這將在調(diào)度路徑上引入模型推理，而預(yù)測精度越高意味著計算復(fù)雜，從而調(diào)度開銷越大，簡單的計算卻難以有效保證QoS，存在預(yù)測精度與調(diào)度開銷之間的權(quán)衡；其次，當(dāng)負載波動時，為了快速釋放空閑實例資源，需要更敏感的自動擴容能力來靈活地調(diào)整實例個數(shù)，也意味著要更多額外的冷啟動，那么如何在資源利用率和冷啟動開銷之間進行權(quán)衡成了難題。
2、基于JIAGU的高效調(diào)度：華為云對資源利用率的優(yōu)化探索
2.1、系統(tǒng)架構(gòu)
為了應(yīng)對上述技術(shù)挑戰(zhàn)，我們可以考慮以下兩點：
預(yù)測與決策解耦。預(yù)測精度和調(diào)度成本之間的權(quán)衡來自于預(yù)測和決策的耦合，即往往在調(diào)度期間進行代價高昂的模型推斷。我們可以將預(yù)測和決策解耦。具體來說，調(diào)度器可以在新實例到來之前對資源環(huán)境進行建模，并基于假設(shè)進行提前預(yù)測。當(dāng)一個新的實例到來，并且調(diào)度時的資源環(huán)境符合我們之前的假設(shè)時，可以直接根據(jù)準備好的決策來進行調(diào)度。這提供了一個無需推理的調(diào)度快速路徑。
資源釋放和實例淘汰解耦。資源利用率和冷啟動開銷之間的權(quán)衡來自于資源釋放和實例驅(qū)逐的耦合。相反，我們可以解耦資源釋放和實例驅(qū)逐。具體來說，即使一個實例沒有被驅(qū)逐，我們也可以調(diào)整路由，不向它發(fā)送請求，將負載較低的實例中的請求路由到其他實例中，達到與實際驅(qū)逐類似的資源釋放效果。調(diào)整路由的開銷遠小于實際的冷啟動開銷。因此，通過這種方式，我們可以以更高的靈敏度釋放/回收資源以應(yīng)對負載波動，同時避免過多的額外冷啟動開銷。
基于此，我們設(shè)計了一個高效、高密度的QoS感知調(diào)度系統(tǒng)JIAGU（甲骨），如圖2所示。首先，我們設(shè)計了一種預(yù)決策調(diào)度，可以在低調(diào)度延遲的情況下做出準確的預(yù)測。在創(chuàng)建實例時，會對其部署后的性能進行預(yù)測，在不違反QoS的前提下，盡量提高實例的部署密度，以充分利用資源。其次，采用了兩階段擴縮容設(shè)計，在負載波動情況下，以最小的開銷高效利用資源。
圖2 JIAGU 系統(tǒng)設(shè)計（來源于論文）
2.2、系統(tǒng)設(shè)計
QoS預(yù)測模型：QoS感知調(diào)度建立在能夠精確預(yù)測各函數(shù)在特定資源條件下的性能的基礎(chǔ)上。與現(xiàn)有工作以實例粒度做性能預(yù)測不同，JIAGU利用了同一函數(shù)多個實例之間的同構(gòu)性，以函數(shù)為粒度做性能預(yù)測，并引入了并發(fā)度作為每個函數(shù)的新特征。如圖3所示，這有效地降低了輸入維數(shù)，從而減少了訓(xùn)練開銷，并可能緩解“維數(shù)詛咒”。其中QoS考慮了性能目標，主要以尾延遲為指標，但可以擴展到其他指標。
圖3 預(yù)測模型（來源于論文）
節(jié)點容量表：為將預(yù)測和決策解耦，對于每一個部署的函數(shù)，提前預(yù)測新實例的性能，基于QoS保證原則的計算它在該節(jié)點上的容量，最終計算出節(jié)點上每個函數(shù)的容量表?！叭萘俊北硎驹摵瘮?shù)能夠在當(dāng)前環(huán)境下部署的不違背QoS的最大并發(fā)實例數(shù)。之后，當(dāng)調(diào)度器做出調(diào)度決策時，它可以通過表查詢的方式，即檢查函數(shù)實例部署后并發(fā)度是否超過該函數(shù)的容量，來預(yù)測QoS違規(guī)，而無需進行模型推斷。這就是調(diào)度“Fast path”。此外，只有當(dāng)傳入實例所屬的函數(shù)不在該節(jié)點的容量表中時，例如函數(shù)第一次部署到該節(jié)點上時，才需要對關(guān)鍵路徑進行預(yù)測，此為“Slow path”。而實際負載的結(jié)果顯示，超過80%的調(diào)度通過Fast path。
容量異步更新：由于部署新函數(shù)可能會對節(jié)點上其他函數(shù)施加資源干擾，從而導(dǎo)致它們的QoS違反。因此，引入了異步更新容量，當(dāng)新函數(shù)被調(diào)度到節(jié)點時，它會觸發(fā)更新容量表，更新在調(diào)度關(guān)鍵路徑之外異步完成。即保證了容量表始終最新，又避免了容量更新引入額外的調(diào)度開銷。
并發(fā)度感知調(diào)度：云上最極端的調(diào)用模式之一是負載峰值，當(dāng)負載快速上升，需要同時創(chuàng)建多個函數(shù)實例。若如圖4（a）所示的每個實例的創(chuàng)建都進行一次預(yù)測，將會帶來巨大的調(diào)度開銷?；诖?，JIAGU 進一步采用并發(fā)感知調(diào)度，它在負載高峰時對同一個函數(shù)并發(fā)傳入的實例進行調(diào)度。容量的計算方式，不僅考慮到是否可以部署下一個實例，還考慮了可以部署多少個下一個實例，如圖4（b）所示，當(dāng)同一函數(shù)的多個實例到達時，如果該函數(shù)在節(jié)點上的容量足以容納這些新的實例，則多個實例的調(diào)度和異步更新可以被批處理，只需要進行一次。
圖4 并發(fā)度感知調(diào)度（來源于論文）
兩階段擴縮容：當(dāng)前通用的實例驅(qū)逐策略是當(dāng)負載下降時，針對空閑實例等待一段時間后直接進行驅(qū)逐，如圖5（a）所示，這種直接縮容的方式在負載波動的場景下往往會導(dǎo)致更頻繁的冷啟動。為了將資源釋放與實例淘汰解耦，考慮如圖5中（b）所示兩階段擴縮容：
一階段：當(dāng)負載下降時，在驅(qū)逐實例之前，會先以更高的敏感性調(diào)整路由，將請求發(fā)送到更少的實例，從而使部分實例處于空閑狀態(tài)；
二階段：當(dāng)處于空閑狀態(tài)一段時間后，再進行實例資源的釋放。如果負載在空閑實例被釋放之前再次上升，則可以通過重路由以最小的開銷使實例重新工作。此外，為了應(yīng)對某個節(jié)點的容量滿了，而其上的處于空閑狀態(tài)的情況，會提前將空閑實例 遷移 到其他節(jié)點上，以減少冷啟動的開銷。
圖5 兩階段縮容設(shè)計（來源于論文）
2.3、效果驗證
基于云上的真實負載數(shù)據(jù)我們驗證分析了JIAGU的調(diào)度性能，如下圖6（a）部分結(jié)果所示，相比于當(dāng)前先進的基于模型的調(diào)度器Gsight[4]（發(fā)表于SC’21）相比，其調(diào)度成本降低了81.0%–93.7%，這是因為 JIAGU的基于節(jié)點容量的調(diào)度策略可以大幅減少模型推理的數(shù)量, 從而在多次冷啟動中避免了推理開銷。如圖6（b）(c)所示在不同運行時的場景下，JIAGU的冷啟動延遲相比Gsight分別降低了57.4%和20%?？偟膩碚fJIAGU在調(diào)度性能上普遍優(yōu)于當(dāng)前的基于模型的調(diào)度器。
圖6 調(diào)度性能驗證結(jié)果（來源于論文）
同時我們評估了JIAGU在資源利用率提升和QoS保障方面的效果，如圖7所示，與現(xiàn)有流行的調(diào)度器Kubernetes、Gsight[4]、Owl[5]相比，在維持相當(dāng)?shù)腝oS保障性的基礎(chǔ)上，JIAGU實現(xiàn)了最高的資源利用率，實例密度比Kubernetes高54.8%，比Gsight高22.0%，比Owl高38.3%?？梢姰?dāng)用戶負載下降時，JIAGU可以快速利用不飽和實例的資源。
圖7 資源利用率驗證結(jié)果（來源于論文）
3、總結(jié)與展望
本文介紹了華為云對調(diào)度優(yōu)化這一業(yè)界難題的探索之路，創(chuàng)新性提出了基于JIAGU的高效的資源優(yōu)化調(diào)度系統(tǒng)，通過在現(xiàn)網(wǎng)的大規(guī)模驗證，我們發(fā)現(xiàn)JIAGU在不同資源密集型業(yè)務(wù)混部的場景，保證QoS不影響的前提下實現(xiàn)了資源利用率30%+的提升，歡迎大家來體驗。同時我們也在持續(xù)探索、優(yōu)化調(diào)度能力，面向GPU等資源異構(gòu)資源，結(jié)合函數(shù)畫像實現(xiàn)精準調(diào)度。
此外在其它關(guān)鍵技術(shù)上，華為云FunctionGraph在過去一年內(nèi)陸續(xù)構(gòu)建了多項能力，旨在優(yōu)化平臺極致性能。在冷啟動優(yōu)化方面，探索了基于進程級快照的Java冷啟動加速方案 [6]，節(jié)省了框架與業(yè)務(wù)初始化時間（占Java應(yīng)用冷啟動時間的90%），通過函數(shù) 鏡像 預(yù)加載技術(shù)，大幅縮減了函數(shù)代碼下載解壓時間，實現(xiàn)了冷啟動時延降低90%+；在彈性效率方面，面向水平彈性決策與啟動時間長的問題，一方面通過流量預(yù)測進行實例預(yù)熱，另一方面構(gòu)建了實例垂直彈性能力，實現(xiàn)毫秒級響應(yīng)；在函數(shù)間通信性能方面，通過多語言Runtime加速、統(tǒng)一消息結(jié)構(gòu)免序列化、集成Kmesh加速節(jié)點內(nèi)數(shù)據(jù)轉(zhuǎn)發(fā)等技術(shù)，實現(xiàn)亞毫秒級低時延函數(shù)互調(diào)，為微服務(wù)Serverless化保駕護航；在邊緣計算方面，自研了基于WASM輕量級安全沙箱的調(diào)度底座，在高并發(fā)下實現(xiàn)小于3ms的冷啟動的極致彈性能力，且支持可編程CDN，云邊一體。
FunctionGraph 作為華為元戎內(nèi)核加持的下一代 Serverless 函數(shù)計算與編排服務(wù)，致力于持續(xù)為用戶提供方便、迅捷的 Serverless 服務(wù)體驗。您可以登錄華為云 FunctionGraph 控制臺來深入體驗，更多信息請參閱 華為云FunctionGraph 官方文檔 [7] 。后續(xù)我們將分享更多圍繞通用全場景 Serverless 的前沿理論及其案例實踐，回饋社區(qū)。
華為云Serverless 應(yīng)用中心：http://m.cqfng.cn/product/functiongraph/applications.html
作者：思遠
審稿：清源、舊浪
參考文獻
