問題背景

Serverless 計(jì)算也稱服務(wù)器無感知計(jì)算或函數(shù)計(jì)算，是近年來一種新興的編程模式。其致力于大幅簡化云業(yè)務(wù)開發(fā)流程，使得應(yīng)用開發(fā)者從繁雜的服務(wù)器運(yùn)維工作中解放出來（例如自動伸縮、日志和監(jiān)控等）。借助 Serverless 計(jì)算，開發(fā)者僅需上傳業(yè)務(wù)代碼并進(jìn)行簡單的資源配置便可實(shí)現(xiàn)服務(wù)的快速構(gòu)建部署，云服務(wù)商則按照函數(shù)服務(wù)調(diào)用量和實(shí)際資源使用收費(fèi)，從而幫助用戶實(shí)現(xiàn)業(yè)務(wù)的快速交付(fastbuilt&Relia.Deliv.)和低成本運(yùn)行。

然而，Serverless 計(jì)算的無狀態(tài)函數(shù)編程在帶來高度彈性和靈活性的同時(shí)，也導(dǎo)致了不可避免的冷啟動問題。由于函數(shù)通常在執(zhí)行完請求后被釋放，當(dāng)請求到達(dá)時(shí)，如果沒有可用實(shí)例則需要從零開始啟動新的實(shí)例處理請求（即冷啟動）。當(dāng)冷啟動發(fā)生時(shí)，Serverless 平臺需要執(zhí)行實(shí)例調(diào)度、鏡像分發(fā)、實(shí)例創(chuàng)建、資源配置、運(yùn)行環(huán)境初始化以及代碼加載等一系列操作，這一過程引發(fā)的時(shí)延通常可達(dá)請求實(shí)際執(zhí)行時(shí)間的數(shù)倍。相對于冷啟動調(diào)用，熱調(diào)用（即請求到達(dá)時(shí)有可用實(shí)例）的準(zhǔn)備時(shí)間可以控制在亞毫秒級。在特定領(lǐng)域例如 AI 推理場景，冷啟動調(diào)用導(dǎo)致的高時(shí)延問題則更為突出，例如，使用 TensorFlow 框架的啟動以及讀取和加載模型可能需要消耗數(shù)秒或數(shù)十秒。

因此，如何緩解 Serverless 函數(shù)的冷啟動問題，改善函數(shù)性能是當(dāng)前 Serverless 領(lǐng)域面臨的主要挑戰(zhàn)之一。

解決方案

從研究思路上看，目前工業(yè)界和學(xué)術(shù)界主要從兩個方面入手解決冷啟動問題：

（1）加快實(shí)例啟動速度：當(dāng)冷啟動調(diào)用發(fā)生時(shí)，通過加速實(shí)例的初始化過程來減少啟動時(shí)延；

當(dāng)冷啟動發(fā)生時(shí)，Serverless 平臺內(nèi)部實(shí)例的初始化過程可以劃分為準(zhǔn)備和加載兩個階段。其中，準(zhǔn)備階段主要包括控制面決策調(diào)度/鏡像獲取、Runtime 運(yùn)行時(shí)初始化、應(yīng)用數(shù)據(jù)/代碼傳輸幾個部分。而加載階段位于實(shí)例內(nèi)部，包括用戶應(yīng)用框架和代碼的初始化過程。在工業(yè)界和學(xué)術(shù)界公開的研究成果中，針對實(shí)例啟動過程中的每個階段都有大量的技術(shù)手段和優(yōu)化方法。如下圖所示，經(jīng)過優(yōu)化，實(shí)例冷啟動的準(zhǔn)備階段和加載階段時(shí)間可被極大得縮短。

下面列舉了一些近年來發(fā)表在計(jì)算機(jī)系統(tǒng)領(lǐng)域知名會議的相關(guān)工作，主要可以分為五個方面：

1、調(diào)度優(yōu)化/鏡像快速分發(fā)/本地池化：

