由于無(wú)服務(wù)器計(jì)算的易編程性和易管理，近年來(lái)它得到了迅速的普及。許多人將其視為云服的下一個(gè)通用計(jì)算平臺(tái)[4]。 但是，雖然現(xiàn)有的無(wú)服務(wù)器平臺(tái)已經(jīng)成功地支持了一些流行的應(yīng)用，如事件處理和簡(jiǎn)單的ETL，但它們還是無(wú)法支持那些對(duì)延遲和吞吐量敏感的應(yīng)用，如流式計(jì)算和機(jī)器學(xué)習(xí)（ML）。無(wú)服務(wù)器計(jì)算所面臨的主要挑戰(zhàn)源于這些應(yīng)用（通常被部署在虛擬機(jī)上）對(duì)性能的要求與現(xiàn)有無(wú)服務(wù)器平臺(tái)的性能之間的差距。
在這篇博文中，我們認(rèn)為如果要縮小與傳統(tǒng)的基于虛擬機(jī)的解決方案的性能差距，無(wú)服務(wù)器平臺(tái)需要增加對(duì)以下特征的支持：
1.有狀態(tài)計(jì)算
2.通信和數(shù)據(jù)感知函數(shù)的放置
這些都是10倍的特征，即這些特性能把一個(gè)應(yīng)用的延遲和/或吞吐量提升10倍或更多。
為了驗(yàn)證這些聲明，我們將這兩個(gè)功能添加到了Ray（一個(gè)以前只提供無(wú)服務(wù)器類(lèi)似抽象的通用系統(tǒng)）。在添加有狀態(tài)計(jì)算和通信以及數(shù)據(jù)感知函數(shù)放置之后，Ray能夠支持新的對(duì)吞吐量和延遲敏感的應(yīng)用，而這在現(xiàn)有無(wú)服務(wù)器抽象中是不可能辦到的。
評(píng)估性能的差距
無(wú)服務(wù)器平臺(tái)允許開(kāi)發(fā)人員通過(guò)在大型集群上透明地分發(fā)和執(zhí)行這些函數(shù)來(lái)并行運(yùn)行。通常這些函數(shù)都是無(wú)狀態(tài)的，即每個(gè)函數(shù)從共享存儲(chǔ)器（例如，S3）讀取輸入，執(zhí)行計(jì)算，再將輸出寫(xiě)回共享存儲(chǔ)器，然后其他函數(shù)可以使用它的輸出。
雖然無(wú)服務(wù)器計(jì)算讓開(kāi)發(fā)人員不必再操心如何管理集群，但它也帶來(lái)了顯著的性能上的開(kāi)銷(xiāo)[4]：
- 數(shù)據(jù)傳輸：今天，云計(jì)算函數(shù)需要從共享存儲(chǔ)器（如S3）讀取和寫(xiě)入數(shù)據(jù)。使用AWS Lambdas（號(hào)稱(chēng)是最成熟的無(wú)服務(wù)器產(chǎn)品），一個(gè)云函數(shù)（lambda）可以以70-80MB/s的速度從S3讀取數(shù)據(jù)，并以大約50MB/s的速度向S3寫(xiě)入數(shù)據(jù)。訪(fǎng)問(wèn)S3的延遲可達(dá)數(shù)十毫秒。這個(gè)吞吐量和延遲都比訪(fǎng)問(wèn)本地內(nèi)存甚至本地SSD差了幾個(gè)數(shù)量級(jí)。這些不成比例的性能差異顯著地影響了對(duì)延遲和吞吐量敏感的應(yīng)用（例如機(jī)器學(xué)習(xí)）。
圖1. 用AWS lambda從S3讀/寫(xiě)的吞吐量。平均寫(xiě)入速度為約50MB/s，而讀取吞吐量有兩個(gè)峰值，一個(gè)約70MB/s和一個(gè)約85MB/s。（感謝Eric Jonas提供內(nèi)容，http://ericjonas.com/。）
- 啟動(dòng)時(shí)間：云函數(shù)啟動(dòng)可能需要幾秒鐘，在某些情況下需要十多秒。啟動(dòng)時(shí)間包括(1)調(diào)度和啟動(dòng)云函數(shù)，以及(2)下載應(yīng)用軟件環(huán)境。雖然云函數(shù)可以在亞秒級(jí)[3]啟動(dòng)，但下載軟件環(huán)境會(huì)需要更長(zhǎng)的時(shí)間。例如，Python程序需要在啟動(dòng)之前下載數(shù)百M(fèi)B的庫(kù)和環(huán)境依賴(lài)項(xiàng)，這就可能用掉十幾秒。
- 通信成本：與基于虛擬機(jī)的解決方案相比，云函數(shù)可能需要傳輸10倍或更多的數(shù)據(jù)。這是因?yàn)闊o(wú)服務(wù)器平臺(tái)沒(méi)辦法為應(yīng)用來(lái)優(yōu)化云函數(shù)的放置位置。例如圖2顯示了聚合通信的模式，即通常由SQL聚合查詢(xún)或分布式SGD生成的模式。對(duì)于虛擬機(jī)的方案和基于函數(shù)的方案，通過(guò)為每個(gè)虛擬機(jī)打包K個(gè)函數(shù)，基于虛擬機(jī)的解決方案比無(wú)服務(wù)器解決方案?jìng)鬏數(shù)臄?shù)據(jù)少K倍，通常K在10~100之間。
?
圖2：(a)一個(gè)云函數(shù)聚合來(lái)自N個(gè)其他函數(shù)的結(jié)果。(b)相同的聚合模式，其中N個(gè)函數(shù)在N / K個(gè)虛擬機(jī)實(shí)例上運(yùn)行，每個(gè)實(shí)例運(yùn)行K個(gè)函數(shù)?；谔摂M機(jī)的解決方案?jìng)鬏數(shù)臄?shù)據(jù)量是1/K。更重要的是，聚合結(jié)果的函數(shù)接收的數(shù)據(jù)也更少
有沒(méi)有解決的方法？
最近，已經(jīng)出現(xiàn)了幾個(gè)改善無(wú)服務(wù)器平臺(tái)和云函數(shù)服務(wù)性能[2,4]的建議。 這些建議包括：
1.更快的共享存儲(chǔ)系統(tǒng)（例如，基于內(nèi)存或NVRAM支持的系統(tǒng)）。
2.通過(guò)保持云函數(shù)處于內(nèi)存狀態(tài)來(lái)減少功能啟動(dòng)的時(shí)間。
3.函數(shù)之間直接通信。
雖然這些建議可以顯著地提高現(xiàn)有云函數(shù)的性能，但我們認(rèn)為它們并不足以支持新的工作負(fù)載，例如機(jī)器學(xué)習(xí)的訓(xùn)練、模型服務(wù)和流式計(jì)算。
首先，正如我們接下來(lái)將看到的，即使共享存儲(chǔ)系統(tǒng)在內(nèi)存中，遠(yuǎn)程訪(fǎng)問(wèn)該存儲(chǔ)數(shù)據(jù)仍然比從本地存儲(chǔ)器訪(fǎng)問(wèn)相同數(shù)據(jù)要慢得多，甚至比從以下位置訪(fǎng)問(wèn)數(shù)據(jù)要慢得多——硬件加速器（如GPU）的芯片內(nèi)存。其次，雖然保持函數(shù)處于內(nèi)存里肯定有幫助，但啟動(dòng)時(shí)間仍然是幾百毫秒[7]。 最后，雖然直接通信消除了對(duì)共享存儲(chǔ)器的讀/寫(xiě)需求，但它不控制函數(shù)所處的位置，因此不能解決如圖2所示的低效通信模式的問(wèn)題。
為了進(jìn)一步說(shuō)明這些改進(jìn)建議的不足，接下來(lái)會(huì)介紹我們?cè)诩又荽髮W(xué)伯克利分校建立的通用分布式系統(tǒng)Ray的經(jīng)驗(yàn)。
Ray的任務(wù)——無(wú)服務(wù)器平臺(tái)的“最佳”性能
Ray最初是一個(gè)面向任務(wù)的框架，這里的任務(wù)是指的遠(yuǎn)程運(yùn)行的無(wú)狀態(tài)函數(shù)，類(lèi)似于無(wú)服務(wù)器平臺(tái)。由于多租戶(hù)不是Ray的原始目標(biāo)，因此我們是可以超越上述的性能改進(jìn)建議的。我們認(rèn)為Ray的性能是當(dāng)前無(wú)服務(wù)器架構(gòu)可實(shí)現(xiàn)的性能的實(shí)際上限。Ray采用了大量?jī)?yōu)化措施，可以顯著地縮短啟動(dòng)時(shí)間，并提高函數(shù)之間的數(shù)據(jù)傳輸?shù)耐掏铝俊?/p>
- 基于內(nèi)存的共享存儲(chǔ)：為了提高讀取函數(shù)輸入和輸出的吞吐量和延遲，我們實(shí)現(xiàn)了基于內(nèi)存的存儲(chǔ)引擎。同一臺(tái)機(jī)器上的函數(shù)在共享數(shù)據(jù)時(shí)使用內(nèi)存共享，從而避免了數(shù)據(jù)的復(fù)制。這使得函數(shù)能夠以幾GB/s的速率從/向共享存儲(chǔ)讀取/寫(xiě)入數(shù)據(jù)，這比訪(fǎng)問(wèn)諸如S3這樣的存儲(chǔ)器（參見(jiàn)圖1）的速度高出幾個(gè)數(shù)量級(jí)。
- 毫秒級(jí)啟動(dòng)時(shí)間：在Ray里，當(dāng)聲明函數(shù)時(shí)，函數(shù)及其環(huán)境的代碼會(huì)被急迫地分發(fā)到集群的所有節(jié)點(diǎn)，而不是在調(diào)用函數(shù)時(shí)才被分發(fā)。 因此，函數(shù)的啟動(dòng)時(shí)間被極大地縮短了。在同一臺(tái)機(jī)器上執(zhí)行no-op函數(shù)需要大約300微秒，在遠(yuǎn)程機(jī)器上需要大約1 毫秒（這些結(jié)果是在A(yíng)WS中運(yùn)行的集群上獲得的）。這比在現(xiàn)有平臺(tái)上運(yùn)行云函數(shù)所需的時(shí)間（可能是100毫秒或更長(zhǎng)[7]）快了幾個(gè)數(shù)量級(jí)。
雖然這些設(shè)計(jì)決策和實(shí)現(xiàn)方法為現(xiàn)有云函數(shù)提供了顯著的性能改進(jìn)，它們比近期提出并在上一節(jié)中描述的技術(shù)的改進(jìn)更大，但我們發(fā)現(xiàn)它們不足以支持一些應(yīng)用，例如機(jī)器學(xué)習(xí)和流式計(jì)算。
無(wú)狀態(tài)函數(shù)還不夠好
最初Ray面向的主要工作負(fù)載之一是分布式機(jī)器學(xué)習(xí)和強(qiáng)化學(xué)習(xí)應(yīng)用。這些工作負(fù)載很快就暴露了Ray的功能抽象的局限性，其中許多限制也在其他應(yīng)用中出現(xiàn)，例如流式計(jì)算和數(shù)據(jù)庫(kù)[2]。
低效的GPU訓(xùn)練
在許多情況下，我們希望在相同的數(shù)據(jù)上訓(xùn)練相同的模型，但是從不同的初始狀態(tài)開(kāi)始。 使用一個(gè)函數(shù)抽象，模型權(quán)重和訓(xùn)練數(shù)據(jù)需要在每輪訓(xùn)練中被復(fù)制到GPU。不幸的是，即使數(shù)據(jù)已經(jīng)在本地內(nèi)存中（而不是在磁盤(pán)上或遠(yuǎn)程存儲(chǔ)上），將其傳輸?shù)紾PU也需要花費(fèi)大量的時(shí)間。這是因?yàn)镚PU通常只能通過(guò)PCI Express總線(xiàn)從內(nèi)存讀取數(shù)據(jù)，而目前PCI Express總線(xiàn)的最大速率為32GB/s。這與今天的GPU中可用的內(nèi)存帶寬（從500 GB/s開(kāi)始）相差甚遠(yuǎn)。 使用無(wú)狀態(tài)函數(shù)抽象，我們無(wú)法在GPU內(nèi)存中保持訓(xùn)練輪次之間的狀態(tài)，從而最大化性能。
圖3. 模擬器的例子。（a）每個(gè)動(dòng)作都用一個(gè)無(wú)狀態(tài)函數(shù)實(shí)現(xiàn)，從共享存儲(chǔ)中讀取模擬器的狀態(tài)，執(zhí)行一個(gè)模擬步驟，并寫(xiě)回更新的狀態(tài)。（b）由有狀態(tài)的運(yùn)算實(shí)現(xiàn)的相同場(chǎng)景。模擬器的狀態(tài)是內(nèi)部的，因此無(wú)需傳輸狀態(tài)數(shù)據(jù)。（c）不暴露狀態(tài)的封閉源模擬器。在這種情況下，我們別無(wú)選擇，只能將模擬器實(shí)現(xiàn)為有狀態(tài)運(yùn)算
序列化和反序列化的開(kāi)銷(xiāo)
在Ray中，任務(wù)輸入/輸出的讀/寫(xiě)性能被限制在8GB/s左右，比直接訪(fǎng)問(wèn)內(nèi)存低10倍。盡管數(shù)據(jù)存儲(chǔ)在同一臺(tái)機(jī)器上的共享內(nèi)存中，但我們使用Apache Arrow對(duì)數(shù)據(jù)格式進(jìn)行快速序列化和反序列化。圖3說(shuō)明了運(yùn)行模擬器的情況，這是強(qiáng)化學(xué)習(xí)應(yīng)用的一個(gè)常見(jiàn)工作負(fù)載。一個(gè)自然的解決方案是為每個(gè)模擬步驟運(yùn)行一個(gè)任務(wù)，如圖3(a)所示。在每個(gè)步驟中，任務(wù)將（1）使用當(dāng)前狀態(tài)初始化模擬器;（2）基于某些策略應(yīng)用某個(gè)動(dòng)作，以及（3）讀取模擬器的狀態(tài)（將在下一步使用），它可能是獎(jiǎng)勵(lì)。但是，這需要從外部存儲(chǔ)器讀取/寫(xiě)入模擬器的狀態(tài)，并承擔(dān)大量的序列化/反序列化的開(kāi)銷(xiāo)。假設(shè)模擬器狀態(tài)為80MB，外部存儲(chǔ)器的讀/寫(xiě)吞吐量為8MB/s，更新?tīng)顟B(tài)需要1毫秒。這意味著讀取狀態(tài)需要10毫秒，寫(xiě)回來(lái)需要10毫秒，比更新?tīng)顟B(tài)慢20倍！相反，如果我們使用一個(gè)在本地存儲(chǔ)狀態(tài)的有狀態(tài)運(yùn)算，則只需1毫秒就可執(zhí)行一步模擬（參見(jiàn)圖3(b)）。
缺乏對(duì)閉源模擬器的支持
如果模擬器是閉源的（例如星際爭(zhēng)霸2），我們甚至無(wú)法訪(fǎng)問(wèn)模擬器的完整狀態(tài)。 結(jié)果，我們被迫將模擬器視為黑盒子。在每一步，我們都做一個(gè)動(dòng)作，不是讀取模擬器的狀態(tài)，而是獲取模擬器內(nèi)部狀態(tài)的外部觀(guān)察。典型的觀(guān)察是每次動(dòng)作后屏幕的圖像。不幸的是，由于我們無(wú)法使用當(dāng)前狀態(tài)初始化模擬器，因此我們無(wú)法再將任務(wù)抽象用于模擬。在這種情況下，將模擬器包裝成有狀態(tài)運(yùn)算是唯一可行的解決方案。圖3(c)說(shuō)明了這種情況。
Ray的教訓(xùn)：在無(wú)服務(wù)器中找到缺失的鏈接
有狀態(tài)運(yùn)算
如上所述，雖然無(wú)狀態(tài)計(jì)算是優(yōu)雅且易于推理的，但即使數(shù)據(jù)和計(jì)算在同一臺(tái)機(jī)器上，它們也會(huì)產(chǎn)生很大的開(kāi)銷(xiāo)（例如，數(shù)據(jù)存儲(chǔ)在本地內(nèi)存中而計(jì)算運(yùn)行在GPU）。為了支持更廣泛的應(yīng)用，除了將數(shù)據(jù)和計(jì)算共同放置并添加對(duì)有狀態(tài)計(jì)算（例如行動(dòng)者）的支持外，我們看不到其他選擇。行動(dòng)者封裝了可變狀態(tài)，這使它們能夠避免在同一個(gè)行動(dòng)者上的連續(xù)操作之間進(jìn)行昂貴的狀態(tài)傳輸。
在Ray中，行動(dòng)者允許我們執(zhí)行有效的訓(xùn)練、交互式查詢(xún)處理以及支持專(zhuān)有模擬器。例如，在訓(xùn)練時(shí)，網(wǎng)絡(luò)權(quán)重和訓(xùn)練數(shù)據(jù)被封裝為行動(dòng)者的狀態(tài)。然后，一個(gè)輪次的訓(xùn)練就變成為在該行動(dòng)者上的方法調(diào)用。因此，新的訓(xùn)練輪次只需要重新初始化模型權(quán)重，這比讀/寫(xiě)和序列化/反序列化這些權(quán)重要經(jīng)濟(jì)得多。通過(guò)行動(dòng)者和任務(wù)抽象，Ray支持了更廣泛的應(yīng)用，其性能優(yōu)于當(dāng)前的無(wú)服務(wù)器平臺(tái)。
放置位置控制
如上所述，當(dāng)需要在云函數(shù)間共享大量數(shù)據(jù)時(shí)，缺少放置位置的控制可能導(dǎo)致性能降低幾個(gè)數(shù)量級(jí)。解決此問(wèn)題有兩種通用的方法：
- 底層API。在這種方法中，無(wú)服務(wù)器平臺(tái)可以提供靈活的底層機(jī)制，使開(kāi)發(fā)人員能夠在應(yīng)用級(jí)別實(shí)現(xiàn)所需的策略。這是Ray采用的方法，它為應(yīng)用提供了定義邏輯資源并將函數(shù)與這些資源相關(guān)聯(lián)的能力[5]。例如，這允許應(yīng)用通過(guò)指定相同的資源調(diào)度在同一節(jié)點(diǎn)上運(yùn)行兩個(gè)函數(shù)。這使我們能夠?qū)崿F(xiàn)能相當(dāng)于基于虛擬機(jī)的解決方案（例如，圖2的(b)）的高效的通信模式、高性能SGD和復(fù)雜應(yīng)用（例如AlphaGo）。
- 聲明式API。在這種方法中，無(wú)服務(wù)器平臺(tái)可以公開(kāi)一個(gè)API，讓?xiě)?yīng)用指定他們的首選項(xiàng)，例如TetriSched在[6]里提出的“n Choose k”模式。在此模式中，用戶(hù)可以指定作業(yè)可以使用n個(gè)等效資源中的任意k個(gè)。
結(jié)論和尚未解決的挑戰(zhàn)
總之，本博客認(rèn)為，要實(shí)現(xiàn)提供通用計(jì)算平臺(tái)以支持各種應(yīng)用的承諾，無(wú)服務(wù)器計(jì)算平臺(tái)需要有（1）有狀態(tài)計(jì)算和（2）控制函數(shù)放置位置以最小化數(shù)據(jù)傳輸?shù)哪芰?/strong>。其中每一個(gè)都可以將數(shù)據(jù)傳輸?shù)男阅芴岣咧辽?0倍，和/或?qū)鬏數(shù)臄?shù)據(jù)量減少10倍或更多。
作為證明，在Ray中，我們通過(guò)添加對(duì)這兩個(gè)特性的支持來(lái)擴(kuò)展原始任務(wù)（函數(shù)）抽象。 這些擴(kuò)展使Ray能夠支持對(duì)延遲和吞吐量敏感的應(yīng)用，包括流式計(jì)算、分布式訓(xùn)練和模擬。而這些應(yīng)用要單獨(dú)使用函數(shù)是不可能實(shí)現(xiàn)的。
展望未來(lái)，重新構(gòu)建現(xiàn)有的無(wú)服務(wù)器平臺(tái)以支持長(zhǎng)時(shí)運(yùn)行的有狀態(tài)計(jì)算和放置位置控制將是令人興奮的。在這種情況下，我們注意到在多租戶(hù)環(huán)境中Ray需要提供的兩個(gè)有挑戰(zhàn)的優(yōu)化：?jiǎn)喂?jié)點(diǎn)共享內(nèi)存和在啟動(dòng)函數(shù)之前主動(dòng)推送函數(shù)代碼。將函數(shù)推送到整個(gè)數(shù)據(jù)中心可能運(yùn)行該函數(shù)的每個(gè)節(jié)點(diǎn)可能是不可行的。在保持Ray提供的性能改進(jìn)的同時(shí)應(yīng)對(duì)這些挑戰(zhàn)是一個(gè)有趣的未來(lái)研究方向。
引用文獻(xiàn)
[1]https://dl.acm.org/citation.cfm?id=3154630.3154660
[2]https://arxiv.org/abs/1812.03651
[3]https://www.usenix.org/system/files/conference/hotcloud16/hotcloud16_hendrickson.pdf
[4]https://arxiv.org/abs/1902.03383
[5]https://rise.cs.berkeley.edu/blog/ray-scheduling/
[6]https://dl.acm.org/citation.cfm?id=2901355
[7]https://www.usenix.org/conference/atc18/presentation/wang-liang
