文 | 廣州醫(yī)科大學(xué)附屬第五醫(yī)院信息科，廣東高校生物靶向診治與康復(fù)重點實驗室 李斌 高振宇

隨著大數(shù)據(jù)應(yīng)用的普及以及深度學(xué)習的快速發(fā)展，深度神經(jīng)網(wǎng)絡(luò)模型依靠海量數(shù)據(jù)的學(xué)習和極深的網(wǎng)絡(luò)深度，在很多領(lǐng)域取得了不亞于人類的結(jié)果。而在醫(yī)療行業(yè)中，模型計算的準確率是其能否應(yīng)用到臨床的一個非常重要的指標。當前很多深度神經(jīng)網(wǎng)絡(luò)模型為了提高計算精確度，其模型的大小正在變得越來越大，從幾十GB到上百GB不等。這些大模型相對小模型具有更高的準確度，但是在部署，特別是在分布式的環(huán)境下，常常遇到難以升級迭代的問題。

一、問題分析

容器技術(shù)目前已經(jīng)相當成熟，相比傳統(tǒng)虛擬化技術(shù)構(gòu)建的虛擬機，容器的性能和部署便捷性要遠遠優(yōu)于虛擬機。特別是在需要異構(gòu)計算的人工智能領(lǐng)域中，為了能更好利用GPU的性能來進行模型訓(xùn)練和推理，采用容器方案可以更好地適配訓(xùn)練和推理中對性能和擴展性的需求。Kubernetes目前已經(jīng)成為了私有云容器集群編排管理的事實標準，通過Kubernetes可以非常便捷管理容器的整個生命周期。但是目前Kubernetes對于深度學(xué)習的場景支持還是不充分的，Kubernetes的架構(gòu)對于stateless容器和使用共享存儲的state-ful場景有比較好的支持，但是對于深度學(xué)習節(jié)點，因其所依賴的數(shù)據(jù)十分龐大，而且對性能的苛刻要求，所以共享存儲的性能是不能滿足實際生產(chǎn)環(huán)境要求的。另一方面，Kubernetes對于容器使用本地持久化存儲的支持有限，它難以管理容器的依賴數(shù)據(jù)的生命周期。在實際生產(chǎn)環(huán)境中，醫(yī)學(xué)方面的模型往往是非常大的，例如一個多模態(tài)的從DR圖片生成檢查報告的模型的大小往往在十幾GB，其訓(xùn)練過程中所需要的數(shù)據(jù)會達到數(shù)TB。由于Kubernetes的特殊機制，Pod的描述信息一旦發(fā)生變化就必須重建。所以這種深度神經(jīng)網(wǎng)絡(luò)模型容器哪怕只是更新了一個簡單的配置也會引發(fā)容器銷毀，新建的容器需要耗費大量的時間把依賴數(shù)據(jù)通過網(wǎng)絡(luò)拉取到本地，最后造成新啟動的容器往往遲遲不能提供服務(wù)，時間成本較高。

二、現(xiàn)有方法

為了降低時間成本，盡快讓銷毀重建的容器重新提供服務(wù)，常見的解決方案是添加更多的硬件資源或者采用并行拉取的方式來提升網(wǎng)絡(luò)拉取數(shù)據(jù)速度，這需要投入更多的設(shè)備用于提高整個網(wǎng)絡(luò)的數(shù)據(jù)鏈路傳輸性能。另一種方案是限定Pod（Kubernetes 中創(chuàng)建和管理的、最小的可部署的計算單元）的調(diào)度范圍，使Pod只能調(diào)度到指定的一批Kubernetes工作節(jié)點上，提高Pod調(diào)度回原來節(jié)點或者相似節(jié)點的概率，以減少拉取數(shù)據(jù)的工作，這種方法利用了Kubernetes的自身的調(diào)度策略，需要人工篩選特定機器后再去進行綁定。但是即使利用該方式也難以保證Pod可以調(diào)度到理想的節(jié)點上。

（一）建立多個數(shù)據(jù)服務(wù)集群

一個容器的模型或其依賴的數(shù)據(jù)量如果很大，一般會選擇將其存儲在一個方便遠程拉取的集群中，常見的方式是將容器依賴的數(shù)據(jù)上傳到HDFS(Hadoop Distributed File System)集群上，由HDFS集群充當數(shù)據(jù)服務(wù)集群，Pod啟動后其sidecar容器從數(shù)據(jù)服務(wù)集群將所依賴的數(shù)據(jù)拉取下來。但是在多IDC機房環(huán)境中，單一數(shù)據(jù)服務(wù)集群的網(wǎng)絡(luò)速率往往在跨IDC的數(shù)據(jù)傳輸中變得很慢。建立多數(shù)據(jù)服務(wù)集群可以有效解決這個問題，不同的IDC的數(shù)據(jù)服務(wù)集群利用IDC之間的網(wǎng)絡(luò)同步數(shù)據(jù)，Pod的sidecar從所屬IDC的數(shù)據(jù)服務(wù)集群拉取數(shù)據(jù)，避免出現(xiàn)跨IDC交互。該方案的缺點是需要投入大量的服務(wù)器和網(wǎng)絡(luò)改造成本在每個IDC機房建立同質(zhì)化的數(shù)據(jù)服務(wù)集群。

