簡介：USENIX ATC (USENIX Annual Technical Conference) 學術會議是計算機系統(tǒng)領域的頂級會議，入選中國計算機協(xié)會（CCF）推薦 A 類國際會議列表；本次會議共投稿 341 篇論文，接收 64 篇，錄用率 18.8%。阿里云 Serverless 團隊第一個提出在 FaaS 場景下的去中心化快速鏡像分發(fā)技術，團隊創(chuàng)作的論文被 USENIX ATC’21 錄用。

作者 | 王驁
來源 | Serverless 公眾號

導讀

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

阿里云 Serverless 團隊第一個提出在 FaaS 場景下的去中心化快速鏡像分發(fā)技術，團隊創(chuàng)作的論文被 USENIX ATC’21 錄用。以下是論文核心內(nèi)容解讀，重點在縮短阿里云函數(shù)計算產(chǎn)品 Custom Container Runtime 的函數(shù)冷啟動端到端延遲。

USENIX ATC 將于 7.14-7.16 在線上舉辦，論文信息見：
https://www.usenix.org/conference/atc21/presentation/wang-ao?

摘要

Serverless Computing（FaaS）是一種新的云計算范式，它允許客戶只關注自身的代碼業(yè)務邏輯，系統(tǒng)底層的虛擬化、資源管理、彈性伸縮等都交給云系統(tǒng)服務商進行維護。Serverless Computing 上支持容器生態(tài)，解鎖了多種業(yè)務場景，但是由于容器鏡像復雜，體積較大，FaaS 的 workload 動態(tài)性高且難以預測等特性，諸多業(yè)界領先的產(chǎn)品和技術并不能很好的應用于 FaaS 平臺之上，所以高效的容器分發(fā)技術在 FaaS 平臺上面臨著挑戰(zhàn)。
?
在這篇論文中，我們設計并提出 FaaSNet。FaaSNet 是一個具有高伸縮性的輕量級系統(tǒng)中間件，它利用到鏡像加速格式進行容器分發(fā)，目標作用場景是 FaaS 中突發(fā)流量下的大規(guī)模容器鏡像啟動（函數(shù)冷啟動）。FaaSNet 的核心組件包含 Function Tree (FT)，是一個去中心化的、自平衡的二叉樹狀拓撲結構，樹狀拓撲結構中的所有節(jié)點全部等價。

我們將 FaaSNet 集成在函數(shù)計算產(chǎn)品上，實驗結果表明，在高并發(fā)下的請求量下，相比原生函數(shù)計算（Function Compute, 下稱 FC），FaaSNet 可以為 FC 提供 13.4 倍的容器啟動速度。并且對于由于突發(fā)請求量帶來的端到端延遲不穩(wěn)定時間，FaaSNet 相比 FC 少用 75.2% 的時間可以將端到端延遲恢復到正常水平。
?

論文介紹

1. 背景與挑戰(zhàn)

FC 于 2020 年 9 月支持自定義容器鏡像（https://developer.aliyun.com/article/772788）功能，相繼 AWS Lambda 在同年 12 月公布了 Lambda container image 支持，表明 FaaS 擁抱容器生態(tài)的大趨勢。并且函數(shù)計算在 2021 年 2 月上線了函數(shù)計算鏡像加速（https://developer.aliyun.com/article/781992）功能。函數(shù)計算這兩項功能解鎖了更多的 FaaS 應用場景，允許用戶無縫將自己的容器業(yè)務邏輯遷移到函數(shù)計算平臺上，并且可以做到 GB 級別的鏡像在秒級啟動。

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

1）Workload 分析

我們首先對 FC 兩大區(qū)域（北京和上海）的線上數(shù)據(jù)進行了分析：

• 圖（a）分析了函數(shù)冷啟動中，FC 系統(tǒng) pull image 的延遲，可以看到在北京和上海分別有 ~80% 和 ~90% 的拉去鏡像延遲大于 10 秒；
• 圖（b）展示 pull image 在整個冷啟動中的占比，同樣可以發(fā)現(xiàn)，北京區(qū)域內(nèi) 80% 的函數(shù)，上海區(qū)域內(nèi) 90% 的函數(shù)拉取鏡像時間會占據(jù)大于整個冷啟動中 60% 的延遲；

