FinOps-運用Spot資源的能力
- Spot 資源是什麼、它們如何運作以及它們存在的原因
- 運用 Spot 所需的一些注意事項
- Spot 資源使用的特性及其成本影響
- 使用 Spot 資源具有優勢並推薦的場景
定義
CSP發展了所謂 Spot instance的服務(因為沒人租所以用便宜價格租出去)，允許客戶以高達 91% 的折扣購買Instance，從而將其未使用的運算能力貨幣化。 儘管此折扣會因instance類型而異，但 Spot 是購買運算容量的最經濟選擇。
這種顯著折扣的代價是CSP可以在很短的通知期內（30 秒到 2 分鐘）回收instance。 這意味著客戶必須考慮為此類召回(recall)建置解決方案。到目前寫本文為止，三大公有雲均使用術語「Spot Instance」或「Spot VM」來表示此功能。 先前的術語是「Preemptive Instances」(GCP) 和「Low Priority VMs」(Azure)。
為何此能力重要
很簡單，利用 Spot 很重要，因為與所有其他購買選項相比，它提供了最大的折扣。 缺點是，它不一定能集中採用，因為每個開發團隊都必須主動評估和部署最適合其架構的方式。 因此，中心化FinOps 團隊很可能並且應該採取措施來識別潛在的使用場景，並提供其他材料來強調這種能力的優點。
與Spot資源使用相關的預測應包含在與承諾折扣相關的計算中，因為Spot的使用的突然大幅增加可能會對大量預購產生影響，從而導致投資損失。
最後，Spot 確實支援一些現代雲端架構和託管服務，例如AI/ML 基礎架構、大數據分析、鬆散耦合架構、微服務架構、水平擴展、K8S或其他容器基礎架構可以包括Spot 和on- Demand的某種組合。
參與的角色
那麼這個能力應該涉及哪些角色呢？ 雖然 Spot 的使用將由開發人員和產品團隊執行，但產品負責人和(或)架構主管將對可能與 Spot 使用相關的任何合規性負責。 應根據需要諮詢技術人員，確保架構的穩定性和可靠性。
FinOps 團隊應報告任何結果（可能從Walk階段開始），以強調 Spot 的優點，並在帳號或業務實體層級提供與由此產生的節省相關的透明度。
Spot 的使用必須是產品、架構和技術團隊達成一致並密切理解的內容。 由於 Spot 並不總是每次都可用，因此財務團隊（以及支出的其他利害關係人）也應該意識到它正在被使用，以便有一個開放的理解，即有時高成本產生可能是因為Spot 的不可用。 重要的是，該架構設計為在可用時使用Spot，而在低可用性期間預設為On-Demand。
成功的衡量因素
- 建立適合Spot的架構
- 辨識目前適合的工作負載
- 定義和維護目標百分比 Spot 使用率
- 如果使用量增加超過歷史百分比，FinOps 團隊需要改變基於承諾的折扣購買方法
- 考慮 Spot 使用情況的財務建模
Crawl階段
在產品團隊的雲端初始之旅，他們將專注於提升技能並掌握其架構。 很少有人會花時間考慮利用Spot instance所需的考慮。
FinOps 專業人員應重點宣傳現階段使用 Spot Instance的顯著優勢。 在這些初始階段，測試/開發環境中的過渡要容易得多，同時團隊在確保其架構能夠在instance recall之後保持服務可用性方面獲得了一定的信心。
在這些初始階段，團隊通常會認為 Spot 只能在測試/開發環境中使用。 FinOps 團隊應該強調將這些相同的考量因素與哪些生產工作負載也可能有利於發現相關的潛力。 早期階段的另一個趨勢可能是產品團隊將採用二分法來運行Spot instance，他們可能會認為Spot使用是全部或都不要，而最佳實踐是使用Spot和On-Demand的適當組合。
Walk階段
隨著團隊的成熟（以及帳單的成長），我們可能會看到更多的Spot運用。
FinOps 團隊應該停止以少量節省為例，進一步向組織的其他部門宣傳這種能力。FinOps 團隊可以考慮提供一些範例或可重用的代碼模組，以幫助雲端使用者優化其運算資源的支出，或者也許希望從使用情況被視為典範的團隊中獲得推薦。 儘管使用量有所增加，但這種情況仍可能主要在Walk階段的測試/開發環境中觀察到。
Run階段
在此階段，我們應該會看到測試/開發環境中 Spot 的使用率非常高，生產環境中的使用率中等，也許還有一些在生產環境中使用率較高的範例。 Spot 可能會成為足夠的標準，以定義圍繞它的某種程度的受監管合規性。 Spot 的使用可能會變得足夠重要，從而導致 FinOps 團隊調整其基於承諾的折扣範圍的方法。
最佳實踐
最重要的是要理解，Spot 並不適合所有工作負載，但它在其利基場景中非常有用。 它在促進開發或 PoC 環境方面特別有用，無狀態作業是非常好的用例，批次作業或可以創建/運行/銷毀資源的短期運行作業也是如此。 需要注意的是，適合 Spot 的作業與使用無伺服器功能來完成相同任務之間可能會有一些重疊。
Spot instance可以用作 Spot Fleet的一部分，它允許管理一系列 Spot 實例類型，理想情況下，將包括On-Demand instance和某些 Spot 實例的某種組合。 很多時候，Spot 可以在Auto Scaling group中使用，其中也可能適合將 Spot 與On-Demand實例混合，並且可能包括擴展選項，這些選項將在 Spot 可用時使用 Spot 並在 Spot 不可用時使用On-Demand。
Spot 實例可能不適合對回應有一定時間敏感性的應用程式，在需要高度保證可用性的場景中也不是一個好的選擇。 同樣，由於存在recall的可能性，使用 Spot 來實現一致且有狀態的工作負載也不是最佳實踐。 Spot 是不太可行的選擇的一個很好的例子是傳統風格的商業應用程式，這些應用程式可能是從傳統的地端機房升級和轉變的。
我們將重點介紹幾個類別，需要考慮一些類別來規劃Spot供應量較低的時期。 從技術角度來看，確保在 Spot 可能無法使用時制定B計劃 或C計劃 可能很重要。 這些計劃可能需要使用到On-Demand instance，改變我們請求點的位置（如果適用），並且可能在這些時候做更少的事情，在這些情況下，對效能和可用性期望進行水準設定也很重要。 無論情況如何，都要確保規劃好各種突發事件。
從財務角度來看，財務部門可能需要解釋由於 Spot 不可用而導致的成本增加，因為這會影響其成本分配模型。 業務利害關係人需要了解其他選項，以便他們能夠就最小應用程式可用性和(或)最大可接受成本做出更好的決策。
所有解決可用性問題的方法都必須是多維的，以確保所有利害關係人達成一致。
大多數FinOps專業人員可能會明白，基於承諾的折扣不涵蓋 Spot 實例，因為這些折扣有些相關，但它們是可以使用的完全不同的成本管理槓桿。 同樣應該理解的是，與Spot相比，這些使用承諾的折扣較低，雖然這些承諾本質上是可用性的保證，但Spot並沒有提供此類保證。 因此，這兩個槓桿都很有價值，但它們確實有可能發生衝突。 特別是在Spot使用量可能突然大幅增加的情況下。
因此，預期的Spot使用量應計入承諾覆蓋範圍目標中，以避免過度承諾。 當承諾金額非常高時，這一點尤其重要。 理想情況下，Spot到期日應遵循與組織的策略相同的時間線，以獲得高承諾覆蓋率。
然而，由於與讓產品團隊進行盡職調查的典型情況相比，在組織層面可以更快地實現高度的承諾（由於這些承諾由單一實體管理）為了有效實施Spot，FinOps 團隊必須了解Spot 使用量是否以及何時會大幅增加。
真正洞察架構和業務驅動因素以有效設計現場使用的人是負責應用程式的產品團隊。 也就是說，FinOps 團隊可以透過一些方法來定義一些看起來適合 Spot 的標準。
從雲端平台的控制台運算統計資料的角度來看，一個有用的模式可能是根據運算資源活動來查看網路使用率。 此方法的優點是同樣適用於記憶體或 CPU 限制的工作負載。 然而，使用此類分析時的重要假設是，雲端足跡將存在大量 Web 伺服器，其中網路活動是運算使用情況的良好指標。 這可能允許我們針對特定團隊進行對話，這可能會影響他們開始使用 Spot 實例。
另一種可用於實現此效果的機制是收集和報告正確的規模建議和閒置實例，因為這些也可能是激勵 Spot 使用的機會。
針對Spot的架構
用於短期運作的流程:
- 開發環境
- Stateless tasks
- Batch Job、建立/運作/銷毀資源的短期運行作業
作為Fleet的一部分使用
- 有些是On-Demand，有些是Spot
- Auto Scale中某些使用Spot
什麼時候不合適
- 有時間敏感性
- 需要保證可用性
- 需要有一致/Stateful的工作負載
Spot不可用時的規劃
技術面的:
- 改變請求的資源類型、位置
- 如果可能的話延遲執行
- 降低對效能的期望
財務面的:
- 討論不可用的地點如何影響成本分配模型中的總體成本
- 業務利害關係人應了解可用性降低或成本增加的可能性，以便做出與最短正常運作時間和最大所需支出相關的決策
與基於承諾的折扣(也就是大量預購)相平衡
- 基於承諾的折扣不包括Spot的使用
- 基於承諾的折扣具有較低的折扣（較高的成本），但保證始終可用
- 快速或大量變更為Spot時
識別適合 Spot 的現有工作負載
- 將成本一致性與網路使用率（或其他單一資源使用率統計資料）進行比較
- 識別與不一致的突發使用情況的嚴重不匹配
- 利用CSP工具來激勵 Spot 使用
- 由團隊討論 Spot 對於團隊工作負載的適用性
