李 哲，譚郁松，李 寶，余 杰

(國(guó)防科技大學(xué)計(jì)算機(jī)學(xué)院,湖南 長(zhǎng)沙 410073)

1 引言

高性能計(jì)算問題的解決往往需要用到大量的計(jì)算資源，包括足夠的內(nèi)存、足夠的存儲(chǔ)空間以及為了提升并行計(jì)算效率的大量CPU。利用以虛擬機(jī)為節(jié)點(diǎn)的傳統(tǒng)云計(jì)算架構(gòu)，租用大量的云計(jì)算資源是一個(gè)不錯(cuò)的解決方案[1]。然而，在傳統(tǒng)云計(jì)算的架構(gòu)模式下，用戶不僅需要針對(duì)計(jì)算任務(wù)做出復(fù)雜的分布式設(shè)計(jì)，同時(shí)也需要租用大量的額外計(jì)算資源來應(yīng)對(duì)高性能計(jì)算問題中可能出現(xiàn)的峰值現(xiàn)象[2]。在實(shí)際的任務(wù)執(zhí)行過程中，還需要考慮到節(jié)點(diǎn)的故障與恢復(fù)等問題。另外，在整個(gè)高性能任務(wù)執(zhí)行過程中，申請(qǐng)的云計(jì)算資源并不會(huì)一直處于滿負(fù)載或者高負(fù)載的狀態(tài)，導(dǎo)致被用來應(yīng)對(duì)峰值效應(yīng)的很大一部分資源都出現(xiàn)了浪費(fèi)現(xiàn)象。

函數(shù)計(jì)算是近幾年誕生的一種全新的云計(jì)算范型，是無(wú)服務(wù)器計(jì)算的一種服務(wù)模式[3]。與傳統(tǒng)云計(jì)算相比，用戶在函數(shù)計(jì)算平臺(tái)上不再需要關(guān)心服務(wù)器的維護(hù)和一些分布式特性的管理，只需要通過函數(shù)計(jì)算平臺(tái)提供的相關(guān)接口將代碼上傳，并設(shè)定好預(yù)期使用資源和運(yùn)行時(shí)長(zhǎng)等參數(shù)，就可以將其當(dāng)作一個(gè)完整的分布式應(yīng)用運(yùn)行。圖1給出了一個(gè)典型的函數(shù)計(jì)算平臺(tái)架構(gòu)圖。每一個(gè)云函數(shù)是一個(gè)基本的計(jì)算單元模型，包括了待運(yùn)行的代碼包、一系列參數(shù)設(shè)置以及相關(guān)的配置文件等。每個(gè)云函數(shù)都可以獨(dú)立執(zhí)行自己的業(yè)務(wù)邏輯，也可以通過函數(shù)調(diào)用的方式與其他云函數(shù)進(jìn)行交互。通常一個(gè)計(jì)算任務(wù)會(huì)由不同的事件觸發(fā)而執(zhí)行，這些事件可以由不同的事件觸發(fā)器(HTTP觸發(fā)器、定時(shí)觸發(fā)器和對(duì)象存儲(chǔ)服務(wù)觸發(fā)器等)進(jìn)行捕獲。

Figure 1 Architecture of FaaS圖1 函數(shù)計(jì)算平臺(tái)架構(gòu)圖

當(dāng)函數(shù)計(jì)算平臺(tái)收到一個(gè)請(qǐng)求時(shí)，平臺(tái)會(huì)先定位到相關(guān)的云函數(shù)，然后會(huì)根據(jù)云函數(shù)提供的配置信息(業(yè)務(wù)代碼、資源限定參數(shù)等)提供一個(gè)能夠處理該請(qǐng)求的容器。容器作為函數(shù)計(jì)算最基本的計(jì)算實(shí)例，具有獨(dú)立的計(jì)算資源和運(yùn)行空間，并且裝載了對(duì)應(yīng)云函數(shù)所必要的運(yùn)行環(huán)境和相應(yīng)的業(yè)務(wù)代碼。在處理高性能并發(fā)請(qǐng)求的時(shí)候，函數(shù)平臺(tái)能夠根據(jù)請(qǐng)求數(shù)量自動(dòng)地進(jìn)行擴(kuò)容，而不需要用戶進(jìn)行管理。同時(shí)對(duì)單個(gè)容器而言，當(dāng)前容器最大允許使用的內(nèi)存由用戶自行設(shè)定。這種快速自動(dòng)擴(kuò)容的機(jī)制恰好能夠很好地用于高性能計(jì)算中的并行任務(wù)[4]，而且不會(huì)造成大量的計(jì)算資源浪費(fèi)。這種由平臺(tái)隱性提供的備用資源措施雖然能夠節(jié)省很大一筆費(fèi)用，但也帶來了一個(gè)函數(shù)計(jì)算平臺(tái)上存在的潛在問題——冷啟動(dòng)延遲問題。如上文所述，一個(gè)對(duì)云函數(shù)的請(qǐng)求是由平臺(tái)所提供的函數(shù)容器進(jìn)行處理的，如果這個(gè)容器是之前剛使用過的(通常一個(gè)容器被使用完能夠存活15～20 min[5])，那么幾乎不用額外的啟動(dòng)耗時(shí)就可以接著處理新來的請(qǐng)求。但是，如果該云函數(shù)一開始就不存在相關(guān)函數(shù)容器實(shí)例，平臺(tái)就需要為其新創(chuàng)建一個(gè)，而在平臺(tái)收到請(qǐng)求到完成請(qǐng)求處理的這段時(shí)間中，需要花費(fèi)額外的時(shí)間來進(jìn)行容器初始化、運(yùn)行環(huán)境初始化和代碼下載等準(zhǔn)備工作。這部分任務(wù)執(zhí)行之外的額外耗時(shí)被稱作冷啟動(dòng)延遲。盡管一次冷啟動(dòng)延遲最多可能僅達(dá)到幾百毫秒，但考慮到高性能計(jì)算應(yīng)用存在很大的并發(fā)量，這個(gè)問題就會(huì)被嚴(yán)重放大。

