首页 > 资讯 > > 内容页

世界信息:大型活动容量支撑速增10+倍,B站容量管理下的资源活化

发表于: 2023-06-26 03:30:14 来源:dbaplus社群
一、容量管理的设计理念1、为什么要做容量管理?1)容量风险未知

集群/资源池/Node容量水位缺乏可视化,稳定性难以保证

随着云原生和K8S普及,若没有很好的容量管理,我们就无法感知整个集群、整个资源池以及Node容量的水位变化,也无法得知是否有必要采购资源,无法察觉整体的资源风险。


(资料图片)

容量变更根因难以追溯

有时我们在做一些发版或迭代时,会发现原本充足的资源突然出现紧缺。此时,若要查探容量何时变化或追溯变化的根因,存在一定难度,也比较复杂。

HPA覆盖率低,业务稳定性难以保障

B站有很多活动和突发流量,但由于HPA的覆盖率比较低,业务容量弹性往往难以保障。

2)降本增效大背景资源使用率低,迫切需要提高整体使用率资源碎片化较为严重,资源无法得到充分利用平台缺乏统一的资源协调能力

由于将物理资源分散到各个部门,如直播业务有独立的直播物理资源池,电商有专属物理资源,碎片化程度极高,所以平台统一协调资源的能力难免存在欠缺。

资源占用大头难以快速发现,治理困难

降本增效遵循二八原则,即20%的业务可能占了80%的资源。我们需要快速如何找出20%的业务,并推动其进行治理,这部分业务得到治理后往往收益较大。

2、不同部门的关注点研发/部门:要有资源去做资源的扩容发布、蓝绿发布和回滚。希望部门的成本不能过高,避免资源浪费。SRE:服务的稳定性。在保证稳定性的情况下,聚焦服务资源的使用率,以达到降本增效的目的。平台:需要统筹资源buffer,控制资源的超卖率,保证底层容量的稳定,从而实现降本增效的目标。成本部门:资源使用率,账单、预算和成本。

3、容量管理面临的挑战内部因素复杂,变动频繁

包括代码变更、配置变更、压测活动、多活切量、定时任务和缓存过期等,都可能导致容量模型发生改变。

外部场景多样,难以预知

B站活动比较多,运营也会进行不定时的推广,一些热门事件或话题都有可能导致容量的突增。

链路瓶颈点多,难以提前发现

无论是东西向流量还是南北向流量,整个链路比较长,因此上游服务、下游服务和中间件都可能遇到瓶颈。

应急依赖人工,恢复时间长

以上问题发生时,如果依靠人工应急,上游扩容可能会将下游直接打垮,容易引发二次故障。

4、容量管理的整体思路

整个容量体系的设计,从下到上分为几大部分,包括基础容量、弹性资源、合池和配额管理。

首先是基础容量,它包含平台关注的集群容量、资源池容量、Node容量,以及应用画像的相关数据。虽然我们将服务本身发版涉及到应用资源的容量视作基础容量,同时业务也会关注。

在这些基础容量之上,我们构建了一些弹性资源,包括VPA和HPA,还有我们的合池和配额管理。同时我们构建了整个容量可视化的一些页面,用于帮助我们的业务和平台更好地将自己的资源数据可视化,做一些资源的管理。

二、容量管理之降本增效1、降本增效通用手段

2、具体方案介绍1)弹性伸缩-VPA(Vertical Pod Autoscaler)

针对每一个服务,我们都有服务的软限和硬限,这是K8S的基本概念。应用CPU Used即应用的CPU的真实使用量。B站所有的硬限和软限都是通过我们的发布平台caster去指定,它们可能是业务基于经验设置的,设置的值不一定合理。随着业务和服务越来越多,这种不合理性就会越发明显,导致分配率非常高,但整体的使用率却不高。

如何解决这个问题?

我们认为,研发部门无需关注软限多少,只需关注需要多少资源。基于应用的真实CPU使用量和应用画像,评估它的服务等级、是否多活等指标,以此判断应动态分配多少软限。这种方法能提高整个服务的部署密度,提高整体资源池的使用率。

进行大型活动时,如果分配率已经很高,可以应用VPA的策略,把非核心服务(如 L2/L3的后台服务)用来降级,调低软限,给核心服务腾让资源。

我们通过VPA管理平台下发VPA策略,使其经过VPA-API组件。这个组件是一个中间代理,主要实现对K8S集群中VPA Generator对象的增删改查操作,负责汇总收集VPA相关的可观测数据。

