本文是 Serverless Computing: One Step Forward ,Two Steps Back 的閱讀筆記。該論文發表在 CIDR 2019 上，出自 UC Berkeley 的 RISELab。這篇論文看題目好像是 serverless 勸退文，實際上這篇論文更加宏觀而客觀地審視了一遍 serverless computing，指出了目前商業化的 serverless 所存在的主要問題和挑戰，最後提出了未來 serverless 的發展方向。

一、摘要和介紹

目前主流的雲服務商都已經有了自己的 serverless 計算服務，特別是 Amazon 的 Lambda 服務。這篇文章主要討論的不是 serverless 的定義，而是目前的雲服務商提供的 serverless 服務為什麼是令人失望的。需要注意的是，該文章主要討論的是 Faas 這種常見的 serverless 形式 ，更具體的說，是討論 Amazon Lambda（其他的 serverless 服務，如 Google 和 Azure 提供的 serverless 其實相差不大）

文章主要內容是：

  1. 總結了 serverless 的主要應用場景
  2. 指出目前的 serverless 服務主要的局限性是什麼
  3. 這些局限性會產生哪些影響
  4. 通過具體實驗，對比使用 Faas 和 Paas 的計算成本和效果。
  5. 提出未來的研究方向

1.1 Faas 簡介

目前常見的 serverless 服務是所謂的 Faas Function-as-a-service。Faas 的主要概念是，將使用雲服務的過程變得和傳統編程一樣：一個應用由很多個函數組成，每個函數有輸入輸出，在函數內完成必要的邏輯。開發者只需要編寫好函數代碼，將代碼註冊到雲端，將這些函數組成一個完整的應用即可。

而 Faas 在雲端可以提供常見的運行環境，如 Python，Java 等。而且函數的執行是事件驅動的，使用流程可以歸納為：

  1. 編寫函數，並註冊到雲端
  2. 聲明事件觸發器，由事件觸發器觸發函數的執行
  3. Faas 基礎設施監控事件觸發器，在觸發時分配必要的資源和運行環境給對應的函數，執行並保存運行的結果。

使用 Faas 編寫函數並沒有特別大的問題，但是用 Faas 來構建應用的話，涉及到函數和函數之間的調用。從而需要解決以下問題：

  1. 由於每個函數是獨立的而且是無狀態化，所以需要一種方法來管理一個應用的非持久化狀態信息和持久化數據
  2. 需要一個有效的機制觸發函數的執行
  3. 函數運行環境的可擴展性

因為存在這些問題，很多人強調說 sereverless 不僅僅是 Faas，因為為了給以上的技術問題需要引入其他解決方案，需要一些配套的多租戶和自動擴縮容的 service ：例如 Amazon 的 S3（對象存儲服務）, DynamoDB（key-value存儲服務），SQS（隊列服務），SNS（通知服務）等

總的來說，Faas 或者 Serverless 提供了一種彈性的，自動擴縮容的編程模式，是一大進步。

但是接下來我們也看到，目前的 serverless 也有兩點退步的地方

  1. 忽視了數據處理的效率
  2. 阻礙分散式計算的發展

二、Serverless 的主要應用場景

以 Amazon 的 Lamda 為例，

aws.amazon.com/cn/solut

Faas 主要的使用案例可以總結為下面三種類型：

1.並行的函數

每個函數都是完成獨立功能的，也就是不需要和其他函數相互交互和通信，函數沒有有串列的執行流程

2. 編排函數

利用 serverless 函數來完成簡單的服務調用編排。例如 Amazon 的參考應用：使用 serverless 函數來編排查詢服務，具體的查詢和查詢的數據都是由 Amazon 提供的雲服務 Athena 和 S3 來完成的，所以 serverless 函數在這裡只起到一個指揮官的作用，主要的運算工作是由雲服務，而不是由 serverless 函數來完成的。

3. 函數組合

這個有點類似於服務組合和服務編排，通過組合多個 serverless 函數來構建一個大的應用。

但是這種通過無狀態函數構建應用的工作流程時，需要考慮數據的依賴，不同的函數之間需要通過某種方式維持上下文狀態，並且要符合 serverless 事件驅動模式的特性。為了解決這些問題，需要使用其他雲服務，例如隊列服務 SQS，key-value 存儲服務 S3等。Amazon 提供的『創建用戶流程』用例裡面就提到，用 Faas 和上面提到的雲服務構建的用戶創建服務，延時平均 10 min。可見這並不是很高效。

