函數計算鏡像加速：從分鐘到秒的跨越

簡介： 函數計算 FC 正式發佈容器鏡像加速，經過按需讀取和更高效的解壓技術在不一樣場景下加速 50%-80%，即便 GB 級別的鏡像也能夠在幾秒內完成端到端啓動。

FaaS 和容器

容器鏡像因其顛覆式創新成爲雲原生時代應用部署格式的事實標準。頭部雲廠商 FaaS (Function-as-a-Service) 服務如阿里雲函數計算、AWS Lambda 也相繼在2020年支持使用容器鏡像部署函數，全面擁抱容器生態。自發布以來，開發者陸續將機器學習、音視頻處理、事件驅動離線數據處理、前端自動化等多個場景使用鏡像快速無服務器化，提升效率、下降成本。然而，冷啓動一直是 Serverless 沒法繞開的問題。容器鏡像須要將數據經過網絡遠程下載並解壓，對於GB級別的鏡像，拉取時間可能高達分鐘級別，客觀上放大了冷啓動反作用，阻礙實時應用的 Serverless 演進。

函數計算鏡像加速功能

傳統的鏡像拉取加速強調"開發者負責"，如精簡鏡像，合理分配鏡像層，multi-stage 構建，使用工具（如 docker-slim）去除不須要的數據，遵循構建最佳實踐等。這些工做不只加劇了用戶負擔，加速效果有限，且有運行時穩定性風險。阿里集團超大規模和場景高度複雜的容器環境，對鏡像存儲、加速技術有深厚的積累，出色地承擔了3年雙十一，雙十二，春節等大促秒殺場景的嚴苛的挑戰。阿里雲 Serverless 同容器鏡像、存儲等服務深度合做，將內部創新在函數計算輸出：杭州、北京、上海、美東、美西正式發佈了鏡像加速功能。該功能將本來屬於開發者的鏡像優化負擔轉由函數計算承擔，進一步幫助開發者提升生產效率，專一業務創新。

加速效果

咱們在選擇了內部生產環境和開源社區的工做負載，覆蓋機器學習、人工智能、前端自動化、Web 應用等7種鏡像大小、IO 訪問模式、啓動命令的不一樣組合做爲 benchmark，部署在 FC 北京區域。以下圖所示，函數計算開啓鏡像加速功能後加速廣泛超過 50%，對於機器學習場景中常見的臃腫鏡像（如多個團隊共享基礎鏡像, ml-small-import, ml-large-import, ai-cat-or-dog）加速效果更爲明顯（約 70%-86%），鏡像越大優化空間每每越高。

使用方式

鏡像加速能夠經過控制檯、CLI 工具或是 FC SDK 開啓，詳細步驟參加鏡像拉取加速文檔
• 方式一：在函數計算控制檯函數配置下選擇「開啓鏡像加速」。

• 方式二：使用 Funcraft 工具部署

在已有的 CustomContainerConfig 配置下添加 AccelerationType: Default 如需關閉則配置 AccelerationType:
None

CustomContainerConfig:
          Image: registry-vpc.cn-beijing.aliyuncs.com/fc-demo/python-flask:v0.1
          AccelerationType: Default

功能特色

FC 鏡像加速具有如下特色：

1. 使用簡單：只需在函數上開啓鏡像加速，函數計算會自動製做加速鏡像和緩存，轉換完成後（5分鐘之內），函數自動採用加速鏡像緩存。
2. 專一業務創新：開發者無需花費時間刻意精簡優化鏡像大小或嚴格區分 Serverless 和 Serverfull 應用鏡像的構建方式，FC 負責按照應用實際使用數據拉取和解壓。
3. 加速免費，使用門檻低：鏡像加速開啓不產生額外費用，也不須要開發者額外購買或升級任何其餘服務。事實上因爲鏡像拉取時間變短，相應的請求費用也隨之下降。
4. 極速彈性、縮容到 0、事件觸發：FaaS 結合容器鏡像已經極大簡化了應用遷移至 Serverless，加速功能進一步解鎖了實時、準實時工做負載，曾經須要分鐘級別的容器啓動如今能夠幾秒內快速啓動，真正實現縮容到0。

鏡像拉取爲何慢？

一個 OCI V1 容器鏡像包含多個層（layer），每層都是一個壓縮打包的文件系統（文件夾），一般以 tar.gz 格式存儲在遠端服務（如對象、文件存儲）。拉取鏡像時步驟以下：

1. 將各個 layer 對應的 tar.gz 文件完整下載至本地
2. 每層順序解壓
3. 將各個層合併（如 Overlay）做爲 rootfs 啓動容器

上述步驟雖然簡單，倒是鏡像拉取慢的主要緣由：
• 文件格式缺陷、粗粒度數據分層、順序解壓：gzip 層致使沒法細粒度隨機讀取應用實際須要的數據，且要求全部層單線程順序解壓。實際觀察發現鏡像層能夠經過併發下載提升速度，然而解壓環節在 gzip 格式下卻很難優化。
• 低效的壓縮/解壓縮算法：鏡像層採用的 gzip，benchmark gzip 解壓速度對比 lz4 平均慢接近9倍。
• 全量數據下載：一樣因爲粗粒度的分層和 gzip 格式（不支持 seek），鏡像數據不管是否實際有用，都要被完整下載至本地。
綜上原理，鏡像拉取時間和鏡像大小成正比，而容器鏡像構建過程當中運行 apt/yum install, 無用的測試、數據文件，構建過程當中執行 chmod/chown 等命令形成同一數據複製多份，極易引入大量應用不須要的數據。

加速原理

函數計算將阿里集團成熟的鏡像加速技術應用在公共雲服務中，加速技術圍繞兩個核心思路：
• 按需加載：僅讀取應用真實須要的數據，極大減小數據傳輸量
• 更高效的存儲和算法：相同大小的數據，更快地解壓

按需加載

Benchmark 中包含鏡像數據加載率在 12% - 84% 之間，除了鏡像較小的 web 應用，大部分場景數據利用率低於 50%。以層（layer）做爲數據分發單位的原始鏡像被轉換成支持細粒度按需讀取的數據格式，並存放在延遲和吞吐都更優的存儲中。

高效解壓

除了按需加載帶來的下載步驟延時節省，鏡像加速技術在數據解壓步驟也一樣作了大量優化。下圖能夠看出即便在加載 70% 以上全量數據的狀況下，優化效果仍然超過 60%。

將來規劃

函數計算正式發佈了容器鏡像加速，經過按需讀取和更高效的解壓技術在不一樣場景下加速 50%-80%，即便 GB 級別的鏡像也能夠在幾秒內完成端到端啓動。加速功能結合函數計算極致彈性和事件觸發的特色，解鎖了更多對實時要求高的工做負載。容器應用能夠更容易地享受 Serverless 特性，真正作到縮容到0以及快速大規模擴容。FC 在將來會持續優化冷啓動各個環節提供極致彈性，承擔更多用戶責任，使開發者專一業務創新。

附錄：實驗場景數據

做者：Shuai Chang，阿里云云原生 Serverless 團隊高級技術專家，主導了函數計算同容器技術生態融合以及 FaaS 雲原生可觀測。
原文連接本文爲阿里雲原創內容，未經容許不得轉載