VPA Generator主要负责拆解先前下发的具有相同画像的规则,如果下发一个L0等级的多活规则,它会拆解并创建很多对应VPA对象,最后通过VPA Recommender从监控系统中采集一些对应的应用资源指标,计算推荐值即合适的request值,并通过VPA Updater组件调整Pod的资源。

发布服务时也可能涉及到资源改变,VPA Webhook会监听类似事件,再动态调整Pod值。

①策略管理

包括VPA指标管理、模板管理和预估/对照组。

VPA的指标管理:基于不同的指标例如CPU的使用量max、P99等做一些调整。VPA的模板管理:基于我们的一些应用画像,例如根据L0服务或L2服务等不同的服务画像做一些不同的模板和管理。VPA的策略预估与对照:分清哪种指标或哪部分对我们更优,因此我们会对不同的策略进行策略预估和对照,以便择优。②数据运营

包括VPA的覆盖大盘、VPA执行记录和VPA策略分析。

VPA覆盖大盘:分析整个资源池的覆盖率和执行记录,记录服务软限的调整幅度。VPA策略分析:调整后,通过可视化界面观察是否还存在问题。③黑名单

整个服务的使用量一般会在活动时剧增,或某个服务上线了新功能,进行压测,都会导致整个容量数据变化。所以我们制作了黑名单机制,进行VPA策略避让,保证在非预期的情况下,不会对这些服务进行相关调整。

④预警

即使执行了VPA,通常也有可能出现不符合预期的情况,所以我们制作了失败率、覆盖率和冗余度的策略预警。如果本次调整有多处不符合预期,提前预警将递送给SRE和平台方,然后进行治理和排障。

2)PaaS合池

我们的漫画业务、直播业务和OGV业务都是独立的物理资源池,如下图所示,番剧的CPU分配率很高,而漫画跟直播的分配率相比较低。如果番剧需要资源去完成一些事情,漫画和直播往往不能满足,所以需要采购独立的预算,或额外申请云上资源。

所以我们认为业务不应关注底层资源,从而完成了PaaS的合池。合池后,业务更关注逻辑的配额管理,即整个配额的使用率。如果使用率过高或出现问题,业务可以解决,底层资源则由平台统一管控,进而平台的统一管控能力提升。

合池具体如何落地?可分为以下几步:

标准化治理

基于历史原因,不同的资源池使用不同策略,甚至配置、内核版本也各不相同,所以涉及到标准化的操作。首先,去除特殊约束,有些服务可能绑定了特殊的物理机发布。其次,不能配置nolimit相关的服务,因为合池完毕后如果某个服务压力比较大,且配得不合理,往往会增加物理机的压力,影响其他业务。同时,我们还进行了去cpuset化、统一操作系统内核和日志规范化的操作。

平台支撑

由于合池完毕后资源也不能无限使用,所以要基于合池后的不同组织进行逻辑配额管理,再整个大资源池覆盖VPA。

老板的支持

合池涉及到不同的部门,这一方面最重要的是需要老板的支持。自上而下进行的合池较依赖协同合作。

3)配额管理

容量平台提供了配额管理相关的策略下发能力,同时对接内部的CMDB业务树。基于组织业务的关系,可以设置不同的组织需要的资源数量。若使用超额,会联动发布平台,进而控制整体资源。如果资源不够,可能就无法发布或扩容。

降本增效的收益

成本:通过这些手段,我们实现了22年H1在线业务PaaS物理机的0新增,同时整个S12的活动保障实现了0采购。平台:统一管控能力极大提升同时,快速支撑大型活动方面,活动数量攀升了不止10倍。以往进行大型活动支撑时,直播资源不足往往需要采购预算,周期漫长。目前我们可以通过协调资源和统筹调度尽快交付资源,时间也从原来的一个半月缩短到现在的一个小时或两个小时。PaaS的整体使用率获得较大提升。业务:首先,对于小业务而言,由于本身资源池的资源较少,物理机不多,所以宕机对它的影响较大。合池后资源池的规模较大,服务相对分散,所以无论挂一台机器还是两台机器,对小业务的影响会大大降低。第二,业务整体的容量需求得到快速满足。资源紧张时,它也可以进行临时的蓝绿发布或者HPA超卖。三、容量管理之稳定性1、在线业务的典型特征2、弹性伸缩-HPA(Horizontal Pod Autoscaler)

