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

背景

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 波峰 burst 模式

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

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

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

• runtime 為 python2.7;

• Memory 為 3GB 。

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

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

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

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

• 每波請(qǐng)求的時(shí)間間隔為 10s。

TPS情況如下，增長(zhǎng)率為100%：

優(yōu)化前后對(duì)比

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

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

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

單個(gè)請(qǐng)求情況分析

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

優(yōu)化前:

優(yōu)化后:

波峰 burst 模式

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

• 每波請(qǐng)求時(shí)間間隔 10s;

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

• burst 請(qǐng)求數(shù) 20;

TPS請(qǐng)求如下，burst 流量猛增 10 倍:

優(yōu)化前后對(duì)比

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

對(duì)比99%的請(qǐng)求 latency，毛刺下降了整整一倍多。

優(yōu)化前

優(yōu)化后

單個(gè)請(qǐng)求情況分析

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

請(qǐng)求序列(按執(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í)際在線用戶請(qǐng)求優(yōu)化結(jié)果

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

總結(jié)

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

原文鏈接

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