写点什么

B 站容量管理:游戏赛事等大型活动资源如何快速提升 10+ 倍?

  • 2023-03-28
    浙江
  • 本文字数:5121 字

    阅读完需:约 17 分钟

一分钟精华速览

当成千上万的服务器都处于低利用率时,就意味着巨额的浪费,良好的容量管理可以帮助消除某些“最后时刻”的临时应急式的盲目或者超量采购。除了成本合理控制方面,容量管理还要预估对客户可能产生影响的业务发展和风险变化。

B 站在降本增效大背景下,从业务视角对整体容量做了可视化管理,本文详细描述了其容量管理的背景、思路及成效。

作者介绍



 哔哩哔哩资深 SRE 专家  张鹤 

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


温馨提醒:本文约 4500 字,预计花费 9 分钟阅读。

后台回复 “交流” 进入读者交流群;回复“2252”获取课件资料;


背景

对于 B 站来讲,我们最大的三个活动是 S 赛、拜年纪、B 站跨年晚会。在用户增长的背后,SRE 团队做了非常多的事情来保障业务连续性,比如多活、混沌工程等等。

今天换个角度聊聊——“容量管理”,B 站为什么要做容量管理的平台?我们的容量管理体系是怎么设计的?平台侧和业务侧我们是如何去运营、让工作变得“可视化”的?我也将结合容量管理平台在 S12 赛事中的实际应用,来分享“赋能业务”的一些经验。

一、为什么 B 站要做容量管理?

在做容量管理之前,B 站面临了几个很明显的痛点,如下图所示。

除了需要解决未知的容量风险,在提倡“降本增效”的大背景下,提高资源利用率,制定合理的、有数据支撑的预算决策也非常重要。

而此前,B 站在大型活动中的容量决策,比如 S9、S10 等,并没有沉淀下来可供 S12 参考的相关数据,系统本身容量是否足够、是否需要扩容、应该扩容多少等等,少有容量数据支撑。另外,全年的预算制定也迫切需要参考容量数据。

二、B 站容量体系是如何设计的?

2.1  不同角色的诉求

基于上述的痛点,我们计划做整个容量体系的设计,其中不同的角色关注的流量指标其实不太一样。比如:

研发部门:关注是否有足够资源,能扩容、能发布即可。级别比较高的研发 Leader 可能更关注整个部门的资源使用率、部门的成本是否合理等;

平台:更关注平台的售卖率、资源 Buffer、资源使用率,以及其他降本增效的工作;

SRE:核心关注稳定性,还需要提升总体资源的使用率,实现降本增效的大目标;

成本部门:更关注账单、成本、预算、资源使用量等,即节省整体费用。

2.2 容量体系整体设计


从下往上看,最下层主要是基础数据(基础容量),比如机器、资源池等偏向云底层的层面。SRE 和平台更多要感知到集群的容量、资源池的容量等到底怎么样,无论资源池如何超卖或者调控,前提是整体底层的资源使用一定要在安全水位。

在基础容量之上,我们构建了一套基 VPA 的伸缩策略,以及基于 HPA 的弹性扩缩实例的策略。还和业务的资源池做了合池,合池后可能就会面临一个问题,即都在一个大池子里,如何控制每个业务方使用的资源?此时,就需要基于业务做配额管理,即管控每个业务能使用多少资源。

在更上层,我们还提供了一套容量可视化以及可运营的数据,提供给业务做支撑,提高业务团队的效率,包括基于业务部门的组织容量、容量事件等,比如容量运营周报,将不同的部门的使用率公开排名,根据数据提供优化建议等,这部分我将在后面详细地介绍。

三、容量运营与可视化如何帮助业务解决问题?

3.1  基础容量

基础容量是整个容量体系的基础,上文提到基础容量我们更关注集群、资源池、 node 以及一些应用维度的容量报表,如下图所示。

集群:关注集群容量水位和超卖率;

资源池:关注资源池容量水位、超卖率、资源冗余度。资源使用率决定了我们是否需要及时采买机器、判断是否能承载更多业务;

Node:关注 Node 资源水位、Node 超卖率,因为超卖会有热点带来的压力,所以对 Node 做了使用率相关的报表;

应用:关注使用量、使用率、实例数、单实例容器数等。业务比较关注应用层面的数据的,比如,服务是否是单点的,因为单点代表如果一台物理机挂了,恰巧服务在这台物理机上,此时服务会短暂不可用,对于核心业务来说是不能被接受的。

基于这些指标,我们做了一些可视化的界面,与对外监控系统 Grafana 数据默认存储 2 周不同的是,我们整个容量平台的数据是持久存储的,目前已存储接近两年的数据。

3.2  业务组织容量


