導讀
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摘要
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% 的時間可以将端到端延遲恢複到正常水準。
論文介紹
背景與挑戰
FC 于 2020年9月支援
自定義容器鏡像功能，相繼 AWS Lambda 在同年 12 月公布了 Lambda container image 支援，表明 FaaS 擁抱容器生态的大趨勢。并且函數計算在 2021年2月上線了
函數計算鏡像加速功能。函數計算這兩項功能解鎖了更多的 FaaS 應用場景，允許使用者無縫将自己的容器業務邏輯遷移到函數計算平台上，并且可以做到 GB 級别的鏡像在秒級啟動。
當函數計算背景遇到大規模請求導緻過多的函數冷啟動時，即使有鏡像加速功能的加持，也會對 container registry 帶寬帶來巨大壓力，多台機器同時對同一個 container registry 進行鏡像資料的拉取，導緻容器鏡像服務帶寬瓶頸或限流，使得拉取下載下傳鏡像資料時間變長（即使在鏡像加速格式下）。較為直接的做法可以提高函數計算背景 Registry 的帶寬能力，但是這個方法不能解決根本問題，同時還會帶來額外的系統開銷。
Workload 分析
我們首先對 FC 兩大區域（北京和上海）的線上資料進行了分析：
- 圖(a)分析了函數冷啟動中，FC 系統 pull image 的延遲，可以看到在北京和上海分别有 ~80% 和 ~90% 的拉去鏡像延遲大于 10 秒；
- 圖(b) 展示 pull image 在整個冷啟動中的占比，同樣可以發現，北京區域内 80% 的函數，上海區域内 90% 的函數拉取鏡像時間會占據大于整個冷啟動中 60% 的延遲；
workload 的分析表明，函數的冷啟動絕大多數時間花在了容器鏡像資料的擷取之上，是以優化此部分延遲可以大大提高函數的冷啟動表現。
根據線上運維的曆史記錄，某大使用者的代表在瞬時會并發拉起 4000 個函數鏡像，這些鏡像的大小解壓前為 1.8GB，解壓後大小為 3-4GB，在大流量的請求到達開始拉起容器的瞬間，就收到了容器服務的流控報警，造成了部分請求延遲被延長，嚴重的時候會收到了容器啟動失敗的提示。這類問題場景都是亟需我們來解決的。
State-of-the-art 對比
學術界和工業界有若幹相關技術可以加速鏡像的分發速度，例如阿裡巴巴的
DADI，
蜻蜓以及Uber開源的
Kraken。
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 的 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 内網帶寬，并且這些機器的生命周期是不可靠的，随時可能被回收。
這樣帶來了三個較為嚴重的問題：
1、内網帶寬不足導緻在全連接配接中較為容易出現帶寬擠兌，導緻資料傳輸性能下降。全連接配接的拓撲結構沒有做到 function-aware，在 FC 下極易引起系統安全問題，因為每台執行函數邏輯的機器是不被FC系統元件信任的，會留下租戶 A 截取到租戶 B 資料的安全隐患；
2、CPU 和帶寬規格受限。由于函數計算 Pay-per-use 的計費特性，我們叢集内的機器生命周期是不可靠的，無法在機器池中拿出若幹機器作為中央節點管理整個叢集。這部分機器的系統開銷會成為一大部分負擔，還有就是可靠性不能被保證，機器會導緻 failure 的情況；FC 所需要的是繼承按需付費特性，提供可以瞬時組網的技術。
3、多函數問題。上述三者并沒有 function-awareness 機制，例如 DADI P2P 中，可能存在單節點存有過多鏡像成為熱點，造成性能下降的問題。更嚴重的問題是多函數拉取本質上是不可預測的，當多函數并發拉取打滿帶寬，同期的從遠端下載下傳的服務也會受到影響，如代碼包，第三方依賴下載下傳，導緻整個系統出現了可用性的問題。
帶着這些問題，我們在下一節中詳細闡釋 FaaSNet 設計方案。
設計方案 - FaaSNet
根據上述三種業界成熟的 P2P 方案，沒有做到 function 級别的感覺，并且叢集内的拓撲邏輯大多為全連接配接的網絡模式，并且對機器的性能提出了一定需求，這些前置設定不适配 FC ECS 的系統實作。是以我們提出了 Function Tree (下稱 FT)，一個函數級别并且是 function-aware 的邏輯樹狀拓撲結構。
FaaSNet 架構
圖中灰色的部分是我們 FaaSNet 進行了系統改造的部分，其他白色子產品均延續了 FC 現有的系統架構。值得注意的是，FaaSNet 所有 Function Tree 均在 FC 的排程器上進行管理；在每一個 VM 上，有 VM agent 來配合 scheduler 進行 gRPC 通信接受上下遊消息；并且，VM agent 也負責上下遊的鏡像資料擷取與分發。
去中心化的函數/鏡像級别自平衡樹狀拓撲結構
為了解決上述三個問題，我們首先将拓撲結構提升到了函數/鏡像級别，這樣可以有效降低每一個 VM 上的網絡連接配接數，另外，我們設計了一種基于 AVL tree 的樹狀拓撲結構。接下來，我們詳細闡述我們的 Function Tree 設計。
1、Function Tree
1）去中心化自平衡二叉樹拓撲結構
FT 的設計來源于 AVL tree 算法的啟發，在FT中，目前不存在節點權重這個概念，所有節點等價（包括根節點），當樹中添加或删除任意個節點時，整個樹都會保持一個 perfect-balanced 結構，既保證任意一個節點的左右子樹的高度差的絕對值不超過 1。當有節點加入或删除後，FT 會自己調整樹的形狀（左/右旋）進而達到平衡結構，如下圖右旋示例所示，節點 6 即将被回收，它的回收導緻了以節點 1 作為父節點的左右子樹高度不平衡，需要進行右旋操作已達到平衡狀态，State2 代表旋轉後的終态，節點 2 成為了新的樹根節點。注：所有節點均代表 FC 中的 ECS 機器。
在 FT 中，所有節點全部等價，主要職責包括：1. 從上遊節點拉取資料；2. 向下遊兩個孩子節點分發資料。（注意，在 FT 中，我們不指定根節點，根節點與其他節點的唯一差別是他的上遊為源站，根節點不負責任何的 metadata 管理，下一部分我們會介紹我們如何進行元資訊的管理）。
2）多個 FT 在多個 peer 節點上的重疊
一個 peer 節點上勢必會存在同一使用者下的不同函數，是以一定會出現一個 peer 節點位于多個 FT 的情況。如上圖所示，執行個體中有三個 FT 分别屬于 func 0-2。但是由于 FT 的管理是互相獨立的，是以即使有重疊下的傳輸，FT 也是可以幫助每個節點找到對應的正确的上有節點。
另外我們會将一個機器可以 hold 最大數量函數做限制已達到 function-awareness 的特性，進一步解決了多函數下拉取資料不可控的問題。
2、設計的正确性讨論
- 通過在 FC 上內建，我們可以看到因為 FT 中的所有節點等價，我們不需要依賴于任何的中央節點；
- 拓撲邏輯的管理者不存在于叢集之中，而是由 FC 的系統元件（scheduler）來維護這一記憶體狀态，并通過 gRPC 随着建立容器的操作請求下發給每一個 peer 節點；
- FT 完美适配 FaaS workload 的高動态性，以及叢集中任何規模的節點加入于離開，FT 會自動更新形态；
- 以函數這一較粗粒度進行組網，并且利用二叉樹資料結構來實作 FT，可以大大降低每個 peer 節點上的網絡連接配接數；
- 以函數為隔離進行組網，可以天然實作 function-aware 以提高的系統的安全性和穩定性。
性能評測
實驗中我們選取了阿裡雲資料庫 DAS 應用場景的鏡像，以 python 作為 base image，容器鏡像解壓前大小為 700MB+，擁有 29 層 layers。我們選取壓力測試部分進行解讀，全部測試結果請參考論文原文。測試系統我們對比了阿裡巴巴的 DADI，蜻蜓技術和 Uber 開源的 Kraken 架構。
壓力測試
壓測部分記錄的延遲為使用者感覺的端到端冷啟動平均延遲。首先我們可以看出鏡像加速功能相比于傳統的 FC 可以顯著提升端到端延遲，但是随着并發量的提高，更多的機器同時對中央的 container registry 拉取資料，造成了網絡帶寬的競争導緻端到端延遲上升（橘色和紫色 bar）。但是在 FaaSNet 中，由于我們去中心化的設計，對源站的壓力無論并發壓力多大，隻會有一個 root 節點會從源站拉取資料，并向下分發，是以具有極高系統伸縮性，平均延遲不會猶豫并發壓力的提高而上升。
在壓測部分的最後，我們探究了同一個 VM 上如果放置不同 image 的函數（多函數）會帶來如何的性能表現，這裡我們比較了開啟鏡像加速功能并且裝配 DADI P2P 的 FC（DADI+P2P）和 FaaSNet。
上圖縱軸表示标準化後的端到端延遲水準，随着不同鏡像的函數的數量增多，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 平台提供新的機會，可以完全打開擁抱容器生态的大門，解鎖更多的應用場景，如機器學習、大資料分析等任務。
掃碼檢視更多中間件技術幹貨和案例：