Gcp Preemptible Instance

Share on:

前言

鐵人賽的第二部分,要帶來公有雲省錢系列文章。

架構的成本,很多時候會影響架構的設計與需求。公司的營運都需要在成本與需求之前平衡,成本其實是影響公司決策的重要因素。身為架構管理員,應該要試著量化並且進行成本管理,提出解決方案時,也需要思考如何幫公司開源節流。

一昧消減架構的成本也未必是最佳方案,帳面上消減的成本有時也會反映在其他地方,例如:使用比較便宜的解決方案,或是較低的算力,但卻造成維運需要花更多時間維護,造成隱性的人力成本消耗。用什麼替代方案 (trade-off) 省了這些錢。

Kubernetes 是一個很好的例子:例如:有人說「Kubernetes 可以省錢」,但也有人說「Kubernetes 產生的 Overhead 太重會虧錢」。

「要不要導入 Kubernetes 是一個好問題」。應該回歸基本的需求,了解需求是什麼。例如:Google 當初開發容器管理平台,是面對什麼樣的使用需求,最終開發出 Kubernetes,各位可以回顧前篇文章「Borg Omega and Kubernete,Kubernetes 的前日今生,與 Google 十餘年的容器化技術」,從 Google 的角度理解容器管理平台,反思自身團隊的實際需求。

這套解決方案是否真的適合團隊,解決方案帶來的效果到底是怎樣呢?希望看完這系列文章後,能幫助各位,從成本面思考這些重要的問題。

這篇使用 GCP 的原因,除了是我最熟悉的公有雲外,也是因為 GCP 提供的免費額度,讓我可以很輕鬆地作為社群文章的 Demo,如果有別家雲平台有提供相同方案,請留言告訴我,我可能就會多開幾家不同的範例。

先占虛擬機 TL;DR

  • 先占虛擬機為隨選虛擬機定價的 2-3 折,使用先占虛擬機可能可以節省 7 成的雲平台支出
  • 先占虛擬機比起隨選虛擬機,外加有諸多限制,e.g. 最長壽命 24 hr、雲平台會主動終止先占虛擬機…等
  • 配合使用自動水平擴展 (auto-scaler),讓舊的先占虛擬機回收的同時,去購買新的先占虛擬機
  • 配合可容錯 (fault-tolerent) 的分散式應用,讓應用可以無痛在虛擬機切換轉移,不影響服務
  • 要讓應用可以容錯,需要做非常多事情
  • 搭配 kubernetes ,自動化管理來簡化工作
  • 配合正確的設定,可以穩定的執行有狀態的分散式資料庫或儲存庫

或是看 Google 官方 Blog:Cutting costs with Google Kubernetes Engine: using the cluster autoscaler and Preemptible VMs

預計內容

  1. 需求假設、釐清需求,並且精準計價
  2. 精準計價使用先占虛擬機的節省成本
  3. 先占虛擬機的規格、額外限制
  4. 額外限制,造成技術要多做很多額外的事情
  5. 實務經驗分享:API server
  6. 實務經驗:從使用隨選虛擬機,移轉到先占虛擬機,公司實際導入經驗
  7. 實務經驗:Elasticsearch
  8. 實務經驗分享:其他分散式資料庫,也許是 Cassandra 或是 cockroachDB

上面的內容不曉得會寫幾篇看感覺 XD

有寫過鐵人賽的都知道 30 篇真的很漫長,一篇文章幾千字,都要花好幾個小時。我去年後半,真的都會看讀者的留言跟按讚,取暖一波,才有動力繼續寫。留言的人多就會多寫,留言的人少就會少寫,各位覺得文章還看得下去,請務必來我粉專按讚留個言,不管是推推、鞭鞭、或是有想看的文章來許願,都十分歡迎。有你們的支持,我才有動力繼續寫。

請大家務必以實際行動支持好文章,不要讓劣幣驅逐良幣。不然 iThome 上面之後只剩洗觀看數的熱門文章了 XD

當然,沒人留言我就會當作自己才是垃圾文 (自知之明XD),就會收一收回家嚕貓睡覺,掰掰~

->我的粉專,等你來留言