針對(duì)上述問題，本文結(jié)合阿里云提出的快速擴(kuò)容機(jī)制[6]，提出了一種通過預(yù)熱方式來降低冷啟動(dòng)延遲的方法，該方法能夠有效地降低函數(shù)計(jì)算平臺(tái)在執(zhí)行高性能計(jì)算這一類任務(wù)時(shí)產(chǎn)生的冷啟動(dòng)延遲。本文第2節(jié)介紹有關(guān)高性能計(jì)算任務(wù)和函數(shù)計(jì)算問題的相關(guān)工作；第3節(jié)和第4節(jié)將對(duì)提出的方法進(jìn)行定義并通過一個(gè)高性能計(jì)算問題的實(shí)驗(yàn)來說明其優(yōu)化效果；最后對(duì)所完成的工作做一個(gè)簡(jiǎn)短的總結(jié)并給出今后的工作計(jì)劃。

2 相關(guān)工作

Chung團(tuán)隊(duì)[6]在很早就做過高性能計(jì)算與容器虛擬化技術(shù)結(jié)合的研究工作。他們?cè)谌萜?docker)上運(yùn)行最常用的高性能計(jì)算測(cè)試工具HPL(High Performance Linpack)[7]和 Graph500[8]，用容器化的方式來執(zhí)行高性能計(jì)算任務(wù)。同時(shí)他們比較了在虛擬機(jī)和容器2種模式下高性能計(jì)算任務(wù)的執(zhí)行性能，發(fā)現(xiàn)在容器上的運(yùn)行效果遠(yuǎn)遠(yuǎn)好于在虛擬機(jī)上的效果。而Spillner團(tuán)隊(duì)[9]則進(jìn)一步將高性能計(jì)算問題遷移到了函數(shù)計(jì)算平臺(tái)來處理。Josef團(tuán)隊(duì)設(shè)計(jì)了4個(gè)典型的高性能計(jì)算問題：斐波那契數(shù)列、人臉檢測(cè)、密碼破譯和天氣預(yù)測(cè)。這4個(gè)問題的共同特點(diǎn)是都是計(jì)算密集型，而計(jì)算密集型任務(wù)恰好能夠很好地適應(yīng)函數(shù)計(jì)算這種計(jì)算模式[9,10]。

Malla等人[11]通過實(shí)驗(yàn)詳細(xì)對(duì)比了高性能計(jì)算任務(wù)在函數(shù)計(jì)算平臺(tái)上和傳統(tǒng)云計(jì)算平臺(tái)上執(zhí)行的各項(xiàng)結(jié)果，包括執(zhí)行的速度、所需的時(shí)間和租用的經(jīng)濟(jì)成本等。作者以蛋白質(zhì)序列匹配算法作為測(cè)試任務(wù)，分別運(yùn)行在谷歌的函數(shù)計(jì)算平臺(tái)(GCF)上和傳統(tǒng)的基礎(chǔ)設(shè)施平臺(tái)(GCE)上。他們發(fā)現(xiàn)盡管GCF的性能會(huì)產(chǎn)生一定的波動(dòng)，但在相同的性能下，使用GCF會(huì)比GCE更加便宜。另一方面，這2種執(zhí)行模式都會(huì)產(chǎn)生前期的任務(wù)準(zhǔn)備耗時(shí)，但在GCF上表現(xiàn)得更為明顯。這是因?yàn)樵谌蝿?wù)準(zhǔn)備階段，平臺(tái)需要在短時(shí)間內(nèi)生成大量容器實(shí)例，從而導(dǎo)致冷啟動(dòng)延遲較長(zhǎng)。

針對(duì)函數(shù)計(jì)算平臺(tái)上存在的冷啟動(dòng)延遲這一問題，Lin等人[12]提出利用容器池來對(duì)使用過的容器進(jìn)行保存。他們利用已有的開源函數(shù)計(jì)算框架Knative[13]進(jìn)行改進(jìn)，通過在框架中加入容器池請(qǐng)求的步驟達(dá)到優(yōu)化的目的。這種優(yōu)化方式在容器實(shí)例較少的情況下的確能夠有不錯(cuò)的表現(xiàn)，但如果處理高并行度的計(jì)算任務(wù)，其劣勢(shì)就很明顯，因?yàn)椴豢赡苊看味继崆邦A(yù)存好上百個(gè)容器實(shí)例。為了使函數(shù)計(jì)算平臺(tái)更好地用于解決高性能計(jì)算這種短期內(nèi)并發(fā)度較高的計(jì)算問題，阿里云提出了一種容器的動(dòng)態(tài)加載技術(shù)，能夠在短時(shí)間內(nèi)快速?gòu)?fù)制出大量相同的容器實(shí)例，其實(shí)驗(yàn)結(jié)果顯示能夠達(dá)到秒級(jí)啟動(dòng)一萬(wàn)個(gè)容器的效果[14]。

