关于服务端:云音乐-KubeCost-助力-FinOps-降本增效

16次阅读

共计 4432 个字符，预计需要花费 12 分钟才能阅读完成。

本文作者：木心

背景

目前很多互联网公司都辞别了过来流量和业务迅猛增长的期间，进入了一个绝对稳固倒退的新阶段，业务增长可预期，老本管制成为了一个重要的议题。

在典型的互联网公司的老本组成中，IT 老本占比并不低，技术老本与人力老本的比例差不多在 1:2 ~ 1:2.5 左右，升高 IT 老本显然能带来空谷传声的成果。

10 年来云计算、云原生、容器、Kubernetes、DevOps 等技术的高速倒退，使得 IT 老本的治理变得更加简单，也给老本的治理带来了更多的挑战。

目前大多数互联网公司，都基于 Kubernetes 实现资源的对立管控，实现对立的大池子，基于此的对立调度、调配、混合云等都是过来降本增效的重要伎俩。

在网易云音乐，咱们通过 2 年多的工夫实现了在线业务简直 100% 的容器化，通过超售、对立调度、混合云、混合部署等卓有成效的伎俩使得在线资源峰值利用率晋升到 50%+，每年为公司带来数千万的老本节俭。

然而，随着老本治理的深刻，咱们会发现，资源治理团队的压力会越来越大。因为研发一侧 DevOps 很容易获取资源，导致资源的增长也仍然十分地快，并且在流程上不足管控（因为实质上从 DevOps 角度心愿提效，传统的工单审批机制被摈弃）。

在云原生时代，随着资源池化之后，老本默认归属到了技术核心部门，业务部门对老本没有感知，同时不足无效的伎俩针将老本拆分到业务线，呈现了典型的 大账问题 ，导致无奈无效评估业务 ROI。

总结一下存在的变动与挑战:

  • 去中心化 ：随着云和云原生利用的蓬勃发展，传统的集中式财务预算和 IT 管理模式在向以业务为导向的分布式决策转型
  • 动态变化 ：云上的动静环境和弹性能力导致费用随业务负载一直变动
  • 过剩节约 ：对资源和服务的即时拜访使翻新成为可能，但往往导致供给过剩

这也就驱动了云音乐推动 FinOps 零碎建设，即通过数据驱动工程、财务、技术、业务团队合作，实现对老本的洞察、优化和经营，驱动建设更宽泛更多角色参加得经营责任制，帮助组织实现 ROI 的最大化。

云音乐的 FinOps 零碎目前还在外部应用，建设以及欠缺，后续咱们会择机开源进去，共享给社区。

在 FinOps 开源之前，咱们第一阶段先介绍下 “ 基于 Kubernetes 实现资源货币化，帮助推动大账拆分小账 ” 的组件 KubeCost。

KubeCost

KubeCost 是一个基于 Kubernetes 的资源老本剖析工具，通过对 Kubernetes 集群资源的动态分析，将老本动静的调配到业务线，让业务线更加地关注老本，从而更好地利用资源，进步资源利用率，进步业务 ROI。

性能介绍

1 反对多种计费计划

比方包年包月、按量计费。

  • 包年包月 ：目前大多数互联网企业都是依照包年包月的形式购买云资源，或者领有外部固定的专有资源池。在固定领有资源池的状况下，实质上企业须要依照业务峰值购买资源。天然须要依照业务峰值向业务摊派费用。
  • 按需计费 ：在固有资源池状况下，往往有很多低峰期的资源是较为节约的，为了进步资源利用率，须要通过技术手段去充分利用低谷资源，比方在音乐场景，一些音频转码，音频特征分析等能够承受 T+1 的业务场景往往能够填补这些低谷。在这种场景下，须要依照业务理论应用的资源进行费用摊派，而不是依照常驻峰值。

备注：SPOT 资源（比方为了疏导用户应用夜间资源，不同工夫点价格不同）临时不反对，后续会反对。

2 反对混合云多云计费

除了应用外部固有资源，云音乐也在应用私有云资源，比方阿里云，AWS 等。针对这种混合云以及多云场景，须要反对不同环境资源采纳不同的计费单价。

3 计费模型

遵循 OpenCost 规范的计费模型，OpenCost Specification

根本的准则就是，allocate = Max(Usage, request)

为了确保 计费稳固、牢靠、可回赎、可反复 ，根底计费单元，默认依照 10min，并且依照墙上工夫对齐作为稳固的根底计费数据起源。

下图为根底的计算过程示例:

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 的架构如上图所示，架构设计次要思考几点:

  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！

正文完
服务端
发表至： 服务端
2023-06-29
 0
关于服务端:云音乐-GitOps-最佳实践
关于服务端:前端服务框架调研NextjsNuxtjsNestjsFastify
关于服务端:服务API版本控制设计与实践
关于服务端:云音乐-GitOps-最佳实践