不同企业上云后,其成本节省程度是不一的。从 IT 资源成本节省量来看,低的企业不到 10%,高的企业可达 60%-70%。究竟为何会造成这么大的差异?又有什么组织管理手段和产品技术手段可以降低企业上云成本?
在 2021 年 QCon 全球软件开发大会【北京站】中,腾讯云专家工程师于广游发表了《1000+ 企业云原生改造成本优化总结》的主题演讲,介绍了腾讯云云原生团队,通过大范围的客户调研和访谈,解答了企业如何借助云原生进行更深层次的成本优化,以及腾讯内部和腾讯容器服务客户在容器化过程中进行成本优化的最佳实践。
“从我加入腾讯以来,主要做了两件事情:第一件事情是主导了腾讯云容器产品从 0 开始的设计、研发和运营工作,第二件事情是把腾讯内部的全部自研业务上云。”
在 2017 年时,我们经常跟客户讲容器和云原生的优势,客户会问它到底有什么好处,能降低多少成本?为此,我们与腾讯内外部的客户进行了多次访谈,最后通过数据分析,得出了云原生、容器跟资源利用率之间的关系。
大家应该知道,把 IDC 中的设备和业务搬到云上,在架构不变的情况下,资源利用率肯定不会提升。事实上,我们的调研数据跟预期是一致的,将业务从 IDC 搬到公共云,它的资源利用率平均值一般还是低于 10%。
在 TKE 中,70% 客户的平均资源利用率低于 20%;40% 客户的资源利用率只有不到 10%。也就是说,把业务从 IDC 搬到云上,资源利用率没有提升;接着,把业务容器化以后,资源利用率竟然还是没有提升多少,这是一件非常奇怪的事情。因此,我们针对以下三类客户,进行了一次更深层次的分析:
第一类:业务有波峰、波谷,但是波峰其实不高,波谷更低;
第二类:全天的资源利用率都非常低,一直不到 10%;
第三类:晚上会跑一些离线的计算业务,这类客户资源利用率稍微高一点,但平常也不高。
我们总结了资源利用率低的两大类原因:
举个例子,假设一家公司在云上共有 1 万核,资源利用率每提高 10%,每年就能省 100 万,如果能从 10% 提升到 40% 左右,企业一年其实能省几百万,想必没有企业会拒绝如此大的成本优化吧?为此,我们又进行了一个调研,总结出了企业资源利用率优化失败的典型模式,我们称它为四步失败法。
在第一阶段中,公司业务高速发展,老板告诉 IT 团队要全力保障业务发展,要多少机器给多少机器,业务就能够随便用,但是资源利用率非常低。
第二阶段是公司业务发展没那么快,老板一声令下让 IT 团队优化成本,但由于业务下降,团队都在寻求新的增长点,所以依旧没有精力进行成本优化。在这种情况下,无论是业务还是平台,大家都开始在百忙之中建设资源运营平台、弹性平台,推动业务团队改造。
到了第三阶段,某天业务突发了线上故障,企业内部就会组织一场复盘大会,业务团队复盘认为是 IT 团队推动成本优化,架构冗余减少,挤占研发人力造成的;而 IT 团队则认为是业务技术能力差,提出不合理接入需求、团队人力少所导致的。最终在一次次的博弈中,成本优化就无疾而终了,进而走向了第四个阶段,业务与 IT 团队关系极度恶化,所有团队都觉得成本优化是件吃力不讨好的事情。
根据上述提到的企业成本优化的失败路径,我们发现成本优化其实是由三对本质矛盾组成的,且这三对矛盾不可调和。
第一对是业务稳定性跟资源利用率间的矛盾,很多业务没有人维护,其稳定性全靠冗余来支撑,而冗余天然跟资源利用率就是一个互斥的话题,没有冗余,业务的稳定性就会降低;
第二对是业务投入与技术投入的矛盾,假设部门只有一个 hire count,到底应该去做业务,还是去把架构搞得可弹性,这其实也是一个不可调和的矛盾;
第三对是企业内不同角色 / 组织的矛盾,不同团队由于各自目标,最终演化成了业务团队与资源团队之间的矛盾。
虽然这些矛盾是本质性的,无法完全解决,但企业可以通过技术手段和组织手段减少这些矛盾。组织手段可以分为两个方面:一方面可以通过奖励进行驱动,拿腾讯举例,只要能够观测到每个业务真实的成本和资源利用率,接下来也不需要强制做什么,只需要挂一个红黑榜,给资源利用率前十名的团队奖励,请排名后三位的团队回复邮件,解释说明资源利用率低的原因。
另一方面,企业还可以设置一些增强手段——建立成本文化,这是刚刚兴起的一个名词叫 FinOps,意思是代码设计之初就需要考虑冗余和架构,企业要监控性能、稳定性等数据的指标。它让每个团队都可以像监控业务可用性一样监控业务成本,像优化业务可用性一样去持续优化成本。
此外,组织手段虽然可以使不同团队目标对齐、促进协作,但关键难点还在于技术复杂度的处理,没有技术投入和技术实力,成本优化就是无休止的扯皮和甩锅。实际上,资源利用率提升的本质是消除浪费,一种方式是推动业务按需使用,即为弹性伸缩,用多少申请多少,不用就把它缩下去;第二种是业务不用动,平台方进行资源腾挪复用,即为在离线混部。这两种方式分别有不同适用的场景:
弹性伸缩是根据实际负载,对业务和资源进行横向和纵向的动态调整,它的核心是业务资源的按需使用,一般资源池大小是动态的。所以它有两个限制条件,一是纯 IDC 环境效果有限,缩容的资源依旧空闲;另外是业务方需要进行微服务化改造,无法无痛接入。
目前,腾讯云已经在这方面做了一系列工作,并且主要围绕及时性、灵活性、可用性做了优化。其中,及时性支持基于预测的提前扩缩容,基于 Buff 的节点预扩容,基于配置扩容等等;灵活性是从业务层载体的扩缩容算法、支持多种指标扩缩容;可用性则能够动态感知资源售罄,智能调整扩容策略,提高扩容成功率;在大数据方面,腾讯云基于 Yarn Operator 和存算分离实现了大数据等业务的弹性扩缩容。
那弹性该怎么落地呢?腾讯内部推出了一个云原生弹性成熟度模型,用来监控业务组件在过去一周中是否发生过伸缩。如果监测到从来没有发生过伸缩业务,就让它能够伸缩,有这个能力之后,再去推动弹性改造,最终,通过这种方式资源利用率提升了 30%-40%。
在离线混部的本质是将分配给应用,但应用实际未使用的资源,再动态分配给其他应用,其核心是资源的腾挪、再利用,一般资源池大小是固定的。它的优势非常明显,业务几乎不需要做过多的改造,且平台可后台对资源进行灵活腾挪和复用。
但是它同样也是有限制的,首先,总资源池大小固定,无法应对流量突发的场景;其次,需要有离线业务能够填补在线低峰。在腾讯云的在离线混部实践中,提出了如意 RUE 的解决方案,它能够让机器分别部署高优业务和低优业务,当高优业务起来的一瞬间,能够对低优业务进行绝对的压制,并且对在线业务零干扰。最终,能够使资源利用率提升 60%-70%。
前面提到的两种方案都有各自的优缺点,所以最好的方式就是互补,在离线混部 + 弹性伸缩才是提升 IT 资源利用率的绝佳组合。
在 2020 年时,有一个腾讯云的外部客户对整个在线业务进行了容器化改造,他们也是非常惊讶地发现,容器化改造之后,资源利用率的提升是有限的,所以就希望在 2021 年进一步提升。
显而易见,这家公司内部已经将全部业务进行弹性化改造了,另外,他们业务的波峰、波谷非常明显,而且离线业务非常大,以至于离线业务跑起来的时候,在线业务的池子是不够用的,所以腾讯云为他提供了混部 + 弹性的方案。
客户的集群本身部署了在离线混部的特性,同时腾讯云又给他们提供了一个大数据的容器化方案,使其现有的大数据系统不用做任何改造,只需部署一个组件,就能够把大数据系统的 Job 任务运行在 K8s 集群中。
客户进行了非常稳健的内部推广,前期只在业界把离线业务往在线业务平台上发布,但整个实施过程其实非常简单,因为绝对压制的 OS 内核能力,使其并没有用太多的调度能力。
此外,TKE 可以在一个集群中插入虚拟的 Node,正常情况下插入一个真实的节点,用户需要创建一个容器。当创建虚拟动作时,最终会到腾讯云的资源大池中创建一个轻量的虚拟化 Pod。在这种情况下,就完成了在线和离线的统一。最终,通过优化资源碎片、在离线混合部署、自动扩缩容,这家企业的整体计算成本下降了 43%。
最后再介绍下腾讯内部自研上云混部的实践,游戏、金融、社交等 6 个腾讯 BG ,每一个业务的技术栈都是不一样的,所以进行混部优化的过程非常艰难,但腾讯公司内部还是通过自上而下的支持,进行了全面云原生的改造,把全部的增量业务全部放在 TKE 进行,存量业务逐渐往 TKE 迁移,共用 TKE 这样的调度系统进行混部。最终,平均资源利用率达到了 46.5%,样板集群资源利用率达 65%。
演讲最后,于广游对成本优化的关键点进行了总结,他提到,仅把设备搬到云上,资源利用率是无法提升的,企业会惊讶地发现他们把业务容器化以后,资源利用率的提升竟然也是有限的。当企业去实施成本优化方案时,对其自身企业的技术实力和管理能力,又是一个真正的大考核,但这个大考也是有答案的,那就是 TKE ,云原生能够把握效率和成本的平衡点。
演讲嘉宾介绍: 于广游 腾讯云专家工程师,腾讯云容器技术总监 主导了腾讯云容器产品从 0 开始的设计、研发和运营工作,并在腾讯云海量 Kubernetes 集群的治理和落地过程中积累了大量的经验。腾讯自研业务全面云原生上云的主要参与者之一,在云原生领域有丰富的实践和思考。目前致力于 Kubernetes 在成本节省、Serverless、混合云等场景的探索。
领取专属 10元无门槛券
私享最新 技术干货