上述工作已經(jīng)證明高性能計(jì)算能夠很好地和函數(shù)計(jì)算結(jié)合，與此同時(shí)函數(shù)計(jì)算平臺(tái)在處理該類問題時(shí)也確實(shí)存在一定的優(yōu)化空間[15,16]。上文給出的優(yōu)化策略，很多都是從架構(gòu)的角度重新設(shè)計(jì)一個(gè)新的函數(shù)計(jì)算平臺(tái)，這對(duì)于一般的云計(jì)算開發(fā)者來說無(wú)疑是復(fù)雜且耗時(shí)的。因此，本文將基于阿里云的公有云函數(shù)計(jì)算平臺(tái)，結(jié)合阿里云平臺(tái)自身的快速擴(kuò)容策略，從用戶使用的角度出發(fā)，提出一種結(jié)合時(shí)間序列分析技術(shù)的預(yù)熱方法，來有效降低高性能計(jì)算問題在函數(shù)計(jì)算上的冷啟動(dòng)延遲。

3 冷啟動(dòng)分析

實(shí)際上高性能計(jì)算在函數(shù)計(jì)算平臺(tái)上的冷啟動(dòng)現(xiàn)象已經(jīng)在一些研究工作中被觀測(cè)到過[17,18]。為了更清晰地展示觀測(cè)到的冷啟動(dòng)延遲，本節(jié)設(shè)計(jì)了針對(duì)不同編程語(yǔ)言的實(shí)驗(yàn)，通過調(diào)整計(jì)算量大小來觀察冷啟動(dòng)延遲是否會(huì)發(fā)生明顯的變化。觀測(cè)實(shí)驗(yàn)部署在國(guó)內(nèi)2個(gè)知名的函數(shù)計(jì)算平臺(tái)上，分別為阿里云的FC(Function Compute)[19]和騰訊云的SCF(Serverless Cloud Function)[20]。

第1個(gè)實(shí)驗(yàn)不包含復(fù)雜的邏輯，僅執(zhí)行一句“hello world”的輸出，目的是測(cè)試?yán)鋯?dòng)延遲在函數(shù)計(jì)算平臺(tái)上的存在性。在模擬冷啟動(dòng)時(shí)，只需新建一個(gè)云函數(shù)，那么第1次請(qǐng)求就符合冷啟動(dòng)的條件——不存在該云函數(shù)的任何容器實(shí)例；對(duì)于熱啟動(dòng)，只需執(zhí)行完一次請(qǐng)求后接著執(zhí)行，就能夠滿足。本文對(duì)FC和SCF上支持的語(yǔ)言都進(jìn)行了測(cè)試，如表1所示，短橫線“-”表示FC不支持Go語(yǔ)言。從表1中可以看出，幾乎所有的實(shí)驗(yàn)中都存在明顯的冷啟動(dòng)延遲現(xiàn)象。另外發(fā)現(xiàn)，在測(cè)試腳本語(yǔ)言Python時(shí)，冷啟動(dòng)和熱啟動(dòng)運(yùn)行時(shí)長(zhǎng)幾乎沒有差別，這很可能是因?yàn)槠脚_(tái)事先準(zhǔn)備好了相關(guān)的容器，而腳本語(yǔ)言的環(huán)境并不需要任何的預(yù)加載。與之相反的是Java，可以很明顯地觀察到其在冷啟動(dòng)下的執(zhí)行時(shí)長(zhǎng)要遠(yuǎn)遠(yuǎn)超過在熱啟動(dòng)下的執(zhí)行時(shí)長(zhǎng)。這是因?yàn)榧词蛊脚_(tái)預(yù)先準(zhǔn)備好了容器，但Java這種跨平臺(tái)語(yǔ)言運(yùn)行之前需要包含JVM的啟動(dòng)過程以及類的加載過程，因此可以很明顯地觀測(cè)到。在接下來的實(shí)驗(yàn)中，我們也會(huì)選取Java這種易觀察到冷啟動(dòng)現(xiàn)象的語(yǔ)言來進(jìn)行實(shí)驗(yàn)。

Table 1 Simple task executed on SCF and FC in the way of cold start and warm start

在第1個(gè)實(shí)驗(yàn)中，觀測(cè)到了冷啟動(dòng)延遲在函數(shù)計(jì)算平臺(tái)上的存在，相對(duì)于其他編程語(yǔ)言而言，Java的冷啟動(dòng)延遲最為明顯，所以接下來的第2個(gè)實(shí)驗(yàn)利用Java這種冷啟動(dòng)延遲明顯的語(yǔ)言進(jìn)一步分析冷啟動(dòng)延遲是否受到計(jì)算量、內(nèi)存設(shè)定大小以及一些其他因素的影響。實(shí)驗(yàn)環(huán)境為：JDK 1.8，Maven 3.6.1以及阿里云的FC平臺(tái)。這個(gè)實(shí)驗(yàn)利用FC在不同內(nèi)存設(shè)定下計(jì)算不同計(jì)算量的遞歸版本的斐波那契數(shù)列，然后每種樣例分別在冷啟動(dòng)和熱啟動(dòng)情況下測(cè)試10次，觀察對(duì)照2種啟動(dòng)模式下的執(zhí)行情況。

