Gcp Preemptible Instance Requirement

Share on:

需求規劃

使用先占節點比起使用一般隨選虛擬機,會多出許多技術困難需要克服,只有節省下的成本大於整體技術成本時,我們才會選用先占節點。因此這邊要進行成本精算,重新調整的架構下,實際到底能省多少錢。務必使用 Google Cloud Pricing Calculator 精算成本。

另外,雖然先占虛擬機會有很多額外的限制與技術困難,但實務上還是要對比實際的需求,有些限制與需求是衝突的,有些限制則完全不會影響我們的需求。前者當然會帶給我們較高的導入難度,後者可能會非常輕鬆。

這邊想給大家的概念是,務必先明確需求,再討論技術。這點很重要,技術的適用與否,不是由個人的喜好決定,唯一的判斷標準,是能不能有效率的滿足需求。

所以這邊先定義我們以下幾個需求:

  • 執行短期的 batch job
  • 執行長期的 user-facing API server
  • 執行長期的 stateful 資料庫、儲存庫

Batch Job

常見的範例,例如

  • 使用網路爬蟲 (crawler) 去抓取許多網站的所有內容
  • 使用 GPU 進行機器學習的 Model Training
  • 大數據計算
  • MapReduce

這些任務的核心需求,很簡單直接

  • 盡快完成整體工作
  • 盡可能節省大量算力成本

例如:我手上的機器學習 Model 粗略估計 10000 小時*GPU 的算力需求,才能產出一個有效的Model。由於大量的算力需求,一般來說都會選擇分散式的運算框架 (ex. MapReduce) ,將真正消耗算力的工作,使用分而化之 (divide and conquer) 的架構設計,將分配任務的控制節點 (master),與實際進行運算的工作節點(worker) 拆分。基於原本的分散式架構,幾乎可以無痛地將工作節點轉移到先占虛擬機上。

根據上述的需求,這類的工作特性可能有

  • CPU / GPU 算力需求高的運算節點 (Worker)
  • Worker 本身是無狀態的 Stateless
  • 可控的即時負載
  • 將整體工作切分成任務單元 (task),分配給工作節點
  • 任務單元的狀態外部保留,工作節點可容錯 (fault-tolerent),任務單元可復原

由於先占虛擬機可能是浮動價格,這類工作可以根據優先程度,調整合適的工作時間,例如在資料中心算力需求低,先占虛擬機的費用低廉時,啟用較多的工作節點加快運算,如果費用高時,可以降低先占虛擬機的使用,延後工作,甚至是調用不同區域,費用低的工作節點,來降低整體的成本。

執得注意的是,這類任務的控制節點 (master),也許是集中式的,也許是分散式的,需要根據性質考量,是否適合放在先占虛擬機上。有些架構控制節點可以容錯,然而錯誤發生後會需要復原狀態,這時會消耗額外的算力,可能會拖緩整體進度,造成算力的消耗。也許就可以考量使用隨選虛擬機配合使用。

User-facing services

常見的範例,例如

  • Restful API server
  • Websocket Server
  • TCP/HTTP reverse proxy

這些工作的核心需求如下:

  • 整題服務的高可用性 (high availability)
  • 承受不可預期的負載高峰 (load spikes)
  • 整體表現需要低延遲 (low latency)
  • 可以水平擴展 (horizontal scaling),支撐用戶的成長
  • 最終平衡效能呈現與成本

由於會面對使用者,需要能支持使用者的壓力,又同時需要有一定的服務效能,來維持使用者體驗。實務上設計可能採用無狀態應用 (stateless),多副本 (replica) 部署到集群中。需要儲存的狀態(如用戶狀態),使用外部的共用儲存 (例如:Redis,RDBMS,或是 Non-SQL DB)。請求的流量,透過上游的負載均衡器 (Load Balancer),送進多個後端,處理完成請求後,再返回給使用者。

這樣的設計,使用先占虛擬機也不會有太多的問題

  • 現代的附載均衡器多半都能像後端做可用性檢測 (health check),可以把流量導向工作正常的節點,如果後端的虛擬機被資料中心收回了,流量也會移轉到其他節點上,不會遺失用戶請求
  • 配合自動水平拓展工具 (Auto horizontal scaler),可以設定期望的服務節點數量,如果資料中心回收先占節點,拓展工具可以同時去取得新的先占節點,或是取得隨選隨用的虛擬機
  • 配合流量監測,也可以動態調整期望的服務節點數量,例如:偵測到大量用戶連線數時,增加更多服務節點,待流量下降後,再降低服務節點數量

這樣的設計實務上有幾點注意

  • 雖然說應用後端本身是無狀態的,但面對用戶也許還是會有部分狀態存在應用外部,例如:User session,或是 websocket 的長連線。特別注意這些服務斷線的時候,對於使用者的影響,配合前端增強使用者體驗
  • 後端水平拓展後,瓶頸會轉移到其他地方,例如 Database 成為效能瓶頸,應用這邊需要做一定程度的自律( ex. connection limit,rate limit),避免不斷增長的應用壓垮依賴的服務,如 MessageQueue 或是 Database

分散式的儲存中心 (distributed DB),如:cassandra 或是小強 DB。而這樣類型的服務,是否適合放在先占節點上?