摘要：

人們對無服務(wù)器計算越來越感興趣么库，無服務(wù)器計算是一種云計算模型勇婴，可自動執(zhí)行基礎(chǔ)架構(gòu)資源分配和管理，同時僅根據(jù)客戶使用的資源向客戶收費(fèi)。

這些無服務(wù)器框架的高彈性和細(xì)粒度怜校，將帶來諸如流處理之類的工作量成翩。但是败去，到目前為止暴构，服務(wù)器CPU有限的并發(fā)性和高延遲阻止了許多交互式工作負(fù)載（例如，Web服務(wù)器和數(shù)據(jù)庫客戶端）利用無服務(wù)器計算來實現(xiàn)高性能置鼻。在

本文中镇饮，我們認(rèn)為服務(wù)器CPU不適合運(yùn)行無服務(wù)器工作負(fù)載（即lambda），并且提出了λ-NIC（一種開源框架）箕母，該框架直接在SmartNIC上運(yùn)行交互式工作負(fù)載;更具體地說储藐，是基于ASIC的NIC，它由網(wǎng)絡(luò)處理單元（NPU）內(nèi)核的密集網(wǎng)格組成司蔬。

λ-NIC利用SmartNIC靠近網(wǎng)絡(luò)和大量NPU內(nèi)核的方式，在具有嚴(yán)格尾延遲保證的情況下姨蝴，在單個NIC上同時運(yùn)行數(shù)千個lambda俊啼。為了簡化lambda的開發(fā)和部署，λ-NIC公開了基于事件的編程抽象左医，Match + Lambda和一種機(jī)器模型授帕，該模型允許開發(fā)人員在SmartNIC上輕松編寫和執(zhí)行l(wèi)ambda。我們的評估表明浮梢，λ-NIC分別在工作負(fù)載的響應(yīng)延遲和吞吐量方面分別提高了880倍和736倍跛十，同時顯著減少了主機(jī)CPU和內(nèi)存使用量。

背景/問題：

無服務(wù)器計算正在成為一種主動式云計算模型秕硝，該模型使開發(fā)人員僅專注于核心應(yīng)用程序即可將工作負(fù)載構(gòu)建為細(xì)粒度的自定義程序（即lambda）芥映，而不必?fù)?dān)心其運(yùn)行的基礎(chǔ)架構(gòu)。

云提供商針對這些工作負(fù)載動態(tài)地配置远豺，部署奈偏，修補(bǔ)和監(jiān)視基礎(chǔ)架構(gòu)及其資源（例如，計算躯护，存儲惊来，內(nèi)存和網(wǎng)絡(luò)）；租戶僅需支付以毫秒為單位消耗的資源棺滞。無服務(wù)器計算降低了進(jìn)入門檻裁蚁，尤其是對于缺乏專業(yè)知識矢渊，人力和預(yù)算來有效管理基礎(chǔ)架構(gòu)資源的組織而言。

如今枉证，所有主要的云供應(yīng)商都提供某種形式的無服務(wù)器框架矮男，例如Amazon Lambda，Google Cloud Functions和Microsoft Azure Functions刽严，以及像OpenFaaS 這樣的開源版本和OpenWhisk 昂灵。這些框架依賴于服務(wù)器虛擬化（即虛擬機(jī)（VM））和容器技術(shù)（即Docker）來執(zhí)行和擴(kuò)展租戶的工作負(fù)載。

但是舞萄，在無服務(wù)器計算中眨补，對租戶隱藏了服務(wù)器管理，這些虛擬化技術(shù)變得多余倒脓，不必要地消耗了無服務(wù)器工作負(fù)載的代碼大小撑螺，并導(dǎo)致處理延遲（數(shù)百毫秒）和內(nèi)存開銷（數(shù)十兆字節(jié)）。這些增加的開銷還限制了這些工作負(fù)載在單個服務(wù)器上的并發(fā)執(zhí)行（少于一百個左右）崎弃，因此甘晤，增加了在數(shù)據(jù)中心中運(yùn)行此類工作負(fù)載的總體成本。