計(jì)算任務(wù)大小實(shí)驗(yàn)結(jié)果如圖2所示。圖2a描述的是運(yùn)行時(shí)長(zhǎng)與內(nèi)存大小之間的關(guān)系，在該實(shí)驗(yàn)中，計(jì)算量是保持一致的(即斐波那契數(shù)列的計(jì)算長(zhǎng)度是一致的)。盡管當(dāng)內(nèi)存被設(shè)定為256 MB時(shí)，運(yùn)行時(shí)長(zhǎng)會(huì)處于最低，但仍然遠(yuǎn)遠(yuǎn)高于熱啟動(dòng)的運(yùn)行時(shí)長(zhǎng)。如圖2a所示，在不同的內(nèi)存設(shè)定中，2種啟動(dòng)模式下的平均運(yùn)行時(shí)長(zhǎng)分別為108 ms和13 ms，其差值大約為100 ms左右。圖2b展示了計(jì)算量大小與在不同啟動(dòng)模式下的延遲關(guān)系，從中可以看到，盡管在冷啟動(dòng)和熱啟動(dòng)2種情況下，運(yùn)行時(shí)長(zhǎng)都會(huì)呈指數(shù)增長(zhǎng)，但是二者的差值仍然保持在100 ms左右。這表明冷啟動(dòng)延遲是一個(gè)趨于穩(wěn)定的值。

Figure 2 Different cases of Fabonaci sequence test圖2 不同參數(shù)設(shè)定下的斐波那契數(shù)列運(yùn)行結(jié)果

最后在第3個(gè)實(shí)驗(yàn)中觀察了FC本身采用的快速擴(kuò)容機(jī)制。在計(jì)算斐波那契數(shù)列的實(shí)驗(yàn)中，利用阿里云FC提供的SDK進(jìn)行了并發(fā)請(qǐng)求的測(cè)試。每次測(cè)試中，在客戶端同時(shí)向同一個(gè)云函數(shù)發(fā)送10條執(zhí)行請(qǐng)求，并觀察其平均執(zhí)行時(shí)長(zhǎng)。其中斐波那契數(shù)列的計(jì)算量設(shè)定為遞歸計(jì)算第35項(xiàng)，同時(shí)將云函數(shù)的最大允許使用內(nèi)存設(shè)定為512 MB。如表2所示，當(dāng)一個(gè)云函數(shù)存在1個(gè)容器實(shí)例時(shí)，意味著1個(gè)熱啟動(dòng)處理和9個(gè)冷啟動(dòng)處理，那么10條請(qǐng)求的平均處理時(shí)長(zhǎng)并不會(huì)太長(zhǎng)，僅僅比單次熱啟動(dòng)延遲多17 ms；而當(dāng)不存在容器實(shí)例時(shí)，意味著10條請(qǐng)求都是冷啟動(dòng)，此時(shí)平均處理時(shí)長(zhǎng)不僅僅高于單次熱啟動(dòng)時(shí)長(zhǎng)，甚至比單次冷啟動(dòng)時(shí)長(zhǎng)還要高出將近30%。這個(gè)實(shí)驗(yàn)結(jié)果說明，阿里云能夠利用一個(gè)已有的完整容器——阿里云容器團(tuán)隊(duì)提出的DADI加速器[14]進(jìn)行快速擴(kuò)容。

Table 2 Concurrent requests test 表2 并發(fā)請(qǐng)求實(shí)驗(yàn) ms

一般而言，一個(gè)完整的容器啟動(dòng)鏡像往往有上百M(fèi)B甚至達(dá)到GB級(jí)，如果每次將已有的鏡像完整加載，那么耗時(shí)是很高的。阿里云提出的DADI加速器避免了傳統(tǒng)容器“下載鏡像 > 解壓鏡像 > 啟動(dòng)容器”的啟動(dòng)步驟，容器的啟動(dòng)耗時(shí)以及擴(kuò)容時(shí)間大大縮短，這其中包括3點(diǎn)優(yōu)化：(1)鏡像格式優(yōu)化：DADI團(tuán)隊(duì)設(shè)計(jì)了一種新型的鏡像模式，無(wú)需下載和解壓全部的完整鏡像即可直接訪問；(2)按需P2P數(shù)據(jù)讀取：DADI利用樹形P2P網(wǎng)絡(luò)對(duì)數(shù)據(jù)進(jìn)行分發(fā)，即少數(shù)P2P根節(jié)點(diǎn)從Registry獲取，其他節(jié)點(diǎn)(宿主機(jī))之間可相互傳輸數(shù)據(jù)，利用已有容器快速分發(fā)數(shù)據(jù)到所有節(jié)點(diǎn)從而進(jìn)行擴(kuò)容；(3)高效的壓縮算法：DADI提供了一種新型的壓縮文件格式，可按需單獨(dú)解壓用戶實(shí)際訪問的數(shù)據(jù)，且解壓時(shí)間開銷可忽略不計(jì)[14]。

4 解決方案

