近日，京東發(fā)布登月機器學(xué)習(xí)平臺，并在京東云上線，正式對外提供人工智能服務(wù)。登月機器學(xué)習(xí)平臺的上線代表著京東人工智能技術(shù)從應(yīng)用級服務(wù)到基礎(chǔ)算法的全面對外開放，實踐著京東RaaS(零售即服務(wù))的發(fā)展策略。今天我們邀請了AI與大數(shù)據(jù)部的工程師為大家深度解密京東登月平臺基礎(chǔ)架構(gòu)。

從2016年9月開始，京東AI基礎(chǔ)平臺部基于Kubernetes和Docker構(gòu)建機器學(xué)習(xí)平臺的底層架構(gòu)，后續(xù)逐步完善和優(yōu)化了網(wǎng)絡(luò)、GPU管理、存儲、日志、監(jiān)控、權(quán)限管理等功能。目前集群管理的容器實例數(shù)量有5K+，至今已上線運行了20多個AI前向服務(wù)(50多個API)，同時為后向訓(xùn)練提供支持，在618大促中表現(xiàn)高效穩(wěn)定。

架構(gòu)

登月平臺的基礎(chǔ)架構(gòu)以Docker+Kubernetes為中心，底層基礎(chǔ)設(shè)施包括CPU、GPU、FPGA計算資源，IB、OPA高速互聯(lián)網(wǎng)絡(luò)以及多樣化的文件系統(tǒng)，之上是機器學(xué)習(xí)框架和算法庫，最上層是業(yè)務(wù)應(yīng)用。管理中心包括權(quán)限管理、任務(wù)管理、流程管理、監(jiān)控中心、日志中心。

平臺整體設(shè)計思想是Kubernetes調(diào)度一切，應(yīng)具有以下特性(為了方便起見所有的inference類型的應(yīng)用我們稱為App，所有training類型的應(yīng)用我們稱為Job)：

高可用、負(fù)載均衡。大量的inference App運行在容器中，需要保證App能夠穩(wěn)定高效的對外提供服務(wù)。

應(yīng)用打包與隔離。研究人員、開發(fā)人員將自己的代碼打包成image，方便的進行CI/CD，透明的將自己的App運行于平臺中。

自動擴容/縮容，training/inference用同一批機器調(diào)度。白天有許多活躍的用戶，平臺應(yīng)該擴展更多inference App，而到了晚上，應(yīng)該將更多的資源分配給training Job。

作為大數(shù)據(jù)調(diào)度平臺。平臺不僅可以原生的調(diào)度Tensorflow/Caffe/XGBoost/MXNet等機器學(xué)習(xí)、深度學(xué)習(xí)工具包，也應(yīng)該將Hadoop/Spark系列的大數(shù)據(jù)生態(tài)系統(tǒng)調(diào)度在Kubernetes中。

支持豐富的硬件資源類型。根據(jù)不同的App，Job類型，應(yīng)該使用不同的硬件資源以提高加速比，平臺不僅需要支持CPU、GPU，還應(yīng)該支持FPGA，InfiniBand，OPA等專用高速計算資源。

最大化利用整個集群資源。顯而易見，對于平臺來說已經(jīng)不再區(qū)分是inference App還是training Job，所有的計算資源都統(tǒng)一在一個大的資源池中。

推行數(shù)據(jù)隔離架構(gòu)，保證數(shù)據(jù)安全。通過網(wǎng)絡(luò)優(yōu)勢將數(shù)據(jù)和計算進行分離，提供更高級別的數(shù)據(jù)access權(quán)限。

多租戶安全保證。平臺接入公有云，需要支持multi-tenancy的架構(gòu)，不同的用戶共享計算資源的池子，但是彼此在網(wǎng)絡(luò)級別、文件系統(tǒng)級別、Linux內(nèi)核級別都相互隔離。

登月平臺架構(gòu)

網(wǎng)絡(luò)

Kubernetes自身不具備網(wǎng)絡(luò)組件，需要使用第三方網(wǎng)絡(luò)插件實現(xiàn)。前期我們調(diào)研了Flannel、Weave、Calico三種容器網(wǎng)絡(luò)，并做了性能對比測試。由于Flannel、Weave都是overlay網(wǎng)絡(luò)，均采用隧道方式，網(wǎng)絡(luò)通信包傳輸過程中都有封包拆包處理，因此性能大打折扣;而Calico基于BGP路由方式實現(xiàn)，沒有封包拆包和NAT，性能堪比物理機網(wǎng)絡(luò)。

