撰稿 | 言征

出品 | 51CTO技術棧（微信號：blog51cto）

公司業務高歌猛進時，云成本被掩埋在“數字繁榮”之中，但一旦紅利退卻，云超高的成本就會讓老板們覺得如鯁在喉。這并不是一朝一夕的問題。

這樣的大環境下，企業的側重點變成了，如何在不影響應用性能、盡量保持基礎設施不變的情況下，削減云開支。

在今天的文章中，會為諸位帶來一個“對基礎設施做出簡單改變，并將成本降低 30%的案例，并探究云成本到底哪里貴了。

一、一個操作，6萬美元沒了

云計算帶來的體驗可以說是前所未有：幾秒鐘內生成一個服務器，后端配上無服務器，前端配上存儲桶，就可以托管起整個網站，直到調用數量達到限制之前，該過程甚至都可以不花一分錢。

但是，流量開始增加后，痛苦就來了，就如同“走鋼絲”一般，必須變得小心翼翼起來，因為免費只是暫時的，一個操作不當，糟糕的事情就奔你而來。 

網絡上有很多關于公司或某開發人員一夜之間云成本賬戶銀行卡被通知“刷爆”的恐怖故事，可謂觸目驚心：

上述造成的云賬單，有的是因為一個調用了 lambda 函數而導致了 4.5k 美元的費用，有的則是因為按照某云的說明文檔做了一個測試任務，結果3個月后收到了6萬美元的郵件賬單。

圖片

這些并非個例，但因為高昂地上云的成本就簡單粗暴下云，卻又是另外一番動人心魄的故事，這里不再贅述。

二、云，哪里跑“貴”了？

問題就在于，既想要云端的高效便捷、彈性足夠、便于維護，又不想云賬單一日千里地不可控，有沒有一些可參考的方法和實踐？

我們不妨先看一下這張賬單：

圖片

21,433.21 歐元。這是筆者公司在 2022 年 10 月為臨時環境和生產環境支付的總費用。細分來看，K8s集群、云存儲赫然在列——

• Kubernetes 集群13,743.83 歐元（折扣2,333.84歐元）
• 云存儲（存儲桶）6,124.75 歐元
• SQL 數據庫3,237.22 歐元
• 還有其他較小的成本，本文中忽略不計。

雖然成本并未失控，但 Kubernetes 集群和存儲讓我們付出了昂貴的代價。

三、K8s集群哪里貴了？

接下來，就是分開看這兩塊的成本產生過程。首先是 Kubernetes 集群本身在生產環境上的成本細分。通過下圖就能看出三大罪魁禍首：

計算引擎中的N1預定義實例Core/RAM、Spot可搶占實例、區域間網絡出口產生的費用最高。

圖片

谷歌云計費頁面的屏幕截圖顯示了我們的臨時和生產環境的價格

Tips：對于那些不熟悉的人來說，這些標簽可能需要解釋一下：

• N1 預定義實例 core/ram 是我們 Kubernetes 集群日常使用的節點。N1 是節點類型。
• Spot 可搶占實例 core/ram 是我們生成的用于運行異步任務的節點。可搶占意味著我們為這些節點支付更少的費用，但我們無法保證可用性。
• 區域間網絡出口（Network Egress Inter Zone）是通過網絡在可用區域(AZ)之間移動的數據。假設有一個托管在區域 AZ 中的節點中的 API，如果該 API 向 AZ B 中的節點中的另一個 API 進行查詢，將為從 AZ B 到 AZ A 的數據付費。

問題一：沒有管理好Kubernetes的預期

我們接著逐個攻破。從成本明細中最高的開始：N1 預定義實例core/RAM。

問題的根源就在于我們有沒有告訴Kubernetes該如何擴展新節點。

N1 預定義實例Core/RAM方面，當前使用的是n1-standard-8節點，它們根據使用情況自動縮放。在進行修正之前，了解 Kubernetes 如何擴展新節點非常有必要。

