Serverless遇到 FinOps: Economical Serverless

摘要：本文基于FunctionGraph在Serverless 領域的FinOps探索和實踐，提出業界首個Serverless函式總成本估計模型

歷川：華為云Serverless研發專家
平山：華為云中間件Serverless負責人
馮嘉：華為云中間件首席專家

Key Takeaways:

1）盡管Serverless的迅猛發展吸引了廣泛深入的關注，Serverless函式總成本的事先估計仍缺乏有效的理論指導，本文基于FunctionGraph在Serverless 領域的FinOps探索和實踐，提出業界首個Serverless函式總成本估計模型；

2）根據對成本模型的關鍵因素分析，提出五大類函式運行成本的優化方法；同時，為更好地幫助用戶實作降本增效，華為云首次提出透明、高效、一鍵式的 “用戶函式成本研究中心”，

問題引言

Serverless 精確到毫秒級的按用付費模式使得用戶不再需要為資源的空閑時間付費，然而，對于給定的某個應用函式，由于影響其計費成本的因素并不唯一，使得用戶對函式運行期間的總計費進行精確的事先估計變成了一項困難的作業，

以傳統云資源的周期性租賃模式為例，通過周期數乘以周期單價，用戶可以很容易地估計出租賃期間的總費用，形成清晰的心理賬戶預期，即使在云平臺采用階梯定價或價格歧視策略的情形下，計算租賃總成本也不是一件難事，

但在Serverless場景中，事先估計函式總成本仍缺乏有效的理論指導，一方面，影響函式計費的關鍵因素不唯一，如包括函式記憶體規格、單實體并發度、函式執行時長等；另一方面，函式呼叫流量的波動通常具有隨機性和非平穩性，使得基于流量的“按用計費”具有較大的不確定性，

當然，尋找函式計費的理論指導主要是為用戶評估函式總成本提供一種有效依據，但更加重要地，如何進一步利用估計模型，幫助用戶優化應用函式及其配置選擇，進而顯著降低用戶函式總成本，是Serverless領域中，FinOps亟待回答的問題，

FinOps聚焦云上資源管理和成本優化，通過有機鏈接技術、業務、和財務專業人士，來優化用戶、企業、組織的云資源成本，提高云上業務的投入-產出比 [1]，本文結合華為云FunctionGraph在Serverless 領域的FinOps探索和實踐，剖析Serverless場景下的函式計費模式和關鍵影響因素，介紹一種對函式運行期間總計費進行事先估計的模型框架; 更重要地，該模型為幫助用戶優化函式運行總成本、提升用戶云上Serverless資源管理效能，實作經濟型 (Economical) Serverless 提供有效依據，

一. 名詞解釋與背景知識

首先對表1所列的幾個概念做簡要說明，

表1：Serverless函式常見名詞

記憶體規格 (Memory)：記憶體規格也即函式規格、函式實體規格，表示Serverless平臺為函式的單個實體所分配的資源大小，一般表示為函式可使用的記憶體大小，由用戶指定；實體可使用的CPU份額與記憶體大小成正比，Serverless云平臺通常提供多種規格供用戶選擇，以FunctionGraph為例，用戶可選15種函式規格，如圖1所示，

圖1：FunctionGraph提供多種函式記憶體規格

函式執行時延 (Function Execution Time): 這里指完成一次呼叫請求回應的程序中，函式本身執行所消耗的時間，主要由函式代碼邏輯決定，一般地，對于CPU密集型的函式，增大函式資源規格（記憶體-CPU Share），可以顯著降低函式執行時延，但對于消耗大部分時間在網路IO等操作上的函式，增大資源規格對執行時延的改善則非常有限，

單實體最大并發度 (Maximum Requests per Instance)：函式的單個實體可以同時處理的最大請求數，主要適用于函式執行程序中有顯著時間在等待下游服務回傳的場景，如訪問資料庫操作或磁盤IO等，對于相同的流量負載，提高函式的單實體并發度可以降低按量實體個數，為用戶節省計費，同時，也可以降低函式呼叫請求的冷啟動比例，

單函式最大實體數 (Maximum Instances per Function)：指同一函式同一時刻下同時運行的實體數上限，對用戶來說，最大實體數可以防止例外流量洪峰下或函式發生故障時由于云平臺的過度擴容而導致的費用失控；對云平臺來說，最大實體數可以防止例外情況下平臺資源被部分函式耗光，從而保障不同函式間的性能隔離，

