摘要：?背景 函數(shù)計(jì)算是一個事件驅(qū)動的全托管 serverless 計(jì)算服務(wù)。使用函數(shù)計(jì)算構(gòu)建應(yīng)用，用戶只需要專注于實(shí)現(xiàn)應(yīng)用層的邏輯實(shí)現(xiàn)；服務(wù)器等基礎(chǔ)設(shè)施的容錯、伸縮以及運(yùn)維工作由平臺來完成。因此用戶能在很短的時間內(nèi)實(shí)現(xiàn)彈性高可用的云原生應(yīng)用。

背景

函數(shù)計(jì)算是一個事件驅(qū)動的全托管 serverless 計(jì)算服務(wù)。使用函數(shù)計(jì)算構(gòu)建應(yīng)用，用戶只需要專注于實(shí)現(xiàn)應(yīng)用層的邏輯實(shí)現(xiàn)；服務(wù)器等基礎(chǔ)設(shè)施的容錯、伸縮以及運(yùn)維工作由平臺來完成。因此用戶能在很短的時間內(nèi)實(shí)現(xiàn)彈性高可用的云原生應(yīng)用。

函數(shù)計(jì)算在容器中執(zhí)行用戶函數(shù)代碼，這樣的環(huán)境我們稱為函數(shù)實(shí)例。實(shí)例的生成需要一些額外的系統(tǒng)準(zhǔn)備工作，比如選擇執(zhí)行函數(shù)的引擎，下載用戶的代碼，啟動容器，加載函數(shù)等等。如果請求的調(diào)用鏈路里包含了上述環(huán)節(jié)，我們就稱之為冷啟動。實(shí)例一旦生成，會持續(xù)服務(wù)請求；當(dāng)一段時間內(nèi)沒有請求后，系統(tǒng)將回收實(shí)例。因此，冷啟動通常發(fā)生在函數(shù)首次調(diào)用或者負(fù)載升高需要更多的實(shí)例來處理對應(yīng)的請求。

"冷啟動"對于毛刺敏感的業(yè)務(wù)會顯得不那么友好，所以冷啟動的優(yōu)化對于函數(shù)計(jì)算在延時敏感型場景中的應(yīng)用尤為重要。

系統(tǒng)架構(gòu)

在探討調(diào)度優(yōu)化之前，我們先簡要介紹函數(shù)計(jì)算的架構(gòu)以及調(diào)度方式，如下圖所示。

API 服務(wù)層完成身份驗(yàn)證，元數(shù)據(jù)的讀寫等功能。同步調(diào)用函數(shù)時，API 服務(wù)模塊從資源調(diào)度模塊獲取可用的函數(shù)執(zhí)行引擎并發(fā)送請求，函數(shù)執(zhí)行引擎根據(jù)函數(shù)相關(guān)信息準(zhǔn)備執(zhí)行所需環(huán)境，啟動容器進(jìn)行計(jì)算，最后取回結(jié)果。異步調(diào)用函數(shù)時，則將事件寫入到消息隊(duì)列后即返回。由事件分發(fā)模塊分發(fā)事件，整個流程和同步調(diào)用類似。

資源調(diào)度模塊主要負(fù)責(zé)函數(shù)計(jì)算分布式系統(tǒng)的負(fù)載均衡和實(shí)時彈性伸縮。當(dāng)一個用戶請求達(dá)到時，資源調(diào)度模塊進(jìn)行第一層調(diào)度——分配函數(shù)執(zhí)行引擎，然后在函數(shù)執(zhí)行引擎中進(jìn)行第二層調(diào)度——分配函數(shù)實(shí)例，進(jìn)而才開始執(zhí)行用戶函數(shù)。而當(dāng)用戶一段時間內(nèi)不再請求，調(diào)度系統(tǒng)就會自動回收函數(shù)實(shí)例和函數(shù)執(zhí)行引擎資源。如下為用戶請求處理資源調(diào)度流程:

為了保證用戶請求使用的資源，一個函數(shù)實(shí)例只能同時服務(wù)一個請求，所以在用戶請求并發(fā)較大的情況下，系統(tǒng)會調(diào)度更多的資源來消費(fèi)該用戶的請求。

如架構(gòu)圖所示，系統(tǒng)層的"冷啟動"就是從函數(shù)執(zhí)行引擎的獲取到函數(shù)實(shí)例創(chuàng)建的整個過程，主要的步驟如下:

而冷啟動的快慢受限于很多情況，主要因素有用戶代碼大小、網(wǎng)絡(luò)因素、runtime 環(huán)境因素等，所以，對于實(shí)時性要求高的業(yè)務(wù)場景來說，冷啟動的存在是不友好的。

調(diào)優(yōu)策略

冷啟動問題導(dǎo)致了大量并發(fā)到來的時候，毛刺加劇，根源在現(xiàn)存的實(shí)例調(diào)度方式無法快速響應(yīng)請求而引起請求在整條鏈路中長時間處于系統(tǒng)新資源的分配等待中。

所以，要提高實(shí)例調(diào)度速率、快速響應(yīng)請求，減少排隊(duì)請求數(shù)，主要著手于如下兩個方面:

1. 加快空閑實(shí)例投入使用，提高利用率；

2. 在峰值到來時，加快新實(shí)例生成，增加實(shí)例儲備。

