Cloud Programming Simplifie : A Berkeley View on Serverless Computing
Abstract
??? 無服務器云計算幾乎處理所有系統管理操作，使程序員更容易使用云。 它提供了一個極大簡化云編程的接口，代表了從匯編語言到高級編程語言的過渡。 本文簡要介紹了云計算的歷史，包括對2009年伯克利云計算視圖的預測進行了說明，解釋了無服務器計算的動機，描述了擴展無服務器當前限制的應用程序，然后列出了障礙和研究機會 無服務器計算需要充分發揮其潛力。 就像2009年的論文確定了云的挑戰并預測它們將得到解決以及云的使用會加速一樣，我們預測這些問題是可以解決的，無服務器計算將成為云計算未來的主導。
1. Introduction to Serverless Computing
2009年，為了幫助解釋圍繞云計算的興奮，“伯克利云計算視圖”[2]確定了六個潛在優勢：
1.按需提供無限計算資源。
2.消除云用戶的前期承諾。
3.根據需要在短期內支付使用計算資源的能力。
4.由于許多非常大的數據中心，大規模降低成本的規模經濟。
5.通過資源虛擬化簡化操作并提高利用率。
6.通過復用來自不同組織的工作負載來提高硬件利用率。
?????? 在過去的十年中，這些優勢已經基本實現，但云用戶繼續承擔復雜運營的負擔，許多工作負載仍然無法從高效的多路復用中受益。 這些不足主要與未能實現最后兩個潛在優勢相對應。 云計算減輕了物理基礎設施管理的用戶，但卻為他們提供了大量的虛擬資源來管理。 多路復用適用于批處理工作負載，例如MapReduce或高性能計算，可以充分利用他們分配的實例。 它對于有狀態服務的效果較差，例如將數據庫管理系統等企業軟件移植到云中時。
?????? 2009年，云中存在兩種相互競爭的虛擬化方法。 作為論文解釋：
?????? 亞馬遜EC2處于頻譜的一端。 EC2實例看起來很像物理硬件，用戶可以從內核向上控制幾乎整個軟件堆棧。 …...另一個極端的應用領域特定平臺，例如Google App Engine …...強制實施無狀態計算層和有狀態存儲層之間清晰分離的應用程序結構。 App Engine令人印象深刻的自動擴展和高可用性機制…...依賴于這些限制。
?????? 市場最終采用了亞馬遜的低級虛擬機云計算方法，因此谷歌，微軟和其他云計算公司提供了類似的界面。 我們認為，低級虛擬機成功的主要原因是，在云計算的早期階段，用戶希望在云中重建與他們在本地計算機上相同的計算環境，以簡化將工作負載移植到 云[3-6]。 理所當然地，這種實際需求優先于僅為云編寫新程序，特別是因為不清楚云的成功程度。
?????? 這種選擇的缺點是開發人員必須自己管理虛擬機，基本上要么成為系統管理員，要么與他們一起設置環境。 表1列出了在云中運行環境必須管理的問題。 長期的低級虛擬機管理職責列表激發了客戶使用更簡單的應用程序，以便為新應用程序提供更輕松的云路徑。 例如，假設應用程序想要將鏡像從電話應用程序發送到云，這應該創建縮略圖鏡像然后將它們放在Web上。 完成這些任務的代碼可能是幾十行JavaScript，與使用適當的環境來運行代碼來設置服務器相比，這將是一個微不足道的開發。
?????? 對這些需求的認識導致2015年亞馬遜推出了一項名為AWS Lambda服務的新選項。 Lambda提供了云功能，并引起了對無服務器計算的廣泛關注。雖然無服務器計算可以說是一種矛盾 - 你仍然在使用服務器進行計算 - 這個名稱可能會被卡住，因為它表明云用戶只需編寫代碼并將所有服務器配置和管理任務留給云提供商。雖然云功能 - 打包為FaaS（功能即服務）產品? - 代表無服務器計算的核心，但云平臺還提供專門的無服務器框架，滿足特定的應用需求，如BaaS（后端即服務）產品[7]。簡而言之，無服務器計算= FaaS + BaaS.3在我們的定義中，對于服務被視為無服務器，它必須自動擴展而無需顯式配置，并根據使用情況進行計費。在本文的其余部分，我們將重點關注云功能的出現，發展和未來。云功能是當今無服務器計算中的通用元素，并引領著云的簡化和通用編程模型。
?????? 接下來，我們將激勵并定義無服務器計算。 與最初的關于云計算的Berkeley View論文一樣，我們列出了無服務器計算需要解決的挑戰和研究機會，以實現其承諾。 雖然我們不確定哪些解決方案會贏，但我們相信所有問題都將最終得到解決，從而使無服務器計算成為云計算的代表。
2. Emergence of Serverless Computing
?????? 在任何無服務器平臺中，用戶只需用高級語言編寫云功能，選擇應觸發功能運行的事件 - 例如將圖像加載到云存儲中或將圖像縮略圖添加到數據庫表中 -? 讓無服務器系統處理其他所有事情：實例選擇，擴展，部署，容錯，監視，日志記錄，安全補丁等。 表2總結了無服務器和傳統方法之間的區別，我們在本文中稱之為服務器云計算。 請注意，這兩種方法代表了基于函數/服務器中心的計算平臺的連續體的端點，其中集成化的編排框架如Kubernetes代表了中間體。
?????? 圖1說明了無服務器如何通過使云資源更易于使用來簡化應用程序開發。在云環境中，服務器計算就像用低級匯編語言編程，而無服務器計算就像用Python等高級語言編程。計算簡單表達式（如c = a + b）的匯編語言程序員必須選擇一個或多個要使用的寄存器，將值加載到這些寄存器中，執行算術運算，然后存儲結果。這反映了服務器云編程的幾個步驟，其中首先提供資源或識別可用的資源，然后使用必要的代碼和數據加載這些資源，執行計算，返回或存儲結果，并最終管理資源釋放。無服務器計算的目標和機會是為云程序員提供類似于向高級編程語言過渡的優勢.高級編程環境的其他功能在無服務器計算中也有自然的相似之處。自動內存管理減輕了程序員管理內存資源的負擔，而無服務器計算使程序員無法管理服務器資源。
準確地說，無服務器和服務器計算之間存在三個關鍵區別：
1.解耦計算和存儲。 存儲和計算分別單獨提供和定價。 通常，存儲由單獨的云服務提供，并且計算是無狀態的。
2.在不管理資源分配的情況下執行代碼。 用戶不是請求資源，而是提供一段代碼，云自動提供資源來執行該代碼。
3.按比例使用的資源支付，而不是分配資源。 計費是與執行相關聯的某些維度，例如執行時間，而不是基礎云平臺的維度，例如分配的VM的大小和數量。
2.1 Contextualizing Serverless Computing
?????? 需要哪些技術突破才能實現無服務器計算？有人認為無服務器計算僅僅是對先前產品的重新定義，可能是平臺即服務（PaaS）云產品（如Heroku [8]，Firebase [9]或Parse [10]）的適度概括。其他人可能會指出，20世紀90年代流行的共享Web托管環境提供了無服務器計算所提供的大部分內容。例如，它們有一個無狀態編程模型，允許高水平的多租戶，對可變需求的彈性響應，以及標準化的函數調用API，即公共網關接口（CGI）[11]，它甚至允許直接部署寫入的源代碼在Perl或PHP等高級語言中。谷歌的原始App Engine在無服務器計算普及之前幾年被市場拒絕，也允許開發人員部署代碼，同時將大多數操作方面留給云提供商。我們相信無服務器計算代表了PaaS和其他先前型號的重大創新。
?????? 今天，具有云功能的無服務器計算與其前代產品的不同之處在于幾個基本方面：更好的自動擴展，強大的隔離，平臺靈活性和服務生態系統支持。 在這些因素中，AWS Lambda提供的自動縮放標記與以前的標記有明顯的不同。 它以比服務器自動縮放技術更高的保真度跟蹤負載，在需要時快速響應擴展，并在沒有需求的情況下一直縮減到零資源和零成本。 它以更細粒度的方式收費，在按小時計費的其他自動調節服務時提供100毫秒的最小計費增量.8在關鍵的離開時，它向客戶收取其代碼實際執行時間的費用， 不是為執行他們的程序保留的資源。 這種區別確保云提供商在自動縮放中具有“游戲中的皮膚”，從而提供了確保有效資源分配的激勵。
?????? 無服務器計算依賴于強大的性能和安全隔離，使多租戶硬件共享成為可能。類似VM的隔離是云功能多租戶硬件共享的當前標準[12]，但由于VM配置可能需要很長時間，因此無服務器計算提供商使用復雜的技術來加速功能執行環境的創建。 AWS Lambda中反映的一種方法是維護僅需要分配給租戶的VM實例的“熱池”，以及之前用于運行功能并維護以服務于未來的實例的“活動池”調用[13]。實現高利用率所必需的資源生命周期管理和多租戶倉包裝是無服務器計算的關鍵技術推動者。我們注意到，最近的一些提案旨在通過利用容器，unikernel，庫操作系統或語言VM來減少提供多租戶隔離的開銷。例如，Google宣布gVisor [14]已被App Engine，Cloud Functions和Cloud ML Engine采用，亞馬遜發布了用于AWS Lambda和AWS Fargate的Firecracker VM [15]，而CloudFlare Workers無服務器平臺提供了多個使用Web瀏覽器沙盒技術在JavaScript云功能之間進行租戶隔離[16]。
?????? 其他一些區別幫助無服務器計算成功。 通過允許用戶使用自己的庫，無服務器計算可以支持比與特定用例緊密相關的PaaS服務更廣泛的應用程序。 無服務器計算在現代數據中心中運行，并且比舊的共享Web托管環境以更大的規模運行。 如第1節所述，云功能（即FaaS）推廣了無服務器范例。
?????? 但是，值得承認的是，他們的成功部分歸功于自公共云開始以來存在的BaaS產品，如AWS S3等服務。 在我們看來，這些服務是特定于域的，高度優化的無服務器計算實現。 云功能以更一般的形式表示無服務器計算。 我們通過比較幾種服務的編程接口和成本模型，總結了表3中的這一觀點
?????? 用于部署微服務的“容器編排”技術。與無服務器計算不同，Kubernetes是一種簡化服務器計算管理的技術。源于谷歌內部使用多年的發展[18]，它正在迅速普及。 Kubernetes可以提供短期計算環境，例如無服務器計算，并且具有很少的限制，例如，關于硬件資源，執行時間和網絡通信。它還可以完全在公共云上部署最初為內部部署使用而開發的軟件，幾乎不做任何修改。另一方面，無服務器計算引入了一種范式轉換，允許將操作職責完全卸載到提供者，并使細粒度多租戶多路復用成為可能。托管的Kubernetes產品，例如Google Kubernetes Engine（GKE）和AWS Elastic Kubernetes Service（EKS）在這個連續體中提供了一個中間立場：它們卸載了Kubernetes的運營管理，同時為開發人員提供了配置任意容器的靈活性。托管Kubernetes服務和無服務器計算之間的一個關鍵區別是計費模型。前者按預留資源收費，而后者按功能執行持續時間收費。
?????? Kubernetes也是混合應用程序的完美搭檔，其中一部分在本地硬件上運行，一部分在云中運行。我們的觀點是，這種混合應用程序在向云的過渡中是有意義的。然而，從長遠來看，我們相信云規模經濟，更快的網絡帶寬，不斷增長的云服務以及通過無服務器計算簡化云管理將降低此類混合應用的重要性。邊緣計算是PostPC時代云計算的合作伙伴，雖然我們關注的是無服務器計算將如何改變數據中心內的編程，但也有可能在邊緣產生影響。多個內容分發網絡（CDN）運營商提供了在靠近用戶[19,20]的設施中執行無服務器功能的能力，無論他們在哪里，AWS IoT Greengrass [21]甚至可以在邊緣設備中嵌入無服務器執行。現在我們已經定義了無服務器計算和上下文化，讓我們看看為什么它對云提供商，云用戶和研究人員具有吸引力。
2.2 Attractiveness of Serverless Computing
?????? 對于云提供商而言，無服務器計算可促進業務增長，因為使云更容易編程有助于吸引新客戶并幫助現有客戶更多地使用云產品。 例如，最近的調查發現，大約24％的無服務器用戶不熟悉云計算[22]，30％的現有服務器云客戶也使用無服務器計算[23]。 此外，短時間，小內存占用和無狀態特性通過使云提供商更容易找到運行這些任務的未使用資源來改善統計復用。 云提供商也可以使用不那么受歡迎的計算機 - 因為實例類型取決于云提供商 - 例如舊服務器，這些服務器可能對服務器云客戶的吸引力較小。 這兩項福利都會增加現有資源的收入。
?????? 客戶受益于提高的編程生產力，并且在許多情況下也可以節省成本，這是底層服務器利用率更高的結果。 即使無服務器計算讓客戶更有效率，Jevons悖論[24]表明他們將增加對云的使用，而不是削減，因為更高的效率將增加用戶的需求。
?????? 無服務器還提高了x86機器代碼的云部署水平--99％的云計算機使用x86指令集 - 高級編程語言，9支持架構創新。 如果ARM或RISC-V提供比x86更好的性價比，則無服務器計算可以更輕松地更改指令集。 云提供商甚至可以接受語言定位優化和特定領域架構的研究，這些架構專門用于加速用Python等語言編寫的程序[25]（參見第4節）。
?????? 云用戶喜歡無服務器計算，因為新手可以在不了解云基礎架構的情況下部署功能，因為專家可以節省開發時間并專注于應用程序獨有的問題。 無服務器用戶可以節省資金，因為只有在事件發生時才執行功能，細粒度會計（現在通常為100毫秒）意味著他們只為他們使用的東西而不是他們保留的東西付費。 表4顯示了當今無服務器計算的最流行用途。
?????? 研究人員已經被無服務器計算，尤其是云計算功能所吸引，因為它是一種新的通用計算抽象，有望成為云計算的未來，并且因為有很多機會可以提升當前性能并克服當前的局限性。
3. Limitations of Today’s Serverless Computing Platforms Serverless
?????? 無服務器云功能已成功用于多類工作負載，包括API服務，事件流處理和有限的ETL（參見表3）。 為了了解哪些障礙阻礙了支持更多的一般工作負載，我們嘗試創建我們感興趣的無服務器版本的應用程序，并研究其他人發布的示例。 這些無意代表當前無服務器計算生態系統之外的其他信息技術; 它們只是為了發現可能阻止許多其他有趣應用程序的無服務器版本的常見弱點而選擇的示例。
?????? 在本節中，我們概述了五個研究項目，并討論了阻礙現有無服務器計算平臺實現最先進性能的障礙，即為相同工作負載匹配服務器云的性能。 我們特別關注利用通用云計算功能進行計算的方法，而不是過分依賴其他特定于應用程序的無服務器產品（BaaS）。 然而，在我們的最后一個例子，無服務器SQLite中，我們確定了一個用于映射如此糟糕的FaaS的用例，我們得出的結論是數據庫和其他狀態繁重的應用程序將保留為BaaS。 本文末尾的附錄詳細介紹了每個應用程序。
?????? 有趣的是，即使這種折衷的應用程序組合也暴露了類似的弱點，我們在描述應用程序后列出了這些弱點。 表5總結了五種應用。
ExCamera：實時視頻編碼。 ExCamera [26]旨在為用戶上傳視頻到YouTube等網站提供實時編碼服務。 根據視頻的大小，今天的編碼解決方案可能需要幾十分鐘甚至幾小時。 為了實時執行編碼，ExCamera并行化編碼的“慢”部分，并連續執行“快速”部分。 ExCamera公開了視頻編碼器和解碼器的內部狀態，允許使用純函數語義執行編碼和解碼任務。 特別地，每個任務將內部狀態與視頻幀一起作為輸入，并將修改的內部狀態作為輸出發出。
MapReduce： MapReduce，Hadoop和Spark等分析框架傳統上部署在托管集群上。 雖然其中一些分析工作負載現在轉向無服務器計算，但這些工作負載主要由僅映射作業組成。 自然的下一步是支持完全成熟的MapReduce工作。 這項工作背后的驅動力之一是利用無服務器計算的靈活性來有效地支持資源需求在執行期間顯著變化的作業。
Cirrus：機器學習培訓。 機器學習（ML）研究人員傳統上使用VM群集來處理ML工作流程中的不同任務，例如預處理，模型訓練和超參數調整。 這種方法的一個挑戰是該管道的不同階段可能需要顯著不同的資源量。 與線性代數算法一樣，固定的簇大小將導致嚴重的未充分利用或嚴重的減速。 無服務器計算可以通過擴展每個階段來滿足其資源需求來應對這一挑戰。 此外，它使開發人員免于管理集群。
Serverless SQLite：數據庫。各種自動調節數據庫服務已經存在[28-33]，但為了更好地理解無服務器計算的局限性，了解是什么使數據庫工作負載實施起來特別具有挑戰性非常重要。在這種情況下，我們考慮第三方是否可以使用云功能（通用無服務器計算構建模塊）直接實現無服務器數據庫。一個簡單的解決方案是在云功能中運行常見的事務數據庫，例如PostgreSQL，Oracle或MySQL。然而，這立即遇到了許多挑戰。首先，無服務器計算沒有內置的持久存儲，因此我們需要利用一些遠程持久存儲，這會帶來大的延遲。其次，這些數據庫假定面向連接的協議，例如，數據庫作為接受來自客戶端的連接的服務器運行。此假設與在網絡地址轉換器后面運行的現有云功能沖突，因此不支持傳入連接。最后，雖然許多高性能數據庫依賴于共享內存[34]，但云功能是孤立運行的，因此無法共享內存。雖然無共享分布式數據庫[35-37]不需要共享內存，但它們希望節點保持在線并可直接尋址。所有這些問題都對在無服務器計算上運行傳統數據庫軟件或實現等效功能提出了重大挑戰，因此我們希望數據庫保持為BaaS。
這些應用程序希望使用無服務器計算的關鍵原因之一是細粒度自動縮放，因此資源利用率與每個應用程序的不同需求密切匹配。 表5總結了這五個應用程序的特性，挑戰和變通方法，我們接下來用它來確定當前無服務器計算狀態的四個限制。
3.1 Inadequate storage for fine-grained operations
?????? 無服務器平臺的無狀態特性使得難以支持具有細粒度狀態共享需求的應用程序。這主要是由于云提供商提供的現有存儲服務的限制。表6總結了現有云存儲服務的屬性。
?????? 對象存儲服務（如AWS S3，Azure Blob存儲和Google云存儲）具有高度可擴展性，可提供廉價的長期對象存儲，但具有較高的訪問成本和較高的訪問延遲。根據最近的測試，所有這些服務至少需要10毫秒才能讀取或寫入小物體[38]。關于IOPS，在最近的限制增加[39]之后，S3提供了高吞吐量，但它帶來了高成本。維持100K IOPS的成本為30美元/分鐘[40]，比運行AWS ElastiCache實例多出3到4個數量級[41]。這樣的Elasti-Cache實例在多個軸上提供了更好的性能，具有亞毫秒讀寫延遲，并且一個實例配置為運行單線程Redis服務器，IOPS超過100K。
?????? 鍵值數據庫，例如AWS DynamoDB，Google Cloud Datastore或Azure Cosmos DB提供高IOPS，但價格昂貴且可能需要很長時間才能擴展.最后，雖然云提供商提供基于流行的內存存儲實例像Memcached或Redis這樣的開源項目，它們不具有容錯能力，并且不像無服務器計算平臺那樣自動縮放。
?????? 從表5中可以看出，構建在無服務器基礎架構上的應用程序需要具有透明配置的存儲服務，該存儲等效于計算機自動擴展。不同的應用程序可能會激發對持久性和可用性的不同保證，也可能是延遲或其他性能測量。我們認為這需要開發短暫且持久的無服務器存儲選項，我們將在第4節進一步討論。
3.2 Lack of fine-grained coordination
?????? 為了擴展對有狀態應用程序的支持，無服務器框架需要為任務提供協調的方法。 例如，如果任務A使用任務B的輸出，則必須有一種方法讓A知道其輸入何時可用，即使A和B駐留在不同的節點上也是如此。 許多旨在確保數據一致性的協議也需要類似的協調。
?????? 現有的云存儲服務都沒有通知功能。 雖然云提供商確實提供獨立的通知服務，例如SNS [42]和SQS [43]，但這些服務會增加顯著的延遲，有時會增加數百毫秒。 而且，當用于細粒度協調時，它們可能是昂貴的。 已經有一些擬議的研究系統如Pocket [44]沒有很多這些缺點，但它們尚未被云提供商采用。
?????? 因此，應用程序別無選擇，只能（1）管理提供通知的基于VM的系統，如ElastiCache和SAND [45]，或者（2）實現自己的通知機制，例如ExCamera [26] ]，使云功能能夠通過長時間運行的基于VM的集合點服務器相互通信。 此限制還表明，無服務器計算的新變體可能值得探索，例如命名函數實例并允許直接尋址以訪問其內部狀態（例如，Actors as a Service [46]）。
3.3 Poor performance for standard communication patterns
Broadcast，aggregation和 shuffle是分布式系統中最常見的通信原語。 這些操作通常用于機器學習培訓和大數據分析等應用程序。 圖2顯示了基于VM和基于功能的解決方案的這些原語的通信模式。
?????? 使用基于VM的解決方案，在同一實例上運行的所有任務可以共享正在廣播的數據的副本，或者在將部分結果發送到其他實例之前執行本地聚合。因此，廣播和聚合操作的通信復雜性是O（N），其中N是系統中VM實例的數量。但是，對于云功能，此復雜性為O（N×K），其中K是每個VM的功能數。洗牌操作的差異更為顯著。使用基于VM的解決方案，所有本地任務都可以組合其數據，以便兩個VM實例之間只有一條消息。假設相同數量的發送者和接收者產生N消息。為了比較，使用云功能我們需要發送（N×K）條消息。由于現有功能的核心數量遠少于VM，因此K的范圍通常為10到100.由于應用程序無法控制云功能的位置，因此無服務器計算應用程序可能需要發送兩個和四個數量級的數據而不是基于VM的等效解決方案。
3.4 Predictable Performance
?????? 盡管云功能的啟動延遲比傳統的基于VM的實例低得多，但啟動新實例時產生的延遲對于某些應用程序來說可能很高。 影響此冷啟動延遲的因素有三個：（1）啟動云功能所需的時間; （2）初始化函數的軟件環境所花費的時間，例如，加載Python庫; （3）用戶代碼中特定于應用程序的初始化。 后兩者可以使前者相形見絀。 雖然啟動云功能可能不到一秒鐘，但加載所有應用程序庫可能需要幾十秒。
?????? 可預測性能的另一個障礙是硬件資源的可變性，這是由于云提供商可以靈活地選擇底層服務器。 在我們的實驗[47]中，我們有時會收到來自不同硬件代的CPU。 這種不確定性暴露了云提供商希望最大限度地利用其資源和可預測性之間的基本權衡。
4. What Serverless Computing Should Become
現在我們已經解釋了今天的無服務器計算及其局限性，讓我們展望未來，了解如何將其優勢帶給更多應用程序。 研究人員已經開始解決上面提出的問題，并探討如何改進無服務器平臺以及在其上運行的工作負載的性能[48,49]。 我們的伯克利同事和我們中的一些人所做的額外工作強調以數據為中心的分布式系統，機器學習以及編程模型的挑戰和無服務器計算的機會[50]。 在這里，我們廣泛地考慮增加適用于無服務器計算的應用程序和硬件類型，確定五個領域的研究挑戰：抽象，系統，網絡，安全性和架構。
4.1 Abstraction challenges
Resource Requirement：通過今天的無服務器產品，開發人員可以指定云功能的內存大小和執行時間限制，而不是其他資源需求。 這種抽象阻礙了那些想要更多控制指定資源的人，例如CPU，GPU或其他類型的加速器。 一種方法是使開發人員能夠明確指定這些資源需求。 但是，這會使云提供商更難通過統計復用實現高利用率，因為它會對功能調度施加更多限制。 通過增加云應用程序開發人員的管理開銷，它也違背了無服務器的精神。
?????? 更好的選擇是提高抽象級別，讓云提供者推斷資源需求，而不是讓開發人員指定它們。 為此，云提供商可以使用各種方法，從靜態代碼分析，分析以前的運行，到動態（重新）編譯，以將代碼重新定位到其他體系結構。 自動配置適當數量的內存特別有吸引力，但當解決方案必須與高級語言運行時使用的自動垃圾收集進行交互時尤其具有挑戰性。 一些研究表明，這些語言運行時可以與無服務器平臺集成[51]。
Data dependencies：今天的云功能平臺不了解云功能之間的數據依賴性，更不用說這些功能可能交換的數據量。 這種無知可能會導致次優放置，從而導致通信模式效率低下，如MapReduce和numpywren示例所示（參見第3節和附錄）。
?????? 解決這一挑戰的一種方法是讓云提供商公開API，允許應用程序指定其計算圖，從而實現更好的布局決策，從而最大限度地減少通信并提高性能。 我們注意到許多通用分布式框架（例如，MapReduce，Apache Spark和Apache Beam / Cloud Dataflow [52]），并行SQL引擎（例如，BigQuery，Azure Cosmos DB）以及編排框架（例如，Apache Airflow [ 53]）已經在內部生成這樣的計算圖。 原則上，可以修改這些系統以在云功能上運行并將其計算圖暴露給云提供商。 請注意，AWS Step Functions通過提供狀態機語言和API來表示此方向的進展。
4.2 System challenges
高性能，經濟實惠，透明配置的存儲：如第3節和表5所述，我們看到了兩個不同的無需解決的存儲需求：無服務器短暫存儲和無服務器持久存儲。
?????? Ephemeral Storage。 第3節中的前四個應用程序受限于用于在云功能之間傳輸狀態的存儲系統的速度和延遲。 雖然它們的容量需求各不相同，但在應用程序生命周期內，所有這些都需要這樣的存 應用程序完成后，可以丟棄狀態。 這種短暫存儲也可以配置為其他應用程序中的緩存。
?????? 為無服務器應用程序提供短暫存儲的一種方法是使用優化的網絡堆棧構建分布式內存服務，以確保微秒級延遲。 該系統將使應用程序的功能能夠在應用程序的生命周期內有效地存儲和交換狀態。 這種內存服務需要根據應用程序的需求自動擴展存儲容量和IOPS。 這種服務的一個獨特方面是它不僅需要透明地分配內存，還要透明地釋放內存。 特別是，當應用程序終止或失敗時，應自動釋放分配給該應用程序的存儲。 此管理類似于操作系統在進程完成（或崩潰）時自動釋放進程分配的資源。 此外，此類存儲必須跨應用程序提供訪問保護和性能隔離。
?????? RAMCloud [54]和FaRM [55]表明，可以構建內存存儲系統，可以提供微秒級別的延遲，并支持每個實例數十萬IOPS。 他們通過仔細優化整個軟件堆棧并利用RDMA來最小化延遲來實現這一性能。 但是，它們要求應用程序明確配置存儲。 它們也不能在多個租戶之間提供強大的隔離。 最近的另一項努力，Pocket [44]，旨在提供短暫存儲的抽象，但也缺乏自動縮放，要求應用程序先驗地分配存儲。
?????? 通過利用統計復用，這種短暫的存儲可以比現在的服務器計算更具內存效率。 通過服務器計算，如果應用程序需要的內存少于分配的VM實例的聚合內存，那么該內存就會浪費掉。 相反，對于共享的內存服務，一個無服務器應用程序未使用的任何內存都可以分配給另一個。 事實上，統計多路復用甚至可以使單個應用程序受益：使用服務器計算，VM的未使用內存不能被屬于同一應用程序的另一個VM上運行的程序使用，而在共享內存服務的情況下， 能夠。 當然，即使使用無服務器計算，如果云功能不使用其整個本地內存，也可能存在內部碎片。 在某些情況下，將云功能的應用程序狀態存儲在共享的內存服務中可以減輕內部內存碎片的后果。
?????? Durable Storage。與其他應用程序一樣，我們的無服務器數據庫應用程序實驗受到存儲系統的延遲和IOPS的限制，但它還需要長期數據存儲和文件系統的可變狀態語義。雖然數據庫功能（包括OLTP）可能會越來越多地作為BaaS產品提供，但我們將此應用程序視為幾個應用程序的代表，這些應用程序需要比無服務器臨時存儲更適合提供的更長保留和更高的持久性。要實現高性能無服務器持久存儲，一種方法是利用基于SSD的分布式存儲與分布式內存緩存配對。最近實現其中許多目標的系統是Anna鍵值數據庫，它通過組合多個現有云存儲產品來實現成本效率和高性能[56]?？紤]到內存緩存容量可能遠低于SSD容量這一事實，這種設計的一個關鍵挑戰是在存在重尾訪問分布的情況下實現低尾部延遲。利用新的存儲技術[57]，承諾微秒級訪問時間，正在成為應對這一挑戰的有前途的方法。
?????? 與無服務器短暫存儲類似，此服務應透明配置，并應確?？鐟贸绦蚝妥鈶舾綦x，以確保安全性和可預測的性能。 但是，無應用程序短暫存儲將在應用程序終止時回收資源，而無服務器持久存儲必須僅顯式釋放資源（例如，作為“刪除”或“刪除”命令的結果），就像在傳統存儲系統中一樣。 此外，它當然必須確保持久性，以便任何已確認的寫入將在失敗后存在。
?????? Coordination/signaling service：功能之間的共享狀態通常使用生產者 - 消費者設計模式，這需要消費者在生產者可以獲得數據時立即知道。 類似地，當條件變得可用時，一個函數可能想要發信號通知另一個函數，或者多個函數可能想要協調，例如，以實現數據一致性機制。 這種信令系統將受益于微秒級延遲，可靠傳遞以及廣播或群組通信。 我們還注意到，由于云函數實例不能單獨尋址，因此它們不能用于實現教科書分布式系統算法，如共識或領導者選舉[50]。
?????? Minimize startup time：啟動時間有三個部分（1）調度和啟動資源以運行云功能，（2）下載應用軟件環境（例如，操作系統，庫）以運行功能代碼，以及（3） 執行特定于應用程序的啟動任務，例如加載和初始化數據結構和庫。 資源調度和初始化可能會因創建隔離的執行環境以及配置客戶的VPC和IAM策略而產生顯著的延遲和開銷。 云提供商[14,15]以及其他[58,59]最近致力于通過開發新的輕量級隔離機制來縮短啟動時間。
?????? 減少（2）的一種方法是利用單核[60]。 Unikernel以兩種方式消除傳統操作系統產生的開銷。首先，代替動態檢測硬件，應用用戶配置和分配傳統操作系統等數據結構，unikernel通過預先配置它們運行的??硬件并靜態分配數據結構來壓縮這些成本。其次，unikernel僅包括應用程序嚴格要求的驅動程序和系統庫，這導致比傳統操作系統更小的占用空間。值得注意的是，由于unikernel是針對特定應用程序量身定制的，因此在運行標準化內核的許多實例時，它們無法實現一些可能的效率，例如在同一VM上的不同云功能之間共享內核代碼頁，或者減少啟動時間通過預緩存來節省時間。減少（2）的另一種方法是在應用程序調用庫時動態地和遞增地加載庫，例如，由Azure Functions中使用的共享文件系統啟用。
?????? 特定于應用程序的初始化（3）是程序員的責任，但云提供程序可以在其API中包含準備就緒信號，以避免在開始處理函數之前將工作發送到函數實例[61]。 更廣泛地說，云提供商可以提前執行啟動任務[59]。 這對于客戶無關的任務尤為強大，例如使用流行的操作系統和一組庫來啟動VM，因為這些實例的“熱池”可以在租戶之間共享[13]。
4.3 Networking challenges
?????? 如第3節所述，如圖2所示，云功能可能會對流行的通信原語（如廣播，聚合和混洗）產生巨大的開銷。 特別是，假設我們可以在VM實例上打包K個云功能，云功能版本將發送比實例版本多K倍的消息，并且在shuffle的情況下發送K2個更多消息。
?????? 可能有幾種方法可以應對這一挑戰：
請注意，前兩個提案可能會降低云提供商放置云功能的靈活性，從而降低數據中心利用率。 可以說，它們也違背了無服務器計算的精神，迫使開發人員考慮系統管理。
4.4 Security challenges
無服務器計算重新安排了安全責任，將其中許多人從云用戶轉移到云提供商，而沒有從根本上改變它們。 但是，無服務器計算還必須解決應用程序分解多租戶資源共享中固有的風險。無服務器計算重新安排了安全責任，將其中許多人從云用戶轉移到云提供商，而沒有從根本上改變它們。 但是，無服務器計算還必須解決應用程序分解多租戶資源共享中固有的風險。
Scheduling randomization and physical isolation: 物理共存是云中硬件級邊通道或Rowhammer [62]攻擊的中心。 作為這類攻擊的第一步，對抗性租戶需要在同一物理主機上確認與受害者的同居，而不是隨機攻擊陌生人。 云功能的短暫性可能會限制攻擊者識別同時運行的受害者的能力。 隨機化，對手感知調度算法[63]可能會降低共同定位攻擊者和受害者的風險，使共存駐留攻擊更加困難。 但是，故意阻止物理共存可能與放置相沖突，以優化啟動時間，資源利用或通信。
Fine-grained security contexts：云功能需要細粒度的配置，包括訪問私鑰，存儲對象甚至本地臨時資源。 將要求從現有的服務器應用程序轉換安全策略，并提供高度表達的安全API以便在云功能中動態使用。 例如，云功能可能必須將安全權限委托給另一個云功能或云服務。 使用加密保護的安全上下文的基于能力的訪問控制機制可以自然地適用于這種分布式安全模型。 最近的工作[64]建議在多方設置中使用信息流控制進行跨功能訪問控制。 如果為云功能動態創建短期密鑰和證書，則會加劇提供安全原語的分布式管理的其他挑戰，例如非模糊性[65]和撤銷。
?????? 在系統級別，用戶要求為每個功能提供更細粒度的安全隔離，至少作為一種選擇。提供功能級沙盒的挑戰是保持較短的啟動時間，而不會以在重復的功能調用之間共享狀態的方式緩存執行環境。一種可能性是本地快照實例，以便每個功能可以從干凈狀態開始。或者，輕量級虛擬化技術開始被無服務器提供商采用：庫操作系統，包括gVisor [14]，在用戶空間“填充層”中實現系統API，而unikernel和microVM，包括AWS Firecracker [15]，流客戶內核并幫助最小化主機攻擊面。與以秒為單位測量的VM啟動時間相比，這些隔離技術將啟動時間減少到幾十毫秒。這些解決方案在安全性方面是否實現了與傳統虛擬機的平價仍有待展示，我們期望尋找具有低啟動開銷的強大隔離機制成為正在進行的研究和開發的活躍領域。從積極的方面來說，無服務器計算中的提供程序管理和短期實例可以更快地修補漏洞。
?????? 對于需要防止共存駐留攻擊的用戶，一種解決方案是要求物理隔離。 最近的硬件攻擊（例如，Spectre [66]和Meltdown [67]）也使得整個核心甚至整個物理機器都能夠為用戶提供吸引力。 云提供商可以為客戶提供高級選項，以便在專用于其使用的物理主機上啟動功能。
Oblivious serverless computing：云功能可以通過通信泄漏訪問模式和時間信息。 對于服務器應用程序，通常批量檢索數據，并在本地緩存。 相比之下，由于云功能是短暫的并且廣泛分布在云中，因此網絡傳輸模式可以將更敏感的信息泄露給云中的網絡攻擊者（例如，員工），即使有效負載是端到端加密的 -? 結束。 將無服務器應用程序分解為許多小功能的趨勢加劇了這種安全風險。 雖然主要的安全問題來自外部攻擊者，但通過采用不經意的算法可以保護網絡模式免受員工的影響。 不幸的是，這些往往有很高的開銷[68]。
?
4.5 Computer architecture challenges
Hardware Heterogeneity, Pricing, and Ease ofManagement：唉，主宰云的x86微處理器性能幾乎沒有提高。 2017年，單項計劃績效僅提升3％[69]。 假設趨勢繼續下去，表現將不會翻倍20年。 同樣，每芯片的DRAM容量接近其極限; 16 Gbit DRAM今天正在銷售，但構建32 Gbit DRAM芯片似乎不可行。 這種緩慢變化速度的一線希望是讓供應商更換舊電腦，因為它們在當前無服務器市場上幾乎沒有中斷。
?????? 通用微處理器的性能問題不會降低對更快計算的需求。 前進有兩條路[70]。 對于使用JavaScript或Python等高級腳本語言編寫的函數，硬件 - 軟件協同設計可能會導致語言特定的自定義處理器運行速度提高一到三個數量級。 另一條前進道路是Domain Specific Architectures。 DSA針對特定問題域進行了定制，并為該域提供了顯著的性能和效率提升，但對該域外的應用程序執行效果不佳。 圖形處理單元（GPU）長期以來一直用于加速圖形，我們開始看到用于機器學習的DSA，例如Tensor Processing Units（TPU）。 TPU的性能優于CPU的30倍。 這些示例是眾多中的第一個，因為針對不同域增強了DSA的通用處理器將成為常態。
如上面4.1節所述，我們看到了無服務器計算的兩條路徑，以支持即將到來的硬件異構性：
?????? 對于x86的SIMD指令，無服務器計算現在在很小的方面面臨異構性。 AMD和英特爾通過增加每個時鐘周期執行的操作數量并添加新指令，迅速改進了x86指令集的那一部分。 對于使用SIMD指令的程序，在具有512位寬SIMD指令的最新Intel Skylake微處理器上運行要比在具有128位寬SIMD指令的舊版Intel Broadwell微處理器上運行要快得多。 今天，兩個微處理器在AWS Lambda中以相同的價格提供，但目前無服務器計算用戶無法表明他們想要更快的SIMD硬件。 在我們看來，編譯器應該建議哪種硬件最匹配。 隨著加速器在云中變得越來越流行，無服務器的云提供商將不再能夠忽視異構性的困境，特別是因為存在可行的補救措施。
?????? 隨著加速器在云中變得越來越流行，無服務器的云提供商將不再能夠忽視異構性的困境，特別是因為存在可行的補救措施。
5. Fallacies and Pitfalls
6. Summary and Predictions
?????? 通過提供簡化的編程環境，無服務器計算使云更易于使用，從而吸引更多能夠并將使用它的人。 無服務器計算包括FaaS和BaaS產品，標志著云編程的重要成熟。 它不再需要手動資源管理和優化，而今天的服務器計算對應用程序開發人員施加了壓力，這種成熟類似于四十多年前從匯編語言轉向高級語言的過程。 我們預測無服務器的使用將會飆升。 我們還預計，隨著時間的推移，混合云本地應用程序將逐漸減少，但由于監管限制和數據治理規則，某些部署可能會持續存在。
?????? 我們預測無服務器的使用將會飆升。 我們還預計，隨著時間的推移，混合云本地應用程序將逐漸減少，但由于監管限制和數據治理規則，某些部署可能會持續存在。
?????? 無服務器計算的未來面臨的兩個挑戰是提高安全性并適應可能來自專用處理器的成本 - 性能提升。在這兩種情況下，無服務器計算都具有可以幫助解決這些挑戰的功能。物理共存是旁道攻擊的必要條件，但在無服務器計算中更難確認，并且可以輕松采取步驟隨機化云功能放置。在JavaScript，Python或TensorFlow等高級語言中編寫云函數的程序提高了編程抽象的水平，使其更易于創新，從而使底層硬件能夠提高成本性能。
?????? 伯克利的云計算視圖[2]預測，2009年云計算面臨的挑戰將得到解決，并且它將蓬勃發展。云業務每年增長50％，并證明云服務提供商的利潤很高。
我們在本文中總結了以下關于未來十年無服務器計算的預測：
?
總結
以上是生活随笔為你收集整理的Cloud Programming Simplifie : A Berkeley View on Serverless Computing的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Spark详解（十四）：Spark SQ
- 下一篇： 云计算的三种服务模式：IaaS，PaaS