騰訊云批量計算介紹

日期:2018-12-25 12:59 / 人氣:197 / 來源:騰訊云服務器

批量計算概念介紹

引題:工作負載分類

工作負載的分類方法和標準多種多樣,其中 Google 提出的一種簡單的分類標準廣受認可,即將工作負載分為服務型和批處理型。

  • 服務型 service
    • 長時間運行,理論上不會停止,對服務質量敏感,主要是線上業務
    • 例如 web 服務,e-mail 服務等
  • 批處理型 batch
    • 運行時間從幾秒到幾天不等,對短時性能波動相對不敏感,主要是離線業務
    • 例如日志分析等

公有云上的批量計算

最初,公有云的工作負載以服務型負載為主,各大廠商也進行了諸多針對性優化。隨著云計算的快速發展,越來越多的、不同行業的用戶開始使用公有云,批處理型負載顯著增加。針對批處理型負載的需求,我們也通過新的產品形式來滿足用戶。

  • 專注業務,支持大規模自動化調度與執行,為用戶屏蔽資源細節。
  • 調度邏輯,支持 DAG 和優先級調度,滿足用戶復雜的業務處理邏輯。
  • 成本優化,支持資源的動態伸縮,按需分配資源,避免資源浪費,節省成本。

騰訊云 Batch 模型

  • 執行單元
    • Job,作業,一組關聯 Task 的集合
    • Task,任務,指明執行邏輯和資源需求
    • TaskInstance,任務實例,原子執行單元,一個 Task 可并行執行多份
  • DAG依賴
    • 通過圖拓撲表示 DAG 依賴,Job 是 DAG 圖,Task 是點,依賴 Dependence 是邊
    • Task 是依賴關系的維護單元,不使用 TaskInstance 作為依賴關系的維護單元是為了防止依賴關系爆炸

批量計算完整流程

上一小節是騰訊云 Batch 自身的邏輯模型。本節我們將視角提升到整個處理流程,涵蓋調度、計算、存儲等方面。流程示意圖如下圖所示。

  • 主要步驟
    1. 用戶上傳應用程序和輸入文件到對象存儲COS上
    2. 用戶提交 Batch 作業
    3. Batch 創建 CVM 實例
    4. CVM 實例中啟動 Batch agent,從 COS 下載應用程序和輸入文件,執行任務實例
    5. Batch agent 上傳輸出文件到 COS
    6. 用戶監控 Batch 作業的結果
    7. 用戶在 Batch 作業完成后,從 COS 下載獲得輸出文件
  • 騰訊云閉環
    • 整個流程在騰訊云上實現調度、計算、存儲閉環
    • Batch 提供調度分發能力
    • CVM 提供計算能力
    • COS 提供持久化存儲能力

競品調研關鍵問題

在進行產品規劃、系統設計的過程中,我們對公有云批量計算產品進行了較為充分的調研,涵蓋 AWS, Aliyun, Azure, Google Cloud等友商(其中 Google Cloud Batch 是 Google Dataflow 產品的一部分,專注數據處理,與其他競品差別較大,不作為主要對比系)。我們從中汲取了大量養分,同時也發現對于一些關鍵問題和產品規劃,不同廠商采用了不同的策略。對此,我們嘗試分析背后的產品邏輯和各自優劣,結合目標用戶的需求,選擇確定了騰訊云批量計算的產品路線。

