一分钟精髓速览
当成千上万的服务器都处于低利用率时,就意味着巨额的节约,良好的容量治理能够帮忙打消某些“最初时刻”的长期应急式的自觉或者超量洽购。除了老本正当管制方面,容量治理还要预估对客户可能产生影响的业务倒退和危险变动。
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 做了调整,但仍难防止有些服务在物理机上会有热点,所以咱们将基于物理机去做二次调度等工作。(全文完)
增加助理小姐姐(shulie888),凭截图收费支付以上所有材料
并收费退出「TakinTalks 读者交换群」
申明:本文由公众号「TakinTalks 稳定性社区」联结社区专家独特原创撰写,如需转载,请后盾回复“转载”取得受权。
本文由博客一文多发平台 OpenWrite 公布!