![alex-_ZfLlKxilpw-unsplash.jpg](https://ucc.alicdn.com/pic/developer-ecology/2f145cd2e3d84afe91fc3ba0497fd855.jpg)

作者 | 王驁
來源 | [Serverless 公眾號](https://mp.weixin.qq.com/s/YrPS9vGw2pAZXyyFzXwRlg)

# 導讀

USENIX ATC (USENIX Annual Technical Conference) 學術會議是計算機系統領域的頂級會議，入選中國計算機協會（CCF）推薦 A 類國際會議列表；本次會議共投稿 341 篇論文，接收 64 篇，錄用率 18.8%。

阿里雲 Serverless 團隊第一個提出在 FaaS 場景下的去中心化快速映象分發技術，團隊創作的論文被 USENIX ATC’21 錄用。以下是論文核心內容解讀，重點在縮短阿里雲函式計算產品 Custom Container Runtime 的函式冷啟動端到端延遲。

USENIX ATC 將於 7.14-7.16 線上上舉辦，論文資訊見：
[https://www.usenix.org/conference/atc21/presentation/wang-ao](https://www.usenix.org/conference/atc21/presentation/wang-ao)

# 摘要

Serverless Computing（FaaS）是一種新的雲端計算正規化，它允許客戶只關注自身的程式碼業務邏輯，系統底層的虛擬化、資源管理、彈性伸縮等都交給雲系統服務商進行維護。Serverless Computing 上支援容器生態，解鎖了多種業務場景，但是由於容器映象複雜，體積較大，FaaS 的 workload 動態性高且難以預測等特性，諸多業界領先的產品和技術並不能很好的應用於 FaaS 平臺之上，所以高效的容器分發技術在 FaaS 平臺上面臨著挑戰。

在這篇論文中，我們設計並提出 FaaSNet。FaaSNet 是一個具有高伸縮性的輕量級系統中介軟體，它利用到映象加速格式進行容器分發，目標作用場景是 FaaS 中突發流量下的大規模容器映象啟動（函式冷啟動）。FaaSNet 的核心元件包含 Function Tree (FT)，是一個去中心化的、自平衡的二叉樹狀拓撲結構，樹狀拓撲結構中的所有節點全部等價。

我們將 FaaSNet 整合在函式計算產品上，實驗結果表明，在高併發下的請求量下，相比原生函式計算（Function Compute, 下稱 FC），FaaSNet 可以為 FC 提供 13.4 倍的容器啟動速度。並且對於由於突發請求量帶來的端到端延遲不穩定時間，FaaSNet 相比 FC 少用 75.2% 的時間可以將端到端延遲恢復到正常水平。

# 論文介紹

## 1. 背景與挑戰

FC 於 2020 年 9 月支援自定義容器映象（https://developer.aliyun.com/article/772788）功能，相繼 AWS Lambda 在同年 12 月公佈了 Lambda container image 支援，表明 FaaS 擁抱容器生態的大趨勢。並且函式計算在 2021 年 2 月上線了函式計算映象加速（https://developer.aliyun.com/article/781992）功能。函式計算這兩項功能解鎖了更多的 FaaS 應用場景，允許使用者無縫將自己的容器業務邏輯遷移到函式計算平臺上，並且可以做到 GB 級別的映象在秒級啟動。

當函式計算後臺遇到大規模請求導致過多的函式冷啟動時，即使有映象加速功能的加持，也會對 container registry 頻寬帶來巨大壓力，多臺機器同時對同一個 container registry 進行映象資料的拉取，導致容器映象服務頻寬瓶頸或限流，使得拉取下載映象資料時間變長（即使在映象加速格式下）。較為直接的做法可以提高函式計算後臺 Registry 的頻寬能力，但是這個方法不能解決根本問題，同時還會帶來額外的系統開銷。

### 1）Workload 分析

我們首先對 FC 兩大區域（北京和上海）的線上資料進行了分析：

![1.png](https://ucc.alicdn.com/pic/developer-ecology/dce833843809469dbf77a0f1b5a57384.png)

- 圖（a）分析了函式冷啟動中，FC 系統 pull image 的延遲，可以看到在北京和上海分別有 ~80% 和 ~90% 的拉去映象延遲大於 10 秒；
- 圖（b）展示 pull image 在整個冷啟動中的佔比，同樣可以發現，北京區域內 80% 的函式，上海區域內 90% 的函式拉取映象時間會佔據大於整個冷啟動中 60% 的延遲；

workload 的分析表明，函式的冷啟動絕大多數時間花在了容器映象資料的獲取之上，所以最佳化此部分延遲可以大大提高函式的冷啟動表現。

根據線上運維的歷史記錄，某大使用者的代表在瞬時會併發拉起 4000 個函式映象，這些映象的大小解壓前為 1.8GB，解壓後大小為 3-4GB，在大流量的請求到達開始拉起容器的瞬間，就收到了容器服務的流控報警，造成了部分請求延遲被延長，嚴重的時候會收到了容器啟動失敗的提示。這類問題場景都是亟需我們來解決的。

### 2）State-of-the-art 對比

學術界和工業界有若干相關技術可以加速映象的分發速度，例如：

阿里巴巴的 DADI：
_https://www.usenix.org/conference/atc20/presentation/li-huiba_
蜻蜓：
_https://github.com/dragonfly/dragonfly_
以及 Uber 開源的 Kraken：
_https://github.com/uber/kraken/_

- **DADI**

DADI 提供了一種非常高效的映象加速格式，可以實現按需讀取（FaaSNet 也利用到了容器加速格式）。在映象分發技術上，DADI 採用了樹狀拓撲結構，以映象 layer 粒度進行節點間的組網，一個 layer 對應一個樹狀拓撲結構，每一個 VM 會存在於多顆邏輯樹中。DADI 的 P2P 分發需要依賴若干效能規格（CPU、頻寬）較大的 root 節點來擔任資料回源角色、維護拓撲中 peer 的管理者角色；DADI 的樹狀結構偏靜態，因為容器 provisioning 的速度一般不會持續很久，所以預設情況下，DADI 的 root 節點會在 20 分鐘後將拓撲邏輯解散，並不會一直維護下去。

- **蜻蜓**

蜻蜓同樣也是一個基於 P2P 的映象、檔案分發網路，其中的元件包塊Supernode（Master 節點），dfget（Peer 節點）。類似於 DADI，蜻蜓同樣依賴於若干大規格的 Supernode 才可以撐起整個叢集，蜻蜓同樣透過中央 Supernode 節點來管理維護了一個全連結的拓撲結構（多個 dfget 節點分別貢獻同一個檔案的不同 pieces 已達到給目標節點點對點傳輸的目的），Supernode 效能會是整個叢集吞吐效能的潛在瓶頸。

- **Kraken**

Kraken 的 origin、tracker 節點作為中央節點管理整個網路，agent 存在於每個 peer 節點上。Kraken 的 traker 節點只是管理組織叢集中 peer 的連線，Kraken 會讓 peer 節點之間自行溝通資料傳輸。但 Kraken 同樣是一個以 layer 為單位的容器映象分發網路，組網邏輯也會成為較為複雜的全連線模式。

透過對上述三種業界領先的技術闡釋，我們可以看到幾個共同點：

- 第一，三者均以 image layer 作為分發單位，組網邏輯過於細粒度，導致每個 peer 節點上可能會同時有多個 active 資料連線；

- 第二，三者都依賴於中央節點進行組網邏輯的管理以及叢集內的 peer 節點協調，DADI 和蜻蜓的中央節點還會負責資料回源，這樣的設計要求在生產使用中，需要部署若干大規格的機器來承擔非常高的流量，同時還需要進行調參來達到預期的效能指標。

我們帶著上述的一些前提條件來反觀在 FC ECS 架構下的設計，FC ECS 架構中的每個機器的規格為 2 CPU 核、4GB 記憶體以及 1Gbps 內網頻寬，並且這些機器的生命週期是不可靠的，隨時可能被回收。

這樣帶來了三個較為嚴重的問題：

- 內網頻寬不足導致在全連線中較為容易出現頻寬擠兌，導致資料傳輸效能下降。全連線的拓撲結構沒有做到 function-aware，在 FC 下極易引起系統安全問題，因為每臺執行函式邏輯的機器是不被FC系統元件信任的，會留下租戶 A 擷取到租戶 B 資料的安全隱患；

- CPU 和頻寬規格受限。由於函式計算 Pay-per-use 的計費特性，我們叢集內的機器生命週期是不可靠的，無法在機器池中拿出若干機器作為中央節點管理整個叢集。這部分機器的系統開銷會成為一大部分負擔，還有就是可靠性不能被保證，機器會導致 failure 的情況；FC 所需要的是繼承按需付費特性，提供可以瞬時組網的技術。

- 多函式問題。上述三者並沒有 function-awareness 機制，例如 DADI P2P 中，可能存在單節點存有過多映象成為熱點，造成效能下降的問題。更嚴重的問題是多函式拉取本質上是不可預測的，當多函式併發拉取打滿頻寬，同期的從遠端下載的服務也會受到影響，如程式碼包，第三方依賴下載，導致整個系統出現了可用性的問題。

帶著這些問題，我們在下一節中詳細闡釋 FaaSNet 設計方案。

## 2. 設計方案 - FaaSNet

根據上述三種業界成熟的 P2P 方案，沒有做到 function 級別的感知，並且叢集內的拓撲邏輯大多為全連線的網路模式，並且對機器的效能提出了一定需求，這些前置設定不適配 FC ECS 的系統實現。所以我們提出了 Function Tree (下稱 FT)，一個函式級別並且是 function-aware 的邏輯樹狀拓撲結構。

### 1）FaaSNet 架構

![2.png](https://ucc.alicdn.com/pic/developer-ecology/0d0408f0fe8c408fbc27c4c176c35261.png)

圖中灰色的部分是我們 FaaSNet 進行了系統改造的部分，其他白色模組均延續了 FC 現有的系統架構。值得注意的是，FaaSNet 所有 Function Tree 均在 FC 的排程器上進行管理；在每一個 VM 上，有 VM agent 來配合 scheduler 進行 gRPC 通訊接受上下游訊息；並且，VM agent 也負責上下游的映象資料獲取與分發。

### 2）去中心化的函式/映象級別自平衡樹狀拓撲結構

為了解決上述三個問題，我們首先將拓撲結構提升到了函式/映象級別，這樣可以有效降低每一個 VM 上的網路連線數，另外，我們設計了一種基於 AVL tree 的樹狀拓撲結構。接下來，我們詳細闡述我們的 Function Tree 設計。

#### Function Tree

- 去中心化自平衡二叉樹拓撲結構

FT 的設計來源於 AVL tree 演算法的啟發，在 FT 中，目前不存在節點權重這個概念，所有節點等價（包括根節點），當樹中新增或刪除任意個節點時，整個樹都會保持一個 perfect-balanced 結構，既保證任意一個節點的左右子樹的高度差的絕對值不超過 1。當有節點加入或刪除後，FT 會自己調整樹的形狀（左/右旋）從而達到平衡結構，如下圖右旋示例所示，節點 6 即將被回收，它的回收導致了以節點 1 作為父節點的左右子樹高度不平衡，需要進行右旋操作已達到平衡狀態，State2 代表旋轉後的終態，節點 2 成為了新的樹根節點。注：所有節點均代表 FC 中的 ECS 機器。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/9b16ab6243da4c698f9df41d1f1f15a6.png)

在 FT 中，所有節點全部等價，主要職責包括：1. 從上游節點拉取資料；2. 向下遊兩個孩子節點分發資料。（注意，在 FT 中，我們不指定根節點，根節點與其他節點的唯一區別是他的上游為源站，根節點不負責任何的 metadata 管理，下一部分我們會介紹我們如何進行元資訊的管理）。

- 多個 FT 在多個 peer 節點上的重疊

![4.png](https://ucc.alicdn.com/pic/developer-ecology/f2cf0b0f439146dfae11df5021689fdb.png)

一個 peer 節點上勢必會存在同一使用者下的不同函式，所以一定會出現一個 peer 節點位於多個 FT 的情況。如上圖所示，例項中有三個 FT 分別屬於 func 0-2。但是由於 FT 的管理是互相獨立的，所以即使有重疊下的傳輸，FT 也是可以幫助每個節點找到對應的正確的上有節點。

另外我們會將一個機器可以 hold 最大數量函式做限制已達到 function-awareness 的特性，進一步解決了多函式下拉取資料不可控的問題。

#### 設計的正確性討論

- 透過在 FC 上整合，我們可以看到因為 FT 中的所有節點等價，我們不需要依賴於任何的中央節點；
- 拓撲邏輯的管理者不存在於叢集之中，而是由 FC 的系統元件（scheduler）來維護這一記憶體狀態，並透過 gRPC 隨著建立容器的操作請求下發給每一個 peer 節點；
- FT 完美適配 FaaS workload 的高動態性，以及叢集中任何規模的節點加入於離開，FT 會自動更新形態；
- 以函式這一較粗粒度進行組網，並且利用二叉樹資料結構來實現 FT，可以大大降低每個 peer 節點上的網路連線數；
- 以函式為隔離進行組網，可以天然實現 function-aware 以提高的系統的安全性和穩定性。

## 3. 效能評測

實驗中我們選取了阿里雲資料庫 DAS 應用場景的映象，以 python 作為 base image，容器映象解壓前大小為 700MB+，擁有 29 層 layers。我們選取壓力測試部分進行解讀，全部測試結果請參考論文原文。測試系統我們對比了阿里巴巴的 DADI、蜻蜓技術和 Uber 開源的 Kraken 框架。

### 1）壓力測試

壓測部分記錄的延遲為使用者感知的端到端冷啟動平均延遲。首先我們可以看出映象加速功能相比於傳統的 FC 可以顯著提升端到端延遲，但是隨著併發量的提高，更多的機器同時對中央的 container registry 拉取資料，造成了網路頻寬的競爭導致端到端延遲上升（橘色和紫色 bar）。但是在 FaaSNet 中，由於我們去中心化的設計，對源站的壓力無論併發壓力多大，只會有一個 root 節點會從源站拉取資料，並向下分發，所以具有極高系統伸縮性，平均延遲不會由於併發壓力的提高而上升。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/c2c4348edc424c0bb128adbd583878f5.png)

在壓測部分的最後，我們探究了同一個 VM 上如果放置不同 image 的函式（多函式）會帶來如何的效能表現，這裡我們比較了開啟映象加速功能並且裝配 DADI P2P 的 FC（DADI+P2P）和 FaaSNet。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/483164e2ed504027a54690a49e77ea2f.png)

上圖縱軸表示標準化後的端到端延遲水平，隨著不同映象的函式的數量增多，DADI P2P 由於 layer 變多，並且 FC 內每臺 ECS 的規格較小，對每臺 VM 的頻寬壓力過大，造成了效能下降，端到端延遲已被拉長至 200% 多。但是 FaaSNet 由於在映象級別建立連線，連線數目遠遠低於 DADI P2P 的 layer tree，所以仍然可以保持較好的效能。

# 總結

高伸縮性和快速的映象分發速度可以為 FaaS 服務商更好的解鎖自定義容器映象場景。FaaSNet 利用輕量級的、去中心化、自平衡的 Function Tree 來避免中央節點帶來的效能瓶頸，沒有引入額外的系統化開銷且完全複用了現有 FC 的系統元件與架構。FaaSNet 可以根據 workload 的動態性實現實時組網已達到 function-awareness，無須做預先的 workload分析與預處理。

FaaSNet 的目標場景不單單侷限於 FaaS，在眾多的雲原生場景中，例如 Kubernetes，阿里巴巴 SAE 在應對突發流量的處理上都可以施展拳腳，來解決由於冷啟動過多影響使用者體驗的痛點，從根本上解決了容器冷啟動慢的問題。

FaaSNet 是國內首個雲廠商在國際頂級會議發表 Serverless 場景下應對突發流量的加速容器啟動技術的論文。我們希望這一工作可以為以容器為基礎的 FaaS 平臺提供新的機會，可以完全開啟擁抱容器生態的大門，解鎖更多的應用場景，如機器學習、大資料分析等任務。

國內首篇雲廠商 Serverless 論文入選全球頂會：突發流量下，如何加速容器啟動？

相關文章