workload 的分析表明，函數(shù)的冷啟動絕大多數(shù)時間花在了容器鏡像數(shù)據(jù)的獲取之上，所以優(yōu)化此部分延遲可以大大提高函數(shù)的冷啟動表現(xiàn)。

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

2）State-of-the-art 對比

學術界和工業(yè)界有若干相關技術可以加速鏡像的分發(fā)速度，例如：

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

• DADI

DADI 提供了一種非常高效的鏡像加速格式，可以實現(xiàn)按需讀取（FaaSNet 也利用到了容器加速格式）。在鏡像分發(fā)技術上，DADI 采用了樹狀拓撲結構，以鏡像 layer 粒度進行節(jié)點間的組網(wǎng)，一個 layer 對應一個樹狀拓撲結構，每一個 VM 會存在于多顆邏輯樹中。DADI 的 P2P 分發(fā)需要依賴若干性能規(guī)格（CPU、帶寬）較大的 root 節(jié)點來擔任數(shù)據(jù)回源角色、維護拓撲中 peer 的管理者角色；DADI 的樹狀結構偏靜態(tài)，因為容器 provisioning 的速度一般不會持續(xù)很久，所以默認情況下，DADI 的 root 節(jié)點會在 20 分鐘后將拓撲邏輯解散，并不會一直維護下去。

• 蜻蜓

蜻蜓同樣也是一個基于 P2P 的鏡像、文件分發(fā)網(wǎng)絡，其中的組件包塊Supernode（Master 節(jié)點），dfget（Peer 節(jié)點）。類似于 DADI，蜻蜓同樣依賴于若干大規(guī)格的 Supernode 才可以撐起整個集群，蜻蜓同樣通過中央 Supernode 節(jié)點來管理維護了一個全鏈接的拓撲結構（多個 dfget 節(jié)點分別貢獻同一個文件的不同 pieces 已達到給目標節(jié)點點對點傳輸?shù)哪康?#xff09;，Supernode 性能會是整個集群吞吐性能的潛在瓶頸。

• Kraken

Kraken 的 origin、tracker 節(jié)點作為中央節(jié)點管理整個網(wǎng)絡，agent 存在于每個 peer 節(jié)點上。Kraken 的 traker 節(jié)點只是管理組織集群中 peer 的連接，Kraken 會讓 peer 節(jié)點之間自行溝通數(shù)據(jù)傳輸。但 Kraken 同樣是一個以 layer 為單位的容器鏡像分發(fā)網(wǎng)絡，組網(wǎng)邏輯也會成為較為復雜的全連接模式。
?
通過對上述三種業(yè)界領先的技術闡釋，我們可以看到幾個共同點：

• 第一，三者均以 image layer 作為分發(fā)單位，組網(wǎng)邏輯過于細粒度，導致每個 peer 節(jié)點上可能會同時有多個 active 數(shù)據(jù)連接；
• 第二，三者都依賴于中央節(jié)點進行組網(wǎng)邏輯的管理以及集群內(nèi)的 peer 節(jié)點協(xié)調(diào)，DADI 和蜻蜓的中央節(jié)點還會負責數(shù)據(jù)回源，這樣的設計要求在生產(chǎn)使用中，需要部署若干大規(guī)格的機器來承擔非常高的流量，同時還需要進行調(diào)參來達到預期的性能指標。

我們帶著上述的一些前提條件來反觀在 FC ECS 架構下的設計，FC ECS 架構中的每個機器的規(guī)格為 2 CPU 核、4GB 內(nèi)存以及 1Gbps 內(nèi)網(wǎng)帶寬，并且這些機器的生命周期是不可靠的，隨時可能被回收。

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

