KuAI平臺 | 模型在線推理系統的高可用設計

摘要

隨着大數據技術和人工智能技術的發展,越來越多的業務場景,如金融風控、在線廣告、商品推薦、智能城市等,採用大量的機器學習技術來提升服務質量和智能決策水平。針對具體的任務,訓練得到模型後,需要將其封裝、部署上線,提供在線推理服務,解決實際業務問題。

本文提出一種分佈式機器學習模型在線推理系統的完整技術方案,該系統主要採用CPU/GPU 計算節點來提供推理任務的基礎算力,通過Docker容器技術封裝、打包模型推理任務,將不同服務的運行環境完全隔離,並藉助Kubernetes進行服務編排,提供服務的分佈式容災和資源的彈性伸縮功能,同時結合模型倉庫、容器鏡像倉庫、系統/服務狀態監控、服務註冊/訂閱、可視化面板等功能模塊使算法模型與服務架構解耦,使模型的部署上線、更新和管理流程變得簡單,上線效率高、風險低,同時提高預測服務的穩定性、靈活性和服務能力。

模型在線推理服務部署的技術回顧

1. 現有的技術方法

將模型部署爲在線推理服務,當前存在一下幾種技術方法:

① 直接在物理機器上部署。將訓練好的模型文件及對應的推理代碼藉助Flask、Tensorflow Serving等封裝爲Web服務包,拷貝至物理機器,啓動部署。一個物理機器上可能部署一個或多個模型服務。然後將服務接口和調用方式通過文檔的形式提供給模型服務調用方法。

② 在虛擬機上部署。先將物理機器通過vmware、virtual box等虛擬化技術劃分爲多個虛擬機,然後將訓練好的模型文件及對應的推理代碼藉助Flask、Tensorflow Serving等封裝爲Web服務包部署至一個或多個虛擬機上。每個虛擬機上一般只部署一個模型服務,以避免資源衝突。爲解決大規模併發請求,會啓用多個虛擬機和模型服務,通過負載均衡技術將請求流量分轉發至多個機器。最後將統一的對外服務接口和調用方式通過文檔的形式提供給模型服務調用方法。

2. 現有技術存在的問題

① 由於機器學習模型運行的軟件環境、依賴基礎庫及版本多樣,不同模型之間存在差異,部署不同的模型都需要搭建一次基礎環境,存在重複工作,且可能與模型訓練時的環境不一樣,導致運行異常。

② 直接在物理機器上部署多個機器學習模型服務時,雖然可以通過Conda等工具創建虛擬軟件環境的方式隔離多個服務的基礎環境,但多個服務之間會存在資源衝突,影響服務的穩定性。另外,服務均爲單實例部署,不能保證模型服務的高可用性。

③ 在虛擬機上部署同樣存在基礎環境重複搭建問題。另外,爲應對大規模服務請求情況,往往配置較高的虛擬機數量和硬件規格,而大多數服務的調用量往往會隨着業務的漲落而漲落,經常出現類似白天高、夜間低的現象,導致硬件資源在調用量較低期間使用率低,造成資源浪費。

④ 模型推理的準確性由於數據分佈的漂移在一定時間後需要重新訓練模型,更新線上服務,當前的部署方式需要人工選擇某個版本的模型文件、上傳,替換線上的模型文件,根據模型服務封裝方式的不同,可能還需要重啓服務,導致線上服務中斷。另外,該更新過程需要人工操作、無法自動化,且過程繁瑣、缺乏統一管理和追蹤,容易出錯。

高可用模型在線推理系統的設計

1. 總體設計思路

① 基於容器技術,通過預置模型服務的執行環境和容器鏡像,支持Scikit-learn、Tensorflow、PyTorch、Keras、Caffe、MXNet等多種模型框架和基礎環境,無需重複搭建機器學習模型運行的軟件環境。

② 基於開源Kubernetes技術和自研插件,構建Kubernetes集羣,對CPU異構集羣、GPU異構集羣、Ceph/HDFS存儲服務等基礎資源進行隔離和合理的分配、調度,爲模型服務提供高可用的運行時環境,將計算節點集羣化,提供全系統容災保障,無需擔心單點故障。

③ 基於模型在線推理服務資源的彈性擴縮容方法,基於模型服務的資源使用率實時監控指標和期望資源計算公式進行動態的擴展或回縮調整,既保證模型推理服務的資源需求,又減少資源的閒置浪費。

④ 基於模型自動化的模型篩選方法和策略模板,對線上模型服務的更新升級方式進行可視化的配置,使過程變得靈活簡單,且減少人工操作。

2. 系統架構設計

高可用模型在線推理系統的架構圖如下:

圖1 機器學習模型在線推理系統架構圖

該系統包含的各功能模塊的設計以及模塊之間相互協作關係如下文所述:

(A)模型在線服務設計器 :用戶需要將訓練好的機器學習模型部署爲在線服務、對用戶請求服務傳遞的數據進行推理時,通過該系統可視化界面進行相關配置。

配置內容包括:1)服務名稱、服務類型(無狀態服務、有狀態服務)、服務升級策略等;2)從(B)模型倉庫中選擇需要部署爲在線推理服務的模型及對應的版本;3)從(C)容器鏡像倉庫中選擇模型在線推理服務運行的容器鏡像,例如安裝好Scikit-learn、Tensorflow、PyTorch、Keras、Caffe、MXNet等基礎算法庫、依賴包;4)配置服務運行所需的硬件資源(CPU/GPU/內存/存儲等)的需求範圍和分佈式實例的數量範圍;5)模型在線推理服務的輸入/輸出參數等等。

(B)模型倉庫 :指模型構建人員基於不同的框架針對具體機器學習任務訓練好的模型文件及模型元數據信息的管理倉庫,提供模型的版本管理、模型元數據信息的預覽對比、模型的多維度分類、排序、搜索等功能。可將模型倉庫的任意版本模型部署爲批量離線服務或實時在線服務或發佈到模型交易市場。

(C)容器鏡像倉庫 :主要提供模型訓練、模型推理任務等的容器鏡像及鏡像管理,包括不同硬件平臺(CPU/GPU服務器等)上算法模型運行所需的基礎算法庫、依賴包等軟件環境。在(A)模型在線服務設計器中設計具體模型在線推理任務時選擇相應的容器鏡像即可,無需運維重新搭建運行環境。

(D)模型微服務引擎 :根據用戶在(A)模型在線服務設計器中的具體配置,(E)Kubernetes集羣調度器依據服務的計算規格配置,利用節點選擇器將模型服務調度到指定的目標計算節點上,然後從(B)模型倉庫中拉取用戶配置模型文件和對應的模型元數據信息以及從(C)容器鏡像倉庫中拉取用戶配置的模型推理服務運行的容器鏡像到目標節點,通過Service Wrapper模塊將模型算法自動封裝爲可容器化運行的模型推理服務,最後啓動引擎對外提供服務。(D)模型微服務引擎與(E)Kubernetes集羣協同配合。

(E)Kubernetes集羣 :指基於開源的Kubernetes和自研適用於機器學習場景的調度插件搭建的生產級別的容器編排系統,用於對(D)模型微服務引擎中的模型推理服務及其配套的資源進行管理。

基於容器技術、自研調度編排技術對(F)基礎設施中CPU異構集羣、GPU異構集羣、Ceph/HDFS存儲服務等基礎資源進行合理的分配和調度,爲模型服務提供高可用的運行時環境。通過標籤的方式來管理CPU/GPU異構集羣中的計算節點,即將不同的計算節點劃分爲不同的可用區或組。

在部署模型在線服務時,使用節點選擇器將模型在線服務部署至帶有指定標籤的目標計算節點上。爲了保證高可用,每個標籤組合的目標計算節點數大於1。從而避免一臺目標節點宕機後,調度器還能找到滿足條件的計算節點將宕機節點上的在線服務對應的容器遷移到其它計算節點上,從而保證模型在線服務的高可用性。

(F)基礎設施 :包括CPU異構集羣、GPU異構集羣、Ceph/HDFS存儲服務等,爲模型推理服務提供基礎的硬件資源。

(G)模型服務管理 :包括模型在線推理服務的服務發佈、服務註冊、服務發現、服務上下線、服務重啓、服務版本管理等。

(H)壓力測試/在線服務 :指將部署上線的模型推理服務進行壓力測試或開發給需求方提供模型推理服務的功能模塊。壓力測試提供json、數據文件、併發請求三種方式對部署的模型推理服務進行長時間或滿負荷的運行測試,並生成服務的性能、可靠性、穩定性報告;在線服務是指將模型推理服務的API接口、調用方式及反饋狀態相關說明暴露出來,供內、外網請求服務。服務請求經由(I)負載均衡器分發到(D)模型微服務引擎中的各個模型服務實例中。

(I)負載均衡器 :爲每個模型推理在線服務提供自動負載均衡能力,即將(H)壓力測試/在線服務中產生大規模請求流量通過負載均衡算法將請求分配到各個計算節點的容器實例中。負載均衡算法採用隨機法、輪詢法、原地址哈希法、加權輪詢法、最小連接數法等。

(J)系統/服務狀態監控模塊 :對每個模型服務推理的準確性指標(如面向分類模型的精確率、召回率、F1值、AUC等和麪向迴歸模型的MSE、RMSE、MAE等)、模型推理服務的使用情況以及資源的使用狀態進行全方位的採集、存儲,並進行不同時間粒度的彙總計算,主要的監控指標包括CPU使用率、GPU使用率、內存使用率、佔用存儲空間、上下行流量、服務請求數量、服務調用失敗/成功數量、服務響應時延等,並計算反應模型服務性能穩定性和可靠性的衍生指標,如TP99、TP9999等。該部分信息一方面是(K)監控面板上進行可視化的基礎,另一方面也會反饋給(E)Kubernetes集羣,用於指導資源的分配調度和服務的編排。