例如基于樹結(jié)構(gòu)的跨節(jié)點(diǎn)快速鏡像分發(fā)FaasNet[ATC'21]；Pod 池+特化實(shí)例跳過鏡像傳輸[華為 FunctionGraph]。其中，快速鏡像分發(fā)依賴于 VM 節(jié)點(diǎn)的上/下行網(wǎng)絡(luò)帶寬，Pod 池特化技術(shù)則是典型的以空間換時(shí)間的做法。

2、輕量級虛擬化/安全容器：

例如針對傳統(tǒng)容器 Docker 的精簡優(yōu)化工作 SOCK[ATC'21]；更側(cè)重安全性的輕量級虛擬化技術(shù)（KataContainers,gVisor 等)；基于安全容器的進(jìn)一步的精簡優(yōu)化工作(Catalyzer[ASPLOS'20],REAP[ASPLOS'21])。通過裁剪優(yōu)化，安全容器的啟動時(shí)延最快可以被壓縮至亞毫秒級。

3、數(shù)據(jù)共享/跨節(jié)點(diǎn)傳輸優(yōu)化：

例如基于 RDMA 共享內(nèi)存減少跨節(jié)點(diǎn)啟動過程的數(shù)據(jù)拷貝RemoteFork[OSDI'23]；或者利用本地代碼緩存跳過代碼傳輸[華為 FunctionGraph,字節(jié) ByteFaaS 等]。基于 RDMA 技術(shù)的跨節(jié)點(diǎn)數(shù)據(jù)傳輸時(shí)延可降低至微妙級。

4、用戶代碼精簡/快速加載：

例如針對 Java 語言的 JVM（JavaVirtualMachine）運(yùn)行時(shí)優(yōu)化技術(shù)[FunctionGraph]；以及針對 Python 運(yùn)行時(shí)庫的裁剪優(yōu)化工作 FaasLight[arxiv'23]。通過特定的優(yōu)化，JVM 啟動時(shí)間可由數(shù)秒降低至數(shù)十毫秒，而 Python 代碼的啟動加載時(shí)延可降低約 1/3。

5、其它非容器運(yùn)行時(shí)技術(shù)：

例如 WASM（即 WebAssembly）技術(shù)以及針對 WASM 的內(nèi)存隔離方面的優(yōu)化工作 Faasm[ATC'20]。相比容器化技術(shù)，直接以進(jìn)程和線程方式組織運(yùn)行函數(shù)，可在保證低開銷函數(shù)運(yùn)行的同時(shí)具備高度靈活性。

（2）降低冷啟動發(fā)生率：通過函數(shù)預(yù)熱、復(fù)用或?qū)嵗蚕淼确椒ㄌ岣邔?shí)例的利用效率，減少冷啟動調(diào)用的發(fā)生

盡管已有的一些實(shí)例啟動加速方法已經(jīng)可以將運(yùn)行時(shí)環(huán)境的初始化時(shí)間壓縮至數(shù)十毫秒甚至是數(shù)毫秒，然而用戶側(cè)的延遲卻仍然存在，例如程序狀態(tài)的恢復(fù)，變量或者配置文件的重新初始化，相關(guān)庫和框架的啟動。具體來講，在機(jī)器學(xué)習(xí)應(yīng)用中，TensorFlow 框架的啟動過程往往需要花費(fèi)數(shù)秒，即使實(shí)例運(yùn)行時(shí)環(huán)境的啟動時(shí)間再短，應(yīng)用整體的冷啟動時(shí)延對用戶而言依然是無法接受的（注：通常大于 200ms 的時(shí)延可被用戶察覺）。在這種情況下，可以從另一個角度入手解決冷啟動問題，即降低冷啟動調(diào)用的發(fā)生率。例如，通過緩存完整的函數(shù)實(shí)例，請求到達(dá)時(shí)可以快速恢復(fù)并處理請求，從而實(shí)現(xiàn)近乎零的初始化時(shí)延（例如 Dockerunpause 操作時(shí)延小于 0.5ms）。

降低冷啟動發(fā)生率的相關(guān)研究可以分為如下幾個方面：

1、實(shí)例保活/實(shí)例預(yù)留：

例如基于 Time-to-Live 的 keepalive 保活機(jī)制[AWSLambda,OpenWhisk]；或者通過并發(fā)配置接口預(yù)留一定數(shù)量的實(shí)例[AWSLabmda 等]；這些方法原理簡單，易于實(shí)現(xiàn)，但是在面對負(fù)載變化時(shí)緩存效率較低。

2、基于負(fù)載特征學(xué)習(xí)的動態(tài)緩存：

例如基于請求到達(dá)間隔預(yù)測的動態(tài)緩存方案ServerlessintheWild[ASPLOS'20]；學(xué)習(xí)長短期負(fù)載變化特征的動態(tài)緩存方案INFless[ASPLOS'22]；基于優(yōu)先級的可替換緩存策略 FaasCache[ATC'21]；面向異構(gòu)服務(wù)器集群的低成本緩存方案IceBreaker[ASPLOS'22]。這些動態(tài)緩存方案根據(jù)負(fù)載特征學(xué)習(xí)決定實(shí)例緩存數(shù)量或時(shí)長，從而在降低冷啟動調(diào)用率的同時(shí)改善緩存資源消耗。

3、優(yōu)化請求分發(fā)提高命中率：

例如兼顧節(jié)點(diǎn)負(fù)載和本地化執(zhí)行的請求調(diào)度算法CH-RLU[HPDC'22]。通過權(quán)衡節(jié)點(diǎn)負(fù)載壓力和緩存實(shí)例的命中率來對請求的分發(fā)規(guī)則進(jìn)行優(yōu)化設(shè)計(jì)，避免節(jié)點(diǎn)負(fù)載過高導(dǎo)致性能下降，同時(shí)兼顧冷啟動率。

4、改善并發(fā)/實(shí)例共享或復(fù)用：

例如允許同一函數(shù)工作流的多個函數(shù)共享 Sandbox 環(huán)境SAND[ATC'18]；使用進(jìn)程或線程編排多個函數(shù)到單個實(shí)例中運(yùn)行Faastlane[ATC'21]；提高實(shí)例并發(fā)處理能力減少實(shí)例創(chuàng)建Fifer[Middle'20];允許租戶復(fù)用其它函數(shù)的空閑實(shí)例減少冷啟動時(shí)間Pagurus[ATC'22]。這些實(shí)例共享或者復(fù)用技術(shù)可以同緩存方案結(jié)合使用，降低冷啟動帶來的性能影響。

總結(jié)

Serverless 的無狀態(tài)設(shè)計(jì)賦予了函數(shù)計(jì)算高度彈性化的擴(kuò)展能力，然而也帶來了難以避免的冷啟動問題。消除 Serverless 函數(shù)的冷啟動開銷還是從降低函數(shù)冷啟動率和加速實(shí)例啟動過程兩個角度綜合入手。對于冷啟動開銷比較大的函數(shù)，在函數(shù)計(jì)算框架的設(shè)計(jì)機(jī)制中進(jìn)行優(yōu)化，盡量避免冷啟動發(fā)生；當(dāng)冷啟動發(fā)生時(shí)，采用一系列啟動加速技術(shù)來縮短整個過程進(jìn)行補(bǔ)救。在 Serverless 平臺的內(nèi)部，冷啟動的管理在實(shí)踐中可以做進(jìn)一步精細(xì)的劃分，例如針對 VIP 大客戶，針對有規(guī)律負(fù)載的，或是針對冷啟動開銷小的函數(shù)，通過分類做定制化、有目的的管理可以進(jìn)一步改善系統(tǒng)效率。

審核編輯 黃宇