另外，Calico是純?nèi)龑拥臄?shù)據(jù)中心解決方案，主機之間二層通信使用的是物理機的MAC地址，避免了ARP風(fēng)暴。除了路由方式，Calico也支持IPIP的隧道方式;如果使用BGP方式，需要機房的網(wǎng)絡(luò)設(shè)備開啟BGP功能。

公有云上需要解決的一個重要問題就是多租戶網(wǎng)絡(luò)隔離，我們使用了Kubernetes自身的NetworkPolicy和Calico的網(wǎng)絡(luò)策略實現(xiàn)。給每個用戶分配一個單獨的Namespace，Namespace內(nèi)部的Pod間可以通信，但Namespace之間的Pod不允許通信。Kubernetes的NetworkPolicy只支持對“入流量”(ingress)作限制，而Calico的網(wǎng)絡(luò)策略作了更多的擴展，支持對“出流量”(egress)作限制，而且還具備更精細(xì)的規(guī)則控制，如協(xié)議、端口號、ICMP、源網(wǎng)段、目的網(wǎng)段等。

大部分容器網(wǎng)絡(luò)給容器分配的IP只對集群內(nèi)部可見，而登月平臺上很多前向服務(wù)對外提供RPC接口，需要將容器IP暴露到集群外部。經(jīng)調(diào)研之后選用了Cisco開源的Contiv項目，它的底層原理是用OVS打通了容器的跨主機通信，我們使用的是它的VLAN模式，相對于基于隧道技術(shù)實現(xiàn)的overlay網(wǎng)絡(luò)來說，這是underlay網(wǎng)絡(luò)，它不是構(gòu)建于物理機的網(wǎng)絡(luò)之上，而是與物理機位于同一網(wǎng)絡(luò)層面，這種網(wǎng)絡(luò)的性能接近于物理網(wǎng)絡(luò)。

存儲

Kubernetes本身不提供存儲功能，而是通過存儲插件與第三方存儲系統(tǒng)實現(xiàn)，Kubernetes支持二十多種存儲后端，我們選用了Glusterfs。

Glusterfs是面向文件的分布式存儲系統(tǒng)，架構(gòu)和部署都很簡單，社區(qū)版已經(jīng)足夠穩(wěn)定，它的特點是：彈性、線性橫向擴展、高可靠。Glusterfs在架構(gòu)上消除了大多數(shù)文件系統(tǒng)對元數(shù)據(jù)服務(wù)的依賴，取而代之的是以彈性哈希算法實現(xiàn)文件定位，優(yōu)化了數(shù)據(jù)分布，提高了數(shù)據(jù)訪問并行性，極大地提升了性能和擴展性。

Kubernetes的Volume支持靜態(tài)分配和動態(tài)分配兩種方式。靜態(tài)分配指的是由管理員手動添加和刪除后端存儲卷，動態(tài)分配則是使用Kubernetes的StorageClass結(jié)合Heketi服務(wù)實現(xiàn)。Heketi是Glusterfs的卷的管理服務(wù)，對外提供REST接口，可以動態(tài)創(chuàng)建、銷毀Glusterfs Volume。

Glusterfs雖然性能很好，卻不適合存儲海量小文件，因為它只在宏觀上對數(shù)據(jù)分布作了優(yōu)化，卻沒在微觀上對文件IO作優(yōu)化。登月平臺上大多數(shù)前向服務(wù)都是圖像識別應(yīng)用，需要將圖片和識別結(jié)果保存下來，用作訓(xùn)練數(shù)據(jù)，進行算法的迭代優(yōu)化。我們在調(diào)研之后采用了SeaweedFS作為小文件存儲系統(tǒng)。

SeaweedFS的設(shè)計思想源于Facebook的Haystack論文，架構(gòu)和原理都很簡單，性能極好，部署和維護也很方便。SeaweedFS對外提供REST接口，結(jié)合它的filer服務(wù)可實現(xiàn)目錄管理，我們在此基礎(chǔ)上實現(xiàn)了批量上傳和下載功能。SeaweedFS具有rack-aware和datacenter-aware功能，可根據(jù)集群的拓?fù)浣Y(jié)構(gòu)(節(jié)點在機架和數(shù)據(jù)中心的分布情況)實現(xiàn)更可靠的數(shù)據(jù)冗余策略。目前登月平臺上很多圖像服務(wù)已經(jīng)接入SeaweedFS，每天存儲的圖片數(shù)量達到600萬張，存儲量以每天30G的速度增長。