云計算行業(yè)現(xiàn)在已經(jīng)意識到了這些問題饲做，一些提供商（例如Google和CloudFlare）已經(jīng)開始開發(fā)替代框架（例如Isolate [42]）线婚，以刪除這些技術(shù)層（例如容器）并直接在無服務(wù)器上運(yùn)行無服務(wù)器工作負(fù)載裸機(jī)服務(wù)器。

然而盆均，這些裸機(jī)替代品固有地受到基于CPU架構(gòu)的設(shè)計限制的限制塞弊，而在以云數(shù)據(jù)中心規(guī)模運(yùn)行時，這種限制會加劇泪姨。 CPU被設(shè)計為以極快的速度處理指令序列（即函數(shù)）游沿。它們并非旨在并行運(yùn)行數(shù)千個此類小型離散功能—典型的服務(wù)器CPU具有約4至28個內(nèi)核，最多可同時運(yùn)行56個線程肮砾。每個無服務(wù)器功能都會中斷CPU內(nèi)核以存儲當(dāng)前正在運(yùn)行的功能的狀態(tài)（例如诀黍，寄存器和內(nèi)存），并使用新的功能對其自身進(jìn)行加載仗处，從而導(dǎo)致每個上下文切換浪費(fèi)了數(shù)十毫秒的CPU周期（這種浪費(fèi)的周期增加了云提供商的總成本眯勾。

最近，公共云提供商正在盡力部署SmartNIC婆誓，以減少主機(jī)CPU上的負(fù)載咒精。
無服務(wù)器工作負(fù)載的設(shè)計規(guī)模很小，為SmartNIC提供了獨(dú)特的機(jī)會來加速它們旷档，同時還實現(xiàn)了嚴(yán)格的尾部延遲保證模叙。

但是，使用SmartNIC的主要缺點在于編程的復(fù)雜性鞋屈。對SmartNIC進(jìn)行編程是一項艱巨的任務(wù)范咨，需要對NIC的系統(tǒng)和資源體系結(jié)構(gòu)（例如故觅，內(nèi)存層次結(jié)構(gòu)，多核并行性和流水線方法）非常熟悉渠啊。開發(fā)人員需要仔細(xì)劃分输吏，調(diào)度和仲裁這些資源以最大化其應(yīng)用程序的性能，這是與無服務(wù)器計算背后的動機(jī)相反的特征（即替蛉，開發(fā)人員不了解底層基礎(chǔ)架構(gòu)的架構(gòu)細(xì)節(jié)）贯溅。此外，每個應(yīng)用程序都必須顯式處理數(shù)據(jù)包躲查，因為SmartNIC中沒有網(wǎng)絡(luò)堆棧的概念它浅。

解決辦法：

提出了λ-NIC，這是一個完全在SmartNIC上運(yùn)行交互式無服務(wù)器工作負(fù)載的框架镣煮。 λ-NIC支持新的編程抽象（Match + Lambda）和機(jī)器模型（是P4的matchaction抽象的擴(kuò)展姐霍，具有更復(fù)雜的動作），并有助于以多種關(guān)鍵方式解決SmartNIC的缺點典唇。

首先镊折，用戶提供自己的Lambda，由λ-NIC編譯介衔，然后在運(yùn)行時通過匹配傳入請求的數(shù)據(jù)包的報頭選擇執(zhí)行恨胚。

其次，用戶在假設(shè)內(nèi)存模型的情況下編程其lambda炎咖。 λ-NIC分析內(nèi)存訪問模式（即讀取赃泡，寫入或兩者兼有）和大小，并在NIC的不同內(nèi)存層次結(jié)構(gòu)之間最佳地映射這些lambda塘装，同時確保隔離內(nèi)存訪問急迂。

