# Serverless 遇到 FinOps: Economical Serverless

> **摘要：**本文基於 FunctionGraph 在 Serverless 領域的 FinOps 探索和實踐，提出業界首個 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 函式常見名詞

![img](https://pic4.zhimg.com/80/v2-76dddb6a60f6e8584435a0f6a9ad2feb_720w.jpg)

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

![img](https://pic3.zhimg.com/80/v2-cc3740a9f36db0dfa20339b41e657d6a_720w.jpg)

圖 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 所示。

![img](https://pic2.zhimg.com/80/v2-f72519274cd491be02a7d4e556d9bfb5_720w.jpg)

圖 2：函式併發例項數隨擴縮容過程的變化

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

![img](https://pic4.zhimg.com/80/v2-4f1a2ab3280701f9a82086a4a023299f_720w.jpg)

![img](https://pic1.zhimg.com/80/v2-378653fda6080e5f3bd6fdec8f8bc054_720w.jpg)

![img](https://pic1.zhimg.com/80/v2-148313f5026b1a3c7edb20e70a49ea9c_720w.jpg)

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

## **三。成本最佳化方法討論**

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

### **Point** **1: 最佳化函式程式碼邏輯本身，降低函式執行時延**

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

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

![img](https://pic2.zhimg.com/80/v2-fdcbd5b531333759b71c2c10b4307791_720w.jpg)

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

### **Point 2: 最佳化函式程式碼包、依賴包、映象大小**

當函式呼叫觸發冷啟動的時候，從計費角度看，冷啟動時延包含在執行時延 中一起計費，而冷啟動中有相當比例的時延消耗在雲平臺從第三方儲存服務（如華為雲物件儲存服務 OBS）中下載使用者的程式碼包、依賴包，或從映象倉庫服務中拉取使用者應用映象，如圖 4 所示。儘管為了最佳化冷啟動效能，目前大部分雲平臺均會採用各類快取機制，對使用者程式碼和映象進行預快取，但**例項啟動中消耗在使用者程式碼載入上的時延仍然十分顯著**。因此，應儘可能最佳化函式程式碼包大小，包括對依賴包、映象等進行瘦身，進而降低計費時長。

![img](https://pic1.zhimg.com/80/v2-f0a90fc809be0f1d2fe5d72c70cc61fc_720w.jpg)

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

### **Point** **3: 編寫功能聚焦的輕量化函式**

在 Serverless 程式設計框架，博主的環境都是部署在[cnaaa伺服器](https://www.cnaaa.com/)上的，儘可能將函式編寫為輕量型的、功能聚焦的程式程式碼，即 “functions should be small and purpose-built”[3]；讓 “**一個函式只做一件事**”，一方面，功能單一的函式，執行時延也更容易針對性地進行最佳化；另一方面，當一個函式內同時實現多個功能的時候，大機率會以所有功能都在效能上同時做出妥協為結果，最終提高了函式執行期間總計費。

![img](https://pic1.zhimg.com/80/v2-cd79b82874ccd37aecadb399b3fed3e8_720w.jpg)

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

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

### **Point** **4: 業務模型支援的前提下，採用單例項多併發**

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

![img](https://pic4.zhimg.com/80/v2-2b0444739af18aede1af8193116e5067_720w.jpg)

圖 6：單例項併發度：計費時長視角和例項數視角

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

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

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

![img](https://pic3.zhimg.com/80/v2-b0cc0aa936eb2711a697518f0094b96a_720w.jpg)

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

![img](https://pic2.zhimg.com/80/v2-88050273fd253b797e5175a8c4397e15_720w.jpg)

![img](https://pic2.zhimg.com/80/v2-db5d59e3b38e8ed45cb3c43bbd6bf0dd_720w.jpg)

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

## **四. Serverless 函式成本研究中心**

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

![img](https://pic3.zhimg.com/80/v2-4d9dd36bd720c0131581de485f49aa2e_720w.jpg)

![img](https://pic3.zhimg.com/80/v2-a02293fa246bfb98e423410294f80d12_720w.jpg)

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

Serverless 遇到 FinOps: Economical Serverless

相關文章