（二）限定容器部署

Kubernetes的默認scheduler可以支持通過設(shè)定tag親和性來調(diào)度Pod到特定節(jié)點上，該方法通過人工在特定的Kubernetes工作節(jié)點打上特定的tag，隨后創(chuàng)建Pod的時候指定Pod只能調(diào)度到打了特定的tag的Kubernetes工作節(jié)點，以此來進行Pod和機器的綁定。這些打上了tag的工作節(jié)點要提前建立好本地持久化存儲，并下載好依賴的數(shù)據(jù)。這種方式需要大量人工介入，難以擴容和縮容符合親和性的機器。除此之外，這種方式不能很好的管理依賴數(shù)據(jù)在本地存儲的生命周期，可能會出現(xiàn)節(jié)點存儲剩余空間不足導(dǎo)致容器被驅(qū)逐的情況。

三、優(yōu)化

目前Kubernetes默認調(diào)度機制沒有考慮拉取容器依賴所產(chǎn)生的影響，默認的調(diào)度策略會優(yōu)先將Pod調(diào)度到計算資源較充足的節(jié)點。而計算資源較充足的節(jié)點往往是新加入集群的節(jié)點，新節(jié)點是沒有在本地緩存任何依賴數(shù)據(jù)的，它需要從遠端通過網(wǎng)絡(luò)拉取大量依賴數(shù)據(jù)。雖然Pod的原節(jié)點已經(jīng)有了大部分依賴數(shù)據(jù)，但是由于調(diào)度策略的影響，重建的Pod往往不能被調(diào)度回原節(jié)點。所以為了能解決Pod中的業(yè)務(wù)容器長期等待依賴數(shù)據(jù)問題，本文提出通過改造Kubernetes的調(diào)度器來將依賴數(shù)據(jù)缺失部分、本地存儲、網(wǎng)絡(luò)實時狀況等因素納入定制化的調(diào)度器考慮范圍中，當出現(xiàn)Pod需要調(diào)度時候，如圖1流程，定制化調(diào)度器會實時計算出所有符合部署的節(jié)點的得分情況，優(yōu)先調(diào)度Pod到能快速完成數(shù)據(jù)依賴加載的節(jié)點上。此外，Pod啟動后的sidecar容器可以支持使用P2P的方式來從別的節(jié)點拉取依賴數(shù)據(jù)，進一步降低業(yè)務(wù)容器數(shù)據(jù)加載時間。

圖1 定制調(diào)度策略調(diào)度Pod流程

（一）定制調(diào)度策略

定制化調(diào)度器策略包含2個部分，分別是Agent和custom-scheduler（cu-sch）。Agent以Daemonset的方式部署在每個Kubernetes工作節(jié)點上。custom-scheduler作為定制化調(diào)度器用于接收Agent上報數(shù)據(jù)和處理Pod的調(diào)度等事務(wù)。

Agent負責實時獲取當前節(jié)點中如表1中所列的節(jié)點緩存數(shù)據(jù)、鏡像列表、網(wǎng)絡(luò)環(huán)境等信息并上報給Kubernetes的定制化調(diào)度器cu-sch。cu-sch收集到節(jié)點上報的信息后可以計算出Pod從調(diào)度完成到可以正常服務(wù)所需消耗的時間，這個時間將作為重要參考因素用于計算各個節(jié)點部署該Pod的優(yōu)先級分數(shù)。通過該流程，cu-sch可以大概率把容器優(yōu)先放置在已經(jīng)存在鏡像和依賴數(shù)據(jù)的節(jié)點上，以避免重復(fù)從遠端拉取數(shù)據(jù)，或是調(diào)度Pod到網(wǎng)絡(luò)條件好的節(jié)點上，以最大程度節(jié)省拉取數(shù)據(jù)的時間。此外，Agent還負責管理節(jié)點上已經(jīng)拉取的依賴數(shù)據(jù)的生命周期，會采用LRU方式將長期不使用的數(shù)據(jù)清理掉。

表1 Agent所需采集上報信息

存儲依賴數(shù)據(jù)的磁盤剩余空間 RemainDataRoom 操作系統(tǒng)提供的接口拉取鏡像的傳輸速率 PullImageRate拉取遠端測試鏡像計算拉取效率拉取依賴數(shù)據(jù)的傳輸速率 PullRelyDataRate拉取遠端測試數(shù)據(jù)計算拉取效率存儲鏡像數(shù)據(jù)的磁盤剩余空間 RemainImageRoom 操作系統(tǒng)提供的接口

Kubernetes 的custom-scheduler是Kubernetes控制平面的核心組件之一。其主要功能是將Pod分配給節(jié)點，同時平衡各節(jié)點的資源利用率。custom-scheduler具有Kubernetes所有的默認調(diào)度策略，而且該調(diào)度器會將鏡像，依賴的存儲等信息考慮進去，進行過濾和打分。如圖2所示，Agent輪詢檢測節(jié)點上已經(jīng)緩存的依賴數(shù)據(jù)，鏡像數(shù)據(jù)。由于每個節(jié)點配置和所處網(wǎng)絡(luò)環(huán)境是不一致的，Agent會從數(shù)據(jù)服務(wù)集群中定時拉取測試文件，用于檢測節(jié)點和數(shù)據(jù)服務(wù)集群之間的網(wǎng)絡(luò)情況，用于后續(xù)customscheduler準確計算每個節(jié)點的得分。