函數(shù)計(jì)算平臺(tái)最大的一個(gè)特點(diǎn)是不會(huì)暴露給用戶任何能夠直接操控容器的接口，因此站在用戶的使用角度只能夠通過調(diào)用接口進(jìn)行優(yōu)化。本文提出的策略就是提前預(yù)測(cè)請(qǐng)求到來的時(shí)間，然后觸發(fā)該云函數(shù)產(chǎn)生一個(gè)完整的容器實(shí)例，讓之后到來的請(qǐng)求以熱啟動(dòng)的方式運(yùn)行。

在本節(jié)首先對(duì)要用到的開源預(yù)測(cè)工具Prophet[21]進(jìn)行測(cè)試，接著采用本文提出的預(yù)熱方式，分別對(duì)密碼破譯以及多容器協(xié)同求π值等場(chǎng)景進(jìn)行實(shí)驗(yàn)。其中的對(duì)照實(shí)驗(yàn)包括熱啟動(dòng)后的執(zhí)行效果和冷啟動(dòng)后的執(zhí)行效果。在冷啟動(dòng)的實(shí)驗(yàn)中，為了保證每一次調(diào)用都是冷啟動(dòng)調(diào)用，實(shí)驗(yàn)在每次測(cè)試時(shí)重新創(chuàng)建新的云函數(shù)，同時(shí)在運(yùn)行結(jié)束后，將該云函數(shù)刪除，這樣就可以保證下一次不會(huì)使用到先前殘留的熱容器實(shí)例。

4.1 預(yù)測(cè)請(qǐng)求時(shí)間

Prophet是Facebook提供的一款開源的時(shí)間序列分析工具，可以廣泛應(yīng)用于現(xiàn)實(shí)生活中的各類時(shí)間序列分析問題。Prophet認(rèn)為任意一個(gè)時(shí)間序列，都由以下幾個(gè)部份組合而成：

ypredict(t)=g(t)+s(t)+h(t)+p(t)+ε

(1)

其中,t表示待預(yù)測(cè)的時(shí)間；ypredict(t)表示預(yù)測(cè)值，g(t)表示數(shù)據(jù)的大趨勢(shì)(比如整體的預(yù)測(cè)值呈上升趨勢(shì))；周期項(xiàng)s(t)表示周期性的變化趨勢(shì)，即s(t)的值每隔一個(gè)周期就會(huì)重復(fù)出現(xiàn)相同的變化趨勢(shì)，周期內(nèi)的單位時(shí)間間隔由數(shù)據(jù)本身決定(比如每分鐘，每小時(shí)，本文實(shí)驗(yàn)的單位時(shí)間間隔為每5分鐘)，而每個(gè)周期內(nèi)包含的總的時(shí)間間隔是相同的；h(t)表示特殊事件(比如節(jié)假日)；p(t)表示外部因素的影響(比如天氣因素、環(huán)境因素)；ε表示噪聲。

本文利用Prophet預(yù)測(cè)請(qǐng)求時(shí)間，本文所涉及到的請(qǐng)求日志數(shù)據(jù)是每5分鐘一次請(qǐng)求的時(shí)間序列，不考慮復(fù)雜的特殊性因素，這類時(shí)間序列存在以每天為單位的周期性，同時(shí)并不具備長(zhǎng)期變化的大趨勢(shì)。在這種情形下，只考慮周期項(xiàng)s(t)即可，s(t)可表示為：

(2)

其中，P表示頻率，在本文所考慮的情形下，時(shí)間序列為每5分鐘一次，周期為每天，因此有P=24*60/5=288。

s(t)可表示為2個(gè)向量相乘的形式：

s(t)=X(t)·β

(3)

其中,

1≤n≤N

(4)

β=[a1,b1,a2,b2,…,aN,bN]T

(5)

關(guān)于N的取值，通常Prophet會(huì)根據(jù)周期大小給定一個(gè)默認(rèn)值?？梢钥吹降氖?，N的取值越大，考慮的分量因素就越多，預(yù)測(cè)得更加精確但是更容易導(dǎo)致過擬合。s(t)的整個(gè)預(yù)測(cè)過程就是通過已有的時(shí)間序列擬合出參數(shù)an和bn(1≤n≤N)，然后再利用擬合出的參數(shù)預(yù)測(cè)相應(yīng)的時(shí)間值，最終得到預(yù)測(cè)結(jié)果。

