胡忠想
星汉未来联合创始人&CPO
读完需要
18
分钟速读仅需 6 分钟
1
前言
近年来，公有云、混合云等技术在全球迅速发展，云的普及度越来越高，Docker、Kubernetes、DevOps、Service Mesh 等云原生技术蓬勃发展。但在“上云”之后，企业却往往发现“用云”并没有那么容易。
麦肯锡的一份研究报告显示，全球服务器的平均每日利用率通常最高仅为 6％。据 Gartner 统计，全球数据中⼼利用率不足 12%。以上数据都表明，数据中心的服务器成本及资源消耗存在巨大的“浪费”。
中国信息通信研究院调查数据显示，在云原生技术给企业带来的各项价值中，“提升资源利用率以节约成本”已经连续两年排名第一，2021 年有九成用户认可该项价值。
选项 |
2020年 |
2021年 |
提升资源利用率 |
76% |
90.59% |
提升弹性伸缩效率 |
63% |
76.98% |
提升交付效率 |
38% |
66.83% |
简化运维系统 |
30% |
67.57% |
随着企业用云程度加深，已经有越来越多应用迁移到云原生架构上，然而 2021 年 CNCF《FinOps Kubernetes Report》调研报告显示，迁移至 Kubernetes 平台后，68% 的受访者表示所在企业计算资源成本有所增加，36% 的受访者表示成本飙升超过 20%。这些都说明，即使是资源利用率更高的云原生架构也需要合理的资源成本管理。
图 1 CNCF 统计企业迁移至 Kubernetes 平台成本变化调查
基于相同的统计口径，腾讯云分析了 1000 多位云客户的资源利用情况，抽样超过一万计算节点发现，42%的节点资源利用率低于 10%，72%的节点资源利用率低于 20%。
图 2 腾讯云资源利用率调查
为了帮助企业更好地迁移到云原生架构，我们基于之前多年成本优化经验，系统整理了云原生成本优化的各种手段。主要可以归结为以下三个层面：
第一层：通过混合云或多云服务自动化工具无缝使用性价比最高的服务器资源（例如，异地部署、Intel 换成 AMD、私有云与公有云平衡等），达到跨云算力的最优调度。
第二层：通过容器切割，对高配服务器进行切割后再分配，让 CPU、内存最小单位不受限制，这样有不同类型资源需求的业务可以实现混合部署，最大程度提升节点的资源利用率。
第三层：对业务的算力使用情况进行建模量化并建立水位线、冗余度等配套指标体系，再通过削峰填谷、在离线整合、自动化扩缩容等方式不断优化资源配置，从而帮企业最大程度地降本增效。
以上各种手段实现成本有高有低，诸如异地部署、在离线整合对大部分企业来说技术挑战相当大，不同企业需要按照自己的实际情况来选择，为此我们整理了企业云原生成本优化的一般步骤，供大家参考。
2
成本节省第一步：做到成本可观测
要想降低云原生成本，首先要做到成本可观测。具体来讲，就是要知道成本具体花在哪里。
通常企业内部会划分为多个部门，每个部门对资源的需求以及资源掌控力度不尽相同，要让各个部门对成本的认识及管理能力保持一致，就必须有清晰的成本认识，可以从以下两个方面来执行：
2.1
建立资源利用率指标
成本管理实际上是资源使用管理，如何快速并准确地识别出资源的分配、消耗以及浪费，是成本优化的前提条件。因此成本管理首先要做到的是资源消耗和资源利用率可视化。
通常的做法是对资源的各种指标，如 CPU 使用率、内存使用率、磁盘使用率、进出带宽使用率等数据进行采集并展示。采集的方案可以通过在资源上部署自己研发的 agent，或者对接云厂商已有的监控数据。
这里需要注意的是，要对资源打好标签，一般企业内部都有成熟的 CMDB 系统，可以将资源按照类似产品线-业务线-集群等层次组织起来，也可以通过云厂商提供的资源标签功能进行标注组织，这样就能够从多维度多层次洞察资源的消耗与利用率。
2.2
建立每日对账机制
公有云厂商虽然默认提供每日账单机制，但主要是从产品维度来区分，企业内部应该按照集群-业务线-产品线多个层次来观察每日的消耗，以便找出资源消耗异常点。比如，如果使用的弹性资源实例过多或者弹性时间过长，就可以 review 是否要将弹性的实例转化为成本更便宜的常备实例。
除了要建立每日账单机制，最好还要有预算机制，即从集群-业务线-产品线多个层次确立每日资源的正常消耗，结合每日账单就可以判断出哪些集群、哪些业务线或者哪些产品线的资源使用超标，这样可以及时发现超标的原因从而快速加以改进。
完成第一步成本可观测之后，企业就能清楚地知道具体是哪一个业务线或者哪一个集群资源利用率低，紧接着就可以执行下面的步骤来节省成本。
3
成本节省第二步：公有云物尽其用
企业上云的第一步往往是把业务从原有的物理机或者虚拟机迁移到公有云，但因为对云产品本身不是很了解，以及对云成本认识不足导致实际并未节省成本，甚至反而因为引入公有云导致业务复杂度提升，相应的成本反而提高了。仔细剖析，主要有两方面原因导致：
考虑到业务的稳定性以及高可用性，通常系统预留的资源是按照业务峰值再叠加一定的 buffer 来制定的，这就必然导致除了高峰时段资源利用率高，非高峰时段资源利用率低，甚至在业务低峰时段资源利用率极低；
对业务本身的资源需求缺乏精确认识，许多业务对资源的需求不规范，仅凭经验或者出于业务性能的考虑，配置越高越好，然而业务实际运行中发现有严重的资源浪费情况。
如果能够充分利用公有云的弹性以及退改灵活性，则可以通过定时扩缩容和机型降配两种手段，在不对业务进行任何变更的情况下，直接有效降低公有云的使用成本。
3.1
定时扩缩容
很多互联网业务的流量具有周期性，尤其是一些社交应用如微博、抖音等，峰值流量会出现在中午 1 点和晚上 10 点左右，可能达到日常流量的 1.5 倍甚至更多。若是用常备服务器支撑日常峰值流量，那非峰值时段服务器的利用率显然是不足的。
除此之外，大部分公司在凌晨之后的业务流量通常都极低，只需要少数服务器即可支撑线上流量。对于这一类业务，实际上若是能根据实际业务的流量定时扩缩容，比如中午 12 点扩容，下午 2 点缩容，晚上 8 点扩容，凌晨 12 点缩容，显然可以大幅降低服务器成本。
还有一些典型场景如电商大促，因为时间点比较明确，流量可预期，可在大促到来前定时扩容一批机器，待活动结束后再释放。受疫情影响，一部分网课以及在线会议流量暴涨，但因为时间可预期，也可以采用定时扩容的方式来应对。相比购买包年包月的机器，采用定时扩缩容，成本可以大幅降低。
3.2
机型调配
公有云上提供了各种配置的机型，业务可以根据自己对 CPU、内存、磁盘、网卡以及 IO 的实际需求来购买适合自己业务需求的机型，而且公有云提供了包周、包月以及包年等多种订购方式，大部分业务对自己的实际资源需求是不准确的，可以有针对性地进行压测，确定实际需要的资源配置。针对包年包月包周购买的服务器，可以在到期时根据实际配置需求重新订购。如果是按量付费的话，则可以随时更改扩容配置。
除此之外，大多数公有云还提供了两种不被太多人关注但性价比更高的产品，一种是 AMD 实例，一种是竞价实例。
3.3
AMD 实例
在 x86 服务器市场上，Intel 的 CPU 得益于其长久以来出色的稳定性和性能，占据了绝大多数的市场份额。但随着 AMD Zen 架构的 EPYC 处理器的推出，其在同等性能下每核心的价格相比 Intel 的 CPU 更低。以公有云厂商为例，同等规格的实例若采用 AMD 处理器，价格能降低 30%以上。
AMD 实例可以兼容不同版本的操作系统，但因为 AMD Zen 架构发布于 2017 年，处理器的部分新特性在旧版操作系统上会出现部分功能支持上的缺陷。所以需要企业根据应用的实际情况，自行决定需要使用的操作系统版本。
3.4
竞价实例
竞价实例也叫抢占式实例，是一种按需实例，旨在降低部分场景下使用 ECS 的成本，合理的使用 ECS 竞价实例，最高可以降低 50% – 90% 的运营成本(相比按量付费的实例)，可以用相同的预算，将计算容量提升 2–10 倍。
创建竞价实例时，必须为指定的实例规格设置一个价格上限，当指定的实例规格的当前市场价格低于出价时，就能成功创建竞价实例，并按当前市场价格计费。默认能稳定持有实例 1 小时，1 小时之后每 5 分钟会检查一下，当市场价格高于出价或者资源供需关系变化时，实例会被自动释放。
为了保证尽可能高概率的弹出竞价实例，可以设置多个地域多个可用区多个规格进行竞价，可以大大提升了竞价实例的创建成功率。除此之外，因为竞价实例可能随时会被自动释放，就需要业务具备弹性伸缩能力，在竞价实例被回收前，能够自动的重新选择其它竞价实例来替代，如果没有竞价实例了，可以再扩容按量付费的实例。竞价实例适用于无状态的应用场景，例如可弹性伸缩的 Web 站点服务、图像渲染、大数据分析和大规模并行计算等。应用程序的分布度、可扩展性和容错能力越高，越适合使用竞价实例节省成本和提升吞吐量。有状态应用不宜使用竞价实例，例如数据库。因为竞价失败等原因导致实例被释放时，应用状态难以保存。
3.5
私有云与公有云平衡
通常都认为使用公有云比自己采购服务器更加节约成本，然后实际并不一定。企业在实际使用过程中发现大批量采用公有云的包年包月机器后，按年摊销的话相比自建机房采购同等配置的单台服务器成本要高。所以已确定的长期需要使用的包年包月的机器可以转化为自己采购的机器，短期内无法确定是否是长期需求的可继续使用公有云。企业在每经过一段时间，就需要对自己的公有云上的包年包月机器进行 review，确定哪些适合采用私有云，哪些继续使用公有云。以字节和快手最为典型，快速发展的初期大量使用了公有云的包年包月资源，在企业稳定发展后，开始逐步将这些资源转化为私有机房的资源。
以上手段业务无须改造只需要做一些运维层面的变更即可直接实现成本节省，适合大多数上云的企业。这个阶段理论上负责运维的团队即可执行，不需要业务深度参与，执行难度比较小。但当前公有云的产品众多，公有云的控制台操作复杂不适合直接拿来使用，为此可借助一些二次开发的平台，如开源算力引擎 BridgX ( https://github.com/galaxy-future/bridgx/ ），基于多个云厂商的 SDK 封装并提供了简单易用的 API 以及 WEB UI，可快速的使用公有云的各种产品。若企业想进一步优化成本，则需要执行成本节省的第三步：充分利用弹性与共享，来进一步提高资源利用率，以降低成本。
4
成本节省第三步：充分利用弹性与共享
4.1
Kubernetes 资源切割
大部分企业内部不同的业务对机器的资源需求不同，有的业务是计算密集型，对 CPU 的要求较高，有的业务是内存密集型，对内存的大小要求较高，有的业务是网络密集型，对网卡的要求较高，有的业务是离线计算型，对磁盘空间要求较高，然而实际购买的机器并不一定能够与不同业务的需求完全吻合，这就造成大部分机器的资源无法充分利用。
所以需要一种更灵活的资源分配方式，如果业务能够根据自己的需求任意定制是最好的，这一点自己采购机器显然是无法满足的，公有云虽然提供了多种多样配置的机型选择，但对 CPU、内存等的规格还存在固定限制，要求 CPU 和内存比为 1:2 以上。云原生时代以 Kubernetes 技术为代表的容器云平台，可以把企业现有的服务器资源统一管理起来，通过 Kubernetes 的资源隔离技术，按照业务实际的需求，给业务分配实际需要的资源。
但因为 Kubernetes 技术本身的复杂性，企业要想自己搭建一套可稳定运行投入到线上生产环境的云平台，需要投入相当大的研发人力。为此许多云厂商也提供了可托管的 Kubernetes 集群，虽然在一定程度上降低了使用 Kubernetes 的门槛，但仍然需要充分掌握 Kubernetes 技术本身，如交付的 Pod 的 IP 是动态变化的，并且需要有与之配套的网络、监控、日志等解决方案。企业原有面向固定 IP 的运维基础设施将不再适用，所以说迁移成本以及使用门槛还是相当高的。
针对大部分企业的现状，我们建议企业首先利用 Kubernetes 切割现有资源并以固定 IP 形式交付资源，这样企业既能充分利用 Kubernetes 的资源隔离能力提高资源的利用率，又可以继续复用原有的运维解决方案，以便以低成本的方式迁移到 Kubernetes 容器云平台，之后再根据自己的实际情况来决定后续的技术建设。
4.2
自动扩缩容
前面在介绍定时扩缩容时提到有很多互联网业务的流量具有明显的周期性规律，例如中午和晚上流量明显较高，而凌晨以后流量极低，可以使用定时扩缩容固定数量的机器来解决。然后现实中业务的流量增长模型并不是一成不变的，有可能某一天流量增长超出以往，或者某一时间有突发的流量增长，这时候仅仅靠定时扩缩容显然难以满足，这就需要靠自动扩缩容来应对。当前基于 Kubernetes 的容器云平台提供了一些根据 CPU、内存使用率等简单的指标来进行弹性伸缩的手段，但对于大部分企业的业务来说，实际线上服务模型要复杂得多，很难依靠某个单一指标来衡量是否要扩缩容。一个更合理的方案是对流量模型进行抽象，既要考虑 QPS 的变化，又要考虑业务实际性能。可以定义系统冗余度的指标，它代表了系统实际能承受的最大消耗与实际消耗之间的比，其中系统能够承受的最大消耗可以通过压测来衡量，再结合各业务的实际情况定义一个最小冗余度和最大冗余度，若系统冗余度低于最小冗余度则自动扩容，高于最大冗余度则自动缩容。
4.3
错峰调度
除了上面提到的一个业务流量通常在一天之中会有波峰波谷，如果企业内部有多个业务并且不同业务的流量高峰低谷的时间不尽相同，则可以根据各业务的流量特点做错峰调度。
正如前面提到的通常各业务都是按照流量高峰做常备冗余部署资源，可以根据各业务的实际流量情况只保留最小程度的冗余，而将过度冗余的资源统一纳管到一个虚拟资源池当中，这样的话就可以保证波峰波谷不同的业务能够相互利用各自冗余的资源，提高系统整体的资源利用率。
错峰调度的挑战在于能否准确并及时的衡量各业务的冗余度，以便在业务需要资源的时候能够及时的从虚拟资源池回收，并且如果虚拟资源池中资源不足时，还要及时的从外部申请资源。
更进一步可以通过收集分析各业务的历史指标数据，对未来一段时间的指标趋势进行预测，从而确定各个业务的流量高峰及低谷对应的周期，并指导后续的资源调度。
4.4
GPU 共享
随着 AI 技术的逐步成熟，越来越多的企业开始构建自己的 AI 应用，并将 AI 应用迁移到云。其中 AI 应用对 GPU 资源的需求最为强烈，当前基于 Kubernetes 的容器云平台在调度 GPU 资源时，通常是将一张完整的 GPU 卡分配给一个容器。随着显卡技术的不断发展，半导体制造工艺的进步，单张 GPU 卡的算力越来越强，同时价格也越来越高。但在很多的业务场景下，一个 AI 应用并不需要一整张的 GPU 卡。显然若能使多个容器共享一张 GPU 卡，并保证业务的安全隔离，则可以显著提升 GPU 利用率，节约成本。一些第三方如公有云提供了基于 Kubernetes 实现的 GPU 共享解决方案，如果企业在 GPU 资源上花费成本较高，并且资源利用率不高，可以考虑使用 GPU 共享的解决方案，以便节省成本。
通过以上手段，业务可按照自己的实际需求利用弹性与共享来实现最大化的资源利用，不过需要有企业级的统一云平台提供 Kubernetes 切割、自动扩缩容、错峰调度以及 GPU 共享等能力。通常有两种方案，一种是自建基于 Kubernetes 的云平台，不过考虑到技术门槛和生产环境的复杂性，一般企业需要投入至少十名以上的研发人员才能建设一个完整的 Kubernetes 云平台，一种是使用第三方如公有云托管的 Kubernetes 集群，虽然省去了自行维护 Kubernetes 集群的精力，但仍需掌握 Kubernetes 的各种功能特性和开发能力，门槛依然很高。为此我们提供了一个更加容易落地的方案，就是在企业原有的运维设施的基础上，根据需要集成开源的解决方案如开源算力引擎 BridgX( https://github.com/galaxy-future/bridgx/ ），支持 web 服务自动扩缩容、Kubernetes 切割并以固定 IP 形式输出等功能，只需要很小的开发成本即可拥有以上功能。
当企业达到一定规模后，要想进一步优化成本，就得从更高维度去考虑了。这个时候就可以考虑异地部署、混合编排、在离线整合等复杂度更高的手段了。
5
成本节省第四步：应用混部与异地部署
5.1
异地部署
企业的 IT 成本除了服务器自身的成本外，还包括部署服务器的机架成本、机房建设的成本、电力成本以及网络带宽和专线的成本等。西部地区由于电力资源丰富，土地成本以及各种政策扶持的因素，建设数据中心的成本要远小于东部以及中部地区。综合考虑多方面成本，选择在综合成本更低的地区建设或租用机房，或者选择公有云单价更低的可用区，可以明显地降低成本。以公有云为例，西部地区按量付费实例的价格要比东部地区优惠 10%，某些地区如张家口甚至能优惠到 30%。
对于企业内部来说，异地部署最大的挑战在于数据同步与时延，不同 IDC 之间根据距离通常有 10-30ms 的时延。对于时延比较敏感的在线业务来说，要做到异地部署挑战比较大。但对于时延不敏感的离线业务，可以把存储和计算迁移到成本较低的西部 IDC。但离线业务通常数据量比较大，在百 T 以上甚至达到 PB 级规模，若通过公网传输则要以月为单位，而专线的解决方案价格又比较昂贵，通常在百万以上。一个成本较低的解决方案可以使用基于开源算力引擎 BridgX 的数据物流服务 DTExpress，支持通过公网在不同的公有云的不同 IDC 之间传输海量数据，1TB 数据的成本只有 1000 元左右。
5.2
混合编排
上面提到企业不同业务所采用的机型必定存在某一方面的利用率不足，比如计算密集型的 web 业务通常磁盘使用率不高，内存密集型的 NoSQL 业务和 IO 密集型的数据库业务通常 CPU 利用率也不高，通过使用 Kubernetes 切割现有的资源虽然可以一定程度的提供资源使用率，但是因为大部分企业内部的机器配置不高，所以即使使用了 Kubernetes 管理，仍然会存在很多利用不上的资源碎片。一个更好的思路就是把各个业务使用的各种小配置的机器进行整合统一置换为高配机器，再把这些业务混合部署统一编排，这样的话就能做到资源完全互补。
如基于 AMD 处理器的神龙服务器，单台最高具备 256 核 2T 内存 2T 磁盘，并具备高达 60Gb/s 的网络带宽，可以借助 Kubernetes 的资源隔离技术，对 CPU、内存、磁盘、网络进行精细化的调度，如下图所示一台神龙服务器上可同时切割十几个容器跑 web 业务，十几个容器跑 NoSQL，十几个容器跑 MySQL，可满足不同业务的不同资源诉求。
不过多个业务部署到一台大规格机器比较大的风险是一台机器宕机可能影响十几个甚至几十个服务，这时候就需要通过服务/资源治理平台进行快速治理，再加上快速扩容、快速数据分发的能力，则可以达到分钟级的业务迁移。
5.3
在离线整合
大部分企业内部往往存在两种业务类型，一种是在线业务，通常流量高峰比较一致，如果流量高了，在线业务都需要很多机器，一种是离线业务，往往是凌晨开始计算，与在线业务的高峰时间错开。一个合理的设想是为什么不在在线业务高峰期，把离线计算的机器拆借给在线业务使用，等到凌晨在线业务低峰期，把在线业务的机器拆借给离线业务使用，等到早上在线业务高峰期前再拆分回来，然而在企业内部这两种业务的机器并不能充分利用，主要有以下原因：
1、部门墙
在企业内部机器的产品线一般是固定的，成本和利用率也是按照产品线计算的，所以通常情况下机器是不会在不同部门之间自由流转的。
2、机器配置差异大
一般情况下在线业务对 CPU 的要求比较高，对磁盘的需求低，以 web 计算为例，需要的机器配置一般是 16 核 16G 内存 200G 磁盘，而对于离线业务来说，对 CPU 的要求不高，但对内存和磁盘要求比较高，尤其是磁盘单机可达 1T 以上，所以两种类型的机器想复用也比较难。为了解决以上问题，一些企业使用了在离线混部的解决方案，就是将在线业务和离线业务部署在同一个集群同时运行，在线业务流量高时资源主要调度给在线业务，业务低峰期主要运行离线计算，甚至是必要时停掉一些离线任务将资源全部让渡给在线业务，比如阿里双 11 期间就会停掉离线计算业务，将资源全部留给线上的在线业务。这种方案解决了以上问题，但是对技术的挑战比较大，需要对 CPU、内存和网络进行专门的优化，以确保离线计算不会争抢在线计算的资源。
以上手段无论是异地部署、混合编排还是在离线整合都需要涉及不止一个业务，需要从企业整体层面来考虑，通常不是一个部门能解决的。这时候建议企业内部以基础平台或者云平台部门牵头，首先联合关系密切或者对新技术感兴趣的部门成立联合项目组，或者以公司名义成立专项来进行，先从小的业务入手迁移到容器云平台，待验证平台功能完善后，再考虑逐步把核心业务迁移到平台，最终达到优化企业整体资源利用率的目的。
6
总结
上面详细论述了企业优化成本的实施步骤，建议不同企业根据自己现阶段情况有条件的加以选择。如果是企业刚刚迁移上云，可以重点从第二步入手，充分了解云产品的特性，并结合自己业务的特点，真正做到上云以节省成本。如果企业已经上云并且业务稳定运行，但资源利用率不高，并希望通过技术手段进一步提高资源利用率，除了执行第二步以外，还可以考虑第三步在原有的运维设施基础上结合开源的解决方案，选择适合自己的优化手段。最后如果企业的业务达到一定规模，比如具备上万台服务器时，就可以考虑采用异地部署、混合编排以及在离线整合等更高层次更复杂的方案。