HPA的设计理念与VPA相似,包括策略管理、弹性预检、可观测和预警。

策略管理

因为HPA基于CPU使用率、内存使用率或QPS之类等指标进行管理,有些基于不同的应用画像进行管理。例如,针对L0和L1的服务,它们的CPU使用率若达到30%就应该扩容,至于非多活的服务,达到扩容标准的最小值则可能稍高。

弹性预检

配备HPA后也并非万无一失,因为HPA做弹性会涉及到下游及一些基础的技术组件,比如数据库会涉及到一些连接池,需要考虑它是否会满,是否会导致其他风险等。所以我们进行一些弹性预检的相关措施,包括临近值预检和容量风控等能力。

可观测

我们会观测异常记录和覆盖率,比如对L0服务的覆盖率如何,是否所有L0的服务都覆盖了HPA,HPA被触发时HPA的弹性质量如何等问题进行观测。

预警

我们设计了扩缩容的失败预警和HPA失效的预警,如果触发一些HPA扩容或缩容的事件,研发部门会收到相关时间通知,告知因服务压力或流量导致HPA发生变化。

1)HPA可视化①HPA管控

包括HPA 的批量开启和禁用。保障大型活动时,往往会希望容量是稳态的,再基于稳态的容量进行压测,此时需要先关闭HPA,在低峰谷区进行压测。在资源不变的情况下,压测稳态能够支撑的量的数值。后续可能分为几轮压测,最后一轮压测会开启全部HPA,观察我们最终能支持的量,基于这些量预估容估。除此之外,还可能涉及HPA的增删改查能力。

②可视化

主要是HPA覆盖率,要确定整个HPA在不同区域和不同等级覆盖的应用数及覆盖率,对比指标数据和弹性实例。

弹性实例对比表明当前服务的实例数量,并展示一个关键数据。这个数据帮助我们基于HPA配置策略,确定弹性实例的最终数量。弹性实例受限于HPA的最大值控制。如果纯粹通过配置策略计算扩容的实例数,那么能够通过HPA扩至15个。但如果无最大限制,可能会直接扩至20个。因此,借助可视化能直接看出HPA的设置是否合理,了解整个HPA变化的实际趋势。

2)HPA并非可以无限扩容

HPA受限于连接池或下游服务有限的承载能力,因此我们排查了整个过程需要使用消息队列、Tidb、泰山KV、缓存以及中间件等相关组件。整体排查后,发现MySQL风险较大 ,因为大多数组件基本是集中式的代理,例如Tidb和泰山KV都是集中式的proxy部署,无连接池相关风险。缓存使用的redis和mc往往具有较大支持连接数,所以风险相对可控。MySQL 则不同,因此我们在弹性预检这方面增加对MySQL和连接池的预检。如果整个扩容导致MySql水位变高,就会进行相关提示。服务进行HPA扩容时,可能会导致下游的服务压力、下游雪崩,导致一些底层的中间件出现一定的问题或压力。

解决这个问题的整体思路:

一是HPA预检,二是基于全链路的弹性,三是对超出预期的流量做一些组件的限流。

3)容量巡检

容量巡检的作用在于,如果某些服务有风险,能够实现相关数据可视化。

针对不同的场景和不同的角色,关注点也不同。

业务更关注整个业务维度,例如使用率如何、有无风险应用等应用维度,能尽快找到这些列表,进而快速完成治理。配额管理方面,则包括整个配额的使用率和配额可调度的实例数量,帮助快速判断配额风险。

平台方则更关注资源池的分配率,如可调度的实例数峰值、资源使用率、资源池是否为单节点,还会关注整个VPA的调整失败率和冗余度。基于平台方的关注事项,我们制作了风险的巡检大盘,用以确定哪些资源有风险、哪些资源比较空闲、哪些资源急需治理等情况。

4)超载保护

即使有了这些保障,也无法保证万无一失。因为流量突发很常见,如佩洛西事件等热点事件导致B站的直播流量激增、超出预期,所以这方面需要依靠弹性资源。另一比较重要的手段则是依靠技术组件限流熔断和降解。

限流

目前限流主要包括分布式的全局限流和基于http、grpc、qps的限流,同时因为每个业务方基本上都会健全账号,所以我们会对一些比较核心的业务做基于caller即调用方的限流,从而避免因某一个业务的流量突发而导致整个账号体系出现问题。