總的來說，serverless 更適合第一種類型的場景：簡單的，獨立的任務，相互之間不用通信；對於通過 Faas 來構建有狀態化的應用，則尤其不適合。

三、Serverless 的局限性

3.1 局限性

當前的 serverless 的主要局限性體現在一下幾點

1. 存活時間很短

目前 Amazon Lambda 創建的函數，一次運行最多 15 mins，執行完了以後緩存雖然還可能保留在當前運行的主機上，但是下次運行該函數的時候，不一定在這個主機上，所以緩存極大可能會丟失。

2. IO 瓶頸

目前 Faas 訪問共享存儲的方式是通過網路帶寬，而不是直接通過匯流排來訪問的，因此造成了很大的 IO 損耗，網路限制了 IO 的吞吐量，一般情況下，每個 Amazon Lambda Function 的平均網路帶寬是 538Mbps，如果考慮到多個 函數都在一個主機上共享帶寬——假設有 20 個，每個Function 平均帶寬是 28.7 Mbps，那麼每個 Function 的 IO 速度比直接使用 SSD 慢 2.5 個數量級。

3. 需要通過低速存儲進行通信

由於 serverless 函數沒有主機的概念，所以每個函數都沒有一個固定的網路地址，函數和函數之間的通信已經不能通過網路鏈路或者內存，而是通過存儲服務（例如 S3 這種 key-value 存儲服務）來間接地通信，這些額外的存儲服務相對於端到端的網路通信來說，不僅延時高，價格還昂貴。

舉個例子，在處理客戶端請求的時候，每個函數只完成一個子流程，每個子流程都應該知道當前請求的上下文信息，也就需要保存會話狀態，例如session id，但是由於 serverless 的無狀態化特性，每個子流程（函數）的會話信息不能共享，所以這些本該保存在緩存和內存的信息只能先保存在相對低速的存儲服務 S3 中，然後下一個子流程（函數）再從 S3 中獲取上下文信息。

4. 沒有對硬體自定義提供支持

對於 serverless 來說，目前對 GPU 等專有硬體的支持度還不夠，例如 Amazon Lambda 只支持設置 CPU 超線程的時間片和內存使用量。

3.2 局限性導致的問題

以上的局限性會導致以下問題：

  1. Faas 是 Data-shipping 架構

所謂的 Data-shipping 是指：將數據傳輸到代碼所在處執行，而不是將代碼傳輸到數據所在處執行，因為數據一般都比代碼的傳輸量要大得多。而目前主流的 Faas 平台都是『將數據傳輸到代碼所在處執行』這種架構，所以這是 Faas 的最大缺陷。

其次，由於每個函數都是運行在獨立的虛擬機當中的，而且短生命周期和不可定位的，這就限制了多次相同的請求對緩存的使用，造成比較大的性能損耗

2. Faas 阻礙了分散式計算的發展

因為 Faas 的函數之間不是通過網路進行端到端通信的，那麼以計算機網路為基礎的分散式計算理論和通信協議，例如數據一致性，leader 選舉，分散式事務等的發展會受到阻礙。

3. 阻礙了硬體加速軟體的創新

目前 Faas 平台主要運行在統一的平台上面，沒有提供 GPU 等用戶自定義的硬體，加速軟體執行。

筆者註：其實華為雲已經提供了GPU 加速 huaweicloud.com/product

也無法像傳統機器一樣提供內存存儲資料庫，因為函數的生命周期有限，目前Amazon Lambda 提供最多 3 GB 內存，無法用作資料庫

筆者註：但是 Faas 本身的目的就是去狀態化，不太適合用作數據存儲

4. 阻礙開源服務的創新

很多流行的開源軟體不能大規模地部署在 Faas 平台上，畢竟目前主要的開源軟體並不是針對 serverless 執行環境的，特別是數據系統。

四、案例分析

這部分主要是通過實驗來論證使用 Faas 的問題。

  1. 模型訓練

文章中使用 Lambda 的函數和 EC2 雲主機來訓練相同的任務。

