Key Takeaways：

1. 盡管 Serverless 的迅猛發(fā)展吸引了廣泛深入的關(guān)注，Serverless 函數(shù)總成本的事先估計(jì)仍缺乏有效的理論指導(dǎo)。本文基于 FunctionGraph 在 Serverless 領(lǐng)域的 FinOps 探索和實(shí)踐，提出業(yè)界首個 Serverless 函數(shù)總成本估計(jì)模型。

2. 根據(jù)對成本模型的關(guān)鍵因素分析，提出五大類函數(shù)運(yùn)行成本的優(yōu)化方法；同時，為更好地幫助用戶實(shí)現(xiàn)降本增效，華為云首次提出透明、高效、一鍵式的 “用戶函數(shù)成本研究中心”。

Serverless 精確到毫秒級的按用付費(fèi)模式使得用戶不再需要為資源的空閑時間付費(fèi)。然而，對于給定的某個應(yīng)用函數(shù)，由于影響其計(jì)費(fèi)成本的因素并不唯一，使得用戶對函數(shù)運(yùn)行期間的總計(jì)費(fèi)進(jìn)行精確的事先估計(jì)變成了一項(xiàng)困難的工作。

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

但在Serverless場景中，事先估計(jì)函數(shù)總成本仍缺乏有效的理論指導(dǎo)。一方面，影響函數(shù)計(jì)費(fèi)的關(guān)鍵因素不唯一，如包括函數(shù)內(nèi)存規(guī)格、單實(shí)例并發(fā)度、函數(shù)執(zhí)行時長等；另一方面，函數(shù)調(diào)用流量的波動通常具有隨機(jī)性和非平穩(wěn)性，使得基于流量的“按用計(jì)費(fèi)”具有較大的不確定性。

當(dāng)然，尋找函數(shù)計(jì)費(fèi)的理論指導(dǎo)主要是為用戶評估函數(shù)總成本提供一種有效依據(jù)，但更加重要地，如何進(jìn)一步利用估計(jì)模型，幫助用戶優(yōu)化應(yīng)用函數(shù)及其配置選擇，進(jìn)而顯著降低用戶函數(shù)總成本，是Serverless領(lǐng)域中，F(xiàn)inOps亟待回答的問題。

FinOps聚焦云上資源管理和成本優(yōu)化，通過有機(jī)鏈接技術(shù)、業(yè)務(wù)、和財(cái)務(wù)專業(yè)人士，來優(yōu)化用戶、企業(yè)、組織的云資源成本，提高云上業(yè)務(wù)的投入-產(chǎn)出比 [1]。本文結(jié)合華為云FunctionGraph在Serverless領(lǐng)域的FinOps探索和實(shí)踐，剖析Serverless場景下的函數(shù)計(jì)費(fèi)模式和關(guān)鍵影響因素，介紹一種對函數(shù)運(yùn)行期間總計(jì)費(fèi)進(jìn)行事先估計(jì)的模型框架；更重要地，該模型為幫助用戶優(yōu)化函數(shù)運(yùn)行總成本、提升用戶云上Serverless資源管理效能，實(shí)現(xiàn)經(jīng)濟(jì)型 (Economical) Serverless 提供有效依據(jù)。名詞解釋與背景知識

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

表1：Serverless函數(shù)常見名詞

內(nèi)存規(guī)格 (Memory)：內(nèi)存規(guī)格也即函數(shù)規(guī)格、函數(shù)實(shí)例規(guī)格，表示Serverless平臺為函數(shù)的單個實(shí)例所分配的資源大小，一般表示為函數(shù)可使用的內(nèi)存大小，由用戶指定；實(shí)例可使用的CPU份額與內(nèi)存大小成正比。Serverless云平臺通常提供多種規(guī)格供用戶選擇，以FunctionGraph為例，用戶可選15種函數(shù)規(guī)格，如圖1所示。

圖1：FunctionGraph提供多種函數(shù)內(nèi)存規(guī)格

函數(shù)執(zhí)行時延 (Function Execution Time)：這里指完成一次調(diào)用請求響應(yīng)的過程中，函數(shù)本身執(zhí)行所消耗的時間，主要由函數(shù)代碼邏輯決定。一般地，對于CPU密集型的函數(shù)，增大函數(shù)資源規(guī)格（內(nèi)存-CPU Share），可以顯著降低函數(shù)執(zhí)行時延。但對于消耗大部分時間在網(wǎng)絡(luò)IO等操作上的函數(shù)，增大資源規(guī)格對執(zhí)行時延的改善則非常有限。