二. 函式計費與成本模型

單實體視角下的函式計費估計模型，可參考 [2]，在真實生產環境中，除異步函式外，Serverless云平臺通常采用FCFS（First Come First Serve）的方式回應呼叫請求，對于函式流量的潮汐波動，平臺通過自動擴縮容實體進行自適應，系統中運行的并發實體數隨時間的變化，可以由一個分段常線性函式完全刻畫，如圖2所示，

圖2：函式并發實體數隨擴縮容程序的變化

盡管不同Serverless云廠商之間的計費方法存在差異，函式計費一般主要包括兩部分：對函式所使用資源的計費以及對請求次數的計費，表示如下：

后半部分代表云平臺提供的免計費總量，與函式呼叫流量以及函式配置無關，

三. 成本優化方法討論

有了函式成本的估計模型，就可以對影響用戶成本的關鍵因素進行討論， 在估計式 (1) 中，忽略云平臺提供的免計費總量，函式月度總成本的結構如下：

Point 1: 優化函式代碼邏輯本身，降低函式執行時延

對于同樣的函式流量負載，更低的執行時延 可以為用戶節省更多計費成本，在用戶業務邏輯允許的前提下，不斷優化函式代碼、提高函式執行效率是軟體工程本身天然的訴求，但在Serverless場景下，這一點顯得更為迫切，
具體地，考慮采用Python、Nodejs等輕量化編程語言，減少函式初始化配置中的非必要項，將連接其它服務如資料庫等的操作盡量移到函式執行入口之前的初始化階段完成，簡化代碼邏輯等，

另外，為幫助用戶掌握函式運行情況，FunctionGraph為應用函式提供深度可視化的可觀測能力，支持豐富的觀測指標配置，包括呼叫次數、錯誤次數、運行時延等，如圖3所示的函式運行時間監控示例，

圖3: FunctionGraph 函式運行時間監控示例

Point 2: 優化函式代碼包、依賴包、鏡像大小

當函式呼叫觸發冷啟動的時候，從計費角度看，冷啟動時延包含在執行時延 中一起計費，而冷啟動中有相當比例的時延消耗在云平臺從第三方存盤服務（如華為云物件存盤服務OBS）中下載用戶的代碼包、依賴包，或從鏡像倉庫服務中拉取用戶應用鏡像，如圖4所示，盡管為了優化冷啟動性能，目前大部分云平臺均會采用各類快取機制，對用戶代碼和鏡像進行預快取，但實體啟動中消耗在用戶代碼加載上的時延仍然十分顯著，因此，應盡可能優化函式代碼包大小，包括對依賴包、鏡像等進行瘦身，進而降低計費時長，

圖4：冷熱啟動下的計費時長及優化點

Point 3: 撰寫功能聚焦的輕量化函式

在Serverless編程框架下，盡可能將函式撰寫為輕量型的、功能聚焦的程式代碼，即“functions should be small and purpose-built”[3]；讓“一個函式只做一件事”，一方面，功能單一的函式，運行時延也更容易針對性地進行優化；另一方面，當一個函式內同時實作多個功能的時候，大概率會以所有功能都在性能上同時做出妥協為結果，最終提高了函式運行期間總計費，

圖5：華為云FunctionGraph 函式流示例

若應用函式的確需要提供多個功能，可以考慮將大函式分解為多個小函式，然后通過函式編排的方式實作整體邏輯, 如圖5所示的FunctionGraph函式流功能，大函式分解也是Serverless計算中用戶處理超時（timeout）等例外場景的最佳實踐之一 [4]，

Point 4: 業務模型支持的前提下，采用單實體多并發

從公式（2）的函式成本結構中可以看出，在用戶業務模型支持的前提下，配置一定的單實體并發度 ，可以有效降低函式月度總成本；若用戶不進行配置，云平臺默認值通常為1，即單個實體同一時刻只能處理一個請求；因此，在函式被并發呼叫的情形下，平臺會啟動多個實體進行回應，從而增大了計費實體數目，如圖6所示；同時，采用單實體多并發，也能改善呼叫請求處于等待狀態的尾時延，

圖6：單實體并發度：計費時長視角和實體數視角