虛擬機與任務實例的耦合關系

  • AWS
    • 產品策略:作業與 VM 生命周期解耦。一個 VM 可以運行多個作業,作業分配到 VM 需要裝箱。
    • 簡評:AWS Batch 作業通過容器的方式執行,看起來可以快速啟動,但是容器仍然需要運行在 VM 之中,VM 的規格和啟停時機難以把握。在試用過程中,我們發現 AWS Batch 容易出現資源浪費和資源“假死鎖”問題。客觀來說,容器與 VM 2層概念增加了產品邏輯復雜度,而 AWS Batch 并沒有完滿的處理好這方面的產品邏輯。
    • 問題1 資源浪費
      • 在一個MaxvCPU(AWS Batch 產品概念,大意為計算環境可使用的 CPU 上限)為16C的環境中,用戶先提交一個16C的作業A, AWS Batch 會自動創建一個16C的 EC2 實例執行作業A。然后用戶再提交一個8C的作業B,在作業A完成之后,AWS Batch 會復用16C的 EC2 實例執行作業B。AWS Batch的收費策略是根據 EC2 實例收費,這樣存在一個問題,在執行作業B的時候,Batch 用16C的 EC2 執行8C的作業,造成了資源浪費。實際上,用戶提交作業的規格和吞吐量發生變化是較為常見的事情,這樣的 case 比較容易出現。
      • 此外,作業執行完成后,EC2 不會立即銷毀,通常會保留數十分鐘后才會自動釋放,對于不持續提交作業的用戶,也會造成明顯的資源浪費。
    • 問題2 資源“假死鎖”
      • 在一個MaxvCPU為16C的環境中,用戶先提交一個8C的作業A,AWS Batch 會自動創建一個8C的 EC2 實例來執行作業 A。然后提交一個16C的作業B。本來預期 AWS Batch 會立即銷毀現有的 EC2 實例,然后創建一個新的16C EC2 實例來運行作業B。但是,實際情況要略差于預期,在作業B提交近一小時之后,AWS Batch才創建了16C的 EC2 實例,完成計算環境的調整,以至于用戶一度認為 AWS Batch 出現了死鎖 bug。雖然最終沒有造成死鎖,但是 AWS Batch 的調整延遲過大,影響用戶體驗。
  • Aliyun
    • 產品策略: Aliyun Batch 分為2種計算環境類型,AutoCluster 自動集群模式和 Cluster 固定集群模式。對于 AutoCluster 模式,任務實例與 VM 生命周期一致;對于 Cluster 模式,雖然任務實例與 VM 生命周期不一致,但是目前仍然采用1對1模式,即 VM 同時只運行一個任務實例。
    • 簡評:Aliyun Batch,特別是 AutoCluster 模式,產品邏輯簡單直接。
  • Azure
    • 產品策略: 任務與 VM 生命周期解耦。一個 VM 可以運行多個任務。與 AWS Batch 不同,任務分配到 VM 不進行裝箱,而是通過參數設置,即一個 VM 可以同時運行 n 個任務,n 可設置。。
    • 簡評:與 AWS Batch 類似,可能出現浪費資源的問題。不進行裝箱,直接為 VM 分配 n 個任務的策略,對于異構化的任務,存在資源評估不準確的問題。
  • 用戶反饋
    • 用戶關心業務本身,對耦合關系無明顯偏好,希望產品邏輯保持簡潔直觀,避免資源浪費。
  • 騰訊云做法
    • CVM 和 任務實例生命周期耦合,一一對應,執行任務實例前夕創建 CVM 實例,執行完成后立即銷毀 CVM 實例。保證按需分配和使用資源,節省成本。
    • 同時,充分利用 CVM 快速創建優勢,快速響應 Batch 業務。

執行單元的層級關系

  • AWS
    • 產品策略:執行單元為 Job,是原子執行單元,相當于騰訊云的 TaskInstance。
    • 簡評:保證接口原子性。雖然可以通過指定前序 Job 來表示 Job 間的依賴關系,但是需要用戶記錄和維護前序 Job 的唯一 ID,并在提交后序 Job 時指定前序 Job 的唯一 ID,相當于用戶需要參與維護DAG 關系。同時,AWS Batch 目前無法提供完成的 DAG 視圖。
  • Aliyun
    • 產品策略:Job、Task、Instance三層單元
      • 簡評:可以在 Job 內部實現 DAG 關系。Aliyun Batch 和 ECS 是兩款產品,但是二者的 Instance 和 InstanceId 容易混淆。Aliyun Batch 中存在 InstanceId 的概念,卻并非 ECS InstanceId,而是類似 Instance 在 Task 內部索引的概念。
  • Azure
    • 產品策略:具有 Job 和 Task 兩層單元,Job 其實是類似隊列或者任務集合的靜態概念,Task 是其執行單元。
    • 簡評:Azure Batch 中的 Task 類似于 AWS Batch 中的 Job,二者優缺點相似。
  • 用戶反饋
    • 希望 Batch 產品可以優雅地處理 DAG 關系,同時對用戶簡單。
  • 騰訊云做法
    • 借鑒工作流系統 airflow 的命名方式,采用 Job、Task、TaskInstance 三層執行單元。
    • TaskInstance 與 CVM Instance 概念區分。雖然我們目前采用 TaskInstance 和 CVM Instance 生命周期一致的策略,但是二者本身不同,不要混淆。