單實(shí)例最大并發(fā)度 (Maximum Requests per Instance)：函數(shù)的單個實(shí)例可以同時處理的最大請求數(shù)，主要適用于函數(shù)執(zhí)行過程中有顯著時間在等待下游服務(wù)返回的場景，如訪問數(shù)據(jù)庫操作或磁盤IO等。對于相同的流量負(fù)載，提高函數(shù)的單實(shí)例并發(fā)度可以降低按量實(shí)例個數(shù)，為用戶節(jié)省計(jì)費(fèi)，同時，也可以降低函數(shù)調(diào)用請求的冷啟動比例。

單函數(shù)最大實(shí)例數(shù)(Maximum Instances per Function)：指同一函數(shù)同一時刻下同時運(yùn)行的實(shí)例數(shù)上限。對用戶來說，最大實(shí)例數(shù)可以防止異常流量洪峰下或函數(shù)發(fā)生故障時由于云平臺的過度擴(kuò)容而導(dǎo)致的費(fèi)用失控；對云平臺來說，最大實(shí)例數(shù)可以防止異常情況下平臺資源被部分函數(shù)耗光，從而保障不同函數(shù)間的性能隔離。

函數(shù)計(jì)費(fèi)與成本模型

單實(shí)例視角下的函數(shù)計(jì)費(fèi)估計(jì)模型，可參考 [2]。在真實(shí)生產(chǎn)環(huán)境中，除異步函數(shù)外，Serverless云平臺通常采用FCFS（First Come First Serve）的方式響應(yīng)調(diào)用請求，對于函數(shù)流量的潮汐波動，平臺通過自動擴(kuò)縮容實(shí)例進(jìn)行自適應(yīng)，系統(tǒng)中運(yùn)行的并發(fā)實(shí)例數(shù)隨時間的變化，可以由一個分段常線性函數(shù)完全刻畫，如圖2所示。

圖2：函數(shù)并發(fā)實(shí)例數(shù)隨擴(kuò)縮容過程的變化

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

其中，表示對資源使用的計(jì)費(fèi)，單位為GB-秒（GB-second），?表示對調(diào)用次數(shù)的計(jì)費(fèi)。

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

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

我們以一個月作為估計(jì)周期。假設(shè)一個月內(nèi)，函數(shù)共經(jīng)歷了n次擴(kuò)、縮容，形成了n個常線性子區(qū)間（如圖2所示）。先考察單個子區(qū)間內(nèi)的計(jì)費(fèi)成本模型，總成本模型則為各個連續(xù)子區(qū)間的加和。

在時間窗口內(nèi)，假設(shè)函數(shù)調(diào)用次數(shù)為，則該時間窗內(nèi)的并發(fā)實(shí)例數(shù)為：

對應(yīng)的資源計(jì)費(fèi)部分則可表示為：

其中，表示每GB-秒的資源的計(jì)費(fèi)單價。現(xiàn)在，記第i個子區(qū)間為，則一個月內(nèi)的總成本模型可以估計(jì)為：

其中，表示每次調(diào)用的計(jì)費(fèi)單價，?表示函數(shù)該月總流量，為云平臺提供的月度免費(fèi)計(jì)量時間，為月度免費(fèi)計(jì)量調(diào)用次數(shù)。

在上式中，單實(shí)例并發(fā)度c和函數(shù)規(guī)格可以認(rèn)為在用戶配置之后屬于常數(shù)；α屬于平臺側(cè)參數(shù)，也可視作常數(shù)；對于函數(shù)執(zhí)行時延μ，實(shí)際中通常會由于冷熱啟動差異、網(wǎng)絡(luò)抖動、調(diào)用請求入?yún)⒌鹊牟煌▌?，且考慮到Serverless計(jì)費(fèi)是精確到毫秒級別的，因此嚴(yán)格意義上不能被視作為常數(shù)。不過，作為估計(jì)模型，這里暫且假定μ也為常數(shù)。綜上，總成本模型可以表示為：

后半部分代表云平臺提供的免計(jì)費(fèi)總量，與函數(shù)調(diào)用流量以及函數(shù)配置無關(guān)。

成本優(yōu)化方法討論

有了函數(shù)成本的估計(jì)模型，就可以對影響用戶成本的關(guān)鍵因素進(jìn)行討論。在估計(jì)式 (1) 中，忽略云平臺提供的免計(jì)費(fèi)總量，函數(shù)月度總成本的結(jié)構(gòu)如下：

Point 1：優(yōu)化函數(shù)代碼邏輯本身，降低函數(shù)執(zhí)行時延

