基於函數計算+TensorFlow的ServerlessAI推理

NO IMAGE

前言概述

本文介紹了使用函數計算部署深度學習 AI 推理的最佳實踐, 其中包括使用 FUN 工具一鍵部署安裝第三方依賴、一鍵部署、本地調試以及壓測評估, 全方位展現函數計算的開發敏捷特性、自動彈性伸縮能力、免運維和完善的監控設施。

1.1 DEMO 概述

基於函數計算+TensorFlow的ServerlessAI推理
通過上傳一個貓或者狗的照片, 識別出這個照片裡面的動物是貓還是狗
開通服務
免費開通函數計算, 按量付費,函數計算有很大的免費額度。
免費開通文件存儲服務NAS, 按量付費

1.2 解決方案

基於函數計算+TensorFlow的ServerlessAI推理
如上圖所示, 當多個用戶通過對外提供的 url 訪問推理服務時候,每秒的請求幾百上千都沒有關係, 函數計算平臺會自動伸縮, 提供足夠的執行實例來響應用戶的請求, 同時函數計算提供了完善的監控設施來監控您的函數運行情況。

1.3. Serverless 方案與傳統自建服務方案對比

1.3.1 卓越的工程效率

自建服務函數計算 Serverless基礎設施需要用戶採購和管理無開發效率除了必要的業務邏輯開發,需要自己建立相同線上運行環境, 包括相關軟件的安裝、服務配置、安全更新等一系列問題只需要專注業務邏輯的開發, 配合 FUN 工具一鍵資源編排和部署學習上手成本可能使用 K8S 或彈性伸縮( ESS ),需要了解更多的產品、名詞和參數的意義會編寫對應的語言的函數代碼即可

1.3.2 彈性伸縮免運維

自建服務函數計算 Serverless彈性高可用需要自建負載均衡 (SLB),彈性伸縮,擴容縮容速度較 FC 慢FC系統固有毫秒級別彈性伸縮,快速實現底層擴容以應對峰值壓力,免運維監控報警查詢ECS 級別的 metrics提供更細粒度的函數執行情況,每次訪問函數執行的 latency 和日誌等, 更加完善的報警監控機制

1.3.3 更低的成本

  • 函數計算 (FC) 固有自動伸縮和負載均衡功能,用戶不需要購買負載均衡 (SLB) 和彈性伸縮。
  • 具有明顯波峰波谷的用戶訪問場景(比如只有部分時間段有請求,其他時間甚至沒有請求),選擇按需付費,只需為實際使用的計算資源付費。
對於明顯波峰波谷或者稀疏調用具有低成本優勢, 同時還保持了彈性能力,以後業務規模做大以後並沒有技術切換成本,同時財務成本增長配合預付費也能保持平滑。
假設有一個在線計算服務,由於是CPU 密集型計算, 因此在這裡我們將平均 CPU 利用率作為核心參考指標對成本,以一個月為週期,10臺 C5 ECS 的總計算力為例,總的計算量約為 30% 場景下, 各解決方案 CPU 資源利用率使用情況示意圖大致如下:
基於函數計算+TensorFlow的ServerlessAI推理
由上圖預估出如下計費模型:
  • 函數計算預付費 3CU 一個月: 246.27 元, 計算能力等價於 ECS 計算型 C5
  • ECS 計算型 C5 (2vCPU,4GB)+雲盤: 包月219 元,按量: 446.4 元
  • 包月10 Mbps 的 SLB: 526.52 元(這裡做了一定的流量假設), 彈性伸縮免費
  • 飽和使用下,函數計算按量付費的一臺機器成本約為按量付費 C5 ECS 的2 倍
平均CPU利用率計算費用SLB總計函數計算組合付費>=80%738+X(246.27*3+X)無<= 738+X按峰值預留ECS<=30%2190(10*219)526.52>=2716.52彈性伸縮延遲敏感<=50%1314(102193/5)526.52>= 1840.52彈性伸縮成本敏感<=70%938.57 (102193/7)526.52>= 1465.09
注:

  1. 這裡假設函數邏輯沒有公網公網下行流量費用, 即使有也是一致的, 這裡成本比較暫不參與
  2. 延時敏感,當 CPU 利用率大於等於 50% 就需要開始進行擴容,不然更來不及應對峰值
  3. 成本敏感,當 CPU 利用率大約 80% 即開始進行擴容, 能容受一定機率的超時或者5XX
