摘要：借助Serverless計算，開發者僅需上傳業務代碼并進行簡單的資源配置便可實作服務的快速構建部署，云服務商則按照函式服務呼叫量和實際資源使用收費，從而幫助用戶實作業務的快速交付和低成本運行，
本文分享自華為云社區《Serverless冷啟動：如何讓函式計算更快更強？》，作者：DevAI ，
問題背景
Serverless計算也稱服務器無感知計算或函式計算，是近年來一種新興的云計算編程模式，其致力于大幅簡化云業務開發流程，使得應用開發者從繁雜的服務器運維作業中解放出來（例如自動伸縮、日志和監控等），借助Serverless計算，開發者僅需上傳業務代碼并進行簡單的資源配置便可實作服務的快速構建部署，云服務商則按照函式服務呼叫量和實際資源使用收費，從而幫助用戶實作業務的快速交付 (fast built & Relia. Deliv.)和低成本運行，
然而，Serverless計算的無狀態函式編程在帶來高度彈性和靈活性的同時，也導致了不可避免的冷啟動問題，由于函式通常在執行完請求后被釋放，當請求到達時，如果沒有可用實體則需要從零開始啟動新的實體處理請求（即冷啟動），當冷啟動發生時，Serverless平臺需要執行實體調度、鏡像分發、實體創建、資源配置、運行環境初始化以及代碼加載等一系列操作，這一程序引發的時延通常可達請求實際執行時間的數倍，相對于冷啟動呼叫，熱呼叫（即請求到達時有可用實體）的準備時間可以控制在亞毫秒級，在特定領域例如AI推理場景，冷啟動呼叫導致的高時延問題則更為突出，例如，使用TensorFlow框架的啟動以及讀取和加載模型可能需要消耗數秒或數十秒，
因此，如何緩解Serverless函式的冷啟動問題，改善函式性能是當前Serverless領域面臨的主要挑戰之一，
解決方案
從研究思路上看，目前工業界和學術界主要從兩個方面入手解決冷啟動問題：
（1）加快實體啟動速度：當冷啟動呼叫發生時，通過加速實體的初始化程序來減少啟動時延；
當冷啟動發生時，Serverless平臺內部實體的初始化程序可以劃分為準備和加載兩個階段，其中，準備階段主要包括控制面決策調度/鏡像獲取、Runtime運行時初始化、應用資料/代碼傳輸幾個部分，而加載階段位于實體內部，包括用戶應用框架和代碼的初始化程序，在工業界和學術界公開的研究成果中，針對實體啟動程序中的每個階段都有大量的技術手段和優化方法，如下圖所示，經過優化，實體冷啟動的準備階段和加載階段時間可被極大得縮短，
下面列舉了一些近年來發表在計算機系統領域知名會議的相關作業，主要可以分為五個方面：
- 調度優化/鏡像快速分發/本地池化：例如基于樹結構的跨節點快速鏡像分發 FaasNet [ATC'21]；Pod池+特化實體跳過鏡像傳輸 [華為FunctionGraph]，其中，快速鏡像分發依賴于VM節點的上/下行網路帶寬，Pod池特化技術則是典型的以空間換時間的做法，
- 輕量級虛擬化/安全容器：例如針對傳統容器Docker的精簡優化作業SOCK [ATC'21]；更側重安全性的輕量級虛擬化技術（Kata Containers, gVisor等)；基于安全容器的進一步的精簡優化作業 (Catalyzer [ASPLOS'20], REAP[ASPLOS'21])，通過裁剪優化，安全容器的啟動時延最快可以被壓縮至亞毫秒級，
- 資料共享/跨節點傳輸優化：例如基于RDMA共享記憶體減少跨節點啟動程序的資料拷貝 RemoteFork [OSDI'23]；或者利用本地代碼快取跳過代碼傳輸 [華為FunctionGraph, 位元組ByteFaaS等]，基于RDMA技術的跨節點資料傳輸時延可降低至微妙級，
- 用戶代碼精簡/快速加載：例如針對Java語言的JVM（Java Virtual Machine）運行時優化技術 [FunctionGraph]；以及針對Python運行時庫的裁剪優化作業FaasLight [arxiv'23]，通過特定的優化，JVM啟動時間可由數秒降低至數十毫秒，而Python代碼的啟動加載時延可降低約1/3，
- 其它非容器運行時技術：例如WASM（即WebAssembly）技術以及針對WASM的記憶體隔離方面的優化作業Faasm [ATC'20]，相比容器化技術，直接以行程和執行緒方式組織運行函式，可在保證低開銷函式運行的同時具備高度靈活性，
（2）降低冷啟動發生率：通過函式預熱、復用或實體共享等方法提高實體的利用效率，減少冷啟動呼叫的發生
盡管已有的一些實體啟動加速方法已經可以將運行時環境的初始化時間壓縮至數十毫秒甚至是數毫秒，然而用戶側的延遲卻仍然存在，例如程式狀態的恢復，變數或者組態檔的重新初始化，相關庫和框架的啟動，具體來講，在機器學習應用中，TensorFlow框架的啟動程序往往需要花費數秒，即使實體運行時環境的啟動時間再短，應用整體的冷啟動時延對用戶而言依然是無法接受的（注：通常大于200ms的時延可被用戶察覺），在這種情況下，可以從另一個角度入手解決冷啟動問題，即降低冷啟動呼叫的發生率，例如，通過快取完整的函式實體，請求到達時可以快速恢復并處理請求，從而實作近乎零的初始化時延（例如Docker unpause操作時延小于0.5ms），
降低冷啟動發生率的相關研究可以分為如下幾個方面：
- 實體保活/實體預留：例如基于Time-to-Live的keepalive保活機制 [AWS Lambda, OpenWhisk]；或者通過并發配置介面預留一定數量的實體 [AWS Labmda等]；這些方法原理簡單，易于實作，但是在面對負載變化時快取效率較低，
- 基于負載特征學習的動態快取：例如基于請求到達間隔預測的動態快取方案 Serverless in the Wild [ASPLOS'20]；學習長短期負載變化特征的動態快取方案 INFless [ASPLOS'22]；基于優先級的可替換快取策略FaasCache [ATC'21]；面向異構服務器集群的低成本快取方案 IceBreaker [ASPLOS'22]，這些動態快取方案根據負載特征學習決定實體快取數量或時長，從而在降低冷啟動呼叫率的同時改善快取資源消耗，
- 優化請求分發提高命中率：例如兼顧節點負載和本地化執行的請求調度演算法 CH-RLU [HPDC'22]，通過權衡節點負載壓力和快取實體的命中率來對請求的分發規則進行優化設計，避免節點負載過高導致性能下降，同時兼顧冷啟動率，
- 改善并發/實體共享或復用：例如允許同一函式作業流的多個函式共享Sandbox環境 SAND [ATC'18]；使用行程或執行緒編排多個函式到單個實體中運行 Faastlane [ATC'21]；提高實體并發處理能力減少實體創建 Fifer [Middle'20]; 允許租戶復用其它函式的空閑實體減少冷啟動時間 Pagurus [ATC'22]，這些實體共享或者復用技術可以同快取方案結合使用，降低冷啟動帶來的性能影響，
總結
Serverless的無狀態設計賦予了函式計算高度彈性化的擴展能力，然而也帶來了難以避免的冷啟動問題，消除Serverless函式的冷啟動開銷還是從降低函式冷啟動率和加速實體啟動程序兩個角度綜合入手，對于冷啟動開銷比較大的函式，在函式計算框架的設計機制中進行優化，盡量避免冷啟動發生；當冷啟動發生時，采用一系列啟動加速技術來縮短整個程序進行補救，在Serverless平臺的內部，冷啟動的管理在實踐中可以做進一步精細的劃分，例如針對VIP大客戶，針對有規律負載的，或是針對冷啟動開銷小的函式，通過分類做定制化、有目的的管理可以進一步改善系統效率，
文章來自:PaaS技術創新Lab，PaaS技術創新Lab隸屬于華為云，致力于綜合利用軟體分析、資料挖掘、機器學習等技術，為軟體研發人員提供下一代智能研發工具服務的核心引擎和智慧大腦，我們將聚焦軟體工程領域硬核能力，不斷構筑研發利器，持續交付高價值商業特性！加入我們，一起開創研發新“境界”！
PaaS技術創新Lab主頁鏈接：https://www.huaweicloud.com/lab/paas/home.html
參考文獻
[1] 劉方明, 李林峰, 王磊. 華為Serverless核心技術與實踐[M]. 北京: 電子工業出版社, 2021.11.
[2] Zijun Li, Linsong Guo, Jiagan Cheng, Quan Chen, Bingsheng He, Minyi Guo: The Serverless Computing Survey: A Technical Primer for Design Architecture. ACM Comput. Surv. 54(10s): 220:1-220:34 (2022).
點擊關注，第一時間了解華為云新鮮技術~
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/549311.html
標籤：其他
上一篇：D3D12除錯工具——pix