λ-NIC會推斷每個lambda使用哪些數(shù)據(jù)包頭影所，并自動為這些頭生成相應(yīng)的解析器蹦肴，從而無需在這些lambda中手動指定數(shù)據(jù)包處理邏輯。

第四猴娩，λ-NIC無需跨多個NPU劃分和調(diào)度單個Lambda阴幌，而是采用了運(yùn)行到完成（RTC）模型的方式，利用了Lambda很小且可以在單個NPU內(nèi)運(yùn)行的事實卷中。大量的NPU核心和lambda的短服務(wù)時間進(jìn)一步緩解了導(dǎo)致高尾部延遲的行頭阻塞和性能問題矛双。

最后，無服務(wù)器功能通常使用獨(dú)立的蟆豫，互斥的請求-響應(yīng)對進(jìn)行通信议忽，并且不需要TCP提供的嚴(yán)格的有序流傳輸語義。

因此十减，λ-NIC與RDMA一起使用了弱一致性的傳遞語義栈幸，用于無服務(wù)器工作負(fù)載之間的通信-直接在NIC核心內(nèi)處理請求愤估，而無需主機(jī)CPU。

實現(xiàn)細(xì)節(jié)：

圖1說明了當(dāng)今使用的四個不同的云計算框架速址。服務(wù)器虛擬化是云計算下最重要的技術(shù)玩焰，它允許裸機(jī)服務(wù)器托管多個VM，每個VM都有各自獨(dú)立的隔離環(huán)境芍锚，其中包含單獨(dú)的操作系統(tǒng)（OS）昔园，庫和應(yīng)用程序。正是在這種情況下并炮，硬件的發(fā)展使單個應(yīng)用程序難以有效地消耗整個裸機(jī)服務(wù)器資源默刚，而在單個服務(wù)器上同時存在多個應(yīng)用程序卻引發(fā)了各種問題（例如隔離和資源爭奪）。但是渣触，隨著趨勢從整體式發(fā)展為微服務(wù)構(gòu)建應(yīng)用程序[58]羡棵，以提高可管理性，彈性和可伸縮性嗅钻，不再需要為每個微服務(wù)使用單獨(dú)的操作系統(tǒng)而產(chǎn)生的開銷皂冰。

隨之而來的是容器虛擬化，這是在共享操作系統(tǒng)的同時隔離應(yīng)用程序的二進(jìn)制文件和庫的一種方法养篓。但是秃流，隨著云工作負(fù)載的復(fù)雜性和規(guī)模不斷增長，對于許多用戶而言柳弄，調(diào)配和管理基礎(chǔ)結(jié)構(gòu)資源的工作變得艱巨舶胀，而這些任務(wù)需要在不斷變化的工作負(fù)載需求下對資源進(jìn)行重新分配。

早期的解決方案主要是過度配置這些資源碧注，從而增加了閑置資源的成本嚣伐。最近，無服務(wù)器計算[59]成為一種有利的計算模型萍丐，它通過讓用戶僅指定工作負(fù)載轩端，其內(nèi)存和時序約束以及何時和哪些事件（例如，事件）來減輕用戶的此類操作和財務(wù)負(fù)擔(dān)逝变。 API調(diào)用基茵，數(shù)據(jù)庫更新，傳入數(shù)據(jù)流）來觸發(fā)它們壳影。作為響應(yīng)拱层，云提供商獨(dú)立配置基礎(chǔ)結(jié)構(gòu)資源，按需部署一組容器來滿足工作負(fù)載的請求宴咧。一旦工作負(fù)載完成根灯，這些容器將被快速拆除，并且僅在執(zhí)行容器時向用戶收費(fèi)。因此烙肺，無服務(wù)器工作負(fù)載的壽命很短芥驳，并且具有嚴(yán)格的計算時間和內(nèi)存限制（對于Amazon Lambda [14]，分別達(dá)到15分鐘和3 GB）茬高。