另一方面,我们基于BBR进行动态限流,基于cpu使用率、成功qps和响应rt等限流,同时联动移动端并进行流控。如果服务端超出承受极限,我们会给移动端下发策略,驱使移动端做流控的控制,避免用户重试导致雪崩。

熔断

包括通过滑动窗口计算成功失败率以及熔断后需要进行的操作。

降级

基于多活进行跨可能区的降级,业务对这个操作无感,这也是我们做多活的一个好处。而对于Node SSR相关的降级,支持降级至静态页,业务也无感,但耗时相对长些。至于数据类的降级,假若AI方面的算法服务出了问题,我们可以进行兜底数据展示,但用户方的内容质量就有所下降。弱依赖降级时,部分服务会直接降级,不展示非核心数据。

四、容量管理之可视化运营1、基础容量

我们更关注集群、资源池、Node和应用维度的数据,所以制作一些可视化图表,以便更快查看整个集群资源池和应用在这段时间内的变化趋势。

以资源池和Node为例,由于要控制超卖,所以要控制资源池和Node的容量水位和超卖率(Node也有部分热点)。

有些会触发二次调度,把上面的部分服务调用到非热点的服务中。应用则包括应用的资源使用量、使用率、实例数和单实例容器数,它的容器包括多少容器数,例如有一个Pod,它可能包含一个主容器和相关伴生容器,伴生有可能导致容量变化。我们基于这些数据制作趋势图,并在监控上保存应用的相关容量数据。与监控相比,因为数据点更加分散,所以保存期限更长,目前已保存了超过两年的容量数据。

2、业务组织容量

业务痛点

在进行降本增效时,如何快速找到资源占用的大头并优先治理;哪些业务的实用率较低使用不合理;是哪个业务扩容导致成本突增容量治理的效果如何,哪些业务的治理不符合预期

解决方案

根据以上痛点,我们设计了组织业务容量,基于内部的CMDB即组织业务数,通过聚合应用指标,从下往上逐渐递归,算出整个组织和业务的容量,呈现历史容量的变化趋势。例如,总容量是1万盒,1万盒属于整个直播业务,而直播的分支包含直播的房间、直播营收相关业务。

列出每一项所占的资源,就能清晰地感知哪些业务是资源占比的大头和占比总量。通过图片上的红线和红点,就能分析它的使用量与使用合理性。下图右方则呈现了整个容量的变化趋势,这样就能快速定位不合理的板块。同时,我们支持数据的一键下钻,作用同上。

3、容量事件

资源治理时,往往会遇到资源变少变空或不能发版的问题。以往查询这些问题根源,我们可能要翻遍各个平台。例如,查看是否有人在发布平台进行扩容或缩容操作,部分服务是否因压力过大触发HPA,或是否有人在管理平台中临时添加了机器导致容量变大。

由于平台数量多,业务SRE排查相当困难,所以我们做了容量事件相关的平台,以消费包括发布平台、HPA以及Node管理等整个变更平台的变更事件。通过变更事件,把数据消费到容量事件平台上,统筹观察这段时间业务的容量变更,因此容量事件是我们快速定位容量变化根因的重要途径。这样做的收益很显著,以往容量发生变化,业务必须联系SRE和平台。而现在无需这样操作,就能快速感知容量变化的根因,处理效率提升。

4、容量周报

容量周报分为部门周报和内部周报,业务部门更关注整体资源的用量以及资源使用率的变化。观察这些数据能更好地感知容量效果。除了降本增效以外,业务还关注稳定性,希望得知具体的风险应用有哪些,以及一周内哪些应用有怎样的容量变化。

对于内部来说,SRE和平台比较关注哪些部门的自营资源占量较大而使用率较低,这些部门对我们来说往往是能用于降本的组织,我们需要提前与他们沟通,所以就需要内部周报帮助完成。同时我们也列出了部门资源使用率的排名,排名越靠前说明治理得越好,反之亦然。

张鹤

哔哩哔哩

基础架构部资深SRE

2020年加入B站,先后负责社区/直播/OGV/推广搜相关的SRE工作,深度参与多活,活动保障,混沌工程,容量治理相关的建设,主导容量管理平台,混沌平台的架构设计和落地,负责B站S赛、跨年晚会、拜年祭等相关活动的基础架构保障工作,目前主要负责推广搜业务的稳定性建设。

标签:
x 广告
x

Copyright ©  2015-2022 今日上海网版权所有  备案号:京ICP备2022022245号-14   联系邮箱:435 226 40@qq.com