由于并不能獲取到FC的用戶日志信息，本文利用Prophet在Github上提供的測(cè)試數(shù)據(jù)集進(jìn)行了測(cè)試。該數(shù)據(jù)集包含18 000條時(shí)間序列，是一個(gè)連續(xù)2個(gè)月左右、間隔5分鐘的時(shí)間序列數(shù)據(jù)集，精度都為秒級(jí)，同時(shí)每條序列后都對(duì)應(yīng)一個(gè)y值，代表5分鐘內(nèi)的請(qǐng)求數(shù)量。為了模擬函數(shù)計(jì)算的請(qǐng)求，本文根據(jù)y的范圍取中間的值作為一個(gè)閾值，超過閾值的y設(shè)置為1，表示該時(shí)間點(diǎn)的未來5分鐘內(nèi)存在一個(gè)即將到來的請(qǐng)求；低于閾值設(shè)置為0，表示未來5分鐘沒有請(qǐng)求到來。實(shí)際上1可以表示一條請(qǐng)求或多條請(qǐng)求，因?yàn)樵趯?shí)驗(yàn)設(shè)計(jì)中，無(wú)論是一條請(qǐng)求或者是多條請(qǐng)求，只要是在5分鐘的時(shí)間段內(nèi)，實(shí)際上都只會(huì)對(duì)云函數(shù)進(jìn)行一次預(yù)熱處理。另外，考慮到容器的存活時(shí)間具有延續(xù)性——每次處理完新的請(qǐng)求，都至少能再存活15分鐘左右，因此本文的實(shí)驗(yàn)策略就是比較預(yù)測(cè)時(shí)間點(diǎn)和實(shí)際時(shí)間點(diǎn)的請(qǐng)求處理狀態(tài)是冷啟動(dòng)處理還是熱啟動(dòng)處理即可。比如一段連續(xù)的預(yù)測(cè)值為:1(第5分鐘有請(qǐng)求)，0(第10分鐘無(wú)請(qǐng)求)，0(第15分鐘無(wú)請(qǐng)求)。而實(shí)際值為：1(第5分鐘有請(qǐng)求)，1(第10分鐘有請(qǐng)求)，1(第15分鐘有請(qǐng)求)。由于容器存活時(shí)間具有延續(xù)性，那么預(yù)測(cè)點(diǎn)的狀態(tài)就為：第5、10、15分鐘該容器都是處于熱狀態(tài)的，剛好能以熱啟動(dòng)的方式處理實(shí)際到來的請(qǐng)求。也就是說，只要容器狀態(tài)為熱啟動(dòng)狀態(tài)，那么無(wú)論是否有請(qǐng)求到來，容器都保持熱狀態(tài)?；诖说贸龅钠骄A(yù)測(cè)準(zhǔn)確率大約為86%，說明該預(yù)測(cè)工具在這種情況下的預(yù)測(cè)準(zhǔn)確率還是相當(dāng)不錯(cuò)的。

4.2 單容器實(shí)例破譯密碼

本節(jié)首先對(duì)單容器運(yùn)行案例進(jìn)行測(cè)試，測(cè)試用例是通過云函數(shù)暴力破解一個(gè)5位數(shù)的隨機(jī)密碼。該隨機(jī)密碼由數(shù)字0～9以及所有的大小寫字母組成，隨機(jī)初始種子可由用戶指定。實(shí)驗(yàn)測(cè)試一共分為3個(gè)部份：冷啟動(dòng)測(cè)試、熱啟動(dòng)測(cè)試和預(yù)熱后測(cè)試。

在函數(shù)的設(shè)計(jì)上，實(shí)驗(yàn)中的該云函數(shù)會(huì)被綁定一個(gè)HTTP觸發(fā)器，該觸發(fā)器可以捕獲任意訪問該云函數(shù)的HTTP請(qǐng)求。通過對(duì)HTTP請(qǐng)求參數(shù)的解析，云函數(shù)可以決定如何進(jìn)行下一步操作。在每次請(qǐng)求中會(huì)加入2個(gè)參數(shù)，分別是execute和seed。只有當(dāng)execute的值為true時(shí)，云函數(shù)才會(huì)執(zhí)行密碼破譯的任務(wù)，同時(shí)根據(jù)給定的種子值seed,去生成一個(gè)隨機(jī)的5位密碼；而當(dāng)execute被指定為false時(shí)，則不會(huì)執(zhí)行任何計(jì)算任務(wù)，直接退出。這樣做的目的是為了對(duì)該云函數(shù)的容器進(jìn)行一個(gè)最快的預(yù)熱處理，使預(yù)測(cè)到的請(qǐng)求能夠熱啟動(dòng)執(zhí)行的同時(shí)盡可能地減少不必要的計(jì)算成本。

在冷啟動(dòng)測(cè)試的過程中，每次利用相同的執(zhí)行代碼創(chuàng)建一個(gè)新的云函數(shù)，以此來保證每個(gè)容器不會(huì)被復(fù)用。另外，將execute參數(shù)直接設(shè)定為true，使云函數(shù)一收到請(qǐng)求就直接開始執(zhí)行，同時(shí)執(zhí)行完畢后刪除云函數(shù)及其綁定的觸發(fā)器。在熱啟動(dòng)實(shí)驗(yàn)中，首先創(chuàng)建一個(gè)云函數(shù)，順序執(zhí)行多次請(qǐng)求(得到響應(yīng)結(jié)果后再發(fā)出下一次請(qǐng)求，同時(shí)請(qǐng)求的參數(shù)execute設(shè)定為true)后，再開始進(jìn)行測(cè)試。這樣就可以保證每次測(cè)試使用的都是同一個(gè)云函數(shù)容器實(shí)例。預(yù)熱實(shí)驗(yàn)的執(zhí)行過程則分為多個(gè)步驟進(jìn)行。因?yàn)樵摲椒ū旧砭褪菫榱藘?yōu)化冷啟動(dòng)問題，所以仍然需要像冷啟動(dòng)測(cè)試過程一樣，每次都創(chuàng)建新的云函數(shù)和觸發(fā)器。在處理請(qǐng)求第一步首先對(duì)云函數(shù)進(jìn)行預(yù)熱處理，將execute參數(shù)設(shè)置為false，并發(fā)送一條請(qǐng)求；當(dāng)收到響應(yīng)信息后，再將execute參數(shù)設(shè)定為true，并給seed賦值，令之前產(chǎn)生的容器實(shí)例執(zhí)行密碼破譯任務(wù)。每種情形都進(jìn)行10次測(cè)試，而為了保證計(jì)算時(shí)長(zhǎng)的一致性，設(shè)定的seed也都一致，最終的測(cè)試結(jié)果如表3所示。

