Fission 1.4 更新重點聚光燈

你知道 Fission 能夠部署 Tensorflow ML 模型了嗎 ?

ta-ching chen

2 minute read

 文章目錄

Introduction 

在近兩個月的時間裡，針對來自不同用戶的反饋及問題回報 (包含前陣子的通靈故事 Localhost 迷航記)， 我們在 1.4.0 與 1.4.1 做出許多值得一提的改變，讓 Fission 能更加適應跑在不同生產環境上。就讓我們來看看多了什麼改變吧!

Highlight 

新的實驗環境: Tensorflow Serving 

Tensorflow 作為被廣泛接納的機器學習框架，許多公司會利用它來訓練自家模型。但常會發生:

  1. 工程師懂得寫跟訓練模型，卻沒有相關部署知識
  2. 需要花額外時間撰寫 RESTful API server 來服務請求

因此「如何將機器學習模型快速部署到生產環境上」，一直是許多人心中的痛。

有鑑於此 Tensorflow 官方推出 (Tensorflow) Serving 試圖降低模型產出到部署之間的難度。 只要將模型放到對應資料夾內，Serving 偵測到模型後便會啟動對應 API server 服務，甚至版本異動時亦會將請求流量逐步轉移至新的模型。

然而，實際營運上考慮的因素絕不單單只有「將模型利用 API server 來服務預測請求」這麼簡單。

更多數情況我們會問的是:

如何大規模部署機器學習模型? (How to deploy ML models at scale?)

這個問題就牽涉到「底層架構」與「服務水平伸縮」等等議題。

而這勢必需要有對應的人員的協助，因此實際上它只解決部署上的部分問題。但經過仔細思考後可以發現:

「模型」在某種程度上等價於 FaaS 概念中的「function」

因此只要有工具能夠大規模部署與管理 Function，問題自然迎刃而解!

Fission基於 Kubernetes 之上的 FaaS (Function-as-a-Service) 框架 作為基於 Kubernetes 的 serverless 框架在處理類似問題已經有一定經驗， 在 1.4.0 開始 Tensorflow Serving 的加入，意味著使用者可以利用 Fission 同時部署已有 functions 與 ML models!

更多細節請看 這裏 跟 PR#1212。

可調整的 Keep-Alive 設定 

由於已知問題，假設使用者更新 function 後 router 會需要一段時間才能將請求流量從 v1 轉移至 v2 function。當時考慮到使用者可能更加希望做到快速切換版本，我們決定在 code-level 上關閉 Keep-Alive 的設定。

當然每個決定背後都有代價，對於不常更新的 function 而言，關閉 Keep-Alive 帶來的是更高的延遲時間。在觀察用戶的使用情況後，我們決定將設定的調整權利交還給使用者決定， 由用戶根據營運狀況自行調整。

啟用方式非常簡單，將 router deployment 的 ROUTER_ROUND_TRIP_DISABLE_KEEP_ALIVE 環境變數改為 false 即可。

值得注意的是啟用 Keep-Alive 後會帶來幾項變化

  1. 若 function 的 executor type 為 newdeploy 的話，router rollout 至新版 function 的時間會增加。若要縮短或避免這個問題，可以在建立 environment 時設定較短的 grace period (--graceperiod)。

  2. 為了維持 active connections，router 的記憶體使用量會增加。

更多細節請看 PR#1225。

可調整的 Log Level 設定 

在忙碌時過多的 Info 或 Debug 訊息會造成元件運作的資源使用率上升或效率下降的問題，針對此問題我們調整元件內日誌的打印等級 (level) 以及減少不必要欄位。 採用預設安裝時，僅會打印 Info-Level 及其上的日誌內容。想要進行除錯的話，只要將元件 DEBUG_ENV 環境變數設置成 true 即可。

更多細節請看 PR#1217。

Function 會隨著 Configmaps/Secrets 異動時而更新 

和 Kubernetes 隨著時間會自動更新 configmaps/secrets 掛載文件的機制不同，過往在處理 function 用到的 configmaps/secrets 是在啟動前將對應的 configmaps/secrets 下載至 function pod 內。這樣的機制容易實作卻也造成 function 回傳 stale data 的問題。

此次更新中，executor 會偵測 configmaps/secrets 更新事件，並且找出對應的 function 更新，確保能夠快速回傳新資料。

更多細節請看 這裏 跟 PR#1224。

Go 環境開始支援 Go module 

過去由於 Go 的相依管理工具眾多，使得在先前版本會要求使用者先下載相依套件至 vendor 下。直到 Go 1.11 後官方 toolchain 開始支援 Modules後， 開始有許多開源專案逐漸轉移至 go modules 作為預設相依管理工具。

然而由於 Go 1.11 在編譯 go plugin 時對 Modules 支援仍然有問題，致使 Go server 載入 plugin 會顯示版本不符。想體驗的話，請務必使用 fission/go-env-1.12 及其之後的版本。

更多細節請看 這裏 跟 PR#1152。

Conclusion 

看到越來越多用戶使用 Fission 真的是件很值得開心的事情! 最近也忙著進行內部重構，到下個版本肯定會再度進化 XD

在結束前讓我們再次複習更新重點:

  • 新的實驗環境: Tensorflow Serving
  • 可調整的 Keep-Alive 設定
  • 可調整的 Log Level 設定
  • Function 會隨著 Configmaps/Secrets 異動時而更新
  • Go 環境開始支援 Go module

心動不如立刻行動: https://docs.fission.io/installation/

相關文章

文章內容的轉載、重製、發佈，請註明出處: https://tachingchen.com/tw/
comments powered by Disqus