圖2描述了典型的無服務(wù)器計算框架兆旬。 工作量管理器將用戶的工作量編譯為可執(zhí)行的二進(jìn)制文件，并將其與數(shù)據(jù)的依賴關(guān)系一起存儲在全局存儲中（例如怎栽，Amazon S3 [7]丽猬，Google Cloud [31]或Microso‰Azure Storage [46]）。 網(wǎng)關(guān)將用戶的請求（或事件）代理到適當(dāng)?shù)墓ぷ髫?fù)載熏瞄，這些工作負(fù)載通常作為容器在一組稱為工作節(jié)點的動態(tài)配置的服務(wù)器上運(yùn)行脚祟。 完成后，結(jié)果將被寫回到存儲或轉(zhuǎn)發(fā)給其他工作負(fù)載以進(jìn)一步執(zhí)行强饮。

如今由桌，無服務(wù)器框架已在兩種類型的用例中成為應(yīng)用程序[13、29邮丰、96]：（1）運(yùn)行服務(wù)于交互式應(yīng)用程序的API后端行您，例如返回靜態(tài)或動態(tài)內(nèi)容或基于用戶請求的鍵值響應(yīng)。 （2）實時處理數(shù)據(jù)存儲中的更改剪廉，例如裁剪新上傳的圖像或?qū)π绿砑拥臄?shù)據(jù)庫條目運(yùn)行自定義操作娃循。 lambda函數(shù)的復(fù)雜性從運(yùn)行簡單的算術(shù)運(yùn)算到做出通常是短暫的機(jī)器學(xué)習(xí)決策不等。裸機(jī)服務(wù)器可以容納數(shù)千個此類lambda函數(shù)斗蒋。

但是捌斧，這樣做會導(dǎo)致CPU不斷在這些功能之間進(jìn)行上下文切換。這些以及其他通信開銷使服務(wù)（使用Lambda函數(shù)）難以滿足其尾延遲服務(wù)級別目標(biāo)（SLO）[42]泉沾。為了減輕這些問題捞蚂，正在努力將計算移至SmartNIC。

這些SmartNIC分為三種不同類型：基于FPGA跷究，ASIC和SoC [56]姓迅。表1總結(jié)了主要區(qū)別。

λ-NIC背后的主要動機(jī)是通過以下方法來加速無服務(wù)器的交互式工作負(fù)載：（1）減輕過多的計算和網(wǎng)絡(luò)虛擬化開銷以及現(xiàn)代服務(wù)器體系結(jié)構(gòu)的不足揭朝，以實現(xiàn)低和有限的lambda功能尾部延遲队贱；以及（2） 利用正確的特定領(lǐng)域的架構(gòu)色冀，（即潭袱，基于ASIC的SmartNIC）來維持高吞吐量，同時減少云數(shù)據(jù)中心的CPU負(fù)載和每單位成本锋恬。

λ-NIC：

在λ-NIC中屯换，用戶以一種受限的類似于C的語言（稱為Micro-C [27]）提供一個或多個lambda。清單1顯示了頂層函數(shù)的簽名，每個lambda必須以該簽名開頭彤悔， 具有兩個參數(shù)：標(biāo)頭和match_data嘉抓。 λ-NIC中所有支持的標(biāo)頭的編號和結(jié)構(gòu)（即EXTRACTED_HEADERS_T數(shù)據(jù)結(jié)構(gòu)）和功能參數(shù)（即MATCH_DATA_T）均按先驗定義。 lambda直接在這些參數(shù)和標(biāo)頭上操作晕窑，而不必解析數(shù)據(jù)包抑片，這是在解析階段完成的（圖3）。 此外杨赤，這些函數(shù)可以同時具有局部對象和全局對象敞斋，這些對象可以在運(yùn)行之間保持狀態(tài)不變。

