需求規劃

使用先占節點比起使用一般隨選虛擬機，會多出許多技術困難需要克服，只有節省下的成本大於整體技術成本時，我們才會選用先占節點。因此這邊要進行成本精算，重新調整的架構下，實際到底能省多少錢。務必使用 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。而這樣類型的服務，是否適合放在先占節點上？