• 內(nèi)網(wǎng)帶寬不足導致在全連接中較為容易出現(xiàn)帶寬擠兌，導致數(shù)據(jù)傳輸性能下降。全連接的拓撲結構沒有做到 function-aware，在 FC 下極易引起系統(tǒng)安全問題，因為每臺執(zhí)行函數(shù)邏輯的機器是不被FC系統(tǒng)組件信任的，會留下租戶 A 截取到租戶 B 數(shù)據(jù)的安全隱患；
• CPU 和帶寬規(guī)格受限。由于函數(shù)計算 Pay-per-use 的計費特性，我們集群內(nèi)的機器生命周期是不可靠的，無法在機器池中拿出若干機器作為中央節(jié)點管理整個集群。這部分機器的系統(tǒng)開銷會成為一大部分負擔，還有就是可靠性不能被保證，機器會導致 failure 的情況；FC 所需要的是繼承按需付費特性，提供可以瞬時組網(wǎng)的技術。
• 多函數(shù)問題。上述三者并沒有 function-awareness 機制，例如 DADI P2P 中，可能存在單節(jié)點存有過多鏡像成為熱點，造成性能下降的問題。更嚴重的問題是多函數(shù)拉取本質(zhì)上是不可預測的，當多函數(shù)并發(fā)拉取打滿帶寬，同期的從遠端下載的服務也會受到影響，如代碼包，第三方依賴下載，導致整個系統(tǒng)出現(xiàn)了可用性的問題。

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

2. 設計方案 - FaaSNet

根據(jù)上述三種業(yè)界成熟的 P2P 方案，沒有做到 function 級別的感知，并且集群內(nèi)的拓撲邏輯大多為全連接的網(wǎng)絡模式，并且對機器的性能提出了一定需求，這些前置設定不適配 FC ECS 的系統(tǒng)實現(xiàn)。所以我們提出了 Function Tree (下稱 FT)，一個函數(shù)級別并且是 function-aware 的邏輯樹狀拓撲結構。
?

1）FaaSNet 架構

圖中灰色的部分是我們 FaaSNet 進行了系統(tǒng)改造的部分，其他白色模塊均延續(xù)了 FC 現(xiàn)有的系統(tǒng)架構。值得注意的是，FaaSNet 所有 Function Tree 均在 FC 的調(diào)度器上進行管理；在每一個 VM 上，有 VM agent 來配合 scheduler 進行 gRPC 通信接受上下游消息；并且，VM agent 也負責上下游的鏡像數(shù)據(jù)獲取與分發(fā)。
?

2）去中心化的函數(shù)/鏡像級別自平衡樹狀拓撲結構

為了解決上述三個問題，我們首先將拓撲結構提升到了函數(shù)/鏡像級別，這樣可以有效降低每一個 VM 上的網(wǎng)絡連接數(shù)，另外，我們設計了一種基于 AVL tree 的樹狀拓撲結構。接下來，我們詳細闡述我們的 Function Tree 設計。

Function Tree

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

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

在 FT 中，所有節(jié)點全部等價，主要職責包括：1. 從上游節(jié)點拉取數(shù)據(jù)；2. 向下游兩個孩子節(jié)點分發(fā)數(shù)據(jù)。（注意，在 FT 中，我們不指定根節(jié)點，根節(jié)點與其他節(jié)點的唯一區(qū)別是他的上游為源站，根節(jié)點不負責任何的 metadata 管理，下一部分我們會介紹我們?nèi)绾芜M行元信息的管理）。

• 多個 FT 在多個 peer 節(jié)點上的重疊

一個 peer 節(jié)點上勢必會存在同一用戶下的不同函數(shù)，所以一定會出現(xiàn)一個 peer 節(jié)點位于多個 FT 的情況。如上圖所示，實例中有三個 FT 分別屬于 func 0-2。但是由于 FT 的管理是互相獨立的，所以即使有重疊下的傳輸，FT 也是可以幫助每個節(jié)點找到對應的正確的上有節(jié)點。
?
另外我們會將一個機器可以 hold 最大數(shù)量函數(shù)做限制已達到 function-awareness 的特性，進一步解決了多函數(shù)下拉取數(shù)據(jù)不可控的問題。
?

設計的正確性討論

