TL; DR
本文将讨論機器/深度學習基礎設施運維（MLOps）中的機器學習流水線。文章将覆寫以下内容和技術點：
- 定義了生産環境中對 ML pipeline 的要求（requirements）。
- 提供了基于阿裡雲 函數工作流 (FnF) ， 函數計算 (FC) Serverless ML Pipeline 解決方案 Github 。
- 解決方案提供 FC 與 阿裡雲容器服務 K8s (ACK) 結合教程，講解觸發任務，部署預測推理服務和暴露服務步驟。
- 對解決方案和類似方案進行分析比較結論：Serverless ML pipeline 可以提高研發效率，優化運維和經濟成本，幫助 ML 更快産生價值。
- 讨論 ML 基礎設施的選型：函數計算可以很好地和 K8s 叢集形成優勢互補。
前言
随着機器/深度學習的商業價值展現的越來越明顯，圍繞 ML 的軟體技術也日新月異，訓練 （training），模型 (model)，算法 (algorithm)，預測 (predictions)，推理 (inference) 這些概念以及 Spark MLlib, Tensorflow 這些軟體架構也變成了超高頻詞。在本地機器上用 Jupyter notebook 調用 Tensorflow 訓練幾萬張圖檔，不斷調參，然後産出的模型推理/預測看到結果準确當然是很興奮的，但是然後呢 （so what）？發表在 NIPS 的論文
Hidden Technical Debt in Machine Learning Systems中的這幅圖非常準确地展示了在産生商業價值的過程中，支援機器學習的周邊設定的開發，運維 （MLOps）的工程量要遠大于機器學習的核心開發。生産環境中的 MLOps 根據業務場景差别會非常大，子產品多，無法在一篇文章中覆寫，本文将聚焦在其中的一個子產品 -- 機器學習流水線， 重點介紹如何利用阿裡雲 Serverless 雲服務提高研發和運維的效率，自動化地将算法變成訓練後的模型，經過測試和審批最終在生産環境中通過預測/推理産生商業價值。
場景抽象，問題定義
如下圖所示，我們将複雜的 MLOps 簡化抽象成 算法開發 -> 模型建構 (build) -> 訓練 (training) -> 部署 （serving）-> 測試，審批 -> 生産釋出，然後再次傳回算法開發的回報回路。
邏輯雖然清楚簡單，然而流水線系統需要滿足下面的特性才适用于生産環境：
- 支援長時間執行： 模型訓練根據資料量和算法執行時間數量級跨度從分鐘到小時甚至更長。
- 流程可視化： ML/data scientist 和 DevOps 工程師使用的技術棧有明顯差別，需要通過可視化将邏輯描述和實作細節解耦。
- 狀态可觀測性： ML/data scientist 和 DevOps 工程師在流水線的不同步驟需要交流，協調，配合，需要對流程的進度做觀測。
- 描述能力豐富： 相比于 CI/CD 流水線，ML 流水線中業務邏輯更靈活和複雜，例如需要根據結果做選擇下一個步驟，循環回到前面的步驟等。
- 事件不丢失： 流水線事件（code push，建構，部署開始結束等時間）在有各種機器當機或是程序異常的情況下都可以被重新接收處理。
- 步驟可重試： 流水線上的每個任務都有機率随機失敗，為步驟加重試可以大幅提高整個流程的成功率。
- 狀态持久化： 在當機或是程序異常的情況下，流水線重新執行可以繼續從最近成功的步驟開始，無需重新開始。
- 高可用，低延遲，可擴充： 無需贅述。
- 經濟成本高效： 相比起計算資源，流水線編排占總成本比例需要很低。
- 運維成本低： 相比起計算資源，流水線編排占總成本比例需要很低。
- 不同團隊，技能棧要求不盡相同。注： 圖檔來源 Machine Learning Model Deployment: Strategy to Implementation
流水線的概念和上述的要求并不新奇，也有開源的解決方案被廣泛應用，如 CI/CD 系統常使用的 Jenkins, 工作流引擎 Airflow, Uber Cadence 等。然而在阿裡雲平台上還沒有比較流行的 ML 流水線解決方案，本文将提供一種結合 Serverless 雲服務和阿裡雲容器服務 K8s 的解決方案。
解決方案
本文假設訓練，預測推理使用阿裡雲 K8s（ACK） 叢集 或者是基于 ECS 自搭的 K8s 叢集。訓練使用了
Fashion MNIST dataset。預測服務接受圖檔輸入産生對應的預測結果 （如是衣，帽，鞋）。Training 和 serving 有分别的容器鏡像。流水線編排使用阿裡雲
函數工作流（FnF）和
。FC 和 FnF 都是 Serverless 雲服務，都有全托管，免運維，隻為使用量付費，無限擴充等特性。流水線邏輯圖如下：
- 算法，調參或者其他代碼改動觸發 阿裡雲容器鏡像服務鏡像 （image）建構
- 鏡像建構成功後配置的 webhook 觸發 函數計算 HTTP 觸發器 ，函數實作了發起函數工作流流程執行。
- FnF 調用 FC 函數向使用者 VPC 内的 K8s apiserver 發起建立任務（jobs）的請求， apiserver config 通過容器服務 DescribeClusterUserKubeconfig 接口獲得。模型訓練成功後，模型檔案會被上傳到 OSS。
- FnF 調用 FC 函數向 K8s apiserver 發起建立部署 （deployments）的請求，K8s 會啟動容器從 OSS 下載下傳模型，并且監聽本地 8501 端口接受預測/推理請求。此時的 serving 服務還無法從 cluster 外部通路。
- FnF 調用 FC 函數向 K8s apiserver 發起建立服務（service）的請求，并且指定 service spec type: LoadBalancer，K8s 根據這個 spec 會建立相應的可以公網通路的 SLB，産生 internet IP 接受 HTTP 請求。
- FnF 調用 FC 向 serving service 發起 HTTP Restful API 調用，判斷模型預測精度品質，測試結束後發起人工稽核。
- 如果人工稽核通過則繼續部署生産環境，步驟類似 3，4，5，此處不再重複。
方案部署教程
- 依照 Github awesome-fnf/machine-learning-pipeline 項目 README 操作步驟完成部署
- 從 函數工作流控制台 開始流程執行，輸入 input 見 Github README.md，點選下面視訊播放流水線效果：
方案分析
上文提到了使用阿裡雲 Serverless 服務函數計算（FC）和函數工作流 (FnF) 來實作 ML 流水線的協調，有一個很自然的問題就是為什麼要做這樣的選型，相比已有的開源的工作流引擎有哪些優勢。回答這個問題還是要回到
問題定義
部分中我們列出的生産環境 ML 流水線需要具備的能力一一對比分析：
| 比較項 | FnF & FC | Apache Airflow | Uber Cadence | Jenkins |
|---|---|---|---|---|
| 長時間執行 | 支援 | |||
| 流程可視化 | 有 | 強 | 無 | |
| 狀态可觀測 | 可視化 + API | API | 可視化 | |
| 描述能力 | FDL 描述，高度靈活 | Python DAG 有向無環圖描述，受限于資料結構，缺少循環能力，選擇功能較弱 | 代碼描述，最靈活 | 多種語言 DSL 描述，各步驟類型更适用于 CI/CD，不适用于通用任務 |
| 事件不丢失 | 保證 | |||
| 狀态持久化 | ||||
| 高可用 | 不保證，需要額外投入實作 | |||
| 低延遲 | 延遲低，100ms 級别步驟轉換間隔 | 延遲高，10s 級别步驟轉換間隔 | 延遲較低，亞秒級别步驟轉換間隔 | 無資料 |
| 水準擴充架構 | 強，無限水準擴充 | 弱，單叢集有瓶頸，需要分叢集+分資料庫做流量擴充 | 弱，單叢集有瓶頸，需要分叢集做流量擴充 | |
| 經濟成本效率 | 高效， Serverless 服務僅按使用付費 | 低效，單租叢集，多個團隊部署多套限制浪費明顯 | 低效，支援多租戶。自搭叢集有閑置浪費。 | |
| 運維成本 | 低，Serverless 服務免運維 | 高，多個團隊多套叢集，每個叢集多個微服務監控，部署，擴容縮容，failover 機器等 | 高，單叢集多個微服務監控，部署，擴容縮容，failover 機器等 | |
| 阿裡雲雲服務內建 | 有，FC, MNS 隊列 | 無，需要自己實作 | ||
| 适用場景 | 通用工作流引擎 | 對延遲，穩定性可以容忍，任務執行較長的批量任務編排 | 專注于 CI/CD pipeline, 有很多已有的 CI/CD 功能友善使用 |
FnF & FC 的方案較開源工作流/流水線方案滿足上文提出的對生産環境 ML 流水線的所有要求，并且在以下的特點尤其突出：
- 高可用，低延遲，無限水準擴充
- 與阿裡雲服務的原生內建：FnF 是阿裡雲産品中第一個專注于工作流的産品，通過原生內建 Serverless 計算服務函數計算，消息服務 MNS 等阿裡雲服務，打通了幾乎所有阿裡雲産品的編排。加上自身靈活的流程 FDL 描述，滿足了從簡單到複雜的各式工作流場景。
- 經濟成本成本效率高：沒有閑置的流水線服務叢集，資源使用率最高
- 運維成本低：全托管，免運維，研發傳遞效率最高。機器學習模型訓練等計算資源相對較重（如 K8s 叢集，GPU 執行個體），運維壓力也相對重。ML 流水線這類系統通過 Serverless 服務的實作，從主計算資源中剝離出來，不僅簡化了 K8s 叢集上的部署，也免除對流水線系統的運維，讓時間更有效地投入在模型訓練，算法調優上。
- 描述能力靈活和可視化的結合：上文介紹的 ML 流水線，是過度簡化過的實作，實際業務中的流程邏輯會更複雜。例如在某步驟失敗後要實作自動復原，或者循環回到之前的步驟重新進行。相比于 DAG，FnF FDL 描述更靈活，滿足更複雜的流水線場景。自帶可視化降低了流程開發難度也增強了運作過程中的可觀測性。
場景延伸
本文解決方案中, 訓練和預測服務環節是通過 K8s 上的任務 (jobs) 和部署（deployments）實作的，K8s 叢集是一種相對較重的資源，資源使用率低是常見的問題。函數工作流結合函數計算解決方案的一大優勢是其極高的靈活性，例如下列的使用方式：
- FC 預測服務: 對于成本控制和資源使用率要求較高的使用者，預測服務也完全可以以 的形式暴露，降低 K8s 叢集 node 數量，實作 Serverless 的預測服務（參考文章 為你寫詩：3 步搭建 Serverless AI 應用 以及 基于函數計算 + TensorFlow 的 Serverless AI 推理 ）。
- FC 模型訓練：假設訓練模型速度較快，且不需要使用 GPU 這類資源，訓練任務也可以選擇使用 FC 來實作，真正實作了 Serverless ML。
- FC 資料清洗，預處理 ETL：對于資料需要大規模并行清洗，或者 map-reduce 的場景，使用 FnF + FC 高效可靠地提供 ETL 資料清洗，預處理能力 （參考文章 使用函數工作流+函數計算輕松建構 ETL 離線資料處理系統
- 異構計算資源：FnF 中的訓練步驟也可以由函數計算發起 彈性容器執行個體ECI 任務，或是送出到 阿裡雲 PAI 機器學習平台
更多排列組合，期待開發者的發掘。
聯系我們
關于函數工作流或是函數計算有任何需求，回報讨論，歡迎加入官方釘釘群：
函數工作流官網群
- 群号：23116481
生産中的 Serverless 機器學習流水線
函數計算官網群
- 群号：11721331
生産中的 Serverless 機器學習流水線