iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 14
0
DevOps

Kubernetes X DevOps X 從零開始導入工具 X 需求分析*從底層開始研究到懷疑人生的體悟*系列 第 14

Day 14 - 先占節點 Preemptible Instance 實戰分享,虛擬機資源評估,機器應該開多大台

本文同步刊登於個人技術部落格,有興趣關注更多 Kubernetes、DevOps 相關資源的讀者,請務必追蹤從零開始的軟體工程師之旅,喜歡的話幫我按讚分享、歡迎留言、或是許願想要看的文章。

如果有技術問題也可透過粉絲專頁 討論,技術方面諮詢免錢、需要動手做另計 XD。

曬貓


關於資源評估

架構團隊提供虛擬機給應用,有個問題時常出現:應該分配多少資源給應用?例如:後端準備一個 API server,SRE 這邊要準備多少什麼規格的機器?

以往使用虛擬機直接部署應用時,會需要明確規劃各群虛擬機,各自需要執行的應用,如果沒有做資源的事前評估,有可能放上機器運行後就發生資源不足。

導入 Kubernetes 後,透過節點池 (Node Pool) 形成一個大型資源池,設定部署的政策後,讓 Kubernetes 自動調度應用:

  • 每一個節點的資源夠大,使得應用虛擬機器上所佔的比例相對較小,也就是單一應用的調度不會影響節點的整體負載
    • 如果節點太小,調度應用就會有些侷促,例如:一個 API server 均載時消耗 1 cpu 滿載時消耗 2 cpu。準備 3 cpu 的虛擬機,調度應用時幾乎是遷移整台虛擬機的負載
    • 此外還有機會因為上篇提到的資源保留,造成調度失敗。如果準備 24 cpu 的機器,調度起來彈性就很大,對節點的性能衝擊也比較低
  • 只需要估計整體的資源消耗率計算需求,配合自動擴展,動態器補足不足的資源
    • 例如:估計總共需要 32 cpu ,準備 36 cpu 的虛擬機,當滿載時依據 cpu 壓力自動擴容到 48 cpu
  • 希望整體資源的使用率夠高,當然預留太多的資源會造成浪費

要控管 Kubernetes 的資源使用量也可設定資源需求與資源限制,延伸閱讀。

估計得越準確,當然實際部署的資源掌握度就越高,然而筆者過去的經驗,團隊在交付源碼時未必就能夠做出有效的資源消耗評估,那有沒有什麼辦法可以幫助我們?

資源需求估估看

如果應用開發團隊,有先作應用的 profiling,然後 release candidate 版本有在 staging 上作壓力測試的話,維運團隊這邊應該就取得的數據,做部署前的資源評估。

應用在不同狀態或是工作階段,會消耗不同的資源

例如:運算密集的 batch job 可能會有

  • 控制節點 (master node) 啟動後會佔有一定的資源,一般來說不會消耗太多,只是需要為控制節點優先保留資源
  • 工作節點 (worker node) 啟動時會需要預留足夠的資源,接收工作後會逐漸增加資源使用,拉到滿載

例如:面向用戶的服務,可能會有

  • 啟動應用所需的資源
  • 沒有大量請求,只維持基本應用運行所使用的資源
  • 負載壓力灌進來時,消耗資源隨用戶請求數量的成長曲線,設定的安全上界

如果沒有這些數據,其實維運很難事前估計資源,變成要實際推上線後見招拆招,基於實際的資源消耗去做自動擴容,其實有可能會造成資源的浪費,因此我建議如果開發團隊沒有作 profiling,維運團隊可以在工作流程內簡單加一
步 profiling,目前主流語言都有提供相關工具,簡單的執行就可以獲得很多資訊。

至於壓力測試,也是可以使用基本的工具(例如 Artilery)簡單整到工作流程。特別是面對客戶的應用,務必要進行壓力測試。

