00:01
各位网友大家好,欢迎观看原动力云原生正发生降本增效大讲堂系列技术直播。今天是该大讲堂的第一期第一讲直播主题是云原生降本增效优秀实践案例分享。那在6月30日7月7日晚上八点将进行第二讲与第三讲,欢迎大家预约观看啊,原动力云原生正发生降本增效大讲堂是由中国信通院腾讯云box产业标准组联合策划,目的是与开发者一同交流提升资源利用率,降本增效的方法与优秀实践。相信很多开发同学呢,都听说过云原生,甚至已经将云原生的相关技术带到了我们日常的开发和生产中。理论上,当我们使用云平台的弹性伸缩特性来管理各种计算资源的时候。可以使得我们的服务器成本降低。但是根据2021年CF的of Co report指出,迁移到Co平台后,68%的受访者表示所在企业的计算资源成本会有所增加。
01:13
36%的受访者表示成本呢,飙升超过20%。因此,提升资源利用率,实现降本增效以成为当前企业关注的重点。但是,该如何提升资源利用率,实现降本增效,原动力云原生正发生,降本增效大讲堂将通过实讲来为大家进行解答。那今天呢,我们也请到了两位老师来和我们分享云原生降本增效的优秀实践案例,在观看直播过程当中呢,如果有问题可以发送弹幕进行提问与互动。那首先是中国信通院云大所副总工程师陈一利老师,陈老师将为我们分享云原生产业发展态势。然后是腾讯云容器技术专家of产品研发负责人孟凡杰老师。
02:04
孟老师将为我们分享云原生资源利用率现状,深入理解的资源管理。基于云原生技术的成本管理优秀实践。我们先有请陈老师分析一下云原生的产业发展态势。各位嘉宾啊,各位现场的观众,大家好,我是中国信通院陈。呃,非常感谢呃,参加这次原动力原生正正发生降本增效大讲堂。呃,那么今天呢,也给大家这个简单做一个分享吧,就是。分享主题呢,是这个原生产业发展态势分析。嗯,首先是这个,大家现在对语言生都不陌生哈,那么对于这个。呃,生这个技术也是啊,受到大家广泛的关注啊,尤其是在这个数的浪潮么,我们认为是生是一个一个强大这样一个引擎,或者我们的一个,呃,对数字化是一个核心的这样一个驱动。
03:10
向下样一个一个位置。那么向上的话,我们呃,主要从行业这几个方面啊,利用云原生技术,然后去做行业赋能。能够。去这个。易购的资源的这个这样一个融合,呃,原生在国内的发展近几年啊,其实是非常迅猛的,那么呃,之前新能源的这个调查报告,呃,显示的数据是,那么2020年中国生市场规模已经达到将近1000元这样一个规模,那么生同时呢,也在像不同的,呃,除了一些重点的一些行业,比如金融啊,交通能源这些行业,那么更加传统的这些行业也在逐步的去使用,利用原生技术去提升他们的数字化的水平。
04:24
同时呢,原生技术是本身在这个运维和研发的效果是非常显著的,未来它的应用领域也大大的。无论是从这个行业的还是规模,包括整个资领还企业原生建设支出方方面来讲,就是近几年的触是呃,得到了大的提,大幅的提升,原生技术最早是在环境,或者说是类生产环境啊这样的一个有一些嗯。
05:02
主要的一个用处吧,那么包括器微啊这些技术得应用。纳。而且是从这个次核心或者非核心业务逐步向核心业务应用嘛。微服务的这个架构的这个模式也得到大这个广泛的认可,就它有一个非常强的这个耦的这样的一个。灵活度或者扩展性。相对发展还是呃比较前沿的,但是的场景主要有几个,这个典型的。代表吧。原生在各行业的这个,嗯,差是有,但是不同的,这对原生的这个的一些特性的重视也是不不太一样的。
06:12
啊,总体来说,包括这个力度的这个资源利用率,还有这个极致弹性交付的标准化异构资源的统一大管。还有这个开放架构,目前企业比较关注的几个点。啊,降本增效是为什么说是今天我是我们讨论的主要的话题啊。是如何成为企业生应用的一个核心价值啊,因为我们知道就是在原化,其实往都在强调增效降本增效的一个一个一个量化指标,其实呃,大家还是比较模糊的这样一个概念,但是从呃我们实际上来讲,就是现在随着。国内云计算的发展。
07:00
啊,已经历了十多年这样一个阶段,其实对于成本的优化,对于本这需。呃,信通院统计了,就是这个连续几年吧,做了一些,呃绕生领域做了一些调查报告,那连续两年也是就是说于节约成本是两都一个大家是遍认价,那说明也是,同样也说明是。带来了用的升方更资源能高效的这个应用能还有这个的能。的资源利用率,第二个是这个降的门槛,第三个是节约研发的成本。
08:09
啊,第四个少的投入,那从这个方面来讲,恰是我们企业化转或者数字化的一个最优的一个径。那么企业呃用程度加深,那么也必然会导致这个支出浪费的问题,那么我们生成本的治理啊,其实是应该受到大家的广泛的关注的。那么企业用的这个不断加深,呃。我们这个通过。这个2021年状态报告数据显示。啊,平均浪费了30%的云支出,成本预算处于这个整个一个失控状态,那对于C啊Co来讲,它是。在这个企业成本优化面临的一些挑战呢,就是包括了这个计量的式不资源配置不合资管等等几个核心的啊问题吧。
09:15
呃,如何通过原生技术进行成本优化,那我们就可以应该应该做到信息统计的啊,最终实现成本可视。在应用层面的话,应用本实现能够最终现成本优,包括的度应的的优化啊。从资源层面,从架构层面去节约这方面的资源。呃提升利用率呃云应用,呃应用的这个作为呃生本增效的一个核心技术吧。那在传统的这个架构下,就是我们在虚拟化时代。呃,应用和虚拟化是强绑定的关系,或者说一对一的关系,那么或者多对一的关系,嗯,它很难实现这个混的场景下的这个资源的复用。
10:17
原生一个任务啊,不可过。能够让我们的资源弹性资源的利用率啊更加的合理科学。那么在这个混的这个依据的一些业务特性呢来讲的话,主要是分为比如说像业务优先级啊的要求啊,稳定性要求,还有资源的优先级,资源占用。景景。
11:06
对于像容器,微服务服,网格这些技术不断的成熟,那么技术设施也是更加的灵活,同时呢,它和业务这个应用的一个一个基于的这个。应用混技术能够帮助企业呃更加的进一步的提升资源的利用率,实现运营成本的降本增效。大量海量的这样的一个混合的部的这个应用,这个带来的可能是更明显的。那我们从高优先级任务到呃,包括第一优先级任务,我们可以通过资源隔离,应用画像,还有集群的混任务调度,呃,干扰检测充处理,能够实现我们整个的云原生应用的这样一个一个能力。
12:00
嗯。讲一下就是生个趋势,首先生成为普惠何行业,任何现在我们提到很多行业,很多呃技术领域,其实或或少都和运营会产生一定的关系,那这样的话就是它变成一个性的数字接口,能够更好的赋能企业的呃化。所以呢,从技术的革新到我们的业务价值,其实是呃,带给企业的至少是两方面的这样的一个变化。另外一个就是生对软件产业个变革是持续的零二这势了,预测到2025年。
13:05
嗯,那么我们认为未来的云上应用也最终会走向化,那么国内万的软市场重新洗牌,这个是说按照当前国内软件市场这样一个体量来来去估算。就是生是觉得最够。信息化市场产生影响。那第三个是云生和开源的关系,其实这个就是,嗯,一直也是大家这个比较,嗯,老生常谈的一个问题吧,源源这个产业不可灭。
14:01
同时呢,也在大。新发起的这个原生生态景的这个项目,其实把国内比较典型的这个开源项目做了一个录。那一共统计了152个项目吧,这和CF那个是对应的。70%为项目,那么内主项目大概有个。所以呢,进步也可以看到,就是国内,呃,借助原生这波热度能量,或者把我们的开源其实也带上一个更高的高度啊。好,我今天的分享就先到这里,好,谢谢大家的关注哈。感谢陈老师的精彩分享,让我们从全局上了解到了云原生在国内的发展态势,以及云原生对当前it行业的重要影响。对于云原生发展态势,你自己还有哪些见解?欢迎大家在直播间弹幕中提出你的见解。
15:04
好的,下面我们有请孟老师来分享一下云原生降本增效优秀实践案例。大家好,我叫孟凡杰,来自腾讯云容器产品中心。作为fan OPS的产研负责人,我主要把控fan OS的产品定义。啊,以及技术架构。那同时我会啊,致力于推广原生成本优化的,做最佳实践,作为布道者去推广原生技术。那在过去的几年里啊,我写了几本书,包括Co的生产化实践之。以及软件研发效能提升实践。同时,我现在正在翻译啊,翻OPS基金会的cloud OPS这本书。那同时呢,在即课时间我是云啊,即课时间云原生训练营的讲师啊,在过去几年,我也同时是一个各个技术峰会的活跃讲师以及出品人。
16:03
那今天我演讲的啊,主要内容是。啊。云原生增效较满最佳实践案例。好的,那我们正式进入主题。今天的主要内容分三个部分,第一个部分是原生资源利用现状。啊,我会给大家看一些数字,让大家直的去感受原的现好不。那第二呢,会带着大家深入去理解Co提供了哪些技术手段,让我们高效的去管理资源。以及这些技术手段对我们真正在生产环境中使用的过程中啊有哪些挑战?还有第三点就是在腾讯内部大规模资源上云的这个过程中啊,我们如何应对这些挑战。我们通过哪些方法,哪些实践去推进的。增效降。
17:02
从技术层面我们又有哪些思考啊?又做了哪些技术的提升来辅助我们的用户去做增效降,那我们最终都会把这些啊,我们所做的这些思考啊,所做的这些技术提提升,最后都会付给我们的公有云产品,使得用户也能享受到同样的红红利,我们先来了解一下现状啊。啊,这张。图里面啊,有好多数字。这里面给大家一些感性的认识啊,就是首先。2021年云原生基金会的一个调查显示。参与调查的分90组,已经Co在生产系统已经用了Co。这是一个历史性的新高啊。然后第二呢。Flex有一份云原生市场发展状态报告,在这份报告里面显示呢,有30%-35%的云支出都被浪费掉了。
18:08
好,这是一些调查报告啊,一些机构的一些调查问卷的一个统计。那么真实的情况是怎么样的呢?啊,带着这些问题我们就去腾讯的啊。那。同时啊,我们采样了物理级它的一个现状,虚拟的现状,以及容器化的现状。那物理机的利用率?均值大概在10%左右。那虚拟机呢,相对于物理机啊,它会把一台物理机虚拟化成一个个小的实力,对吧?啊,那它有一个稍微的一个提升啊,提升到了12%。那容器化,如果大家对容器化本身的技术比较了解的,我们都知道,对于容器来说,对于Co来说,对资源的管理力度会更小,对吧?啊,比如C分之一C。
19:10
那通过这种方式,理论上资源利润率应该非常非常高才才行,因为已经提供了很多精细化的资源手段啊,资源优化手段给我们,对吧。但是事实上啊,我们看到的一个现状是容器化。的这个这个技术站上资源利用率也只有14%。所以这大大超出我们的预期啊,就是低于我们的预期对吧。为什么会有这样一个现状呢?那我们接下来会一一的去揭晓啊。首先我们再来看一下云上的成本。管理有哪些挑战啊,在传统的企业里面,一般我们都会有一个固定的数据中心,对吧,每家比较大的企业,那这个数据中心呢?啊,大家都会按季度或者按年度去做这种资源规划,比如说明年要多少,我一定会。
20:08
有一个预估啊,预估明年的业务增长回到一个什么样的程度,我会把按照这个业务的增长去采购机器,所以在很多时候我们都会要。因为采购频率很长,所以要有余量对吧,所以通常啊,在传统的这种数据中心里面。啊,都是有统一的集中的啊,这种规划团队去对明年的这个啊。资源的用量去做规划并且采购,所以通常会有比较充足啊,都会比较充足的资源备在那里。我的利用率高还是低?啊,其实没有太大的关系,因为我一次采购就是一个批量,但是在云上这个节奏就变了,对吧。那么这些机器呢?不是云上用户去采购的,而是的供商去。
21:03
那么。云上的用户。就有一个按需采购的。这样的一个选择。也就是说。我不需要按年度去采购设备。我只是在我业务增长的时候啊,我觉得需要更多的的时候,我去临时购买。啊,所以它的灵活性就变得更大了啊,就是以前的这种集中采购的。啊,这种流程就会被改。改变,那同时呢。在云上通常也不需要这样一个,很多公司就已经不再需要这样一个集中的规划团队了。业务部门相反啊,就有了更高的权利,我业务部门要增长,我要有更多的机器来承担我的业务,那我就去购买。所以这个采购决策就会被。去就就有一个去中心化的趋势,就分散到了不同的业务部门啊,所以每个业务部门呢。
22:04
作为。业务啊,比如说业务增长的部门,他又不太会去看成本。啊,他更多的关心的是说我要去确保我的业务增长。不受影响,而不因为资源受影响,所以它通常也会用比较激进的方式去做采购,也没有一些成本意识。所以这就导致了在云上。反而大家上了以后呢,这个成本反而会提高。所以这里面啊,就是会有这样一个挑战,那还有呢,就是。呃,大家上了云以后,虽然我们到了容器的这个技术上面,但是大家的概念啊,大家的观念还是以前的观念,还是按照以前啊。传统数据中心那样的方式去运维整个平台以及整个所有的应用的,所以这就造成了大量的浪费啊,我们做了很多客户的走访,其中最夸张的是有些用户。
23:03
啊,他采购了一些啊机器云上的机器,那这些机器呢,它还是像以前啊在数据中心一样。去做业务部署,哎,就是买了十台机器,比如说。第一台机器啊,不给A业务。第二个第第二台机器预留给B业务,第三台机机器预留给C业务,这样一一绑定啊,即使这个业务没有任何的流量,不消耗任何资源,他这台机器也专门预留给他那。这样的一些啊,反最佳模式啊,我叫做一般都说反模式啊,这样的反模式往往都会造造成比较严重的浪费。但是腾讯其实我们临的挑战。作为一个局外人看腾讯可能觉得,哎,腾讯有这么多的产品线,那技术实力也是很强的,那他的资源利用率是不是也一定很高?
24:01
但是啊,事实上我们也是啊,从最开始上云啊,就是没有任何的优化手段去说去上云,导致云成本不断。增加,然后再到管理,管理层下决心说你必须去做成本优化,必须把成本降下来,这个不断的就是也是经历了同样的路线啊,才走到了现在的这这样一个比较好的状态,那这里给大家分也是分享一下腾讯内部的一个一些数字啊,那腾讯内部的自研业务,比如说大家用的腾讯会议啊,微信游戏啊,啊这些都属于我们内部的自研业务,那这些自研业务啊,总体的一个规模是五千万啊,CP5000万。那利用各种各样的这个技术手段呢?啊,比如说我们对内部的资源利用率啊,有非常非常高的要求,比如说我们可以把在线离线业务混在一起啊,通过这种方式把利用率拉到65%。
25:07
那整个上云的过程中,经过数年的这个优化,累计结成30亿啊,所以我们有非常非常多的云成本优化的实践经验啊,技术手段,我们是希望把这些经验分享出来,供业界参考。OK。资源利用。啊,我们先来理解一下啊。这个部分就是比较偏技术了啊们解Co中的节点。在Co里面啊,因为它是一个式的系统,对吧,所以任何被管控的对象啊,Co都把它抽象成了一个个的API,或者是一个个的对象。那对计算节点来说,就抽象成了node no。
26:04
那。我们就以最常用的这种计算资源,比如说CPU和内存来看啊,任何一个节点都有它本身的容量,对吧,比如说我是一个四啊。这些。比如说这些都要有开销的,所以我首先要预留一些资源给系统啊,所以Co ne允许你。配置一个就是代表你要给系统置那啊多少资源余量啊,这些余量是要占,不能给业务分出的。
27:01
第二个Co运行的时候。比如说自身啊,通常是由一个进程起来的,那它本身也是需要占资源的啊,那有些企业它可能也是一个通过拉起来的一个服务进程,对吧,它也需要一些资源,那这些资源我都要通过Co它占住啊,说这些资源是用来支撑Co运行的。那剩下的这些资源才是说这是可调度的,可以给业务去用的这些资源啊,所以每个节点上有多少资源,就是下面的这个余量的部分。那我们再来看一看啊,就是我的业务调度这个节点以后是这个资布的情况是怎么样的。假设说我了的ABC3个三个的到这个点。那么每一个泡的啊。
28:01
他可以声明自己的资源需求,对吧?啊,比如说。啊,针对CPU这个维度,就是申请了0.91.31.1这三个CPU的值。那么总体的啊,在这个节点上面,从可分配的这个资源啊,叫做resource里面,我们就要把这些资源给扣除掉,因为它已经分配给不同的这些业务了,那最终还会有一个资源在这个节点上,对吧?啊,也就是说这里面还有一些over,就是在通常啊,我们没有办法完美的装箱啊,也就是说我我的不可能把资源节点啊上面的所有资源都分出去,一定会有些资源碎片。啊,分不掉啊,所以在每个节点上通常都会有一些资源水平。那我们再从业的视角来看一看资源管控啊。刚才我给大家看的那个图啊,就是Co用Co个对象去。
29:02
它no里面的status就分为了capacity,就是这个节点的总容量是多少,就是去掉了和Co,剩下的可分配资是多少。那这些资源怎么样去分配呢?哎,就是我们的业务的在定义啊,这个这个每一个的对象的时候。你可以在在这个D里面去明说我的这个D需要多少resource,那这个resource又分为request和limit,那很多同学啊,在入门的时候通常分不清这个request和到底什么样的差异啊,它到底在哪里生效,那我在这里面给大家啊稍微深入的分享一下。的就是你这个需要的这个资源的上限。那就是说我需要下限,也就针对这一个来讲啊,我100M的CPU啊,M是千分之一个CPU的单位啊,100M就是0.1个CPU,就是我至少需要0.1个CPU才能。
30:12
啊,就是以某个节点至少。需要有0.1个CPU才能把我这个调度上去。那等于一呢,就是说明的是我的最需要C。啊,所以它定义了这个炮的资源的上下线,那所以这个就很容易去理解这个两个值到底在什么时候用,对吧?那。Request这个资源啊,刚刚说了,你在调度的时候要去参考啊,某个节点至少要满足我的request才能被调度,所以调度器会去参考request的这个值。啊,在调度的时候不起任何的作用。但是我们都知道啊,技术是通过来我这个资源上的,所以这个及体现,那比如说C为例啊,那么最里面的这个C里面去啊,那通常来说C10万CC是10万过种方式来设置啊,这个进程啊,这个容器进程最多只能用一个CPU。
31:28
那CPU的request里面的值啊,会被体现到CPU里面去,OK。这里面多说一点啊,技术的细节。那为什么Co会分request和这两个值呢?啊,它其实就是提供一种业务啊,提供一种超卖的可能性在这里了,你想。假设说你有一个业务啊,你最多可能需要。啊,一个CP,但是呢,你可能不是任何时候都需要一个CP,对吧,可能很多大部分时间是在低谷。
32:06
那么,如果你。那这样会导致什么呢?导致你大部分时间啊,虽然你锁住了一个CP,但是你的资源量很低对吧,那么你对资源的使用就不是很友好,你整个集群就大量资源浪费。那么它通过两个不同的值来控制啊,就是说我最多需要一个CP。很多时候啊,100个 cpu100M的CPU就够我用了,所以这个时候你只要100M的CPU就把我调过去。啊,然后在那个节点上面,我们可能就可以多卖一些资源,对吧,我可以有更多的的调度到同一个节点上面。那只要这些pod的峰值啊,利用率不同时打满,那么他们应该彼此的这个业务质量不会受影响,对吧。啊,就是这样一个手段来就是,所以云原生的,呃,优势是说第一个他做精细化的资源管理啊,第二个。
33:07
他可以让你去做这种资源超售。那么经过刚才的这种技术手段啊,就是很多人会觉得说,哎,那是不是已经够了,我用只要我这些啊这些啊。API这些对象啊,用的好,配置的好,那我的利用率其实可以提上去,对吗?啊,我们来看一看实际的一个现状啊。这是我们从监控系统拉出来的一些真实业务。那我来给大家看一细这个指标,首先节C。所以你可以看到啊,这个节点上实直都十多个没有分出,我才说的调度,每个节点都有用不尽的。
34:11
那下面这个蓝线呢,是这个真实利率。啊,所以这里面你能看到一个什么样的情况啊,就是。他虽然申请了很多。但是真实的用量比申请的资源要低得多得多啊。这就导致了。很多的业务其实过度分配资源,锁定的太多了。那么这里面就造成了一个主流的大部分的一个浪费。啊,还有一个,还有一个就是你可以看到这是一个典型的在线业务的时间线,对吧,所以它有非常明确的波峰波谷的这样的规律波动。那即使我们把这条线拉到最低啊,假设说我锁定的资源就是到这个最低的这个这个波峰波谷的上限,这啊,那理论上已经能够满足所有的要求了,对吧?啊需求了,但是它波谷这里面其实还是有很多浪费。
35:08
所以这里面就能够体现出来,如果我们要去做资源优化的时候,那有哪些手段或者可能啊,我们去做这些资源优化,首先第一个就是我们能不能把这些资源碎片尽可能的分出去啊,让这些。未分配资源降低对吧,这是一部分浪费,那第二部分浪费就是我们有可有没有可能把锁定的这个这条资源线尽量往下压啊压到底。让过多的分配资源啊,过多分配的这部分资源减少。然后第三个针对于波波谷的这些这些时间线来说,我们有没有可能把这个波谷的部分也给它填上一些业务啊,或者是说我们把风消下来。啊,使得这条曲线啊,利用率曲线更平缓,那么这样的话,我就可以更高的提升啊,更有效的利用我的资源了,对吗?啊,这是一个解题思路啊。
36:10
啊更高效,那本身还提供了。自动的伸缩能力啊,那自动伸自动伸缩能力又分了横向自动伸缩和纵向自动伸缩。那横向伸缩啊,就是这里面啊,我画了一个图,那横坐标是力数量,纵坐标是单实力的资源配置,所以通常我们讲横向的扩缩容,就是相当于我一个业务有三个。当你的业务高峰来了的时候,我的我会有Co里面有控模式,对吧,所以我有一个横向器啊,向展的控制器,那么它会去监听业务的高峰啊,当业务高峰来临的时候,我才长一个pod出来。
37:03
啊,这叫横向扩容,那么纵向的扩容呢,就是当业务高峰来的时候,我不去长pod,我为单实力的pod去增加资源,这个叫纵向纵向扩容。那么通过这种自动的横向和纵向扩缩容能力,能够达到一个什么目标呢?我可以在业务高峰没来取啊,我锁定的资源可以很少。啊,可以很少,我可以满足一个最最低的要求啊,业务需求,这样的话,我把大部分资源释放出去给别的业务用啊,我的利用率一定很高,对吧。但是当业务的高峰来临的时候,诶,我可以通过一些自动化的策略,涨一些实力,或者把单实力的资源调高,这样的话使得他们有更高的处理能力,能应对流量高峰啊,这是自动弹性的一个啊。一个技术手段。OK。那刚才说了啊,有这些技术手段,那这些技术手段又有哪些?
38:06
不足呢,或者说我们在真正使用的时候,大家用的好不。啊。解,想。啊,我开发了一个业务。那我最不希望的一个事情是什么啊?因为资源的问题导致我的业务受损了,这是我最不希望发生的事情,对吧?所以通常我都会。用比较激进的方法啊,就是去锁定更多的资源。通常我怎么做呢?第一啊,如果我的这个业务是从原来的一个啊,传统的比如说虚拟化系统过来的业务,那我基本上就不做,不加思考啊,就是。原来虚拟化。这个虚拟机多大规格,我这边就生成有多少资源,所以我肯定不会犯错,对吧?啊,因为我这是一个经验套用啊,这是经验套用是第一种方式啊。
39:08
那你可以想一下,虚拟化的时候,其实资源利用率高很不高,对吧,所以我原样过来的时候,就我就把原来的历史债带到了一个新的技术站里面。那假设说我更负责一点啊,我觉得新技术站上面啊,它的资源利用率会更高效,因为它没有虚拟化的成本,对吧?啊。我需要去重新做压测。那我会怎么样去做压测呢?我通过压测来确定我要多少资源。我先预预估一下啊。今年。业务的增长会是怎么样的啊,年底的会是多少?那今年啊,很快就过去了。我今年只估今年是不是太保守了,我先估个十年的量嘛,所以我会预估十年以后我这个应用啊,它的并发会是多少啊,我按照这个规格啊,按照这个QS我的业务。
40:04
然后我得出了一个在这种QS前需要少C。得放缩。这样的话就会使得你可以看到我整个的过程,其实逻辑上是没问题的,对吧,但是我也会特别乐观的去预估一个这个这个未来的。业务成长,并去基于这个业务成长去锁定资源,但是这个业务成长可能很多很多年都达不到,那这里面就会导致大量资源浪费,对吧。那这是第一个资源配置啊,其实对我这种在在云计算领域十几年啊,一直在做,而且一直在做云原生的这样一个人啊,其实都有这么有一个不会配的一个问题。那么再说弹性啊,刚才我说了啊,弹性我们可以啊,比如说允许你说C利率,利率达到50%的时候,我增加一些实力。
41:09
那听起来是OK的,但是这里面有一个很大的挑战是什么呢?任何的监控系统都有个滞后性,在Co啊。CU有一个seer啊的组件,会去定期的抓取啊。那我们知道啊,他通过这种的方式去读取的时候,一定会有个的,对吧,有个时间周期的,这个时间周期还不能太快,否则你光这个探测的系统啊,都把整个系统资源开销都给吃掉了啊,所以比如说它会有一个一分钟的周期。那这个。这个啊,采集有一个滞后了,对吧,那这个采集要上的给普罗米修斯,普罗米修斯来整个集群扫描有个时的,有个一分钟的时间周期。
42:03
啊,对吧,或者是说汇报给这个R有一个周期。那。弹性的这个控制器再去他要去看检查当前集群的所有业务啊,哪个利用率高,哪个利用率低,它也是要轮的,对吧,那每一个轮其实都是有一个时间之滞后啊,几个滞后叠加在一起,就是一个三到四分钟的一个滞后性。那更不要说很多业务,特别是Java应用啊,它启动很慢的,对吧?啊,要去数据库,要去加载缓存,那它还有个启动的时间,所以很多业务可能从我们发现这个啊阈值。触达了到弹性控制器发啊感知到这个事情到就绪,可能几十分钟就已经过去了。那么这种滞后性会导致很多业务是来不及谈的啊,他可能。
43:02
还没呢,整个业务就已被压垮了啊,所以这里面就是会导致很多业务不敢配置弹性。还有。当我们通过种手段啊利个节点C是有限的,那它C算力有CPU,时间有限,那么不同的进程在CP时就一定通过什么样的策略去争抢的问题。那大家知道lix里面C调度完调度那味CU实务都是公平的啊,当大家发生资源抢占C,特别是CPU时间抢占的时候啊,这个时候。它默认啊,你们均等受损。但是现实的情况是这样的吗?不是,很多公司,包括腾讯内部,以及我们走访的很多客户。
44:03
公司内部的业务都会有分歧啊。会有高优的敏感性业务以及低的非敏感业务,那么他就不能通过完全公平的策略来抢占CPU识别片,就必然需要某种增强的啊稳定性能力来确保高不受影响啊。所以。Co没有提供这样的手段来辅助我们做这个决策。所以这里面啊,我们就可以看到原生的技术其实有很多很多的限制和挑战的。好,那接下来我就给大家分享一下我们腾讯内部如何处理这些问题。到本的就不得不个frame基提供。基金会致力于啊,就是提供一些。啊,跟云成本优化相关的一些规则啊,最佳实践它是通过啊提供这个啊方法论的指导的这样一个基金会。
45:09
那你可以看到啊,这一页是我直接翻译过来的,可以看到它提提供了很多的原则,比如说S要成功,那应该怎么样去做,要做。团队协作,每个人要承担责任。那他会给一些建议啊,要你整个的组织应该啊,企业应该怎么样去组织这个团队啊,然后分为哪些阶段去推进这个事情。OK,那同时呢,他会提供啊一些建议啊,就是说对于一个S要整个实施的过程中。啊,你需要构建哪些能力。比如说理解成本和用量,你得首先去理解啊,你浪费在哪儿对吧。啊,然后呢,你要去做绩效跟踪和展示,你要把谁好用的,好用的不好把它展示出来。啊,是从公司的层面才能去推动啊,比如说。
46:04
很多同学啊,就是他可能是比如说是个人研发者,他可能不会理解这些企业级的难题,就假设说在腾讯内部啊,我们我们BG可能是十几万的workload。啊,几万几万人,我们要去去跟进和处理的,如果我们没有一个有效的绩效跟踪和展示的这样的看板和工具来推动的话,我根本不可能推得动这件事情。然后需要有实时的报表决策,推动我们去做实时决策。然后优化的话,哎,我要去费率做费率优化,就是我能不能用更便宜的啊,比如说存储的话,我能不能用更便宜的存储,我能不能用便宜的网络对吧。啊,我能不能用更便宜的机型,这叫费费率优化,好用有用量优化,我有没有闲置的资源应该被删掉。啊,我有哪些。
47:00
哪些计算资源啊,哪些节点或者哪些业务,它的资源利用率很低,我应该去提升。啊,所有的这一切都离不开组织的支撑是吧,你整个的公司的上层是要。一旦要决定去做云成成本优化,还是要给予支持,这件事情才能够成功。OK,这是提供的一些方法论。那这些方法论呢,其实就是每家公司最佳实践的一个啊,一个整合或者是一个抽象化。那在腾讯内部,其实我们也是遵循这样的一些骤能力,整个成本优化的啊,我这个下部分主要就是给大家分我们讯如何做这事情。OK。那。工欲善其事,必先利其器,对吧?啊,要做这件事情,我们必然要有一个工具来辅助啊,我们整个成本优化的这个这个决策啊,包括提供技术支撑。
48:03
为了把自研业务的这些经验和工具啊。推广到社区,让更多受众受益。那我们开源了一个项目叫做。啊,为什么起名叫啊,它其实是个简称叫做cloud resource anatic and economics的缩写啊。说白了,就是云资源的分析和优化。我们把它叫做什,那里是金字,金字一层是才翻option能力模型其中的一个部分,比如说理解成本,比如说绩效跟踪和实施决策啊。那。这是他提供的这个方法论,那我们的所有的产品的能力规划都跟这个金字塔。啊,就是跟能力模型一对一。
49:00
啊,这个项目是从去年11月啊开始开源的,那你可以看到啊,我们在这个S领域有很多很多的行动,包括白皮书,包括标准定制,包括开源,包括我们拉起了产业联盟啊跟。成啊,国内的很多的合作伙伴啊,客户啊,一起来推动整个fans的标准和最佳时间。啊,同时我们也获得了很多的荣誉。OK,那。如果大家啊有感兴趣的小伙伴可以访问我们的这个啊网站来参与共建啊,也欢迎大家来落地试用。那这一页啊,简单给大家讲一下的架构啊。啊,刚刚做说的很多事情,就是啊就是。呃。所大家还记得我刚才所说的那些挑战吗?用户不会配,不敢配,不能配对吧,那不会配就是说即使我是一个资深的业务管理人员,我也其实也很难把握的业务到底需要多少的这个这个啊资源对吧。
50:12
然后呢,对于弹性来说不配,为什么不配啊,因为。基于事件的弹性,它有滞后性,我来不及谈了,那我就不敢赔嘛,我不敢配弹性,那我就平时锁定多点资源,对吧,造成一点资源浪费。那么其实。就是要去解决这些问题的,通过技术手段去解决这些问题。那这个所以我们提出了啊,就是开源了这个项目啊的,这个开源项目的组建其实蛮简单的,第一个就有个第是作为一个呃,集中式的控制器啊,部署在这个集群里面。那他所承担的主要职责有几个啊,第一个。
51:02
你有这些业务运行在集群里面。那我其实是基于监控系统是能知道过去的资源利用率的,我能知道当前集群里面所有业务的资源利用率曲线。啊,我能知道感知到你的波动,所以我就能够知道,第一你的资源利用率上限是多少啊,用量的上限是多少。啊,然后你可能有一个上升的趋势,那我能知道你接下来的24小时或者是48小时里面,你的资源上限是多少。基于这个预测呢,哎,我就能告诉你说你不用配。十个CPU你配一个CPU好了,剩的九个回池让其他去啊,你整个集群的资源利用率自然就上去了,对吧,包括你业务的资源利用率也上去了。
52:00
所以我们首先要有一个预测啊,有个resource predict。那这个所的预测就是会承承载了了系统所他的能力。啊,包括我们的成本展示啊,我可以把预测啊,你今今天的成本是多少,我预测你明天或者下个月的成本是多少啊,我都可以预测出来,第二个就是我可以做各种各样的优化,包括刚才说的啊这个。资源的优化对吧,就是你业务降配啊,第二个我能知道你的这个整个时间线,所以我不需要等你CPU利用率达到50%的时候才告诉你该弹出了,那我可能在可以在提前一个小时就感知说接下来一个小时内,你的业务风波峰就要来了,请你提前弹出啊,那这样的话,哎,就使得你的整个。弹出前置啊,弹性前置,那么就预留了你监控系统的滞后,以及业务启动的滞后啊,所以这样的话,使得你业务流量还没到,我就已经提前弹出了,确保弹性弹性的有效性。
53:11
那么还有就是稳定性的能力啊,这也是刚刚讲的,就是当我们有多种不同类型的业务部署到一起的时候,我们可以通过利用扩展了Co啊,这个是业务分级嘛,啊,我们允许。业务去定义说我的是多少。那么针对我这种,我有哪些稳定性保证的能力啊,那针对节点维度啊,我怎么样去做节点的稳定性保证,通过这种方式啊,就是一旦发生冲突,我可以去确保高优的业务不受影响,来牺牲那些低优先级的业务啊,比如说。对他的资源进行压制。比如说把这些业务驱逐走啊,通过这种方式来确保整个群和业务不受影响。
54:02
啊,这是我们的整个开源框架啊,所完成的一个一个啊一些业务逻辑。那么基于可的这个开源框架呢?啊,我们构建了整个腾讯的的产品。那这个分产品啊,跟刚才的cran比起来可以看到啊,Korean就是中间的这。和agent就是这个核心的代码框架,以及一些通用技术,那么针对整个产品呢,我们会有更多的思考啊,包括。啊。对企业用户的一些支撑了啊包括啊这这些支撑包括什么呢?比如说第一个数据运营平台的构建啊。要让用户去做成本优化,那我们刚才仅仅有相关的这些技术能力是不够的,对吧,我需要有业数据来驱动啊,比如说我需要为企业的用户提供提供你当前的资源大盘的情况啊,你总体利用率是怎么样的,你弹性是怎么样的。
55:03
那你的优化的。一旦使用了,你能节省多少钱?同时呢,我们会给组织架构上面提供一些帮助啊,比如说。按部门的绩效,绩效量晒,对吧,谁用的好谁用的不好成这种啊,荣辱榜一贴出来,那大家就自然知道应该去找谁先去做优化了。那针对整个集群呢,我们还会要去,还会对这些业务去做聚类分析啊,我们的整个集群里面到底跑了哪些业务,那么哪些业务是比较相似的,把它归为一类,些业务是相似的,把它分成另外一类。啊,那这些最后就是用的CPU多,用的内存多,那这些最后就沉淀成了一个的应用画像,那在部署的时候,我们其实可以利用这些画像,比如说进行错峰的部署,以及反相似性的部署啊,比如说把把CPU密集型和啊网络密集型放在一起,或者是把磁盘密集放在一起,这样的话使得我同一个节点上面理论上可以放更多很更多的这个这个pod而不受影响,对吧。
56:10
那还有就是我们刚才有预测对吧,那你所有的预测的这些算法到底是不是准确呢?那我们在这个整个数据系统里面会有离线算法评估,来评估我们的这个算法的准确度,那同时啊,我们的实施绩效啊,要去支撑这种实施决策的话,我们会有运营日报来来晾晒。你是不是在做优化了,然后优化的这些客户,它到底是做的好还是不好啊,总体节省了多少啊,这些我的弹性是不是更有了,这些都在我们的运营日报里面去体现的。这是整个数据支撑的系统啊,数据运营的平台,然后会为啊集群的运维和业务的啊平台运维和业务运维提供一个统一的的控制台啊,但是会会分为不同的视角。那业务的视角是更多的是针对他的作业去做优化,就包括我刚才说的我们。
57:07
规格的优化啊,就是你的request配多了,那我这边会给你个建议,你在界面上勾一下可以降配了。然后弹性配置的话,我可以去看你当前集群里面有哪些业务是可以适合配弹性,但是你没配的,有哪些业务你配了弹性,但是你配置的不合理,我会给你一些参数优化的建议啊,那你针对业务来说,你也可以啊,勾一下就能就能看得到了。你也可以为你的业务去定这个级别,那么最终啊,你定好你的业务的级别和S,我来确保你的高业务不受影响。那平台视角啊,这也是我们走访很多客户啊,包括在腾腾讯内部,我们推动过程中发现的一些问题啊,在应对方案就是当我们要去推动一件事的时候,业务是分散的啊。就是一个公司有很多很多很多的业务团队啊,几百几千个业务团队,如果我们要达成一件事。
58:04
通常啊,如果我们只依赖团队个情的话的是常的个。这个list不会很高啊,那就会有各种原因导致这个推不动。那我们通过什么样的方式能够辅助我?速成效呢,台维了一些能力。比如括。节点容量缩放,节点水位管理啊,容量缩放我就是量的,让还记得刚才那个图吧,我尽量让每个集群里面装的更满啊,每个节点装的更满,让那个。每个节点上的资源碎片更少一些。那水位管理就是我尽量让这个利用率更高啊,那通过这种方式来提升集群的整体资源利用率。
59:00
OK。那整个啊,Agent刚才我说了啊,它它主要的目的是收集业务指标,在每个节点收集业务指标,然后判断是不是发生干扰了,然后进行压制与重调度啊。它要依赖于腾讯,有些高级高端的能力,会依赖于腾讯内部的t lix啊,全资Q来保证啊。比如说我们会把在线和离线的进程通过不同的Linux进程调度器去做调度啊,这样确保高邮完全不受影响,但是有余量的CPU资源可以给离线作业用啊,或者给用啊,这个都可能啊。做得到。OK。好,这是产品能力,接下来我就给大家说一下我们内部是如何推动啊。啊,这个队呢,在在这个的通常说不同公队会有直向直接面向高级管理层去汇报。
60:18
啊,然后高级管理层会给这个团队去做啊,去授权啊,然后。个团队有有部平台优化。那这个团队其实是承上启下了,一方面接受管理层的授权,同时会把每个执行的任务细分到不同的啊。平台运维和不同事业群的这个平台运维和业务运维这里面去啊,那这个团队其实是整个降本的核心,他会做什么呢?哎,还是一样的,他会去识别闲置资源对吧?啊。去看低效资源的浪费情况,他去会去晾晒这个每一每一个部门的绩效,然后定好KPI,大家一起冲啊,那剩下的就是平台这边和业务这边的运维去提,尝试去提升节点的利用率和业务的利用率啊,那这里面又包含了刚才所说的费率优化,业务侧的优化和平台优化三个层面的动作啊,用低价资源对吧?啊,用廉价更廉价的资源来做费率优化。
61:28
然后业务侧就是我这规格开启弹性啊,平台侧就是提升。啊,节点的装箱率,提升节点水位,保证稳定性啊,通过这些合力啊,达成最终的目标。那我们的这个整个的实践的主线啊,就是通过这样的方式去做的啊,那从产品的这个层面,我们做了哪些事情?第一个我们通过数据驱动去分析成本,去测算成果,所以针对所有的自研的Co集,我们把。
62:03
每个集群上面都部署了一个指标,拉取的组件和啊,就去把当天集群的所有按天啊,每天在低谷的时候,把当天进行的资源利用率啊,量以及变化都抓到我们的离线仓里面去。那在离线仓里面,我们这边就做很多的事情啊,包括聚类分析和业务化,大盘现状和走势,以及我们优化的空间啊,以及整个的进展,用户的行为啊等等这些这些信息啊全部分析出来,并且。放到我们的运营控制台里面,供大家每日去查看啊,然后第二个我们进行了很多的这种啊,离线算法评估,就是其实主要去评估我们的这个啊。啊,这个这个预测算法,它到底是有有效还是无效,那么这里面可能还有一些算法的超超优啊,超调优的一些一些工作在里面。
63:00
整个事情是事件驱动的,对吧,所以我们会有这样一个数仓,一堆数据分析系统,让我们知道啊,哪个业部门做的好,哪个业务部门做的不好,这样配合运管啊,就是我们一起去走访这些头部客户,他们去做这种啊优化。OK。那第二个啊,就是这一页,其实就是把我们给大家分享一下我们。在优化之前啊。对大盘现状所说的一些分析啊,就是分享一些数据出来啊,这里面体现的是集群的啊,节点装项率,你可以看到有一群的装箱率不足50%。有2/3的集群的峰值利用率啊,就是利用率也很低,装箱率也很低啊,利用率峰值利用率不到40%,这是优化之前的一个现状啊。那么针对大来看啊,我们的总体利用率其实是很之是百分之,就我才说的14%左。
64:04
那这条绿线就是啊。经过我们的这个优化测算啊,就是假设说所有业务都按照我们给的推荐值去做配置的话,它的利用率可以达到多少啊。就是百分之。当然这是一个维度啊,我们还有很多很多技术手段。弹性的手段的手段,那这个只是降配啊,就是通过规格调整以后,它能达到的一个一个一个水平就会达到30%。左右。那么我们同时对弹性做了一个分析啊,我们内部有大量的弹性。可以看到啊,只有10%的在本年度出,就大量的业务就基本上年都没,那说明这些弹性的配置基本上是无效的,所以我这些都是我们啊,为什么去展示这些数据呢?我们要理解一下现有现状啊,理解现在做的有多不好,那基于这些多不好的这种现状,我们有针针对性的去优化,对吧?呃,所以几个点,专项率啊,业务的这种啊,规格的调整,弹性的优化,这就是我们。
65:13
的一个一个方向对吧,啊改进的方向。那怎么样去推动呢?啊,就是我刚才说的目标设定,绩效晾晒啊,我们公司内部啊,就是有老板授权,自上而下设定了一个绩效目标啊,那么我们定义了一种完整的计算手段啊,来计算就是来计算评分,我根据你的弹性,根据你的利用来算分。那最终公司定了一个80分的一个KPI息到每个部门,那每个部门会把自身的work利用率弹性的情况自下而上去汇总啊,然后这样的话就得到了每个BG每个部门,每个BG每公司的一个评分,那最终啊,我们就奔着一个总体的目标去做这个优化。
66:02
那我们同时啊,在内部以及我们的产品都提供了,把这些能力都提供出来了,辅助业务去做决策啊,比如说你的成本用量和趋势分析啊,比如说。它有,它又分了很多种这种度的维度,然后同时提供了说你在界面上你不需要有太多的。感知啊,你不用去自己去查询我这个业务到底要多少啊资源,那我们直接在界面上就告诉你说,哎,你应该怎么样去做资源配置,你应不应该开启弹性,你的弹性配置应该是什么。啊,然后同时呢,我们内部就是说,诶,我可以把这个资源用量的这个时间线给你列出来,你直接就能看到你过去的一个资源走势,那你也理解啊,理解我们为什么给这样一个建议来赢得这个。他的信任,那同时呢,这里面就体现了一下,就是我们在离线数仓那边,针对这些测预测算法的一个评估的分值啊,可以看到它的这个这个准确性还是很高的。
67:06
那平台呢,我们也提供了一些技术手段啊,包括啊。第一个我们提供了一些节点维度的视图啊,我能够让你看到整个集群里面所有节点的利用率是高还是低啊,那不同的这种节点水位我们会以不同的颜色去展示,那你能知道哪些最好,哪些不好,你可以点到每个节点上去,看这些节点上运行了什么业务。那如果你对现状不满意的话,哎,你觉得利用率太低了,那么我们提供了很多运维方面的这种技术手段啊,比如说我允节C。规格去做放大啊,这样的话你的容量就被扩充出来,我允许你去定义你的CPU和内存的这种目标水位,那我们的调度会保证说一你这个节点达到了这个位,我就不会把更多的资源调度去了,通过这种方式。
68:03
来从运维来支撑整个集群的资源利用。利用。那还有就是更高的了,就是我们会去提供这种在线和离线的能力啊,那它是基于啊的一个扩展能力来来定义的啊,就是你可以把高优的业务和低的业务通定义成不同的class,基于。既定的策略。我们可以通过。啊,这种混手段来确保高于业务不受影响。OK。那最后我们来看一看整个大规模落地的一个成果啊,就是我们这套系统啊,在自研啊,内部啊,自研业务落地已经进行了大规模的啊和产品能力的广,你可以看到啊,就是在CS,我们就部署了几百个集群,然后控了数百万盒啊,一个月内我们可以看到上面的这条蓝色的曲线,就是用户的资源申请情况。
69:07
啊,可以看到我们能力推广的那一刻啊,它的它的这个这个曲线直线下降啊。有大概这个我把把整个的绝对数字给掉了啊,但是可以看到大概有25%的节省。啊,25%的结成,效果立竿见影。那么我今天分享的内容就是这么多啊,主要就是希望把我们内部的这些啊实践经验,能够分整个的这种解题思路分享到业界啊,希望。啊,大家可以在自己内部公司内部去做这种降本推广的时候啊,有一些参考啊,包括我们的思想啊,这个这个整个的。推进的过程,我们的解题思路,我们的技术架构啊,都有一些参考啊,那同时呢,我们这个项目啊是啊。
70:01
一个非常活跃的开源项目,也欢迎大家来,一起到社区来啊,关注我们啊,然后参与共建和落地,好,谢谢大家。感谢孟老师的精彩分享,孟老师呢,从当前资源利用率现状开始,讲到如何进行的资源管理啊,最后呢,以具体案例为我们讲解了基于云原生的技术的成本管理优秀实践讲解也是十分的清晰啊,我们再次感谢孟老师,同时呢也再次感谢陈伊丽老师的精彩分享。大家也一定要收藏本次的直播链接,回放地址呢,就是当前的直播地址,关于云原生的直播呢,我们会是一个系列直播,欢迎大家关注我们后续的直播动态。好的,我们今天的直播就到此为止,我们下次再见。
我来说两句