在降本增效的背景下,如何帮助业务去解决问题?业务侧一般更关注如何找出哪些服务占用了较多容量、哪块业务的资源使用率比较低可以缩容、成本突增或者使用突然增多到底是哪个业务导致的、业务治理或者架构整合后到底治理效果如何等等,需要比较直观的界面,能帮他们了解全局。

所以基于以上几点,我们做了基于业务组织的容量报表,如下图所示。

以 B 站直播业务为例,直播作为一个大部门,假设整体容量使用率是 40%,想要提高使用率,通过直观的可视化报表可以看到直播大部门下,分支业务例如营收,会有送礼、抽奖之类的服务,发现其资源较多且使用率低时,业务团队就能依据可视化报表的信息,提前做治理从而获得更多的收益。

同时,能够基于趋势图,看到直播业务下哪些业务突然占用了较大容量,比如新业务场景、研发或者业务突然扩容等,并且支持数据下钻,可以下钻到营收业务下,了解到底是抽奖还是送礼业务引起的变化。

3.3 容量事件

从事件源上看,能引起容量变化的事件有很多,其中包括发布平台/HPA 变更平台/Node 管理,在发布平台里,研发可以扩容或新增服务,以及修改容量配置等,所以发布平台会导致容量的变化。另外,HPA 扩缩容、Node 物理机新增或删除等,也会导致容量的变化。

所以我们内部对接了各种容量变更的平台,做了容量事件相关的能力,当一个业务发现整体资源使用变化很多,此时能通过容量事件快速定位事件源,及时感知容量风险,并追溯容量变化的根因。


3.4 容量周报

容量每周都在发生变化,所以我们平台做了周报的分析,从成本、效率、风险这三个核心出发,业务部门和平台方的周报关注点差异较大。

3.4.1  部门容量周报(业务侧)

业务侧周报核心关注以下 4 点——

  • 整体资源容量,资源使用率,环比上周变化。即和上周比较,资源使用率增加或减少了多少。

  • 应用容量 Top。即哪些应用占用了较多资源,方便业务快速感知大头资源,提高降本优化效率。

  • 风险应用 Top(优先展示 L0/L1 应用)。本部门是否有风险较大的应用,如有使用率较高的核心服务,可以提前扩容。

  • 一周容量变化应用 Top。即新增了哪些服务、哪些服务做了扩缩容、下线了哪些服务等,做到一目了然。


(外部周报展示--部门 main 整体资源利用率)

3.4.2  内部周报(平台侧)

平台侧周报核心关注以下 2 点——

  • 部门资源使用率及排名,部门容量 Top;

  • 部门资源空闲率 Top(大于 5000 核部门)。

通过公开排名,了解哪些业务的容量治理较弱,并优先治理。同时,由于其资源使用量较大,优先对其做治理,平台也将得到更大的治理收益。

(内部周报展示--整体资源利用率)

3.5 容量巡检


不管是在活动大促,还是在日常业务稳定性保障中,我们都需要密切关注整体容量是否存在风险,所以有了容量巡检体系。

3.5.1  业务类巡检

根据业务侧关注的 2 个方面——应用容量巡检、配额巡检,我们做了可视化展示。

应用峰值使用率较高的,会有稳定性风险,需要考虑紧急扩容;而应用使用率较低的,则要考虑是否可以缩容以节省资源。

前面讲到我们做了合池,那么需要关注合池后配额使用率过高的情况,避免导致后续扩容或新增业务无法满足,提前发现风险并做治理。

3.5.2  平台类巡检

平台更关注底层的使用率情况,可调度实例数是否满足后续的业务需求,以及资源池是否是单节点等等。同时,因为平台覆盖了 VPA,那么 VPA 调整完后的失败率也是平台比较关注的。

基于此,我们做了平台巡检大盘、资源池巡检管理、VPA 巡检管理等等。在巡检大盘中,对风险资源池/空闲资源池 Top、风险应用 Top、风险配额 Top 等做了相应展示。


3.6 容量管理的业务价值


容量管理落地后,我们可以直观看到整体工作对业务带来的帮助,比如容量资源导致的发布问题减少 80%、容量问题导致的线上故障降低 90%等等。从这个角度来看,业务部门并非是在配合平台做容量管理,而是大家共同在为最终的业务目标努力,能确保容量管理落实好后,业务的诉求得到更快响应,稳定性也能得到较大提升。

四、容量管理是如何支撑 S12 赛事的?

前面我们讲的是平台侧的能力、业务侧的需求,接下来,我将以刚过去的 B 站大型赛事 S12 为例,具体阐述容量管理平台在具体业务场景中的应用。

4.1 S12 活动节奏



4.2  S12 赛前容量预估


S12 赛前的容量预估主要分为三大步。

第一步,参考历史基础容量数据,计算容量 delta

无论 S 赛事还是跨年晚会,B 站多年来的大型活动,沉淀了一些历史数据可作参考,基于历史数据可以计算出增量。

