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云廠商之間的計費方法存在差異，函數計費一般主要包括兩部分：對函數所使用資源的計費以及對請求次數的計費，表示如下：

其中，表示對資源使用的計費，單位為GB-秒（GB-second），?表示對調用次數的計費。

為方便計算，用表示函數的資源規格，單位為GB。例如，對于128MB規格的函數，其?；c表示該函數的單實例并發數，μ表示函數的平均執行時延，單位為毫秒；并用α（0<α<1）表示Serverless平臺的調用鏈路性能，在最理想的情況下，該指標為1，表示在當前Serverless平臺上，該函數響應單個請求的端到端時延等于函數執行時延μ本身，不同Serverless平臺的α值可能略有不同，但通常在0.9以上。給定上述指標，可以得到單實例在理想狀況下的請求處理能力, 即理論上每秒可以響應的調用次數為：

因此，單實例的實際請求處理能力則為：

我們以一個月作為估計周期。假設一個月內，函數共經歷了n次擴、縮容，形成了n個常線性子區間（如圖2所示）。先考察單個子區間內的計費成本模型，總成本模型則為各個連續子區間的加和。

在時間窗口內，假設函數調用次數為，則該時間窗內的并發實例數為：

對應的資源計費部分則可表示為：

其中，表示每GB-秒的資源的計費單價?，F在，記第i個子區間為，則一個月內的總成本模型可以估計為：

其中，表示每次調用的計費單價，?表示函數該月總流量，為云平臺提供的月度免費計量時間，為月度免費計量調用次數。

在上式中，單實例并發度c和函數規格可以認為在用戶配置之后屬于常數；α屬于平臺側參數，也可視作常數；對于函數執行時延μ，實際中通常會由于冷熱啟動差異、網絡抖動、調用請求入參等的不同而波動，且考慮到Serverless計費是精確到毫秒級別的，因此嚴格意義上不能被視作為常數。不過，作為估計模型，這里暫且假定μ也為常數。綜上，總成本模型可以表示為：

后半部分代表云平臺提供的免計費總量，與函數調用流量以及函數配置無關。

成本優化方法討論

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

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

對于同樣的函數流量負載，更低的執行時延μ可以為用戶節省更多計費成本。在用戶業務邏輯允許的前提下，不斷優化函數代碼、提高函數執行效率是軟件工程本身天然的訴求，但在Serverless場景下，這一點顯得更為迫切。

具體地，考慮采用Python、Nodejs等輕量化編程語言，減少函數初始化配置中的非必要項，將連接其它服務如數據庫等的操作盡量移到函數執行入口之前的初始化階段完成，簡化代碼邏輯等。

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

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

Point2: 優化函數代碼包、依賴包、鏡像大小

當函數調用觸發冷啟動的時候，從計費角度看，冷啟動時延包含在執行時延μ中一起計費，而冷啟動中有相當比例的時延消耗在云平臺從第三方存儲服務（如華為云對象存儲服務OBS）中下載用戶的代碼包、依賴包，或從鏡像倉庫服務中拉取用戶應用鏡像，如圖4所示。

盡管為了優化冷啟動性能，目前大部分云平臺均會采用各類緩存機制，對用戶代碼和鏡像進行預緩存，但實例啟動中消耗在用戶代碼加載上的時延仍然十分顯著。因此，應盡可能優化函數代碼包大小，包括對依賴包、鏡像等進行瘦身，進而降低計費時長。

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

Point3: 編寫功能聚焦的輕量化函數

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

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

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

Point4: 業務模型支持的前提下，采用單實例多并發

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

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

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

Point5: 函數資源規格的選擇需考慮對執行時延的影響

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

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

例如，考慮實例規格的初始配置為（例如從最小規格開始，i.e., 128MB）, 經測試該規格下函數執行時延為，則可以得到基線，然后逐步增大資源規格，測試對應執行時延，直到某一組出現，使得：

此時表明，資源增大對計費成本的邊際提升已經超過了對執行時延的邊際改善，因此，從成本的角度看，此時的為帕累托最優解，即最佳規格，對應執行時延為。

最后，圖8對上述幾個決定函數成本的關鍵因素做了一個總結，其中，箭頭方向表示元素之間的直接影響，“+”號代表成正比，“-”代表成反比。

圖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化上的實踐經驗等。