當定義 Pod 時，需要告訴 Kubernetes 一個信息：Pod 需要多少 RAM 和 CPU 才能正常工作；這就是 Kubernetes 所說的 Request。

假設我的 API 的 pod A 需要 400mo RAM 和 0.2 vCPU 才能正常工作，而 Kubernetes 節點容量為 30 GB RAM 和 8 個 vCPU?？梢栽谠摴濣c中容納 40 個 Pod，因為 8 個 vCPU 除以 0.2 vCPU 等于 40 個 Pod，而 30,000mo 除以 400mo 等于 75 個 Pod。

所以，于K8s集群而言，明確預期的和未使用的資源，是一個技術活兒。

表示請求的 CPU 與節點實際容量的架構

問題二：配置文件中的魔鬼細節：CPU和內存值

如果在 8 個 vCPU 節點中有 40 個 pod 請求 0.2 vCPU，Kubernetes 會認為該節點已滿并啟動一個新節點，即使這些 pod 僅使用 4 個 vCPU。

一個合理的配置，就能大大減少因節點數量產生的付費。同時，節點根據請求的資源進行擴展，如何才能避免過多的浪費擴展中的資源浪費呢？

這就需要深入研究 Kubernetes yaml 配置文件，看看可以更改哪些內容。

我們做的第一件事是將 pod 的 yaml 定義與 Grafana 中的實際資源使用情況進行比較。我們可以使用 Grafana 輕松查看請求與實際使用情況的比較，如下所示。

圖片

Grafana 在運行一個 pod 時對 1 個 API 的 RAM 請求/使用情況（在撰寫本文時拍攝的屏幕截圖，因此在配置更新之后）。

在此圖中，我們可以看到 RAM 的平均使用率為 0.1go，而請求的 RAM 為 0.4go 。

如果我們將其與此 API 的 YAML 配置進行比較，我們可以發現類似的內容。

來自部署.yaml 文件的 IAC 存儲庫中的更改的屏幕截圖

我們顯著減少了請求的內存和 CPU 值，以更接近 API 使用的實際情況 —并且我們仍然保持保守；我們可以進一步減少它。我們對所有服務都執行了此流程。

問題3：默認為單個服務運行了太多的 Pod

例如，對于此部署，我們至少運行三個 Pod，這意味著即使 API 在夜間幾乎沒有收到任何調用，它仍然運行3個 Pod。

因此，我們檢查了每項服務，并將 pod 副本的最小數量減少到一個（在安全的情況下）。

圖片

通過這幾項更改，搞定了 N1 預定義實例Core/RAM的成本問題，從4,235.43 歐元增加到 1,973.28 歐元。

問題4：區域間網絡出口的數據交互費用

這方面是非常棘手的，可用區域之間的網絡的數據交互會產生很大的云費用

我們有四十多個微服務，但好處是它們做得很好，而且它們之間幾乎沒有直接通信，但我們在所有這些服務前面有一個GraphQL 網關。這個網關接到很多調用。

筆者也采取了兩種方式解決了這個問題： 

第一個是使用 Flow Logs追蹤哪些調用對于返回的數據最大。

第二種方法，也是我們最有信心的方法，是檢查哪個 API 收到的調用最多，以及該 API 中的哪個端點非常適合緩存。我們已經使用 Redis 作為發布/訂閱解決方案，因此我們也可以輕松地將它用作緩存。

我們決定先做緩存，因為我們無論如何都需要它，而且一切都已經設置好了。但這仍然是一個錯誤——因為我們只是將問題轉移到緩存系統中，而不知道數據是否太大是因為代碼問題還是因為調用次數過多。

使用Kiali，我們可以看到哪個 API 收到的調用最多。

圖片

根據此信息和應用程序的功能方面，我們決定應緩存哪個端點。這樣，GraphQL 網關將實現緩存，并且不必對服務進行 HTTP 調用來獲取數據，從而降低了 Egress 成本。

僅通過實施第一個解決方案，我們就成功地將出口成本從 2.712,34 歐元降低到 1,095.19 歐元。