因為多數(shù)計算任務(wù)都會使用HDFS，所以HDFS也是登月平臺必不可少的存儲組件。為了提高數(shù)據(jù)讀寫速度，我們引入Alluxio作為HDFS的cache層，跟直接讀寫HDFS相比，性能提升了幾十倍。

在文件系統(tǒng)的多租戶隔離方面，使用Kerberos和Ranger對HDFS作安全管理，Kerberos提供了身份驗證，Ranger提供了權(quán)限校驗。而Glusterfs的Volume使用mount方式掛載到容器中，本身就可將用戶限定在特定卷中，因此可變相支持多租戶隔離。

GPU資源管理

平臺當(dāng)前使用的Kubernetes 是1.4版本，當(dāng)時社區(qū)還沒有加入對多GPU的支持，我們就自己開發(fā)了多GPU管理，包括：GPU探測與映射，cuda driver管理與映射，GPU健康檢查和狀態(tài)監(jiān)控，GPU-aware調(diào)度等。GPU-aware調(diào)度可根據(jù)GPU型號、顯存大小、空閑的GPU數(shù)量等條件合理地調(diào)度應(yīng)用程序，以保證資源利用率最大化。

負(fù)載均衡

登月平臺的前向服務(wù)對外提供的通信接口有RPC和HTTP兩種。RPC服務(wù)可以通過注冊中心和RPC Client實現(xiàn)負(fù)載均衡，HTTP服務(wù)使用的是Kubernetes 社區(qū)的ingress組件實現(xiàn)負(fù)載均衡。Ingress的本質(zhì)是對Nginx作了封裝。用戶只需將Ingress規(guī)則配置到Kubernetes里，指定服務(wù)的Host、Path與Kubernetes的Service之間的映射關(guān)系，然后Ingress-controller實時監(jiān)控規(guī)則的變化，并生成Nginx配置文件，將Nginx程序reload，流量就會被分發(fā)到Serivce對應(yīng)的Pod上。

CI/CD

我們選用Gitlab+Jenkins+Harbor作為持續(xù)集成/部署的組件。開發(fā)者將代碼提交至Gitlab，由Jenkins觸發(fā)編譯、打包的規(guī)則，并生成Docker鏡像push到Harbor上。當(dāng)用戶執(zhí)行上線操作后，鏡像被拉取到Kubernetes集群的Worker節(jié)點上，啟動容器。平臺使用Harbor搭建了私有倉庫和mirror倉庫，為了加速拉取鏡像的速度，在不同機房作了復(fù)制倉庫。

日志

在日志采集方面，我們采用了業(yè)界普遍的解決方案EFK：容器將日志打到標(biāo)準(zhǔn)輸出，由docker daemon落盤存到宿主機的文件里，然后經(jīng)Fluentd收集，發(fā)給Kafka，再經(jīng)Fluentd轉(zhuǎn)發(fā)到Elasticsearch，最后通過Kibana展示給用戶作查詢和分析。之所以中間加了Kafka，一是對流量起到削峰填谷的作用，二是方便業(yè)務(wù)方直接從Kafka上消費日志導(dǎo)入第三方系統(tǒng)處理。

監(jiān)控

我們采用的是Heapster+Influxdb+Grafana監(jiān)控組件。Heapster定期從每個Node上拉取Kubelet暴露出的metric數(shù)據(jù)，經(jīng)過聚合匯總之后寫入Influxdb，最終由Grafana展示出來。Heapster提供了Container、Pod、Namespace、Cluster、Node級別的metric統(tǒng)計，我們對Heapster作了修改，加入了Service級別的metric聚合，以便用戶從應(yīng)用的維度查看監(jiān)控。

Kubernetes調(diào)度Spark

重點說一下Spark on Kubernetes。該開源項目由Google發(fā)起，旨在將Spark能夠原生的調(diào)度在Kubernetes中，和YARN、Mesos調(diào)度框架類似。

業(yè)界有一種比較簡單的做法，就是將Spark Standalone模式運行在Docker中，由Kubernetes進行調(diào)度。

該做法具有以下缺點：

Standalone本身就是一種調(diào)度模式，卻跑在另一種調(diào)度平臺中，架構(gòu)上重疊拖沓。

