當Serverless遇到Regionless：現狀與挑戰
摘要：本文嘗試基於分析現有的學術文章，剖析Serverless與Regionless並存時，在效能提升和成本控制兩個方向的現狀與挑戰
本文分享自華為雲社群《當Serverless遇到Regionless：現狀與挑戰》，作者：雲容器大未來。
近年來，Serverless服務崛起的趨勢是有目共睹的：從Berkeley將Serverless認定為雲端計算向用戶呈現的新預設形態[1]，到頭部廠商紛紛推出Serverless產品併成為爆款。這個趨勢對於雲端計算平臺是個必然，因為Serverless解放了使用者管理和使用複雜雲端計算資源的雙手，猶如第二次工業革命中內燃機汽車的出現解決了馬車伕養馬的麻煩，也推動高效、穩定的交通工具走進尋常百姓家。如同汽車由內燃機和轉向機構等元件構成，Serverless平臺可大致分為資源管理和任務編排[2]，分別致力於提供高效且靈活的算力以及提供方便的使用者程式執行方式。
在Serverless如火如荼的同時，Regionless也是不可忽視的一個方向。Regionless實際上是華為雲提出的概念，即為遮蔽掉雲平臺Region的差異，使得雲服務的租戶能像「用水和用電」一樣隨時隨地使用雲服務。Regionless的內涵實際上是豐富的，囊括了多個學術研究方向：可以是geo-distributed cloud，也可以是multi-cloud，還可以是cloud-edge computing、 hybrid cloud等，分別對應不同的能力。恰好，以上都涵蓋在華為雲分散式雲原生服務提供的offerings中。
既然Serverless和Regionless都是當前雲原生髮展的重要方向，也都基於同一個雲平臺資源底座構建，那麼兩者的發展必然不會是平行的：Serverless對基礎設施進行了標準化，為應用Regionless化減少了管理和適配的成本；反過來，Regionless也是Serverless的重要組成，因其可以避免使用者感知Region間的差異。
事實上，早在2018年，就有學者關注到Serverless對底層差異的遮蔽以及平臺提供商數量的快速增長，使用者必然會有將Serverless業務部署至Regionless平臺的訴求[3]。在此場景下，使用者和平臺設計者首當其中考慮到的就是如何充分利用分佈在各個區域的計算資源以提升如並行度、時延等效能；同時，使用成本也是使用者核心關注點，所以如何充分利用各個廠商的定價差異消減成本，同時也避免與廠商繫結（vendor lock-in）帶來潛在的成本問題也需要充分考慮。因此，本文嘗試基於分析現有的學術文章，剖析Serverless與Regionless並存時，在效能提升和成本控制兩個方向的現狀與挑戰，以期拋磚引玉。
效能提升
早在2019年，來自華盛頓大學的研究者[4]已經注意到Serverless工作流中的計算任務會涉及儲存在不同區位的資料，並且這些資料在對應區位會存在隱私性等問題，因此需要將任務分佈到對應資料所在的雲平臺Region進行計算。為此，作者設計了跨Region的排程器GlobalFlow，其核心思想是將工作流中的任務根據對Region的依賴關係進行分組，形成子工作流排程到對應Region，並且在子工作流之間設計Connector以便於資料交換。
同樣考慮到資料分佈的問題，即資料可能分佈在不同的區域，而且由於資料隱私性、傳輸開銷等問題，並不能方便地集中在一個區域內處理，[5]中的作者設計了FaDO系統用以編排Serverless計算任務和資料。如圖1所示，FaDO通過Backend Server記錄每個區域儲存的資料，這些資訊則被提供給Load Balancer用於將使用者請求的計算任務匹配並行送到對應的區域。並且在規則允許範圍內，Backend Server還會將資料備份在不同的區域間進行復制，以配合計算任務的並行度。
圖1 FaDO系統執行流程
除了資料的分佈會促使Serverless必須接受Regionless，[6]的作者還觀察到：一個雲廠商的每個Region、每個廠商都有不同的並行度限制，並且之間的資料傳輸時延、儲存的資料、每種任務執行的速度等能力均不一致。簡單的將應用分發到多雲/多Region上並不一定能充分提升並行度和整體完成時間。例如圖2左側所示（每種顏色標記的雲上並行度限制為1000，整體應用由f1-f4任務構成，也需要執行1000次），如果f1在藍色標識的雲資源上執行地快，而f4則在橙色上快時，均勻分佈則不能利用這個效能差異，而且在橙色雲上，f2和f3並不能充分並行（完全並行需要1200並行度），進一步影響整體執行時間。在此情況下，如何合理選擇任務所使用的雲資源（如圖2右側所示），以有效地提升並行度是[6]所研究的重點。為此，[6]中提出了基於三層數學抽象構建的排程器演演算法FaaSt。FaaSt能夠合理地將各個任務排程和合適的雲廠商/Region上，使得整體的任務完成時間最短。經過在AWS和IBM雲上4個Region的實驗對比，FaaSt排程後的任務完成時間比單雲提升2.82倍。
圖2 Serverless並行度示意圖
成本控制
為了協助使用者選擇合適的平臺以執行Serverless任務，[3]中提出了MPSC框架，其核心思想是通過實時監控Serverless任務在不同平臺上執行的效能，進而選擇最具價效比的平臺。MPSC的架構如圖3所示，其中Monitoring Controller為核心元件，用於協調監控指標採集分析和任務排程。Function Executor則負責將任務分發至各個平臺執行，並採集對應指標。除此之外，還有三個儲存模組分別用於儲存使用者設定、監控指標、使用者定義的排程邏輯。
圖3 MPSC系統架構
在Serverless任務能夠合理分發的基礎之上，來自CMU和UBC的學者提出了虛擬Serverless提供商（virtual Serverless provider, VSP）[7]的概念。VSP作為第三方的平臺，聚合了各個廠商的Offerings，為使用者提供統一的使用介面，為使用者動態選擇最具價效比的Offering。VSP整體架構如圖4所示，其中核心元件包括：Scheduler用以根據效能指標和花費計算最合適的雲平臺；Controller則負責將應用請求對映到Scheduler選擇的雲平臺上；Bridge用於不同雲平臺之間任務的互動；Monitor用以記錄排程到不同平臺上任務的執行效能；Pre-Load用於初始化新接入的雲平臺；而Cache則記錄了平臺執行情況用於後續分析優化。通過在AWS和Google雲平臺上的測試，VSP將Serverless任務的吞吐量提升了1.2-4.2倍，同時降低了54%的雲資源使用成本。
圖4 VSP系統架構
進一步地，一個面向多雲Serverless的開源library在[8]中提出了。此library主要包括兩部分內容（如圖5所示）：1）統一的API和SDK，用於讓使用者不需要感知底層差異即可將不同人物部署在不同的雲平臺上，並且為了降低使用者的學習門檻，還提供了基於某一家雲平臺提供商的API和SDK（如AWS）拓展出來的、可以將任務部署在其他雲平臺的API和SDK；2）分析系統（EAS），用於分析每個任務最適合的雲平臺，包含用於將任務分發至不同平臺的adaptor、各個平臺log的收集器Cloud Logging Query、各個雲廠商的計費模型Cost Model、接入各個雲平臺的鑑權元件Authentication、任務執行的記錄Local Logging以及效能分析器Analysis。
圖5 面向多雲的Serverless開源library
挑戰
從上述現有工作可以看出，當前學術界對於Regionless和Serverless結合的研究主要面向geo-distributed cloud和multi-cloud這兩個場景下的任務編排系統架構和演演算法。然而這還遠遠不足以構建高效、易用的Regionless化的Serverless平臺。類似於Berkeley將Serverless分成Backend-as-a-Service (BaaS)和Function-as-a-Service (FaaS)兩個層級[1]，我們也可以將當前所面臨的挑戰拆分成底層資源供給以及上層應用管理在Regionless場景的Serverless化：
• 底層資源上，我們需要考慮：
- 通盤考慮每個區域計算資源池的異構性、資源餘量、成本等因素的情況下，提供足夠的資源同時又不因為Serverless極強的彈性而造成過多浪費[9]；
- 從網路角度，在規避部分地理區位間頻寬、時間等限制的同時，提供支援動態創刪的低效能損失、免設定的網路；
- 儲存上，提供使用者無感知的跨Region資料預存取與快取。
• 應用管理層面上看，需要達到如下：
%2) 任務編排上，需要對計算、網路、儲存聯合進行排程以避免其中某項瓶頸對整體應用的影響；
%2) 程式設計框架上，需要在最小甚至沒有侵入式修改的前提下，將使用者應用構建或遷移至該平臺；
%2) 從監控運維角度，需要實現非侵入式、高精度地採集Serverless範例的指標，並基於分佈在各個區域的監控資料進行智慧異常檢測、根因分析。
以上也將雲廠商和學術界共同打造高效且易用的Regionless下Serverless平臺，共同面臨的挑戰。
參考文獻
[1] J. Schleier-Smith, et. al. "What serverless computing is and should become: The next phase of cloud computing," Communications of the ACM, vol. 64, no.5, pp. 76-84, 2021.
[2] Li, Zijun, et. al. "The serverless computing survey: A technical primer for design architecture." ACM Computing Surveys (CSUR), vol. 54, no.10s, pp. 1-34, 2022.
[3] A. Aske, et. al. "Supporting multi-provider serverless computing on the edge," in Proc. Int. Conf. Parallel Processing Companion, 2018.
[4] G. Zheng, et. al. "GlobalFlow: a cross-region orchestration service for serverless computing services," in Proc. IEEE Int. Conf. Cloud Comput. (CLOUD), 2019.
[5] C. Smith, et. al. "Fado: Faas functions and data orchestrator for multiple serverless edge-cloud clusters," in Proc. IEEE Int. Conf. Fog and Edge Comput. (ICFEC), 2022.
[6] S. Ristov, et. al, "FaaSt: Optimize makespan of serverless workflows in federated commercial FaaS," in Proc. IEEE Int. Conf. Cluster Comput. (CLUSTER), 2022.
[7] A. Baarzi, et. al. "On merits and viability of multi-cloud Serverless," in Proc. ACM Symp. Cloud Comput., 2021.
[8] H. Zhao, et al. "Supporting Multi-Cloud in Serverless Computing," arXiv preprint arXiv:2209.09367, 2022.
[9] A. Mampage, et. al. "A holistic view on resource management in serverless computing environments: Taxonomy and future directions," ACM Computing Surveys (CSUR), vol. 54, no. 11s, pp. 1-36, 2022.