上表中, 其中函數計算組合付費中的 X 為按需付費的成本價,假設按需付費的計算量佔整個計算量的 10%,假設 CPU 利用率為100%, 對應上表,那麼需要 3 臺 ECS 的計算能力即可。因此 FC 按量付費的成本 X = 3 ️ 446.4 ️ 10% ️ 2 = 267.84 ( FC 按量付費是按量 ECS 的2倍),這個時候函數計算組合付費總計 1005.8 元。 在這個模型預估裡面, 只要 FC 按量付費佔整個計算量小於 20%, 即使不考慮 SLB, 單純考慮計算成本, 都是有一定優勢的。

1.3.4. 小結

基於函數計算進行 AI 推理等 CPU 密集型的主要優勢:
  1. 上手簡單, 只專注業務邏輯開發, 極大提高工程開發效率。

  • 自建方案有太多學習和配置成本,如針對不同場景,ESS 需要做各種不同的參數配置
  • 系統環境的維護升級等
  1. 免運維,函數執行級別粒度的監控和告警。
  2. 毫秒級彈性擴容,保證彈性高可用,同時能覆蓋延遲敏感和成本敏感類型。
  3. 在 CPU 密集型的計算場景下, 通過設置合理的組合計費模式, 在如下場景中具有成本優勢:

  • 請求訪問具有明顯波峰波谷, 其他時間甚至沒有請求
  • 有一定穩定的負載請求, 但是有部分時間段請求量突變劇烈

打包代碼ZIP包和部署函數

FUN 操作簡明視頻教程

開通服務

免費開通函數計算, 按量付費,函數計算有很大的免費額度。
免費開通文件存儲服務NAS, 按量付費

2.1 安裝第三方包到本地並上傳到NAS

2.1.1 安裝最新的Fun

  • 安裝版本為8.x 最新版或者10.x 、12.x nodejs
  • 安裝 funcraf

2.1.2 Clone 工程 & Fun 一鍵安裝第三方庫到本地

  • git clone https://github.com/awesome-fc/cat-dog-classify.git
  • 複製 .env_example 文件為 .env, 並且修改 .env 中的信息為自己的信息
  • 執行 fun install -v, fun 會根據 Funfile 中定義的邏輯安裝相關的依賴包

基於函數計算+TensorFlow的ServerlessAI推理
[email protected]: ls .fun/nas/auto-default/classify model python [email protected]: du -sm .fun 697 .fun
根據 Funfile 的定義:
  • 將第三方庫下載到 .fun/nas/auto-default/classify/python 目錄下
  • 本地 model 目錄移到 .fun/nas/auto-default/model 目錄下
安裝完成後,從這裡我們看出, 函數計算引用的代碼包解壓之後已經達到了 670 M, 遠超過 50M 代碼包限制, 解決方案是 NAS 詳情可以參考: 掛載NAS訪問,幸運的是 FUN 工具一鍵解決了 nas 的配置和文件上傳問題。

2.1.3. 將下載的依賴的第三方代碼包上傳到 NAS

fun nas init
fun nas info
fun nas sync
fun nas ls nas://classify:/mnt/auto/
依次執行這些命令,就將本地中的 .fun/nas/auto-default 中的第三方代碼包和模型文件傳到 NAS 中, 依次看下這幾個命令的做了什麼事情:
  • fun nas init: 初始化 NAS, 基於您的 .env 中的信息獲取(已有滿足條件的nas)或創建一個同region可用的nas
  • fun nas info: 可以查看本地 NAS 的目錄位置, 對於此工程是 $(pwd)/.fun/nas/auto-default/classify
  • fun nas sync: 將本地 NAS 中的內容(.fun/nas/auto-default/classify)上傳到 NAS 中的 classify 目錄
  • fun nas ls nas:///mnt/auto/: 查看我們是否已經正確將文件上傳到了 NAS
登錄 NAS 控制檯 nas.console.aliyun.com 和 VPC 控制檯 vpc.console.aliyun.com
可以觀察到在指定的 region 上有 NAS 和 相應的 vpc 創建成功

2.2 本地調試函數

