本文根据孙燕老师在《2019DAMS中国数据智能管理峰会》现场演讲内容整理而成。
讲师介绍
孙燕,微博广告基础运维负责人,2009年入职新浪,任职10年间参与博客、图片、视频、微博平台监控、微博广告多个产品运维,致力于运维自动化、产品架构优化、服务治理、智能监控及以监控为依托的服务容灾建设。
1、为什么需要弹性计算
首先,在产品方面,我们的产品线很多,依赖关系比较复杂。
微博广告相当于一个桥梁,左边连接的是广告主,右边连接的是客户,需要将广告主的广告计划转化为用户的需求,让用户看到自己想要看的广告。
为了满足两边不同的需求,产品的变更和发布非常重要且频繁。
其次,在运营方面,很多有推广需求计划的大型活动都有临时扩容需要,比如618跟双十一,对于我们而言这两个活动带来了很大的冲击。
在618和双十一大促之前,为了加大自己的影响力,各个广告主会增加广告计划,微博广告这边再针对广告主的行为加大我们的曝光量,实现广告主广告计划的转化。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
2、传统的业务运维
按照传统运维模式,扩容计划从立项到服务器上线,会经过诸多的流程跟漫长的等待。从结果上来看,服务器扩容了,而且对传统项目而言,整体流程都是可控的,这是它的优点。
它的缺点不言而喻,有以下几点:
首先,它时效性太差,如果按照新浪服务器的采购周期,从审计到上线需要两个月的流程。两个月后服务器上线,恐怕刚结婚的明星都已经离婚了,突发事件流量都已经过去了。
另外,它无法准确预估容量,在传统的业务运维模式下,范冰冰分手、双宋离婚带来的流量是无法实现的,我们无法评估扩容量。
除此之外,传统模式下资源利用率比较低,服务器很难在业务间共享。
在这些问题共同作用下催生了动态扩缩容体系。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
3、弹性计算:实时动态扩缩容
动态扩缩容不是一个工具,是一整套体系。它基于云服务,包含了在线压力检测和消耗度评测的功能,最终实现分级治理。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
1)弹性计算架构
首先简单介绍一下弹性计算的架构,弹性计算依托于Kunkka自动化运维平台,以及Oops监控平台,在业务压测的情况下获取业务指标监控,将数据送到容量决策系统,做出是否扩缩容的决定。
在云服务商方面,我们常用阿里云、华为云跟一部分自建的私有云。DCP混合平台是我们微博另外一个团队做了几年的平台,它能够对接云服务,快速生成云主机快速扩容。今天的重点跟业务方有着最直接的关系:业务上要不要扩容?什么时候扩容?扩多少?我们要解决这样的问题。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
2)决策系统
在上文的架构中,我们提到了容量决策系统,容量决策系统实际上指的是计算系统,会对我们获取到的业务指标进行计算、评估,比如系统的基础信息、一些业务上日志来源的信息等,得到当前业务的容量,通过对历史数据进行同比、环比的分析,得到流量趋势,了解接下来流量会变成什么样子,这两组数据计算结果会给出扩缩容的建议。
同时,他们会计算这些数据并予以呈现,提供一个辅助的API接口,给上下游部门做扩缩容数据。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
3)容量评估方法
这个业务的当前容量是什么样的?是不是健康的?这个指标靠什么来评估?
由于业务系统、业务形态、架构的不同,选取一个实时且通用的指标是非常具有挑战性的,我们也尝试了很久,引入了AVG-hits的概念。
对于处在不同时间内的请求数进行加权、求和来拟合实际的单机消耗量,这个代表的是在不同的区间的耗时数,我们给它一个系数,大于5毫秒小于10毫秒,根据自己的业务给予耗时分区,这样就能计算出来。
事实证明,与之前传统的单一QPS负载对比起来,综合的数据对业务的评估比这种单一指标是更加准确的。
在获得这个数据之后是不是就能够描述当前的系统容量呢?
回答是肯定不能,AVG-hits这个概念第一次接触,确实是有点生涩,举个简单的例子来帮助理解,比如说某个业务消耗指标衡量非常简单,需要通过内存判断消耗情况。
如果监控指标提示内存消耗到80G,那能不能用80G来描述当前系统的消耗情况?这样问就比较容易理解,回答肯定是不能的,因为不知道服务器最大的内存是多少,如果最大是96G,那么80G已经超过80%了,接近危险值,如果最大内存是256G则消耗不到30%,是非常安全的值。
道理是一样的,仅拿到当前消耗值是不能对业务当前状态进行描述的,还需要另一个评估标准。这个业务当前能承载的最大容量是多少?如果是看内存就简单了,可这是一个综合评估标准,要怎么拿到它呢?
作为一个有经验的运维,我觉得根据服务器当前硬件的表现,猜测最大容量不是困难的事情,但现在都2019年了,靠猜是不行的,我们通过压测获取最大容量值。
在实际环境中减少服务器数量,减少到不能再少,记录当前的容量值,作为最大容量,用压测开始之前的实际消耗值除以压测获取的最大容量,得到整个系统的消耗比。这个消耗比就认为是当前这个系统消耗的画像。
压测压到什么情况下达到最大容量不能再压呢?是要压到服务器宕机?我们接入了另外一个概念叫消耗比,在耗时最大区间的Ahits(请求数量)数(PPT上显示:慢速比=100.0*当前容量(Ahits)/最大容量(max_Ahts))与总的请求数之比超过一定的比例,则是影响用户的体现,这个压力达到最大值就不能再压了,就会记录当时的Ahit数,作为这个接口最大容量。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
4)分级治理:水位线
现在拿到了一个非常重要的容量值及消耗比来进行容量评估,用于描述当前的容量消耗情况。拿到这个消耗比之后是不是就可以扩容了?还是可以缩容了?此处还需要一个评估标准,是30%就扩?还是50%再扩?
我们基于历史数据给予分析,制定了三条水位线,包括安全线、警戒线和致命线,拿当前消耗值与水位线进行对比,在不同阶段采取不同的措施。
比如,现在的消耗度远远低于安全线,说明现在服务器部署有冗余,我们可以进行逐步的缩容。如果说现在已经高于致命线,则需要扩容,让这个值更加接近安全线,保证系统的稳定性。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
5)在线容量评估体系
现在自动扩缩容三个要素,当前消耗、水位线、容量决策系统都已经具备了,我们如何把这三个点联动起来?如何让它串在一起完成扩容动作?这些环节都包含在在线容量评估体系内,这个体系可以实现压测的过程。
我们刚才说了压测不是通过流量拷贝进行模拟测试的,我们是针对目标服务,就用线上的流量,记录当前(Ahits)数,开始减少服务器的数量,一直到慢速比达到临界值的时候,记录Ahits数作为本服务单元最大的消耗,得到消耗值后和水位线进行对比,调用决策系统做出是否扩缩容的决定,接下来再对接云服务商,就完成了扩容的动作。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
6)实时演练体系
前面进行的数据采集、计算,以及动作的串联,都是为了完成最后一个目标,服务扩容成功。
真正的服务器扩容到线上之后,怎么样才能保证服务是健康可用的呢?我们还有另外一套辅助系统叫扩容演练。在实时演练过程中,要注意以下几点:
①部署效率
我们通过扩容演练来寻找整个扩容过程中的瓶颈,比如,我们下发是通过DCP对接云服务商来完成扩容的。
在真正的线上扩容过程中,DCP有时要同时承载几千台节点的扩容并发。DCP的效率是否能够满足?在扩容演练过程中需要确认这一点。
②带宽限制
微博和云服务商之间确实是拉了专线,但是微博和云服务商不只是微博广告的一个业务,还有很多其他大户。
而且一般在流量增加的时候他们的扩容也是非常猛烈的,所以带宽是否可用,也是我们在日常演练过程中非常注意的现象。
③依赖服务
这方面有很多案例,在这里简单分享一下,2015年春节,自动扩缩容的流程才刚刚开始,春节当天晚上我们扩容完几千个节点后,忽然发现负载均衡加不上去。
之前做过演练,但不会拿几千台云服务器进行扩容,可能几十台确保功能可用就可以了,到时候要让负载均衡的同事通过配置文件增加下memeber就可以。如果上千台的服务器没有办法增加到负载均衡设备,那个时候大家手忙脚乱,最后通过手动的方式扩容节点。
大家知道春晚的流量高峰很短,但那天确实给了我们当头一棒。接下来我们在扩容演练过程中,不仅会对负载均衡进行确认,还会对我们依赖的服务进行确认。比如每次发生热点事件时,大家会说微博又崩了,评论又崩了,热搜出不来了。其实应对峰值流量是件很头大的事情,我把事情解决了,兄弟部门没有解决,兄弟部门解决了,姐妹部门又出现了问题。
④安全限制
618大促时,京东的同学分享了在扩容的时候新增的服务器IP与VIP发生了冲突,而微博主要的体现就是数据库会对很多业务的请求设置白名单,可是云服务器扩容之后ip是随机的。
图片来源于:《2019DAMS中国数据智能管理峰会》PPT
另外,新浪对于通行证有很多IP限制,所以我们通过扩容演练体系不断发现各个环节中的问题,加以解决,保证在扩容动作进行时能够顺利地完成,保证扩容出来的云主机真正安全上线服务。有了这个系统的加持,截止到现在自动扩容服务都处于比较稳定的状态。