對於 Lambda 來說，數據是存儲在 S3 上的，EC2 的數據可以直接存儲在主機掛載的雲存儲 EBS。於是有了以下數據

  • Lambda：

一次迭代訓練花費 3.08 s，其中 2.49s 用戶從 S3 獲取 100M 數據，0.59s 用來執行迭代優化 。最後需要運行 31 次 Lambda 函數，每次 15 mins，一共用了 465 mins 花費了 $0.29。

  • EC2：

每次迭代 0.14s，其中 0.04s 從 EBS 獲取數據，0.1s 迭代優化。，一共運行了 22 mins，一共花費了 $0.04

2. 低時延的預測服務

就是用一個已經訓練好的模型用來做預測服務。

  • Lambda：平均每個batch 最小時延 447ms，平均花費為 $1584/h
  • EC2：最小時延 2.8ms 比 Lambda 快127倍，平均花費為 $27.84/h 比 lambda 便宜 57 倍

3. 分散式計算

因為 Lambda 的函數之間不能直接通信，需要通過中間的存儲服務來進行間接通信，這裡對比了使用不同中間件，和EC2 雲主機相比，傳輸 1KB 數據的時延分別是多少：

?

由於 Lambda I/O（S3）和 EC2 I/O（S3），以及 Lambda I/O（DynamoDB ）和 EC2 I/O（DynamoDB）的時延幾乎沒有差別，而直接使用網路通信的 EC2 NW 的時延低得明顯，所以有理由相信，主要的時延是由中間的存儲服務造成的。

五、未來方向

雖然目前的 Faas 平台存在很多局限性，這些局限性不一定是壞事。

但是它仍然是一種新的編程模式，它具有的靈活性，可擴展性非常強。它可以帶來兩點好處：

  1. 它的局限性可能激發更有針對性的深入的創新。
  2. 為了構建高性能的大規模 Faas 應用，開發者被迫使用非同步的方式編程，而不是串列的。這從而有利於發展一種 「disorderly」 loosely-consistent 程序模型，這是構建的普遍性的可擴展程序的主要思想。
  3. 因為 Faas 內的函數是沒有網路地址的，這個也許可以推動動態虛擬定位技術 virtual addressing of dynamically shifting agents 的發展
  4. 推動 serverless 社區的發展。正如 MapReduce 的提出，推動了 SQL 和關係代數一系列生態的發展，Faas 應該也許可以推動分散式編程的發展。

通過 Faas 的分析，可知 Faas 不擅長對於數據的處理。而一個更好的雲編程框架的發展，應該同時能兼顧對數據和計算資源的分配和處理。目前需要實現一個真正的可編程的雲環境，還有以下挑戰：

  • 流動的代碼和數據放置 Fluid Code and Data Placement
    • 為了獲得更好的性能，一方面需要考慮怎麼合作式地部署數據和代碼，特別是將代碼運輸到數據處運行，不應該像 Faas 一樣將數據傳輸到代碼執行處
    • 另一方面，考慮到資源的彈性擴縮容，代碼和數據需要邏輯上分離開來
  • 提供對異構硬體的支持
  • 提供長期駐守的可定址的虛擬代理
    • 因為 Faas 里的函數是遊離的，那麼重複的請求無法利用好先前的緩存和數據，所以最好能提供一個長期駐守在平台上的虛擬代理，它能夠指導函數在那裡運行，在重複的請求中，減少數據的傳輸，甚至可以補償運行這個虛擬代理的損耗。
  • Disorderly programming
    • 分散式計算和彈性擴縮容需要從編程方式上有所突破
    • 傳統的串列編程方式很難很好地在大規模的雲中使用，開發者需要新的編程語言
  • Flexible Programming
    • 提供一種用於雲的通用的中間表示層，其他語言可以將自己的代碼編譯為這個中間表示層，從而統一實現對Fluid Code and Data Placement 和 Disorderly programming 的優化和支持。
  • Service-level objectives&guarantee
    • 目前 Faas 平台的收費標準比較簡單，以資源和運行時間收費，應該提供保證服務級別 SLO 的收費支持
  • 安全問題
    • 如果使用的代碼到數據的執行方式，代碼的執行安全問題變得棘手等

作者：youngdou謙知


推薦閱讀：
相关文章