在 template.yml 中, 指定了這個函數是 http 類型的函數, 所以根據 fun 的提示:
Tips for next step
======================
* Invoke Event Function: fun local invoke
* Invoke Http Function: fun local start
* Build Http Function: fun build
* Deploy Resources: fun deploy
執行 fun local start, 本地就會啟動一個 http server 來模擬函數的執行, 然後我們 client 端可以使用 postman, curl 或者瀏覽器, 比如對於本例:
基於函數計算+TensorFlow的ServerlessAI推理
基於函數計算+TensorFlow的ServerlessAI推理

2.3 部署函數到FC平臺

本地調試OK 後,我們接下來將函數部署到雲平臺:
修改 template.yml LogConfig 中的 Project, 任意取一個不會重複的名字即可,有兩處地方需要更改,然後執行
fun deploy
注意: template.yml 註釋的部分為自定義域名的配置, 如果想在 fun deploy 中完成這個部署工作:
  • 先去域名解析, 比如在示例中, 將域名 sz.mofangdegisn.cn 解析到 123456.cn-hangzhou.fc.aliyuncs.com, 對應的域名、accountId 和 region 修改成自己的
  • 去掉 template.yml 中的註釋, 修改成自己的域名
  • 執行 fun deploy
這個時候如果沒有自定義域名, 直接通過瀏覽器訪問訪問http trigger 的url, 比如 https://123456.cn-shenzhen.fc.aliyuncs.com/2016-08-15/proxy/classify/cat-dog/ 會被強制下載.
原因:https://help.aliyun.com/knowledge_detail/56103.html#HTTP-Trigger-compulsory-header
基於函數計算+TensorFlow的ServerlessAI推理
登錄控制檯fc.console.aliyun.com,可以看到service 和 函數已經創建成功, 並且 service 也已經正確配置。
基於函數計算+TensorFlow的ServerlessAI推理
在這裡,我們發現第一次打開頁面訪問函數的時候,執行環境實例冷啟動時間非常長, 如果是一個在線AI推理服務,對響應時間非常敏感,冷啟動引起的毛刺對於這種類型的服務是不可接受的,接下來,本文講解如何利用函數計算的預留模式來消除冷啟動帶來的負面影響。

使用預留模式消除冷啟動毛刺

函數計算具有動態伸縮的特性, 根據併發請求量,自動彈性擴容出執行環境來執行環境,在這個典型的深度學習示例中,import keras 消耗的時間很長 , 在我們設置的 1 G 規格的函數中, 併發訪問的時候耗時10s左右, 有時甚至20s+
start = time.time()
from keras.models import model_from_json
print("import keras time = ", time.time()-start)

3.1 函數計算設置預留

預留操作簡明視頻教程
  • FC 控制檯,發佈版本,並且基於該版本創建別名 prod,並且基於別名 prod 設置預留, 操作過程請參考:help.aliyun.com/document_de…
  • 將該函數的 http trigger 和 自定義域名的設置執行 prod 版本
基於函數計算+TensorFlow的ServerlessAI推理
基於函數計算+TensorFlow的ServerlessAI推理

一次壓測結果

基於函數計算+TensorFlow的ServerlessAI推理
基於函數計算+TensorFlow的ServerlessAI推理
從上面圖中我們可以看出,當函數執行的請求到來時,優先被調度到預留的實例中被執行, 這個時候是沒有冷啟動的,所以請求是沒有毛刺的, 後面隨著測試的壓力不斷增大(峰值TPS 達到 1184), 預留的實例不能滿足調用函數的請求, 這個時候函數計算就自動進行按需擴容實例供函數執行,此時的調用就有冷啟動的過程, 從上面我們可以看出,函數的最大 latency 時間甚至達到了 32s,如果這個web AP是延時敏感的,這個 latency 是不可接受的。

總結

  • 函數計算具有快速自動伸縮擴容能力
  • 預留模式很好地解決了冷啟動中的毛刺問題
  • 開發簡單易上手,只需要關注具體的代碼邏輯, Fun 工具助您一鍵式部署運用
  • 函數計算具有很好監控設施, 您可以可視化觀察您函數運行情況, 執行時間、內存等信息
原文鏈接
本文為阿里雲內容,未經允許不得轉載。

相關文章

Java函數式編程

前端安全防範知識XSS/CSRF/點擊劫持/中間人攻擊及防護方案

JS基本類型、引用類型梳理

PostGIS_小白筆記_行政區劃邊界