有了上述的資源需求數據,才能事先安排機器的規格。例如

  • 應用是面對客戶的 API server
  • 基本資源是 200m cpu 1Gi memory,這部分直接寫進 Kubernetes resource request,在排程時就先結點上預留。
  • 負載拉到 1,000 RPS,latency 95% 20ms 99% 30ms,這時的資源需求的上界大約 2 cpu 4 Gi memory
  • 超過 1,000 RPS 就應該要透過水平擴展去增加更多 instamce

如果單跑這個 API server,就可以安排 memory 8,cpu 4 的 GKE node-pool,讓負載落在可用資源的 60%-70%,這樣還有餘裕可以承受大流量,給自動水平擴展做動的時間。

資源調整參考

當然這些數據都可以依照時實際需求調整,資源要壓縮得更緊或更鬆都是可行的。

如果應用有整合分析後台,例如 Real-time Uer Monitoring、或是基本的 Google Analytics,都可以觀察這些調整實際對用戶帶來的影響,用戶行為改變對公司營收的影響,全都可以量化。例如

  • 機器負載拉到 80%,cpu 的壓力,導致 API latency 增加到 95% 50ms 99% 100ms
  • 此時用戶已經很有感了,會導致 0.1% 用戶跳轉離開
  • 而這 0.1% 的用戶,以往的平均消費,換算成為公司營收,是 $1,000/month
  • 把機器負載壓到 60%,只計算 cpu 的數量的話,需要多開 3 台 n1-standard-4 機器,共計 $337.26/month
  • 提供老闆做參考,老闆可能會趨向加開機器

當然上面的例子都非常簡化,變成國中數學問題,這邊只是提供一個估算的例子。現實中的問題都會複雜百倍,例如機器規格拉上去出現新的瓶頸、例如依賴的服務,message queue、database 壓力上升,或是公司內部問題,就拿不
到預算(血淚 SRE)。如果要減少機器,也可以參考,一般來說聽到關機器省錢的話,老闆都會接受的 XD。

回到先占機器

根據上面的國中數學,把應用一個一個都計算清楚,需求逐漸明確了。假設,架構團隊拿到開機器的工單,掐指一算,決定

  • 1 GKE cluster
  • 6 n1-standard-4

這些都是隨選虛擬機,價格大約是 $747/month (含集群管理費 $73/month)。今天有人腦動大開,那如果全部換成先占節點呢?變成 $265/month,虛擬機費用 $192 / $674 = 0.28 直接打超過三折。

有人就擔心,這樣真的可以嗎?真的沒問題嗎?會不會影響用戶阿。

答案是會,就是會影響用戶 XD

聽到這邊很多人就怕了。但是怎麼個影響法呢,還需要看底下幾個段落,如果換成先占虛擬機,用戶會怎麼受到影響。我們也要試圖量化這個影響,當作要不要導入的判斷依據。

句個反例,「我覺得可以」「你覺得不行」,或是「某某公司的某某團隊可以啊」「我們公司也來做吧」,這些都是很糟糕的理由。除了對內部毫無說服力之外,也沒有辦法作為導入成效的指標,會讓團隊陷入「導入了也不知道有比
導入前好?」或是「具體導入後成效量化」,會影響團隊做出真正有效的判斷,應極力避免。

此外,問行不行之前,其實需要知道團隊願意為了三折機器,付出多少成本。如果只是每月省個台幣 15,000,工程師薪水都超過了。但如果手下有三十台或三百台以上,也許就非常值得投資。成本不是絕對的,很多時候要與其他成>本 (e.g. 開發人力時間成本) 一起考量。


以上幾篇文章都是說明導入的動機,明天開始說明先占虛擬機的各種機制,以及對應用的實際影響。


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

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

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

我的粉專,等你來留言


上一篇
Day 13 - 先占節點 Preemptible Instance 實戰分享,配合 Kubernetes 自動化調度,使用先占虛擬機下篇
下一篇
Day 15 - 先占節點 Preemptible Instance 實戰分享,先占虛擬機如何殺死你的 Pod,如何處置上篇
系列文
Kubernetes X DevOps X 從零開始導入工具 X 需求分析*從底層開始研究到懷疑人生的體悟*30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言