加快空閑實(shí)例投入使用速率這一點(diǎn)，能很大程度上減少請求在鏈路上等待冷啟動的時間，從而加快請求被處理的速率。在用戶函數(shù)邏輯執(zhí)行較快的情況下，實(shí)例能夠被快速釋放，如果此時一個正在等待冷啟動的請求能夠探測到已經(jīng)有實(shí)例進(jìn)入空閑狀態(tài)，那么就會被處理。而之前的冷啟動則轉(zhuǎn)入后臺繼續(xù)進(jìn)行，生成新的實(shí)例，增大實(shí)例儲備，應(yīng)對更多的請求處理。

另外一方面，因?yàn)橛脩舻馁Y源配額在系統(tǒng)層面有限制，比如在超大并發(fā)的請求下用戶可能會遇到 ServiceUnavailable 錯誤。而調(diào)度策略上如果能夠加快空閑實(shí)例投入使用的速率，那么實(shí)際上也減少了冷啟動的次數(shù)，即減少了對資源配額的開銷，增加資源利用率，從而減少了被系統(tǒng)流控的可能。

調(diào)優(yōu)結(jié)果

根據(jù)用戶實(shí)際使用場景，我們設(shè)計(jì)如下兩種測試case來驗(yàn)證調(diào)優(yōu)效果:

• 負(fù)載持續(xù)增加模式

• 波峰 burst 模式

測試函數(shù)的特性如下:

• 函數(shù)自身邏輯運(yùn)行時間為 100ms;

• 函數(shù)代碼包大小為 50MB;

• runtime 為 python2.7;

• Memory 為 3GB 。

這樣的函數(shù)，如果帶有冷啟動，單次端到端的請求 latency 在 1.7s - 3s，不帶冷啟動的請求端到端 latency 在 105 - 120ms。

負(fù)載持續(xù)增加模式

該模式下，用戶的請求在一段時間內(nèi)會持續(xù)增長。設(shè)計(jì)請求行為如下:

• 每波請求并發(fā)數(shù)翻倍遞增: 1, 2, 4, 8, 16, 32;

• 每波請求的時間間隔為 10s。

TPS情況如下，增長率為100%：

優(yōu)化前后對比

10s 聚合的 latency 指標(biāo)如下監(jiān)控:

優(yōu)化前, 平均 latency 在 1000ms 左右，而99%的請求 latency 均在 1.8s 以上。

優(yōu)化后，平均 latency 為 200ms 以下(排除第一個完全冷啟動)，99% 的請求 latency 大部分在 200ms 左右，較之前下降一個數(shù)量級。

單個請求情況分析

更直觀的分析，我們把每一個請求的端到端 latency列出來比較，如下圖。每一波請求中，都有一半的請求能夠直接使用前一波請求現(xiàn)存下來的實(shí)例，而另一半請求都需要等待新的調(diào)度。明顯看到，舊的調(diào)度策略上，這一半請求幾乎全部都在傻傻等待處于完全冷啟動狀態(tài)；新的調(diào)度策略中，明顯看到這一半請求都被調(diào)度到了提前釋放的實(shí)例上被處理，從而大大優(yōu)化了毛刺情況。

優(yōu)化前:

優(yōu)化后:

波峰 burst 模式

波峰burst模式是指用戶請求比較平穩(wěn)，但是會有突然的波峰流量場景。設(shè)計(jì)請求行為如下：

• 每波請求時間間隔 10s;

• 每波平穩(wěn)請求數(shù) 2;

• burst 請求數(shù) 20;

TPS請求如下，burst 流量猛增 10 倍:

優(yōu)化前后對比

10s 聚合的 latency 指標(biāo)如下監(jiān)控:

對比99%的請求 latency，毛刺下降了整整一倍多。

優(yōu)化前

優(yōu)化后

單個請求情況分析

按處理順序，我們羅列出優(yōu)化前和優(yōu)化后處于 burst 時期 20 個請求的每一個 latency 的情況，如下表。不難發(fā)現(xiàn)，除了最前面的兩個請求直接使用了現(xiàn)存的 2 個實(shí)例，其他請求全部都是需要等待調(diào)度的。優(yōu)化前，所有的請求都在完全等待冷啟動；而優(yōu)化后，不難發(fā)現(xiàn)，每兩個請求的 latency 處于相同的水平，而前后兩組之間相差 100ms (正好是函數(shù)執(zhí)行時間)，從而說明新的調(diào)度方式有效的復(fù)用了已有的"熱"的容器。

請求序列(按執(zhí)行順序)優(yōu)化前 latency(ms)優(yōu)化后 latency(ms)1113.45112.932116.45116.2031933.43179.2641941.58174.6551783.99275.0362049.12279.7571938.68377.4382041.51382.5392961.99481.34101919.09485.56111968.41581.29121921.32588.19131927.44684.82141965.75695.01151997.35788.08162086.58798.03171955.57890.27181899.22900.41191941.02955.13201988.231348.59

實(shí)際在線用戶請求優(yōu)化結(jié)果

對在線某一用戶的實(shí)時流量跟進(jìn)分析，看到優(yōu)化前后明顯對比，如下圖所示。優(yōu)化前 TPS 在某一時間點(diǎn)從 11 上升到25，此時 99% 的 latency 出現(xiàn)一個明顯的毛刺現(xiàn)象。在2個小時之后，優(yōu)化開關(guān)打開，某一時間點(diǎn) TPS 達(dá)到了 32，此時 latency 無明顯波動。

總結(jié)

綜上數(shù)據(jù)分析，在典型的負(fù)載變化情況下，冷啟動對 99% 的請求 latency 的影響已經(jīng)忽略不計(jì)，本次調(diào)度上的調(diào)優(yōu)大大改善了函數(shù)計(jì)算在延時敏感場景下的表現(xiàn)。

原文鏈接

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。