CVM 用戶是否可見

  • AWS
    • Batch 創建的虛擬機,在其控制臺可見
  • Aliyun
    • Batch 創建的虛擬機,在其控制臺不可見,不可直接登錄。雖然 Aliyun Batch 提供了內網連通的拓展功能,但是產品體驗有待提高。
  • Azure
    • Batch 創建的虛擬機,在其控制臺可見
  • 用戶反饋
    • 多方用戶提到友商 Batch 創建虛擬機控制臺不可見、無法登錄的痛點。當出現問題時較難定位。
  • 騰訊云做法
    • 保證“搭積木式”的產品觀
    • Batch 和用戶使用相同的方式使用基礎產品(例如 CVM),保證基礎產品邏輯一致

系統設計

TaskInstance 狀態機

騰訊云 Batch 包括 Job、Task、TaskInstance 三層執行單元,TaskInstance 系原子執行單元,這里介紹其狀態機。Job、Task 的狀態依賴其所含 TaskInstance 的狀態,不做展開。

  • SUBMITTED
    • 已經接收到 Job 并解析拆分。
    • 如果存在依賴項,則任務實例進入 PENDING 狀態,否則進入 RUNNABLE 狀態。
  • PENDING
    • 駐留在隊列中,因為等待其他依賴任務,而無法運行
    • 在滿足依賴關系后,任務實例將進入 RUNNABLE 狀態。
  • RUNNABLE
    • 駐留在隊列中且沒有任何未完成依賴項,因為沒有資源或者資源配額不足而暫時無法運行
    • 當資源足夠時,任務實例會被調度運行。
  • STARTING
    • 任務實例完成調度開始執行和下發,任務實例尚未啟動執行
  • RUNNING
    • 任務實例在計算環境中運行
    • 當應用程序退出時,進程退出代碼將確定任務實例是成功還是失敗。退出代碼 0 表示成功,非零退出代碼表示失敗。
  • SUCCEEDED
    • 任務實例成功完成,返回碼為 0
  • FAILED
    • 在執行所有可用嘗試后,任務實例失敗。

系統架構與設計細節

