問題背景

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

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

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

解決方案

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

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

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

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

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

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

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

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

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

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

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

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

5、其它非容器運行時技術：

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

（2）降低冷啟動發(fā)生率：通過函數(shù)預熱、復用或實例共享等方法提高實例的利用效率，減少冷啟動調用的發(fā)生

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

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

1、實例保活/實例預留：

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

2、基于負載特征學習的動態(tài)緩存：

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

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

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

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

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

總結

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

編輯：黃飛