Table 3 Single task request test 表3 單任務(wù)請(qǐng)求實(shí)驗(yàn) ms

在預(yù)期上，單容器實(shí)例預(yù)熱啟動(dòng)的2步總耗時(shí)應(yīng)該和冷啟動(dòng)耗時(shí)大致相同。一次完整的預(yù)熱啟動(dòng)過程包括信號(hào)預(yù)熱和執(zhí)行請(qǐng)求2個(gè)部分，其中預(yù)熱時(shí)長(zhǎng)為183 ms，執(zhí)行時(shí)長(zhǎng)為973 ms。表3所示的運(yùn)行結(jié)果基本上與預(yù)期值一致，即預(yù)熱后的執(zhí)行能夠至少減少183 ms的啟動(dòng)延遲。由于單步冷啟動(dòng)執(zhí)行被分為2步，這個(gè)并不連續(xù)的過程會(huì)導(dǎo)致預(yù)熱啟動(dòng)的總耗時(shí)略微高于單次冷啟動(dòng)的執(zhí)行時(shí)長(zhǎng)，但對(duì)用戶而言，增加的3 ms和減少的183 ms相比幾乎可以忽略不計(jì)。另外讀者可能會(huì)發(fā)現(xiàn)，即使預(yù)熱后執(zhí)行，仍然比熱啟動(dòng)執(zhí)行時(shí)長(zhǎng)略高，這是因?yàn)榘⒗镌撇捎昧藙?dòng)態(tài)鏡像加載的優(yōu)化策略，在每次執(zhí)行時(shí)只加載完整鏡像中運(yùn)行所必須的一小部分文件。而熱啟動(dòng)實(shí)驗(yàn)是在單個(gè)容器執(zhí)行了幾次之后才開始進(jìn)行的，因此容器內(nèi)所需的代碼運(yùn)行環(huán)境已經(jīng)加載完全，運(yùn)行時(shí)長(zhǎng)會(huì)比預(yù)熱后的第一次運(yùn)行時(shí)長(zhǎng)更短。

4.3 多容器實(shí)例協(xié)同計(jì)算π值

本節(jié)利用阿里云的快速擴(kuò)容機(jī)制對(duì)多容器實(shí)例協(xié)同處理問題進(jìn)行測(cè)試。與4.2節(jié)實(shí)驗(yàn)一樣，仍然為每一個(gè)云函數(shù)綁定HTTP觸發(fā)器，同時(shí)通過HTTP請(qǐng)求傳參的方式告知云函數(shù)進(jìn)行預(yù)熱處理還是執(zhí)行任務(wù)。為了模擬高性能計(jì)算在函數(shù)計(jì)算平臺(tái)上的執(zhí)行過程，本節(jié)設(shè)計(jì)了一個(gè)多容器實(shí)例計(jì)算泰勒展開式的實(shí)驗(yàn)。該實(shí)驗(yàn)利用多個(gè)容器實(shí)例協(xié)同計(jì)算π的泰勒展開前1億項(xiàng)來近似逼近π,如公式(6)所示：

(6)

本節(jié)設(shè)計(jì)了2個(gè)云函數(shù)來解決這個(gè)問題，如圖3所示。執(zhí)行過程分為3步：首先從客戶端向counter云函數(shù)發(fā)送執(zhí)行請(qǐng)求，請(qǐng)求中會(huì)包含3個(gè)參數(shù)：execute、n和N，分別代表是否執(zhí)行計(jì)算任務(wù)、執(zhí)行計(jì)算任務(wù)所需計(jì)算實(shí)例的個(gè)數(shù)(即圖3中的Computing Unit函數(shù))和泰勒展開式的項(xiàng)數(shù)；接著counter根據(jù)接收的參數(shù)在同一時(shí)刻向Computing Unit函數(shù)通過線程池發(fā)送n條請(qǐng)求，并在每條請(qǐng)求上分別設(shè)定好對(duì)應(yīng)實(shí)例所需計(jì)算的泰勒展開項(xiàng)式的位置(比如第i條請(qǐng)求計(jì)算泰勒展開式的第j到第k項(xiàng))，同時(shí)由counter中的每一個(gè)異步請(qǐng)求結(jié)果類(Java中為FutureTask類)對(duì)請(qǐng)求結(jié)果進(jìn)行維護(hù)；當(dāng)所有的請(qǐng)求都發(fā)送出去后，counter實(shí)例則會(huì)通過輪詢的方法將所有Computing Unit實(shí)例結(jié)果進(jìn)行匯總，并由counter實(shí)例將結(jié)果返回給客戶端。本節(jié)n設(shè)置為10，N設(shè)置為100 000 000。

Figure 3 Architecture of π computing task圖3 多容器計(jì)算π值架構(gòu)圖