清單2顯示了作為Web服務(wù)器運(yùn)行的lambda的真實示例疾牲。該函數(shù)從headers變量中讀取服務(wù)器地址（第6行）植捎。然后，它將請求的Web內(nèi)容從內(nèi)存中復(fù)制到服務(wù)器地址所指向的標(biāo)頭位置（第8行）阳柔，然后再返回焰枢。

在λ-NIC中，用戶將其Match + Lambda工作負(fù)載針對抽象的機(jī)器模型編寫（圖3）谴忧。在此模型中：（1）Lambda是獨(dú)立的程序很泊，它們不共享狀態(tài)并且彼此隔離；只有匹配的規(guī)則才能調(diào)用這些功能沾谓。 （2）匹配階段用作調(diào)度程序（類似于OS網(wǎng)絡(luò)堆棧）委造，用于將數(shù)據(jù)包轉(zhuǎn)發(fā)到匹配的lambda或主機(jī)OS。最后均驶，（3）解析器處理數(shù)據(jù)包操作（如標(biāo)頭識別）昏兆，而lambda直接在解析的標(biāo)頭上進(jìn)行操作。 Match + Lambda機(jī)器模型的這些特性使軟件開發(fā)人員更容易通過分離解析和匹配邏輯來表達(dá)無服務(wù)器功能妇穴，并且使硬件設(shè)計人員能夠在其目標(biāo)SmartNIC上有效地支持該模型（第5節(jié)）演示了一種使用Netronome SmartNIC的實現(xiàn)爬虱。因此，抽象機(jī)器模型實現(xiàn)了獨(dú)特的優(yōu)化腾它，使無服務(wù)器工作負(fù)載可以作為lambda并行運(yùn)行跑筝，而不會互相干擾。

在本節(jié)中瞒滴，我們介紹在啟用P4的Netronome SmartNIC上的λ-NIC的實現(xiàn)（圖4）曲梗。這些NIC包含數(shù)百個RISC核心赞警，這些核心被分組到各個island中。每個內(nèi)核都有自己的指令和本地內(nèi)存虏两，以及每個island都有一個群集目標(biāo)內(nèi)存（CTM）[27]愧旦，并且能夠同時執(zhí)行多個線程。信號也是所有island及其內(nèi)核之間共享的片上內(nèi)部存儲器（IMEM）和外部存儲器（EMEM）定罢；專用調(diào)度器單元將傳入的數(shù)據(jù)包定向到核心笤虫。因此，Netronome SmartNIC的體系結(jié)構(gòu)具有必要的元素祖凫，可以有效地實現(xiàn)λ-NIC的Match + Lambda抽象機(jī)模型：內(nèi)核可以執(zhí)行l(wèi)ambda來完成（D1）耕皮，數(shù)據(jù)可以駐留在不同的內(nèi)存中（例如，本地蝙场，CTM （或更多）基于它們的使用方式（D2）凌停，并且調(diào)度程序可以將RPC定向到lambda（D3）。更具可編程性的調(diào)度器（例如售滤，基于RMT / PIFO的[37罚拟，94]）可以直接執(zhí)行機(jī)器模型的解析和匹配階段，而內(nèi)核僅處理lambda邏輯完箩。但是赐俗，我們用于評估的Netronome NIC內(nèi)的調(diào)度程序是不可編程的。它節(jié)省了工作弊知，并且將傳入的trac均勻地分布到所有核心阻逮。因此，我們在一個內(nèi)核中一起執(zhí)行所有三個階段（解析秩彤，匹配和lambda）叔扼，每個內(nèi)核運(yùn)行相同的Match + Lambda程序。4,5對于單數(shù)據(jù)包消息漫雷，調(diào)度程序?qū)魅氲臄?shù)據(jù)包隨機(jī)定向到一個內(nèi)核瓜富，該解析器使用數(shù)據(jù)包中嵌入的ID來選擇匹配的lambda。多數(shù)據(jù)包消息通過RDMA傳輸?shù)絻?nèi)存降盹，lambda從所需位置直接讀取与柑。

其他：