基于Serverless計(jì)算場景下的FinOps問題

Key Takeaways：

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

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

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

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

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

當(dāng)然，尋找函數(shù)計(jì)費(fèi)的理論指導(dǎo)主要是為用戶評(píng)估函數(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)鍵影響因素，介紹一種對(duì)函數(shù)運(yùn)行期間總計(jì)費(fèi)進(jìn)行事先估計(jì)的模型框架；更重要地，該模型為幫助用戶優(yōu)化函數(shù)運(yùn)行總成本、提升用戶云上Serverless資源管理效能，實(shí)現(xiàn)經(jīng)濟(jì)型 (Economical) Serverless 提供有效依據(jù)。名詞解釋與背景知識(shí)

首先對(duì)表1所列的幾個(gè)概念做簡要說明。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

對(duì)于同樣的函數(shù)流量負(fù)載，更低的執(zhí)行時(shí)延μ可以為用戶節(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ù)、錯(cuò)誤次數(shù)、運(yùn)行時(shí)延等，如圖3所示的函數(shù)運(yùn)行時(shí)間監(jiān)控示例。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖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í)例級(jí)別的深度可視化、可觀測性前提下，幫助用戶實(shí)現(xiàn)函數(shù)FinOps全流程的自動(dòng)化，為用戶提供透明、高效、一鍵式的函數(shù)資源管理和成本優(yōu)化服務(wù)。

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

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

總結(jié)與展望

本文主要討論了Serverless計(jì)算場景下的FinOps問題，給出了業(yè)界首個(gè)用戶函數(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)等。