在過去的幾年中，我們投入了巨大的精力為我們的團隊構建更好的研究基礎架構。 我們在一些出色的開源項目（尤其是Kubeflow，一個基於Kubernetes構建的開源ML平台）的基礎上，在AWS和Azure上構建了一個多雲研究平台，這使我們的研究團隊能夠規模不斷擴大，交付速度更快。
設計要求
當我們開始構建該平台時，我們提出了一些核心要求：
· 簡便性：該平台應該對沒有Kubernetes，Kubeflow等先驗知識的研究人員來說非常易於使用。它應該儘可能抽象出底層的計算/存儲/集群複雜性。
· 可擴展：由於平台可能包含多個組件，因此我們希望設計一些可以逐步發展的產品。 隨著我們擴展平台功能的不斷增加，功能也會不斷增加。
· 多云：設計一個平台，可以以最少的努力擴展到多個雲提供商。
· 安全：很明顯！
機器學習生命周期
一個好的機器學習平台需要為生成ML模型的各個階段提供適當的工具：
· 早期實驗：在早期，研究人員大多使用諸如Jupyter Notebook之類的開發工具來探索新算法或測試與某些研究論文相關的現有代碼。 在此階段和後續階段，應以較少的更改輕鬆地進行計算和存儲。
· 擴大實驗規模：一旦研究人員對初始實施感到滿意，就可以擴大實驗規模，即預處理和準備大量數據進行訓練，使用不同參數微調ML模型，驗證ML模型等。 。
· 發布新版本模型的管道：一旦發布了具有較高準確性的模型，就必須能夠複製該模型或使用更多數據對其進行進一步訓練，以提高準確性或避免災難性遺忘。 在此階段，培訓管道應該易於創建。
· 服務模型以進行測試：模型發布後，必須將其與實際數據一起部署到暫存或測試位置，以便進行驗證。
架構
為了支持這些用例，我們在下面提供了該平台：
ML平台組件
基礎架構部署
我們使用Terraform部署我們的基礎架構。 每個AWS和Azure組件都是由terraform創建和配置的。 我們使用版本控制來跟蹤更改，並且通過我們的CI工具（Gitlab）驗證了這些更改並應用了Terraform計劃。
控制層（控制器API）
我們在設計控制層上付出了很多努力。 我們希望研究人員完全避免使用Kubernetes，包括配置kubeconfig，權限等。我們最終得到的是一個簡單的命令行工具（我們將其命名為mlcli），可以使用pip輕鬆安裝該工具並可以進行通信。 使用控制器（REST服務）。 然後，控制器使用Kubernetes API遠程（使用k8s python客戶端）通信/創建/更新資源。 這種設計可以通過三種方式幫助我們：
· 為研究團隊輕鬆設置和配置。
· 發布新的改進或以更系統的方式修復錯誤。 像軟體版本一樣，我們將新的更改部署到正在開發的控制器中，一旦通過驗證，我們會將其推廣到所有用戶，並在需要時發布新版本的mlcli。
· 我們公開的API可以被其他團隊輕鬆地用來觸發培訓或遠程運行管道。
命令行工具（mlcli）
mlcli是一個相當簡單的命令行工具。 研究人員可以輕鬆使用它，並且我們支持各種功能。 當前，mlcli提供以下命令，例如筆記本，服務，元數據和作業管理。
計算
我們希望計算的使用儘可能具有彈性和成本效益–雲GPU並非便宜！ 這主要由Kubernetes集群自動縮放器管理-在創建和完成作業時，自動縮放器管理節點的橫向擴展和橫向擴展。 我們使用各種節點組來提供各種實例類，以適應不同的培訓需求。
用戶提交工作時，幕後發生了很多事情：
我們還介紹了使用競價型實例以節省我們的運行成本。 用戶還可以根據需要繞過競價型實例，並通過在mlcli中傳遞–ondemand參數來使用按需節點創建作業。
數據
我們使用S3作為主要數據存儲服務。 為了能夠在Jupyter Notebook或工作中使用數據，我們使用EBS或EFS。
EFS是使用terraform創建的，並使用efs-provisioner在Kubernetes中作為PersistentVolumes掛載。 在為Jupyter / Job / Kubeflow管道創建適當的k8s清單時，持久卷將裝入k8s資源中。 由於在處理多個小文件時EFS速度很慢，因此我們提供了另一種方法來創建EBS卷，並使用mlcli將其附加到筆記本/作業。
對於EBS，通過在k8s中創建AWSElasticBlockStore持久卷聲明（pvc）直接使用動態預配置。 它將自動創建一個EBS卷。 我們還將存儲類的回收策略設置為"刪除"，以便在刪除永久卷聲明（pvc）之後自動清理卷。
我們探索的另一個文件系統是Lustre的Amazon FSx。 Amazon FSx提供了高性能文件系統，該文件系統經過優化，可快速處理類似於機器學習的工作負載。 可以使用aws-fsx-csi-drive將Fsx安裝為PersistentVolume。 我們進行了初步測試，但無法繼續進行，因為當時FSx仍不支持使用KMS加密的S3存儲桶。
日誌和指標
只要與這些作業相關的pod處於活動狀態，就可以通過mlcli看到在我們平台上運行的作業。 但是，為了進一步調試和調查，即使在作業終止或在K8中清理了資源之後，日誌也應該可見。 為此，在每個EKS工作節點上運行Fluentd代理，以收集日誌並將日誌推送到Splunk和S3，以實現持久性。
應用層
我們構建了一些組件，還使用了kubeflow提供的一些組件。 Kubeflow是一站式機器學習，提供了有助於在Kubernetes上構建ML解決方案的工具。 具體來說，一些Kubeflow組件從開發階段到在多台機器上進行實驗探索以更大程度地擴展ML的潛力，從開發階段開始就為我們提供了更多幫助。 在這一部分中，我們將經歷每個階段，並說明我們的內部工具+ Kubeflow如何協助研究人員。
發展歷程
在研究人員嘗試新想法的早期階段，他們通常使用Jupyter Notebook。 Kubeflow在Kubernetes中將Jupyter Notebooks作為獨立的Pod提供。 當前，所有筆記本都是作為一個名稱空間的一部分創建的，但隔離度較低。 但是，社區正在努力在將來的發行版中支持更多的隔離以及更好的身份驗證和授權。
管道/任務
Argo使用戶能夠在Kubernetes上定義和運行容器本機工作流。 在Argo中，工作流的每個步驟都是一個容器，並且步驟可以是連續的或並行的。 Argo工作流引擎遍歷工作流（DAG）的圖形，如果成功完成一個步驟，則將啟動下一個步驟。 我們使用Argo在平台內執行長時間運行的任務。 例如，當用戶要在存儲（S3）和文件系統（EFS或EBS）之間同步某些數據時，定義了一個argo任務來通過mlcli（例如ml數據上傳路徑）來處理它。 這樣，用戶不必使用AWS或Azure專用工具。 Argo非常簡單且易於使用，可以從一項任務變成更複雜的DAG。 它還帶有一個儀錶板，以查看進度和不同任務的日誌。
Kubeflow管道（kfp）已建立在Argo之上。 我們將作業運行程序與kfp集成在一起，以便用戶可以通過使用命令行工具中的一個簡單選項將作業作為Kubeflow管道上下文的一部分來運行，例如ml job Submit xxx –job-type kfp。 將作業作為kfp的一部分運行的優點是，可以輕鬆地將存儲在S3中的實驗日誌和與訓練任務相關的元數據存儲在kfp元數據服務支持的後端存儲中。 我們正處於試驗此功能的全部功能的早期階段，並且尚未擴展它以完全用於Tensorflow作業（tfjobs）。
元數據
我們實現了將與工作相關的元數據存儲到資料庫中的元數據服務。 創建作業後，將調用元數據服務，並使用k8s watch api監視作業並在不同階段更新作業狀態。 我們還將用戶提交的不同元數據推送給它。 由於kfp最近增加了對跟蹤和存儲元數據的支持，因此，我們可以選擇將其用於更高級的用例，以供將來TFX管道使用。
服務
我們正在生產中使用Tensorflow服務，但是在部署任何模型（尤其是新模型）之前，我們可以選擇使用mlcli創建tf服務部署，以測試模型的功能和性能。 創建/刪除非常容易，例如，ml服務創建obj-detection –bucket test-bucket –s3-path = MODEL / S3 / PATH。 還可以指定應為其分配多少內存/ cpu，甚至可以使用–gpu在GPU實例上創建部署。 在此命令後面，mlcli使用不同的參數調用控制器上的服務端點，並且控制器創建k8s部署，服務和入口以訪問服務。
一旦控制器部署了所有組件，端點將準備就緒，用戶可以直接調用它，例如，上述部署的URL將為https：//serving.somewhere/obj-detection/v1/models/obj -檢測
測試完成後，用戶可以使用ml命令rm obj-detection等簡單命令刪除所有組件（部署，服務，入口）。
我們計劃將來提供更多服務選項。 Kubeflow支持其他服務選項，可在此處找到。
構建和推送Docker映像
當我們生活在Kubernetes世界中時，一切都必須變成Docker映像，我們為用戶提供了一種從Kubernetes集群中的計算機遠程構建/推送Docker映像的方法。 mlcli提供了兩個選項，可以在本地或在Kubernetes中構建/推送圖像。 為此，用戶提供項目的路徑以及項目內相應Dockerfile的相對路徑，然後將構建映像並將其推送到ECR（例如ml build create / PATH / TO / PROJECT -df path / Dockerfile）。
在幕後，我們使用Kaniko在Kubernetes中將圖像生成/推送到ECR。 用戶可以直接從mlcli列出並查看進度，也可以隨時將其刪除。 我們在Kaniko中使用了緩存機制，它為即將到來的構建加快了構建速度。
支持多個雲提供商
在Kubernetes上構建我們的平台的動機之一是能夠使用多個雲提供商。 查看下圖，我們可以看到Kubernetes組件在兩個平台上都是相同的，我們要做的就是創建並採用數據層。
從用戶的角度來看，遷移到Azure就像在現有命令前面傳遞新參數-平台天藍色一樣簡單。 Mlcli和控制層將處理對正確的ML平台的正確調用。
摘要
自從我們開始在此平台上工作以來，我們已經訓練了很多模型，這對我們的研究效率產生了重大影響。 作為用戶，您可以在短時間內啟動一項新的培訓/預處理/批量預測作業。 這種架構還幫助我們將ML工作負載擴展到了另一個雲提供商。 最後-自該平台推出以來，我們的研究團隊已經翻了一番-我們能夠以最小的努力為他們提供服務，這在舊的基礎架構中是什至無法接近的。
(本文翻譯自Hamed Saljooghinejad的文章《Building Multi-Cloud Machine Learning Platform using Kubernetes and Kubeflow》，參考：https://medium.com/onfido-tech/building-multi-cloud-machine-learning-platform-using-kubernetes-and-kubeflow-7445c908708e)