對于同樣的函數(shù)流量負(fù)載，更低的執(zhí)行時延μ可以為用戶節(jié)省更多計(jì)費(fèi)成本。在用戶業(yè)務(wù)邏輯允許的前提下，不斷優(yōu)化函數(shù)代碼、提高函數(shù)執(zhí)行效率是軟件工程本身天然的訴求，但在Serverless場景下，這一點(diǎn)顯得更為迫切。

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

另外，為幫助用戶掌握函數(shù)運(yùn)行情況，F(xiàn)unctionGraph為應(yīng)用函數(shù)提供深度可視化的可觀測能力，支持豐富的觀測指標(biāo)配置，包括調(diào)用次數(shù)、錯誤次數(shù)、運(yùn)行時延等，如圖3所示的函數(shù)運(yùn)行時間監(jiān)控示例。

圖3: FunctionGraph 函數(shù)運(yùn)行時間監(jiān)控示例

Point2: 優(yōu)化函數(shù)代碼包、依賴包、鏡像大小

當(dāng)函數(shù)調(diào)用觸發(fā)冷啟動的時候，從計(jì)費(fèi)角度看，冷啟動時延包含在執(zhí)行時延μ中一起計(jì)費(fèi)，而冷啟動中有相當(dāng)比例的時延消耗在云平臺從第三方存儲服務(wù)（如華為云對象存儲服務(wù)OBS）中下載用戶的代碼包、依賴包，或從鏡像倉庫服務(wù)中拉取用戶應(yīng)用鏡像，如圖4所示。

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

圖4：冷熱啟動下的計(jì)費(fèi)時長及優(yōu)化點(diǎn)

Point3: 編寫功能聚焦的輕量化函數(shù)

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

圖5：華為云FunctionGraph 函數(shù)流示例

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

Point4: 業(yè)務(wù)模型支持的前提下，采用單實(shí)例多并發(fā)

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

圖6：單實(shí)例并發(fā)度：計(jì)費(fèi)時長視角和實(shí)例數(shù)視角

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

Point5: 函數(shù)資源規(guī)格的選擇需考慮對執(zhí)行時延的影響

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

圖7：函數(shù)規(guī)格的選擇需同時考慮對成本和執(zhí)行時延的影響

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

此時表明，資源增大對計(jì)費(fèi)成本的邊際提升已經(jīng)超過了對執(zhí)行時延的邊際改善，因此，從成本的角度看，此時的為帕累托最優(yōu)解，即最佳規(guī)格，對應(yīng)執(zhí)行時延為。

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

圖8：函數(shù)計(jì)費(fèi)成本的關(guān)鍵因素分析

Serverless函數(shù)成本研究中心

為用戶降本增效，是FunctionGraph的核心理念。盡管前文分析的五種函數(shù)成本優(yōu)化手段是站在用戶視角下的討論，但我們認(rèn)為這些問題遠(yuǎn)不是只屬于用戶需要考慮的范圍；相反地，F(xiàn)unctionGraph在持續(xù)探索如何最大限度地幫助用戶在Serverless領(lǐng)域?qū)崿F(xiàn)最佳的FinOps效果，讓用戶能夠真正享受到Economical Serverless的福利；例如，在實(shí)例級別的深度可視化、可觀測性前提下，幫助用戶實(shí)現(xiàn)函數(shù)FinOps全流程的自動化，為用戶提供透明、高效、一鍵式的函數(shù)資源管理和成本優(yōu)化服務(wù)。

圖9. 在線式資源消耗感知與規(guī)格動態(tài)推薦

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

總結(jié)與展望

本文主要討論了Serverless計(jì)算場景下的FinOps問題，給出了業(yè)界首個用戶函數(shù)總成本估計(jì)模型，并根據(jù)該模型，為用戶優(yōu)化應(yīng)用函數(shù)、提升Serverless資源管理效能、降低總成本提供理論參考和實(shí)踐依據(jù)。

一項(xiàng)新興技術(shù)領(lǐng)域的興起，首先需要回答的問題是“Why & Value”, FunctionGraph作為華為元戎加持的下一代Serverless函數(shù)計(jì)算與編排服務(wù)，結(jié)合FinOps等技術(shù)理念，持續(xù)為用戶提供經(jīng)濟(jì)型Serverless服務(wù)。后續(xù)我們將分享更多圍繞通用全場景Serverless的前沿理論及其案例實(shí)踐，回饋社區(qū)，包括FunctionGraph在微服務(wù)Serverless化上的實(shí)踐經(jīng)驗(yàn)等。