與4.2節(jié)一樣，實(shí)驗(yàn)分別對(duì)冷啟動(dòng)情形、熱啟動(dòng)情形和預(yù)熱后情形進(jìn)行測(cè)試。與4.2節(jié)實(shí)驗(yàn)不同的是，本節(jié)實(shí)驗(yàn)涉及到了二次請(qǐng)求，即客戶端先請(qǐng)求counter，counter再請(qǐng)求Computing Unit。在冷啟動(dòng)和預(yù)熱實(shí)驗(yàn)測(cè)試中，為了保證每次請(qǐng)求都產(chǎn)生新的容器，仍然采用“創(chuàng)建—調(diào)用—?jiǎng)h除”云函數(shù)的操作方式。另一方面，如第3節(jié)測(cè)試結(jié)果顯示，單個(gè)Java運(yùn)行環(huán)境至少需要100 ms才能完全初始化，而一個(gè)容器實(shí)例必須響應(yīng)完當(dāng)前請(qǐng)求之后，才能繼續(xù)響應(yīng)下一請(qǐng)求，因此當(dāng)counter向Computing Unit瞬時(shí)發(fā)送出n條請(qǐng)求時(shí)，能夠保證每條請(qǐng)求都產(chǎn)生一個(gè)全新的容器實(shí)例來對(duì)請(qǐng)求進(jìn)行處理。在熱啟動(dòng)實(shí)驗(yàn)中，利用上一次被使用過的冷啟動(dòng)容器來保證實(shí)驗(yàn)是在熱啟動(dòng)模式下完成的。在預(yù)熱實(shí)驗(yàn)環(huán)節(jié)，本節(jié)利用阿里云提供的策略對(duì)counter和Computing Unit僅預(yù)熱出一個(gè)容器實(shí)例，而實(shí)際所需的剩下n-1個(gè)實(shí)例，則通過阿里云的擴(kuò)容策略進(jìn)行快速?gòu)?fù)制。

實(shí)驗(yàn)結(jié)果如圖4所示，一次完整的預(yù)熱測(cè)試包括容器預(yù)熱和執(zhí)行計(jì)算任務(wù)2個(gè)過程。從圖4中可以看到，冷啟動(dòng)情形下單次請(qǐng)求的執(zhí)行時(shí)長(zhǎng)為7 300 ms，遠(yuǎn)遠(yuǎn)高出熱啟動(dòng)情況下的執(zhí)行時(shí)長(zhǎng)578 ms。而在本文提出的方法中，預(yù)熱時(shí)長(zhǎng)大約為360 ms，執(zhí)行計(jì)算任務(wù)時(shí)長(zhǎng)大約為4 500 ms。同冷啟動(dòng)情形相比，利用阿里云平臺(tái)本身的快速擴(kuò)容機(jī)制，預(yù)熱措施的確能夠有效地縮短冷啟動(dòng)延遲。但是另一方面發(fā)現(xiàn)，無(wú)論是冷啟動(dòng)還是預(yù)熱之后的執(zhí)行時(shí)長(zhǎng)，都遠(yuǎn)遠(yuǎn)高于熱啟動(dòng)情形下的執(zhí)行耗時(shí)。發(fā)生這種現(xiàn)象的原因可能有2個(gè)：第1是因?yàn)閏ounter和多個(gè)Computing Unit本身的冷啟動(dòng)延遲效應(yīng)，在容器啟動(dòng)時(shí)存在一定的延遲；第2則是2種情形下的容器環(huán)境并沒有加載完全，而熱啟動(dòng)的測(cè)試都是在冷啟動(dòng)環(huán)境執(zhí)行多次后進(jìn)行的測(cè)試。

Figure 4 Result of π computing task圖4 多容器計(jì)算π的實(shí)驗(yàn)結(jié)果

5 結(jié)束語(yǔ)

高性能計(jì)算任務(wù)已經(jīng)被證明能夠有效運(yùn)行在函數(shù)計(jì)算平臺(tái)上，但其對(duì)計(jì)算資源的需求非常高，尤其是當(dāng)整個(gè)任務(wù)被劃分為大量子任務(wù)時(shí)，需要平臺(tái)提供大量的容器實(shí)例來滿足其執(zhí)行需求。在并發(fā)任務(wù)過多的情形下，由于需要產(chǎn)生多個(gè)實(shí)例，同時(shí)可能需要進(jìn)行一些結(jié)果同步的操作(比如4.3節(jié))，冷啟動(dòng)延遲會(huì)嚴(yán)重增加單次任務(wù)執(zhí)行的總耗時(shí)，本文提出一種結(jié)合快速擴(kuò)容機(jī)制進(jìn)行提前預(yù)熱的方法來解決該問題。整個(gè)過程非常簡(jiǎn)單，只需要利用時(shí)間序列分析工具預(yù)測(cè)請(qǐng)求到來的時(shí)間點(diǎn)，并在合適的時(shí)間段內(nèi)利用信號(hào)將相應(yīng)的云函數(shù)提前預(yù)熱即可。實(shí)驗(yàn)結(jié)果表明，無(wú)論在單容器實(shí)例情形還是多容器協(xié)同計(jì)算情形下，本文方法都可以在一定程度上減少冷啟動(dòng)延遲。未來的工作需要更多地去探索其他高性能應(yīng)用場(chǎng)景來驗(yàn)證本文方法。