Standalone模式跑在Kubernetes中經(jīng)過實際測試，很多機器學(xué)習(xí)任務(wù)性能會有30%以上的衰減。

需要預(yù)先設(shè)定Worker的數(shù)量，Executor進程和Worker進程跑在同一個Container中，相互影響。

無法完成多租戶的隔離。在同一個Docker中Worker可以啟動不同用戶的Executor，安全性很差。

為了解決上述問題，Kubernetes需要原生支持調(diào)度Spark，架構(gòu)圖如下：

Native Spark on Kubernetes架構(gòu)

從Kubernetes的角度出發(fā)，把Driver和Executor分別Container化，完成原生調(diào)度，架構(gòu)清晰。

繼承了Docker的計算資源隔離性，并且通過Kubernetes的Namespace概念，可以將不同的Job從網(wǎng)絡(luò)上徹底隔離。

可以保持多版本并行，Spark-submit提交任務(wù)的時，可根據(jù)用戶需求定義不同版本的Driver和Executor。

從Cluster模式的角度來觀察Spark on Kubernetes，顯而易見的結(jié)論是，我們已經(jīng)不再有一個所謂的“Spark Cluster”，取而代之的是Kubernetes調(diào)度了一切，Spark Job可以無縫地與其他應(yīng)用對接，真正形成了一個大的調(diào)度平臺。

當(dāng)前的社區(qū)的版本是非生產(chǎn)環(huán)境下的，我們團隊為此做了大量的benchmark測試，穩(wěn)定性測試等等。為了支持更多的需求，如multi-tenancy，python job， 我們修改了部分代碼，維護了京東的一套版本。

計算與數(shù)據(jù)分離

在Hadoop生態(tài)圈，數(shù)據(jù)本地性一直被津津樂道。但是在容器化、云的領(lǐng)域，大家都在推崇存儲中心化，數(shù)據(jù)和計算分離，現(xiàn)在有越來越多的公司正在將存儲和計算相分離，這主要是得益于網(wǎng)絡(luò)帶寬的飛速發(fā)展。不說專有網(wǎng)絡(luò)，就說通用的25G網(wǎng)絡(luò)，還有RDMA和SPDK等新技術(shù)的使用，讓我們具備了存儲計算分離的能力。

從架構(gòu)的角度看有如下意義：

1、多租戶場景，數(shù)據(jù)安全性得到保證，實現(xiàn)物理上的隔離。

2、部署機房可以靈活多變，計算資源和存儲資源可以分機房部署。當(dāng)然，如果需要性能保證，可以加入中間件例如Alluxio。

3、平臺可以方便的部署在用戶網(wǎng)絡(luò)，而不改變其數(shù)據(jù)結(jié)構(gòu)。例如聯(lián)通、工商銀行等。

對于Tensorflow/Caffe/MXNet框架來說，Glusterfs可以直接滿足需求。而對于Spark框架，我們直接用HDFS和Spark相分離的計算架構(gòu)，經(jīng)過大量的Benchmark，10G網(wǎng)絡(luò)下LR，KMEANS，Decision Tree，Native Bayes等MLlib算法，數(shù)據(jù)分離與數(shù)據(jù)本地性對比，性能損失在3%左右。這樣一來，所有的機器學(xué)習(xí)/深度學(xué)習(xí)框架都可以統(tǒng)一架構(gòu)，將計算和存儲相分離。

Kubernetes作為容器集群管理工具，為應(yīng)用平臺提供了基于云原生的微服務(wù)支持，其活躍的社區(qū)吸引了廣大開發(fā)者的熱情關(guān)注，刺激了容器周邊生態(tài)的快速發(fā)展，同時為眾多互聯(lián)網(wǎng)企業(yè)采用容器集群架構(gòu)升級內(nèi)部IT平臺設(shè)施，構(gòu)建高效大規(guī)模計算體系提供了技術(shù)基礎(chǔ)。

AI基礎(chǔ)平臺部是一個專注、開放的team，致力于打造安全高效的機器學(xué)習(xí)平臺架構(gòu)，為登月算法平臺提供底層支持，研究方向主要為Kubernetes，AI算法工程化，大數(shù)據(jù)系統(tǒng)虛擬化等方向。

感謝Intel公司在Spark on k8s，BigDL等領(lǐng)域為我們提供了有力支持和寶貴經(jīng)驗。

來源：京東大數(shù)據(jù)