举个例子,S11 在 11 月举行总结赛,活动保障启动在 8 月,拿 8 月的使用量 a 和 S11 峰值使用量 b 做比较,并根据 delta = 1 + (b-a) / a,来算出 S11 当年的增量系数,比如 1.3、1.5 等。

第二步,S12 新增场景,预估增量

考虑到 S12 在原有基础上,会有一些新增场景,此时需要在业务目标明确后,将其转化成技术目标,技术目标再去转化为容量需求,得到一个预估的增量 d。

第三步,S12 容量预估,得到资源缺口

在资源准备中,额外 buffer 通常是 10%~20%。总容量的预估,可以根据 S12 当前 8 月的使用量 e 和 buffer 来推算,公式参考如下:

容量预估=(e * delta + d ) * (1 + buffer )

这部分预估的容量,减去当前的总资源存量,即可得到整体的资源缺口,并以此为依据进行容量调整。

4.3  S12 的 PaaS 合池


4.3.1  合池前后对比

在合池之前,各块物理资源池相对独立,如下图所示,漫画业务的整体资源使用率最低,而直播可能已接近饱和,此时由于直播是完全独立的物理资源池,漫画和电商业务的空闲资源无法被利用。在往年,例如 S11 时期,就需要采购资源或临时从云上新增资源来支撑整个活动。

S12 赛前,我们把诸如漫画、电商、直播等的在线类微服务合池完后,业务不再需要关心总体的物理资源池,即只需关心自身业务逻辑配额的使用率,而非底层的分配率或使用率。在物理层面有在线统一物理资源池,底层的分配率、使用率完全由 SRE 和平台来保证。

4.3.2  合池可能风险

合池后可能会面临一些不稳定因素,比如,不同的资源池或不同的业务,其内核版本可能有差异,所以我们做了整体物理层的标准化,统一内核以及去 CPUSET 化,通过底层的 VPA 策略动态调整整体资源使用。

4.4 S12 的配额管理

由于合池后的每个业务都共用一个资源池,所以各业务的资源配额需要做到细分管理,避免资源被无限度使用。这里我们通过容量管理平台进行管理,容量配额下发逻辑如下图所示。

配额是基于组织数来下发的,比如某个组织能使用多少配额,策略下发后会作用在规则引擎上,业务变更时,比如要做发版前,会先在规则平台上了解对应业务的配额是否足够做发版,若资源不够,则会提醒配额不足,此时需联系 SRE 调整配额或者进行配额治理。以此我们就能做到配额管控,保证整个资源池不会被乱用。


4.5 S12 的容量支撑

整个 S12 赛事期间,容量支撑可以大致分为四个方面——HPA、VPA、弹性上云、容量巡检,如下图所示。

4.6 S12 的容量监控大盘

对于 S12 赛事活动保障,整体关注的核心指标有业务指标、SLO、资源饱和度,容量监控大盘能根据核心指标,帮助更快地定位潜在风险点,并快速做决策。

首先是业务指标,S12 我们比较关注直播间在线人数,如超过 1000 万、2000 万等等。当赛事期间的整体流量增加,点播业务也会被影响,所以点播在线人数也是我们关注的业务指标之一。

其次是 SLO,SRE 团队会更关注核心接口的 QPS,以及吞吐、延迟、错误率等。

最后是资源饱和度,包括核心服务饱和度、核心中间件饱和度等。


五、未来规划

5.1 容量风控

我们发现有一些服务的容量变更操作缺乏依据,比如想当然地做缩容,没有指标去提示或验证,很有可能导致服务故障。所以我们会做容量风控相关的拦截策略,基于容量画像、应用群包,去做到容量变更风险控制。

5.2 弹性伸缩

第一块是分时调度。B 站有些小活动比如漫画业务,基本是在夜间有 1 个小时左右的峰值流量,其他时间点都是正常的流量。加入分时调度后,比如夜间 0-1 点的活动,我们就可以在 23 点前提前做好扩容,活动结束后完成缩容。

第二块是弹性预测。一方面是能够预测有规律的流量压力并提前扩容,另一方面如果监控系统挂了,弹性的预测数据也可以作为监控数据的兜底。

5.3 热点打散

我们是基于软限调度,同时软限也基于 VPA 做了调整,但仍难避免有些服务在物理机上会有热点,所以我们将基于物理机去做二次调度等工作。(全文完)




添加助理小姐姐,凭截图免费领取以上所有资料

并免费加入「TakinTalks 读者交流群」    



声明:本文由公众号「TakinTalks 稳定性社区」联合社区专家共同原创撰写,如需转载,请后台回复“转载”获得授权。

用户头像

公众号:TakinTalks稳定性社区 2020-03-03 加入

聚焦SRE和故障的技术交流社区

评论

发布
暂无评论
B站容量管理:游戏赛事等大型活动资源如何快速提升10+倍?_TakinTalks稳定性社区_InfoQ写作社区