流量小生DDOS攻击下,微博如何保证系统稳定不再挂?
微博作为当今中文社交媒体的第一品牌,拥有超过3.6亿的月活用户,也是当前社会热点事件传播的最主要平台。而热点事件往往具有不可预测性和突发性,10 分钟内可能带来流量的翻倍增长,甚至更大。x0ax0a如何快速应对突发流量的冲击,确保线上服务的稳定性?...
作者|胡忠想
编辑|小智
写在前面
图 1. 9 月 26 日上午“谢娜宣布怀孕”事件微博评论流量
传统的面对而传统的人工值守,手工扩容的运维手段,显然无法满足这一需求。为此,我们的目标是做到系统的自动扩容,在流量增长达到系统的警戒水位线时自动扩容,以应对任意时刻可能爆发的流量增长,确保服务的高可用性。微博 Web 弹性调度演进
第一代:人为触发扩缩容
- 人工根据监控系统的 QPS、AvgTime、load 等判断是否扩容;
- 根据经验值人为预估扩容机器数;
- 支持 PC、手机等多渠道触发。
图 2. 人工值守扩缩容流程
问题:需要人为介入确认扩容时机和扩容数量。第二代:无人值守定时扩缩容
- 每天晚上 8 点定时扩容,12 点前定时缩容;
- Web 与依赖的 RPC 可以依赖扩容。
图 3. 无人值守定时扩缩容流程
问题:只能解决晚高峰问题,无法应对突发事件。第三代:智能触发自动扩缩容
- 自动压测评估线上服务池最大承载量
- 实时评估线上服务池冗余度
- 冗余度不足则触发扩容,充足则触发缩容
图 4. 智能触发自动扩缩容流程
下图展示了在 # 薛之谦与前期复合 # 事件中,智能触发自动扩缩容的实际效果。图 5. 薛之谦与前妻复合 # 事件自动扩容效果图
下面对智能弹性调度系统进行详细介绍,图 6 展示了这一系统包括的几个主要组成部分。- 全数据日志分析 Profile,生成业务系统的各种指标并采集汇报给实时监控系统 Graphite。
- 实时监控功能系统 Graphite,实时汇聚并计算多维度业务指标数据,并提供 API 给在线容量评估以及智能弹性调度系统已作决策。
- 在线容量评估系统 Diviner,对在线服务池进行压测,以评估服务池的最大承载能力。
- 智能弹性调度系统 DCOS,根据系统实时的水位线情况,决策是否需要进行扩容以及扩容机器数。
- 混合云平台 DCP,向私有云和公有云申请机器,进行弹性扩容。
图 6. 智能弹性调度系统架构图
Profile- 全数据日志体系
在实际的扩容决策中,需要以一些关键指标如 QPS、AvgTime 或多种指标叠加作为判断依据,所以自动扩缩容系统首先要解决的问题就是关键指标的生成和采集。
指标的生产
指标的采集
图 7. Profile 标准日志格式
实时监控系统
有了关键业务指标的 Profile 日志,就可以对它们进行实时监控,其工作原理如图 8 所示。
图 8. 实时监控系统架构图
从上图可以看出,实时监控系统的核心就是 Graphite。它主要包含两方面的功能:- 将实时传输的 profile 日志进行聚合计算,产生各种维度的数据存储到时序数据库中。
- 还需要提供 API 接口,以提供 dashboard 展示,压测系统以及智能调度系统调用以用于扩缩容决策。下面将对 Graphite 进行详细介绍,其架构如图 9 所示。
图 9. Graphite 架构图
为了减少延迟,我们对 graphite 系统中的关键模块进行了优化,主要包括两个方面:- 用 go 重写了 statsd-proxy 和 statsd 模块
- carbon 中添加缓存,7 天的数据存储在缓存中,7 天以外的数据存到 SSD。
在线容量评估系统
有了关键业务指标的实时监控,就可以对系统进行压测,以评估系统的最大支撑能力。而如何对系统进行压测,以合理评估系统的承载能力主要取决于两个方面:
- 合理选择业务指标来衡量系统健康度;
- 精确定位性能拐点以确定系统临界值。
合理选择业务指标来衡量系统健康度
常见的可作为衡量系统健康度的指标有 avgTime、load、5xx、连接数等,对于单一业务模型的系统来说,选取其中一个指标即可。但对于复杂的业务系统,以微博 web 系统为例,既包含了 CPU 和带宽消耗较高的 feed 接口,又包含了低延迟和高并发的计数器接口,单一接口健康并不能代表整个系统健康。除此之外,单一指标正常也不能代表系统正常,比如我们经常遇到 feed 接口 avgTime 正常,但延迟大于 1s 的比率超过了 1%,这时候会直接造成 1% 用户刷新失败,影响了用户体验。
为此,我们建立了多接口多指标的健康度评估模型。
- 多接口,是指选取服务池中多个具有代表性的接口,并且还会考虑整体服务池中接口的情况,比如我们在微博 web 系统中不仅选取了 feed 接口,还选取了计数器接口等。
- 多指标,是指不仅仅选取单一指标作为参照,比如我们在实际压测过程中,会考虑接口的平均耗时、5XX 以及慢速比(延迟超过 1s 的比率)。
常用的系统压测方案主要包括两种:
- 在线缩减机器数量以增加单机承载量,从而压测到单机承载能力的最大值。
- 模拟洪峰,对服务池进行全链路压测,以模拟出峰值流量下系统的承载能力。
智能弹性调度系统
快。
智能弹性调度并不等到系统的承载量已经濒临临界值时才进行扩容,因为此时可能流量很快上涨超过水位线,在扩容完成之前就已经把系统压垮了。为此,我们给系统设置了三条线:致命线、警戒线、安全线,如图 10 所示。
图 10. 智能弹性调度系统水位线
- 致命线。从字面意义上即可理解,当服务池的流量一旦触及致命线,就应当立即扩容。通常致命线的设定与业务的重要程度有关,一般核心系统的致命线设定要高一些,保证足够的冗余度,目前微博核心 web 系统的致命线设定为 1.6 倍冗余。
- 警戒线。当服务池的流量到达警戒线时,再结合业务指标综合考量是否需要扩容。以微博核心 web 系统为例,如果流量到达警戒线,并且 1s 的慢速比超过了 1%,也需要进行扩容。
- 安全线。主要用于决策缩容,当服务池的流量在安全线以上,则可以进行缩容。
主要体现在两个方面:防抖动和合理扩容。
- 防抖动。当系统的承载量到达临界值时,理论上要进行扩容。但还要考虑在实际线上系统运行时,经常出现系统偶发的抖动现象,避免因为偶发抖动触发临界值进行扩容带来不必要的机器成本。为此,我们在智能弹性调度系统中,设定了 1min 的采集周期,并设置了 5min 的滑动窗口。在这个滑动窗口内采集的 5 个点中,任意满足 3 个点即判断需要扩容。
- 合理扩容。智能弹性调度系统会根据系统当前的水位线,以及系统当前机器数评估出合理的扩容机器数,按需扩容,避免浪费机器成本。
混合云平台 DCP
混合云平台 DCP 主要职能是向内部私有云和外部公有云申请机器,并部署服务扩容到线上服务池。目前微博混合云 DCP 平台,具备 15 分钟内扩容 1000+ 服务器的能力,关于这部分的介绍不是本文的重点,感兴趣的童鞋关注微博 OpenDCP 的 github 主页:
https://github.com/weibocom/opendcp
作者介绍
胡忠想,微博服务化项目架构师、技术负责人。2012 年加入微博工作至今,承担过微博计数器架构升级,春晚和奥运服务保障,以及微博 feed 业务架构升级等工作。目前,主要专注于服务化方向,工作内容包括:微服务治理,弹性调度以及自动化监控等。
今日荐文
点击下方图片即可阅读
禅与互联网技术:龙泉寺的程序员们
更多智能运维实践
12 月 8-11 日 ArchSummit 北京站,除了邀请胡忠想老师进一步讲解《微博应对突发热点事件的弹性调度实践》之外,同话题里还有下述智能运维实践,欢迎前来现场讨论交流。
- 阿里故障治理领域的智能运维实践
- 阿里弹性容量管理探索
- 百度智能故障自愈实践
- 滴滴出行海量数据场景下的智能监控与故障定位实践
- 拍拍贷基础架构的 DevOps 演进之路
关注 InfoQ
微信扫一扫关注公众号