本文同步刊登於個人技術部落格,有興趣關注更多 Kubernetes、DevOps 相關資源的讀者,請務必追蹤從零開始的軟體工程師之旅,喜歡的話幫我按讚分享、歡迎留言、或是許願想要看的文章。
如果有技術問題也可透過粉絲專頁 討論,技術方面諮詢免錢、需要動手做另計 XD。
使用先占節點比起使用一般隨選虛擬機,會多出許多技術困難需要克服,只有節省下的成本大於整體技術成本時,我們才會選用先占節點。因此這邊要進行成本精算,重新調整的架構下,實際到底能省多少錢。務必使用 Google Cloud Pricing Calculator 精算成本。
另外,雖然先占虛擬機會有很多額外的限制與技術困難,但實務上還是要對比實際的需求,有些限制與需求是衝突的,有些限制則完全不會影響我們的需求。前者當然會帶給我們較高的導入難度,後者可能會非常輕鬆。
這邊想給大家的概念是,務必先明確需求,再討論技術。這點很重要,技術的適用與否,不是由個人的喜好決定,唯一的判斷標準,是能不能有效率的滿足需求。
所以這邊先定義我們以下幾個需求:
常見的範例,例如
這些任務的核心需求,很簡單直接
例如:我手上的機器學習 Model 粗略估計 10000 小時-GPU 的算力需求,才能產出一個有效的Model。由於大量的算力需求,一般來說都會選擇分散式的運算框架 (ex. MapReduce) ,將真正消耗算力的工作,使用分而化之 (divide and conquer) 的架構設計,將分配任務的控制節點 (master),與實際進行運算的工作節點(worker) 拆分。基於原本的分散式架構,幾乎可以無痛地將工作節點轉移到先占虛擬機上。
根據上述的需求,這類的工作特性可能有
由於先占虛擬機可能是浮動價格,這類工作可以根據優先程度,調整合適的工作時間,例如在資料中心算力需求低,先占虛擬機的費用低廉時,啟用較多的工作節點加快運算,如果費用高時,可以降低先占虛擬機的使用,延後工作,
甚至是調用不同區域,費用低的工作節點,來降低整體的成本。
執得注意的是,這類任務的控制節點 (master),也許是集中式的,也許是分散式的,需要根據性質考量,是否適合放在先占虛擬機上。有些架構控制節點可以容錯,然而錯誤發生後會需要復原狀態,這時會消耗額外的算力,可能會>拖緩整體進度,造成算力的消耗。也許就可以考量使用隨選虛擬機配合使用。
常見的範例,例如
這些工作的核心需求如下:
由於會面對使用者,需要能支持使用者的壓力,又同時需要有一定的服務效能,來維持使用者體驗。實務上設計可能採用無狀態應用 (stateless),多副本 (replica) 部署到集群中。需要儲存的狀態(如用戶狀態),使用外部的共>用儲存 (例如:Redis,RDBMS,或是 Non-SQL DB)。請求的流量,透過上游的負載均衡器 (Load Balancer),送進多個後端,處理完成請求後,再返回給使用者。
這樣的設計,使用先占虛擬機也不會有太多的問題
這樣的設計實務上有幾點注意
分散式的儲存中心 (distributed DB),如:cassandra 或是小強 DB。而這樣類型的服務,是否適合放在先占節點上?