圖2 定制調(diào)度架構(gòu)示意圖

Custom-scheduler具備訪問鏡像服務(wù)和依賴數(shù)據(jù)存儲服務(wù)的能力，可以取得特定相關(guān)鏡像和容器依賴的數(shù)據(jù)的metadata信息，metadata信息中包含鏡像名字，版本，數(shù)字摘要，鏡像層信息，容器依賴的數(shù)據(jù)名字，唯一標示號，大小，信息摘要等信息。隨后和Agent已經(jīng)提交的信息進行比對，可以知道缺少的鏡像層和缺少的依賴數(shù)據(jù)。例如調(diào)度Pod時候，該Pod需要鏡像M，其依賴的數(shù)據(jù)為集合{a,b,c}。鏡像M實際上是由三層構(gòu)成，為{X,Y,Z}。從Agent提交的數(shù)據(jù)中得知某節(jié)點已經(jīng)存在了Y和Z層鏡像以及依賴數(shù)據(jù){a,b}，計算出Pod部署到該節(jié)點只需要拉取{X,c}，最后通過該節(jié)點Agent提供的PullImageRate和PullRelyDataRate可以計算出拉取依賴數(shù)據(jù)的預(yù)計時間。這個計算過程會對所有符合的節(jié)點進行計算以篩選出可以最快部署好Pod并提供服務(wù)的節(jié)點。

（二）P2P-sidecar

P2P-sidecar以sidecar的方式和業(yè)務(wù)容器一起部署和運行。P2P-sidecar基于BitTorrent協(xié)議實現(xiàn)，可以通過P2P的方式從多個不同的節(jié)點拉取所需的依賴數(shù)據(jù)和模型，同時其也支持S3協(xié)議和HDFS協(xié)議用于從數(shù)據(jù)服務(wù)集群拉取數(shù)據(jù)。P2P的引入在不增加數(shù)據(jù)服務(wù)集群的情況下可以很好地提升依賴數(shù)據(jù)拉取的效率，并且很好地緩解數(shù)據(jù)服務(wù)集群壓力，減少網(wǎng)絡(luò)擁塞情況。如圖3所示，P2P-sidecar可以與同個IDC內(nèi)的節(jié)點通信，分塊獲取所需要的數(shù)據(jù)。

四、實驗

實驗過程中使用了20臺物理服務(wù)器，每個物理服務(wù)器都配置了萬兆雙網(wǎng)卡，每個物理服務(wù)器上虛擬5個虛擬機。實驗針對custom-scheduler方案和P2P-sidecar進行了100Pod-150Pod規(guī)模的Deployment部署、Deployment擴容、Deployment升級、Deployment縮容再擴容等常見場景測試。實驗中用于測試的虛擬模型大小為4GB，8GB，16GB，32GB這4種類型，Deployment會隨機選擇模型的組合用于測試。實驗中設(shè)定Deployment的滾動升級中保證其80%的實例Pod是正常運行的。

整個測試進行了三次重復(fù)實驗，實驗結(jié)果如圖4，其結(jié)果表明定制化的調(diào)度策略可以極大優(yōu)化Pod變更后重新部署的耗時，另外，引入的P2P-sidecar可加速依賴數(shù)據(jù)和模型的下載，進一步降低時間成本。

實驗的結(jié)果表明，Kubernetes的Deployment部署的Pod在使用了文本提出的定制化調(diào)度策略后，其在變更過程中可以大概率調(diào)度到已經(jīng)有依賴數(shù)據(jù)的節(jié)點上，Kubelet可以快速拉起容器并恢復(fù)服務(wù)。對比原生Kubernetes的方式，因為減少了重復(fù)數(shù)據(jù)拉取過程，使得整個變更時間降低到原有的5%。另外，P2P-sidecar的引入可以優(yōu)化節(jié)點第一次拉取依賴數(shù)據(jù)的時間，將初次部署的整體時間降低了25%。

五、結(jié)語

圖4 Kubernetes Deployment多場景耗時測試

Kubernetes托管的容器在實際生產(chǎn)環(huán)境中會經(jīng)常因為各種變更而導(dǎo)致重建，重建過程的耗時常常會影響業(yè)務(wù)的迭代效率。本文針對目前Kubernetes托管的醫(yī)學(xué)領(lǐng)域機器學(xué)習容器的數(shù)據(jù)依賴過重導(dǎo)致變更時間成本較高的問題進行分析并提出了使用定制化調(diào)度的方式以及P2P-sidecar來進行優(yōu)化，該方法降低了變更期間容器不能提供服務(wù)的時間。從實驗結(jié)果可以看到該方法對于容器升級這類場景有較大的效率提升，可以很好滿足容器頻繁變更的需求。