(K)監控面板 :將(J)系統/服務狀態監控模塊中採集、計算的指標進行可視化,方便用戶瞭解模型在線推理服務的狀態。

3. 模型自動篩選與更新流程

機器學習模型往往會隨着時間的推移進行迭代更新,爲保障模型在線推理服務的準確性,需對其進行即時的升級。本文提出一種模型自動化的模型篩選方法和策略,以減少人工操作。具體流程如圖2所示。

圖2 模型自動篩選、更新流程示意圖

用戶根據系統提供的多種篩選策略模板,進行策略配置以初始化模型篩選器,模型篩選器對(B)模型倉庫中的每個模型及其不同版本的元信息進行檢測,篩選出符合策略所定義要求的模型文件,然後由(D)模型微服務引擎對模型在線推理服務在合適的時段(如(J)系統/服務狀態監控模塊監測到的服務調用量較低的時段或用戶自定義的時段)進行更新。

具體地,本文提出以下5種模型篩選策略模板:

① 由上游數據驅動的模型更新,即篩選出該驅動事件對應的模型;

② 模型推理準確性指標下降或低於一定閾值事件驅動的模型更新,即篩選出該驅動事件對應的模型,模型推理準確性指標由(J)系統/服務狀態監控模塊監測模塊反饋,見圖1;

③ 定期從當前衆多版本中篩選出模型性能評估指標(可以是用戶定義的加權指標,下同)最優的一個模型;

④ 定期從當前衆多版本中篩選出模型性能評估指標在一定閾值之上的最新迭代的一個模型;

⑤ 人工手動指定的模型版本。

4 . 資源彈性擴縮容方法

大多數模型在線推理服務的調用量往往會隨着業務的漲落而漲落,經常出現類似白天高、夜間低的服務請求量波動現象,一方面導致硬件資源在調用量較低期間使用率低,造成資源浪費,另一方面當用量過大時可能影響服務的穩定性和可用性。本文提出一種模型服務資源的彈性擴縮容方法,既保證模型推理服務的資源需求,又減少資源的閒置浪費。具體流程如圖3所示。

圖3 模型服務資源彈性擴縮容流程示意圖

當模型在線推理服務成功部署上線後,(J)系統/服務狀態監控模塊實時監測、計算該服務各容器實例的資源使用率等指標,如CPU使用率、GPU使用率、內存使用率、響應時延等,並進行不同時間粒度的彙總計算。

對上一個時間窗口內資源使用率指標,採用本文提出的容器實例數量計算公式或用戶定義自定義的公式進行計算,得到下一個時間窗口內期望的容器實例數量,然後藉助Kubernetes中的橫向自動擴縮容的功能(HorizontalPod Autoscaling,簡稱 HPA),自動化地調整容器實例數量,然後(J)系統/服務狀態監控模塊繼續實時監控更新後各容器實例的資源使用率等指標,以此循環,實現模型在線推理服務資源的動態調整。

期望的容器實例數量計算公式如下所示:

式中,分別爲CPU使用率、GPU使用率、內存使用率、響應時延4各衡量維度的權重因子,取值範圍爲[0,1],總和爲1,用戶可自行調整,也可以調整時間窗口的大小。ceil表示向下取整。另一方面,用戶也可以基於(J)系統/服務狀態監控模塊提供的其他指標完全自定義期望的容器實例數量計算公式。

總結

(1)本文提出了一種分佈式機器學習模型在線推理系統的完整技術方案,通過Docker容器技術封裝、打包模型推理任務,將不同服務的運行環境完全隔離,並藉助Kubernetes進行服務編排,提供服務的分佈式容災和資源的彈性伸縮功能,同時結合模型倉庫、容器鏡像倉庫、系統/服務狀態監控、服務註冊/訂閱、可視化面板等功能模塊使算法模型與服務架構解耦,使模型的部署上線、更新和管理流程變得簡單,上線效率高、風險低,同時提高預測服務的穩定性、靈活性和服務能力。

(2)本文提出了一種模型自動化的模型篩選方法和策略,提出了5種模型篩選策略模板,使線上模型服務的更新升級變得靈活簡單,且減少了人工操作。

(3)本文提出了一種模型在線推理服務資源的彈性擴縮容方法,基於模型服務的資源使用率實時監控指標和期望資源計算公式進行動態調整,既保證了模型推理服務的資源需求,又減少了資源的閒置浪費。

本文轉載自公衆號京東數科技術說(ID:JDDTechTalk)。

原文鏈接

KuAI平臺 | 模型在線推理系統的高可用設計

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章