博客 / 詳情

返回

雲音樂 KubeCost 助力 FinOps 降本增效

本文作者：木心

背景

目前很多互聯網公司都告別了過去流量和業務迅猛增長的時期，進入了一個相對穩定發展的新階段，業務增長可預期，成本控制成為了一個重要的議題。

在典型的互聯網公司的成本組成中，IT 成本佔比並不低，技術成本與人力成本的比例差不多在 1:2 ~ 1:2.5 左右， 降低 IT 成本顯然能帶來立竿見影的效果。

10 年來雲計算、雲原生、容器、Kubernetes、DevOps 等技術的高速發展，使得 IT 成本的管理變得更加複雜，也給成本的管理帶來了更多的挑戰。

目前大多數互聯網公司，都基於 Kubernetes 實現資源的統一管控，實現統一的大池子，基於此的統一調度、分配、混合雲等都是過去降本增效的重要手段。

在網易雲音樂，我們通過 2 年多的時間完成了在線業務幾乎 100% 的容器化，通過超售、統一調度、混合雲、混合部署等行之有效的手段使得在線資源峯值利用率提升到 50%+，每年為公司帶來數千萬的成本節省。

但是，隨着成本治理的深入，我們會發現，資源治理團隊的壓力會越來越大。因為研發一側 DevOps 很容易獲取資源，導致資源的增長也依然非常地快，並且在流程上缺乏管控（因為本質上從 DevOps 角度希望提效，傳統的工單審批機制被擯棄）。

在雲原生時代，隨着資源池化之後，成本默認歸屬到了技術中心部門，業務部門對成本沒有感知，同時缺乏有效的手段針將成本拆分到業務線，出現了典型的 大賬問題 ，導致無法有效評估業務 ROI。

cost-challenge.png
總結一下存在的變化與挑戰:

  • 去中心化：隨着雲和雲原生應用的蓬勃發展，傳統的集中式財務預算和 IT 管理模式在向以業務為導向的分佈式決策轉型
  • 動態變化：雲上的動態環境和彈性能力導致費用隨業務負載不斷變化
  • 過剩浪費：對資源和服務的即時訪問使創新成為可能，但往往導致供應過剩

這也就驅動了雲音樂推進 FinOps 系統建設，即通過數據驅動工程、財務、技術、業務團隊協作，實現對成本的洞察、優化和運營，驅動建立更廣泛更多角色參與得經營責任制，協助組織實現 ROI 的最大化。

finops-framework.png

雲音樂的 FinOps 系統目前還在內部使用，建設以及完善，後續我們會擇機開源出來，共享給社區。

在 FinOps 開源之前，我們第一階段先介紹下 "基於 Kubernetes 實現資源貨幣化，協助推進大賬拆分小賬" 的組件 KubeCost。

KubeCost

KubeCost 是一個基於 Kubernetes 的資源成本分析工具，通過對 Kubernetes 集羣資源的動態分析，將成本動態的分配到業務線，讓業務線更加地關注成本，從而更好地利用資源，提高資源利用率，提高業務 ROI。

功能介紹

1 支持多種計費方案

比如包年包月、按量計費。

  • 包年包月：目前大多數互聯網企業都是按照包年包月的方式購買雲資源，或者擁有內部固定的專有資源池。在固定擁有資源池的情況下，本質上企業需要按照業務峯值購買資源。自然需要按照業務峯值向業務分攤費用。
  • 按需計費：在固有資源池情況下，往往有很多低峯期的資源是較為浪費的，為了提高資源利用率， 需要通過技術手段去充分利用低谷資源，比如在音樂場景，一些音頻轉碼，音頻特徵分析等可以接受 T+1 的業務場景往往可以填補這些低谷。在這種場景下，需要按照業務實際使用的資源進行費用分攤，而不是按照常駐峯值。

備註：SPOT 資源（比如為了引導用户使用夜間資源，不同時間點價格不同）暫時不支持，後續會支持。

2 支持混合雲多雲計費

除了使用內部固有資源，雲音樂也在使用公有云資源，比如阿里雲，AWS 等。針對這種混合雲以及多雲場景，需要支持不同環境資源採用不同的計費單價。

3 計費模型

遵循 OpenCost 標準的計費模型，OpenCost Specification

基本的原則就是， allocate = Max(Usage, request)

為了確保 計費穩定、可靠、可回贖、可重複， 基礎計費單元，默認按照 10min，並且按照牆上時間對齊作為穩定的基礎計費數據來源。

下圖為基礎的計算過程示例:
kubecost-calculate.jpg

4 支持的計費資源類型

  • CPU
  • Mem
  • GPU
  • 等等

在 Kubernetes 中，交付的 workload 非常多樣，無法使用雲廠商虛擬機的按照既定的規格分配進行計費。因此目前是按照不同資源的單價對資源實體，比如 POD 進行資源核算進行獨立計費，分別計算出 CPU 費用，內存費用等，再聚合為 POD 的總費用。進一步彙總到某個應用微服務的費用。

5 支持豐富地過濾以及聚合

  1. 支持按照 Label 進行過濾：提供類似 kubernetes 接口的 label filter 機制，方便用户按照自己的業務場景（label）進行過濾
  2. 支持 Label 聚合：按照 Namespace、Cluster，以及 POD 的 Label 進行聚合。

比如如下為查詢，所有通過雲音樂標準 DevOps（HorizonCD）系統接入的應用的成本的接口。