當然，單實體并發度并非越高越好，例如，過高的并發度設定會使得函式實體內多執行緒之間的資源競爭加劇（e.g., CPU contention），導致函式回應性能惡化，影響用戶應用的QoS指標等，同時，如本文在背景知識中所提，并非所有的應用函式都適合設定單實體多并發，單實體多并發主要適用于函式執行程序中有相當比例的時延消耗在等待下游服務回傳的場景，這類場景下，實體資源如CPU等有顯著比例處于空閑等待狀態，如訪問資料庫、訊息佇列等中間件、或磁盤IO、網路IO等，單實體多并發也需要用戶在函式代碼中對錯誤捕獲（e.g., 考慮請求級別的錯誤捕獲粒度）和全域共享變數的執行緒安全（e.g., 加鎖保護）問題進行適配，

Point 5: 函式資源規格的選擇需考慮對執行時延的影響

最后討論函式資源規格的選擇問題，從公式（2）明顯可以看出，更大規格的實體記憶體 對應更高的計費成本，但記憶體規格的選擇，需要同時考慮對函式執行時延 的影響，從用戶函式的角度看，函式執行時延除了由代碼本身的業務邏輯決定之外，還受實體運行時可使用資源大小的影響，更大的實體規格，對應更大的可使用記憶體和更多的CPU份額，從而可能顯著改善高記憶體占用型或CPU密集型函式的執行性能，降低執行時延；當然，這種改善也存在上限，超過某個資源規格后，資源的增加對降低函式執行時延的效果幾乎可以忽略，如圖7中虛線所表示的程序，上述事實表明，對于給定的用戶函式，為降低總計費成本，需要配置合理的實體規格 ，使得 盡可能取得最小值，如圖7中實線所表示的程序，

圖7：函式規格的選擇需同時考慮對成本和執行時延的影響

圖8：函式計費成本的關鍵因素分析

四. Serverless函式成本研究中心

為用戶降本增效，是FunctionGraph的核心理念，盡管前文分析的五種函式成本優化手段是站在用戶視角下的討論，但我們認為這些問題遠不是只屬于用戶需要考慮的范圍；相反地，FunctionGraph在持續探索如何最大限度地幫助用戶在Serverless領域實作最佳的FinOps效果，讓用戶能夠真正享受到Economical Serverless的福利；例如，在實體級別的深度可視化、可觀測性前提下，幫助用戶實作函式FinOps全流程的自動化，為用戶提供透明、高效、一鍵式的函式資源管理和成本優化服務，

圖9. 在線式資源消耗感知與規格動態推薦

為此，基于內部實踐，FunctionGraph 將于近期推出“用戶函式成本研究中心 – Cost Analysis and Optimization Center”, 為用戶提供包括離線式函式最佳配置調優（offline power tuning）、在線式資源消耗感知與規格動態推薦（online resource recommendation， 如圖9所示）、預測性函式彈性預覽（predictive auto-scaling preview）等在內的多個重量級特性服務，最大限度降低用戶實作函式FinOps的技術門檻，為用戶業務開發、Serverless化改造等提供極致便捷性，

五. 總結與展望

本文主要討論了Serverless計算場景下的FinOps 問題，給出了業界首個用戶函式總成本估計模型，并根據該模型，為用戶優化應用函式、提升Serverless資源管理效能、降低總成本提供理論參考和實踐依據，

一項新興技術領域的興起，首先需要回答的問題是“Why & Value”, FunctionGraph作為華為元戎加持的下一代Serverless函式計算與編排服務，結合FinOps等技術理念，持續為用戶提供經濟型Serverless服務， 后續我們將分享更多圍繞通用全場景Serverless的前沿理論及其案例實踐，回饋社區，包括FunctionGraph在微服務Serverless化上的實踐經驗等，

參考資料：

[1] What is FinOps: https://www.finops.org/introduction/what-is-finops/

[2] Running Lambda Functions Faster and Cheaper: https://levelup.gitconnected.com/running-lambda-functions-faster-and-cheaper-416260fbc375?gi=4370e4c57684

[3] AWS Lambda Cost Optimizations Strategies That Work. https://dashbird.io/blog/aws-lambda-cost-optimization-strategies/

[4] Timeout Best Practices. https://lumigo.io/learn/aws-lambda-timeout-best-practices/

點擊關注，第一時間了解華為云新鮮技術~

標籤：其他

上一篇：ipv4與ipv6的聯系和區別

下一篇：游戲的AI型別