定位為工作流 workflow 系統,適用于 Batch 場景,命名為 Wonderflow。

  • Wonderflow API
    1. 生成唯一 JobId,并將 Job 基本信息提交到數據庫中
    2. 將 Job 完整信息發送至 MQ 中
    3. 向調用方返回 JobId
  • 依賴關系
    • Job 拆分時,根據有無依賴,將 TaskInstance 的狀態設置為 PENDING 或者 RUNNABLE
    • TaskInstance 完成后,會變更關聯對象的狀態,可能包括 Task、Job、后續 Task、后續 TaskInstance 的狀態。
  • 調度策略
    • 以 owner 為粒度進行集中調度,查詢同一 owner、狀態為 RUNNABLE 的 TaskInstance,按照優先級排序,逐個遍歷
      1. 如果 TaskInstance 有足夠資源配額,則下發執行,將 TaskInstance 信息發送至pre-executor MQ
      2. 如果 TaskInstance 無足夠資源配額,則continue
    • owner 之間并行調度;同一 owner 串行調度,避免無意義加鎖。
    • TaskInstance 存儲使用數據庫,不使用優先級隊列,避免“隊列頭阻塞”或者優先級變化。
  • Wonderflow 內部回滾
    • pre-executor 和 post-executor 相對復雜,需要內部回滾
    • 例如 pre-executor 如果執行失敗,進行回滾,銷毀已經創建的 CVM 實例
  • Wonderflow 與 CVM API 交互
    • 支持兩種模式,調用內部 CVM API 和 SDK
    • 默認采用 CVM API 模式,應用在騰訊公有云場景下
    • 可選通過 SDK 模式,與 CVM 用戶行為完全一致,意味著用戶可以在自己的 CVM 集群中搭建 Wonderflow 系統并直接使用。
  • 與CVM實例的交互
    • 鏡像只需安裝 cloudinit,而無須提前嵌入 Batch agent,即可運行批量計算作業
    • cloudinit 是業界認可的標準初始化工具,鏡像制作標準規范、簡易
    • 騰訊云計劃近期更新主流公有鏡像,使之支持 cloudinit

設計原則小結

  • “搭積木”
    • 批量計算保證基礎產品的原生能力,不進行封裝或閹割。批量計算和用戶使用基礎產品的方式一致,保證產品表現一致
  • 多調度器并發架構
    • 多調度器并發調度,用戶(owner)級別并發,類似于 Google Omega 的無鎖樂觀并發調度架構, 可提升調度系統的吞吐率。用戶(owner)內部串行,保證按照優先級調度下發,同時避免無意義加鎖。
    • 在產品調度策略上,目前批量計算對所有用戶采用對等公平策略。如果特定場景(比如私有云環境)需要采用相對公平策略,不同用戶具有不同的權重值,則需要增加一個調度組件和一層調度策略,決定優先為哪個/哪些用戶進行調度。
  • 輕量 API
    • API 邏輯輕量,保持快速響應
    • 復雜邏輯交由異步消費者完成
  • 消費者處理邏輯簡潔明確
    • TaskInstance 狀態機相對復雜,但是每類消費者只做一類事,相當于解耦了狀態機。
    • 例如,Splitter 負責拆分Job,根據 TaskInstance 有無依賴將狀態置為 PENDING 或者 RUNNABLE;Scheduler 只負責調度下發狀態為 RUNNABLE 的 TaskInstance,不會考慮依賴關系;post-executor 在銷毀 CVM 實例之后,負責變更 TaskInstance 狀態和關聯對象狀態,會將已經無依賴的后續 TaskInstance 狀態從 PENDING 變更為 RUNNABLE。

核心功能與產品優勢

  • 自動托管
    • 自動調度、下發、執行海量作業,為用戶屏蔽資源細節,專注業務本身。
  • DAG 依賴
    • 通過 DAG 拓撲形式,描述任務間依賴關系,根據依賴關系保證任務的先后執行順序。通過簡單形式滿足用戶復雜處理邏輯的業務需求。
  • 優先級調度
    • 對于無依賴任務實例,基于優先級進行先后調度。
  • 計算資源動態伸縮
    • 資源與任務實例生命周期一致,根據業務需求動態擴展和釋放計算資源,按需分配資源,避免浪費,節省成本。
  • 天然集成
    • Batch 與騰訊云基礎產品天然集成,涵蓋計算(CVM)、網絡(VPC)、存儲(COS/CFS)、安全(安全組)等多個方面,用戶業務可在騰訊云上輕松閉環。
    • 復用基礎產品優勢,例如騰訊云 CVM 快速創建。
  • 調試 Debug 模式
    • TaskInstance 失敗后,CVM 實例不銷毀,保留現場
    • 批量計算創建的 CVM 實例,在 CVM 控制臺可見、可登陸,便于用戶觀察應用運行狀態。

批量計算作為一款新產品,可能還存在一些不足,也歡迎大家多多試用 & 反饋問題。

作者:騰訊云代理商


广东时时彩几分钟开奖