POST http://localhost:8080/queryrange
Content-Type: application/json

{
  "startTime": 1685894400,
  "endTime": 1685980800,
  "labelSelector": {
    "matchExpressions": [
      {
        "key": "label_cloudnative_music_netease_com_application",
        "operator": "Exists"
      }
    ]
  },
  "groupBy":{
    "groupDefinition":[
      {
        "type": "label",
        "key": "label_cloudnative_music_netease_com_cluster"
      },{
        "type": "time",
        "key": "10m"
      }
    ]
  }
}

架構

kubecost-architecture.jpg

KubeCost 的架構如上圖所示，架構設計主要考慮幾點:

  1. 低侵入：方案儘量做到更低的侵入性，保障對業務流程的影響最小化，所以未考慮使用 webhook 或者 sidecar 等方案，而是基於旁路指標採集的方案。

  2. 可靠性：確保系統組件故障對整個計費系統的影響最小化

    • ApiServer + etcd: 3 副本以上部署，一定程度保障可靠性。另外管控面掛了，基本等同於管控面關了，無法新增 POD，也就是無法新增成本。歷史資源申請數據都已經採集到 Prometheus 中。
    • prometheus：多實例，數據雙備份存儲。
    • Kubelet：故障之後，相關節點的 usage 數據獲取不到。但主要也是某個節點沒有數據，影響範圍較小。
  3. 擴展性: 核心提供最小力度的原子成本數據，通過 OpenAPI 拓展支持各種計費方式，比如日 95 線峯值的計費、按需、包年包月等等不同的計費資源類型。
  4. 大規模：支持 10w+，甚至百萬以上的 POD 的成本數據統計和查詢，數據存儲選用使用 ClickHouse 進行數據的存儲。按照測試 12w 兩級別的 POD，10min 核算一次成本情況下，一個月壓縮後存儲量大約在 20GB 左右，本地一塊 SSD 即可輕鬆保存幾年的數據。
  5. 易使用：可以靈活的通過各種不同的方式進行過濾和聚合。

如上基礎架構確保最簡單最原始的數據的可靠保障，架構可以容忍 KubeCost 不斷迭代和更新，結合底層數據冪等支持，可以方便地實現故障情況下簡單重試，系統魯棒性較高，也很方便進行數據正確性驗證。另外複雜的計費邏輯可以放在 Plugin 中實現，保障系統的可擴展性和故障隔離性。

底層數據模型

如下為底層數據模型，採用 ClickHouse ReplacingMergeTree 方式，使得目前計算模式下故障情況下可以快速重試，而不會重算，大大減少故障情況下的手工運維。

CREATE TABLE IF NOT EXISTS kubecost.kube_billing_infos
(
    create_time        Int64 COMMENT 'record create time',
    start_time         Int64 COMMENT 'billing start time',
    end_time           Int64 COMMENT 'billing end time',
    item               String COMMENT 'billing item, example: cpu, mem, gpu, etc',
    cost               Float64 COMMENT 'billing cost',
    currency           String COMMENT 'billing currency',
    entity_primary_key String COMMENT 'entity primary key, cluster/namespace/pod/container',
    usage_info Map(String, Float64) COMMENT 'etc:usage,request,allocate',
    label_info Map(String, String) COMMENT 'basic labels',
    price_info         String COMMENT 'cost price info'
) Engine = ReplacingMergeTree(create_time)
      PARTITION BY toYYYYMM(FROM_UNIXTIME(start_time))
      ORDER BY (start_time, end_time, item, entity_primary_key)

最後

目前雲音樂內部已經上線了第一版的 Finops 和 KubeCost 系統，這對於一些對成本比較敏感的團隊是一個有效的支撐工具，他們可以基於部門、業務線等各種維度快速定位到自己關心的成本範圍， 對於更好地評估 ROI 起到了關鍵作用。
另外為了驅動建立更廣泛更多角色參與得經營責任制，我們設計了 Category 模型，支持根據標籤任意圈選 Finops 裏匯聚的任意範圍成本、用量和預算數據，非常靈活有效。
後續我們將對 Finops 設計和實現上的方方面面進行整理總結，最終貢獻到開源社區，歡迎大家過來交流。

最後歡迎各位關注瞭解雲音樂標準 DevOps（HorizonCD）系統，已在今年一月份開源，其受 ArgoCD、AWS Proton 啓發，實踐 Gitops 理念，通過模板體系進行最大實踐，並且有完善的系統管理、權限、外部系統集成體系，
可點擊 官網地址 瞭解更多詳情，歡迎關注，提PR、issue，加入我們的社區，一起打磨完善產品，為中國雲原生領域的發展做出貢獻。

參考

  • OpenCost: https://github.com/opencost/opencost/blob/develop/spec/opencost-specv01.md
  • FinOps: https://www.finops.org/introduction/what-is-finops/
  • Labels and Selectors: https://kubernetes.io/docs/concepts/overview/working-with-obj...
本文發佈自網易雲音樂技術團隊，文章未經授權禁止任何形式的轉載。我們常年招收各類技術崗位，如果你準備換工作，又恰好喜歡雲音樂，那就加入我們 grp.music-fe(at)corp.netease.com！
服務端 , kubernetes , 運維自動化 , devops
user avatar
0 位用戶收藏了這個故事！

發佈 評論

Some HTML is okay.