目前深度學習應用廣發， 其中 AI 推理的線上服務是其中一個重要的可落地的應用場景。本文将為大家介紹使用函數計算部署深度學習 AI 推理的最佳實踐, 其中包括使用 FUN 工具一鍵部署安裝第三方依賴、一鍵部署、本地調試以及壓測評估， 全方位展現函數計算的開發靈活特性、自動彈性伸縮能力、免運維和完善的監控設施。
1.1 DEMO 概述
通過上傳一個貓或者狗的照片， 識别出這個照片裡面的動物是貓還是狗
- DEMO 示例效果入口： http://sz.mofangdegisn.cn
- DEMO 示例工程位址： https://github.com/awesome-fc/cat-dog-classify
開通服務
免費開通函數計算， 按量付費，函數計算有很大的免費額度。
免費開通檔案存儲服務NAS， 按量付費
1.2 解決方案
如上圖所示， 當多個使用者通過對外提供的 url 通路推理服務時候，每秒的請求幾百上千都沒有關系， 函數計算平台會自動伸縮， 提供足夠的執行執行個體來響應使用者的請求， 同時函數計算提供了完善的監控設施來監控您的函數運作情況。
1.3. Serverless 方案與傳統自建服務方案對比
1.3.1 卓越的工程效率
| 自建服務 | 函數計算 Serverless | |
|---|---|---|
| 基礎設施 | 需要使用者采購和管理 | 無 |
| 開發效率 | 除了必要的業務邏輯開發,需要自己建立相同線上運作環境， 包括相關軟體的安裝、服務配置、安全更新等一系列問題 | 隻需要專注業務邏輯的開發, 配合 FUN 工具一鍵資源編排和部署 |
| 學習上手成本 | 可能使用 K8S 或彈性伸縮( ESS )，需要了解更多的産品、名詞和參數的意義 | 會編寫對應的語言的函數代碼即可 |
1.3.2 彈性伸縮免運維
| 彈性高可用 | 需要自建負載均衡 (SLB)，彈性伸縮，擴容縮容速度較 FC 慢 | FC系統固有毫秒級别彈性伸縮，快速實作底層擴容以應對峰值壓力，免運維 |
| 監控報警查詢 | ECS 級别的 metrics | 提供更細粒度的函數執行情況，每次通路函數執行的 latency 和日志等， 更加完善的報警監控機制 |
1.3.3 更低的成本
- 函數計算 (FC) 固有自動伸縮和負載均衡功能，使用者不需要購買負載均衡 (SLB) 和彈性伸縮。
- 具有明顯波峰波谷的使用者通路場景(比如隻有部分時間段有請求，其他時間甚至沒有請求)，選擇按需付費，隻需為實際使用的計算資源付費。
對于明顯波峰波谷或者稀疏調用具有低成本優勢， 同時還保持了彈性能力，以後業務規模做大以後并沒有技術切換成本，同時财務成本增長配合預付費也能保持平滑。
- 部分請求持續平穩的場景下,可以配合預付費解決按需付費較高單價問題。 函數計算成本優化最佳實踐文檔 。
假設有一個線上計算服務，由于是CPU 密集型計算， 是以在這裡我們将平均 CPU 使用率作為核心參考名額對成本，以一個月為周期，10台 C5 ECS 的總計算力為例，總的計算量約為 30% 場景下， 各解決方案 CPU 資源使用率使用情況示意圖大緻如下:
由上圖預估出如下計費模型：
- 函數計算預付費 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） | >= 1840.52 | |
| 彈性伸縮成本敏感 | <=70% | 938.57 (102193/7) | >= 1465.09 |
注：
- 這裡假設函數邏輯沒有公網公網下行流量費用， 即使有也是一緻的， 這裡成本比較暫不參與
- 延時敏感，當 CPU 使用率大于等于 50% 就需要開始進行擴容，不然更來不及應對峰值
- 成本敏感，當 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 密集型的主要優勢：
- 上手簡單， 隻專注業務邏輯開發， 極大提高工程開發效率。
- 自建方案有太多學習和配置成本，如針對不同場景，ESS 需要做各種不同的參數配置
- 系統環境的維護更新等
- 免運維，函數執行級别粒度的監控和告警。
- 毫秒級彈性擴容，保證彈性高可用，同時能覆寫延遲敏感和成本敏感類型。
- 在 CPU 密集型的計算場景下， 通過設定合理的組合計費模式， 在如下場景中具有成本優勢：
- 請求通路具有明顯波峰波谷， 其他時間甚至沒有請求
- 有一定穩定的負載請求， 但是有部分時間段請求量突變劇烈
打包代碼ZIP包和部署函數
FUN 操作簡明視訊教程2.1 安裝第三方包到本地并上傳到NAS
2.1.1 安裝最新的Fun
2.1.2 Clone 工程 & Fun 一鍵安裝第三方庫到本地
-
git clone https://github.com/awesome-fc/cat-dog-classify.git
- 複制 .env_example 檔案為 .env, 并且修改 .env 中的資訊為自己的資訊
- 執行
fun install -v
root@66fb3ad27a4c: ls .fun/nas/auto-default/classify
model python
root@66fb3ad27a4c: 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
-
fun nas info
-
fun nas sync
-
fun nas ls nas:///mnt/auto/
登入 NAS 控制台
https://nas.console.aliyun.com和 VPC 控制台
https://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 或者浏覽器， 比如對于本例：
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
登入控制台
https://fc.console.aliyun.com，可以看到service 和 函數已經建立成功， 并且 service 也已經正确配置。
在這裡，我們發現第一次打開頁面通路函數的時候，執行環境執行個體冷啟動時間非常長， 如果是一個線上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 設定預留, 操作過程請參考： https://help.aliyun.com/document_detail/138103.html
- 将該函數的 http trigger 和 自定義域名的設定執行 prod 版本
使用函數計算三步實作深度學習 AI 推理線上服務打包代碼ZIP包和部署函數使用預留模式消除冷啟動毛刺總結
一次壓測結果
從上面圖中我們可以看出，當函數執行的請求到來時，優先被排程到預留的執行個體中被執行， 這個時候是沒有冷啟動的，是以請求是沒有毛刺的， 後面随着測試的壓力不斷增大(峰值TPS 達到 1184), 預留的執行個體不能滿足調用函數的請求， 這個時候函數計算就自動進行按需擴容執行個體供函數執行，此時的調用就有冷啟動的過程， 從上面我們可以看出，函數的最大 latency 時間甚至達到了 32s，如果這個web AP是延時敏感的，這個 latency 是不可接受的。
總結
- 函數計算具有快速自動伸縮擴容能力
- 預留模式很好地解決了冷啟動中的毛刺問題
- 開發簡單易上手，隻需要關注具體的代碼邏輯， Fun 工具助您一鍵式部署運用
- 函數計算具有很好監控設施, 您可以可視化觀察您函數運作情況， 執行時間、記憶體等資訊
有任何問題歡迎進掃碼進釘釘群溝通
“ 阿裡巴巴雲原生 關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”