• 通過在 FC 上集成，我們可以看到因為 FT 中的所有節(jié)點等價，我們不需要依賴于任何的中央節(jié)點；
• 拓撲邏輯的管理者不存在于集群之中，而是由 FC 的系統(tǒng)組件（scheduler）來維護這一內(nèi)存狀態(tài)，并通過 gRPC 隨著創(chuàng)建容器的操作請求下發(fā)給每一個 peer 節(jié)點；
• FT 完美適配 FaaS workload 的高動態(tài)性，以及集群中任何規(guī)模的節(jié)點加入于離開，FT 會自動更新形態(tài)；
• 以函數(shù)這一較粗粒度進行組網(wǎng)，并且利用二叉樹數(shù)據(jù)結構來實現(xiàn) FT，可以大大降低每個 peer 節(jié)點上的網(wǎng)絡連接數(shù)；
• 以函數(shù)為隔離進行組網(wǎng)，可以天然實現(xiàn) function-aware 以提高的系統(tǒng)的安全性和穩(wěn)定性。

3. 性能評測

?
實驗中我們選取了阿里云數(shù)據(jù)庫 DAS 應用場景的鏡像，以 python 作為 base image，容器鏡像解壓前大小為 700MB+，擁有 29 層 layers。我們選取壓力測試部分進行解讀，全部測試結果請參考論文原文。測試系統(tǒng)我們對比了阿里巴巴的 DADI、蜻蜓技術和 Uber 開源的 Kraken 框架。
?

1）壓力測試

?
壓測部分記錄的延遲為用戶感知的端到端冷啟動平均延遲。首先我們可以看出鏡像加速功能相比于傳統(tǒng)的 FC 可以顯著提升端到端延遲，但是隨著并發(fā)量的提高，更多的機器同時對中央的 container registry 拉取數(shù)據(jù)，造成了網(wǎng)絡帶寬的競爭導致端到端延遲上升（橘色和紫色 bar）。但是在 FaaSNet 中，由于我們?nèi)ブ行幕脑O計，對源站的壓力無論并發(fā)壓力多大，只會有一個 root 節(jié)點會從源站拉取數(shù)據(jù)，并向下分發(fā)，所以具有極高系統(tǒng)伸縮性，平均延遲不會由于并發(fā)壓力的提高而上升。

?

在壓測部分的最后，我們探究了同一個 VM 上如果放置不同 image 的函數(shù)（多函數(shù)）會帶來如何的性能表現(xiàn)，這里我們比較了開啟鏡像加速功能并且裝配 DADI P2P 的 FC（DADI+P2P）和 FaaSNet。
?

上圖縱軸表示標準化后的端到端延遲水平，隨著不同鏡像的函數(shù)的數(shù)量增多，DADI P2P 由于 layer 變多，并且 FC 內(nèi)每臺 ECS 的規(guī)格較小，對每臺 VM 的帶寬壓力過大，造成了性能下降，端到端延遲已被拉長至 200% 多。但是 FaaSNet 由于在鏡像級別建立連接，連接數(shù)目遠遠低于 DADI P2P 的 layer tree，所以仍然可以保持較好的性能。?

總結

?
高伸縮性和快速的鏡像分發(fā)速度可以為 FaaS 服務商更好的解鎖自定義容器鏡像場景。FaaSNet 利用輕量級的、去中心化、自平衡的 Function Tree 來避免中央節(jié)點帶來的性能瓶頸，沒有引入額外的系統(tǒng)化開銷且完全復用了現(xiàn)有 FC 的系統(tǒng)組件與架構。FaaSNet 可以根據(jù) workload 的動態(tài)性實現(xiàn)實時組網(wǎng)已達到 function-awareness，無須做預先的 workload分析與預處理。

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

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

原文鏈接：https://developer.aliyun.com/article/784448?

版權聲明：本文內(nèi)容由阿里云實名注冊用戶自發(fā)貢獻，版權歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權，亦不承擔相應法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務協(xié)議》和《阿里云開發(fā)者社區(qū)知識產(chǎn)權保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內(nèi)容，填寫侵權投訴表單進行舉報，一經(jīng)查實，本社區(qū)將立刻刪除涉嫌侵權內(nèi)容。

總結

以上是生活随笔為你收集整理的国内首篇云厂商 Serverless 论文入选全球顶会：突发流量下，如何加速容器启动？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。