遺憾的是，我們尚未實現第二種解決方案來追蹤傳輸大量數據的剩余 HTTP 調用。

四、云存儲哪里貴了？

沒錯，云存儲的成本，大部分還是與容量本身有關，而并非存儲桶中傳輸的數據產生的成本。解決的方法自然就很簡單：刪。

筆者公司的應用程序接收來自用戶的視頻，我們對其進行標準化并存儲原始版本和標準化版本。然后，客戶會對這些視頻進行編輯和驗證（或拒絕）。

此前，我們從未刪除過任何內容。我們多年來一直存儲用戶未使用的視頻，并擁有超過 100 TB 的數據。因此，根據我們的法律和產品團隊的意見，我們設置了一個 CRON 作業，用于查詢數據庫的動態參數（例如“視頻拒絕”）并存檔這些文件。

為了防止出現任何不可恢復的錯誤，我們首先將文件的存儲類別在 GCP 中切換為“歸檔”（在 S3 中為 Glacier），并使用生命周期規則在六個月后將其完全刪除。

2022 年 10 月生產環境存儲成本

2023年9月生產環境存儲成本

這仍然是一個持續的過程，因為我們必須謹慎決定刪除哪些內容，但我們成功地將生產中的存儲成本從 4,754.85 歐元降低到 3,029.93 歐元。

五、臨時環境的成本也很驚人

這里，還有一個細節不應忽視，就是臨時環境所產生的費用也很瘋狂。2022 年 10 月，我們為臨時環境支付了 4,059.25 歐元，接近生產環境的1/4。

生產環境和臨時環境之間的成本明細對比

臨時環境下的成本明細

我們采取了四項簡單的措施來降低成本：

我們在非辦公時間關閉了環境。遺憾的是，由于我們是一支國際團隊，工作日晚上的時間不多。

我們縮小了 Kubernetes 集群規模，將所有部署的最小 pod 設置為 1，并防止自動擴展超過 1 個 pod——除了一些關鍵服務。

我們向云存儲桶添加了生命周期規則，以刪除六個月或更早的所有內容。我們清理了數據庫，并刪除了以前開發人員或 QA 中不再使用的所有數據。

圖片

通過這四個簡單的步驟，我們將臨時環境的月開銷降低了 2500多歐元！

六、進一步削減云成本的思路

其他削減云成本的辦法嗎？

當然，我們已經對計劃如何進一步降低成本有了一些想法，更多的是延續上文的內容。

（1）微調 Kubernetes 請求，以更加精確地了解我們的微服務需要運行的內容；

（2）按照我們最初的計劃追蹤剩余的出口成本

（3）繼續在我們的歸檔 cron 中實施新規則，從存儲桶中刪除不必要的文件；

（4）將我們的視頻處理從 CPU 切換到 GPU（筆者實測速度更快且成本更低）；

（5）清理生產中的 SQL 數據庫，存儲可存檔的 TB 級事件數據。

如果我們比較 2022 年 10 月和 2023 年 10 月，我們每個月節省了 6,369.75 歐元，幾乎節省了 30%，我相信我們可以節省更多。

七、寫在最后

追蹤云成本并優化是一件非常非常有挑戰的、且富有成就感的事情。于與云程師、架構師而言，即便支付云賬單的賬戶是公司，而不是自己。

但說起來容易，做起來難 。在個人項目上使用云的免費層和在每天有數百萬次調用的生產環境中使用云是兩種完全不同的野獸。

本文帶大家從頭開始分析了云成本過高的幾個問題：生產環境下的K8s集群、云存儲的問題、以及臨時環境下的不必要的開支，并給出了解決思路和計劃。

記?。簭囊婚_始就考慮應用程序的生命周期，并采取適當的保護措施，以防止您的云成本過高，而不是一味按照文檔配置部署，否則，迎接你的只能是高昂的收費通知。

參考鏈接：https://alexandreolive.medium.com/how-we-manage-to-reduce-our-cloud-costs-by-25-percents-3f8c26db704a