作者丨魏旸:腾讯高级工程师,15 年运维经验的老专家,负责 QQ 空间、微云、QQ 空间相册的运维工作,亲历 8 亿军装照、QQ 空间异地多活建设等重大架构升级事件。
2017 年 12 月 30 日,元旦假期的第一天,你的朋友圈被 18 岁照片刷屏了吗?据说“晒 18 岁照片”的根源是 2017 年年未,最后一批 90 后将度过他们的 18 岁生日。这意味着,90 后已全部成年,集体告别了青葱芳华。
这是一个青春的、也是怀旧的年华,QQ 空间做为国内第一批社交平台产品,承载了较多的用户记忆,大量的用户涌入 QQ 空间翻找自己多年前的 18 岁照片晒上社交平台。集体引爆了空间相册山洪峰涌而至的照片流量。
下面这篇文章让我们回顾 12 月 30 日,空间相册面对突发四倍流量,七成访问落在后端冷存储的极端压力下,相册运维、开发团队如何凭借平时基础功底,从告警、容量、扩容、柔性、调度等全方面运维能力,扛过“ 18 岁照片”的全民怀旧事件。
突然来袭的用户集中行为,给我们平台的能力带来了非常严峻的考验,先让我们先来看一组数据:
1 ) 图片下载量峰值达到平日晚高峰的 4 倍,且 70%以上都聚集在平日不怎么访问的冷图片。
2 ) 图片上传量达到平日晚高峰的 4 倍。
3 ) 带图说说峰值达到平日晚高峰的 12 倍。
面对突然涌入的用户请求,相册开发与和运维是如何坚守阵地,度过这次难关的呢?
在介绍一系列的措施之前,首先不得不介绍下相册业务架构,下图较为抽像地介绍了相册的主要架构:
同时,我们介绍一下腾讯 SNG 社交网络运营部平时进行的一些日常容量管理工作。
如上节所述,我们梳理出相册核心链路,常用梳理过程有几种:
定期对整条链路做压测,压测手段有异地调度压测,或单机压测,通过压测找出链路内存在瓶颈的模块,及时修正链路模型。
依据压测容量数据,分配设备扩容。负载较低的模块设备进行缩容下线以节省成本。
但是这里的问题是显而易见的:以上常规性的工作,只能发现常规场景下内部存在的瓶颈。像 18 岁照片这种特殊场景(用户大量读取空间相册,获取冷数据),无法通过常规压测检测出来问题, 这就需要一系列的机制来解决
1) 监控和容量弹性机制:
通过 IaaS 层监控对系统的基础特征进行监控,(如 CPU 负载,出入流量),当模块容量出现异常时,弹性扩容机制需要介入处理,进行扩容。
如何快速支持短时间扩容上千台设备呢?不得不介绍一下腾讯 SNG 的织云运维理念。
如上文所述,我们的设备被分配到不同的“业务模块”,而每一个模块有如下的属性:
1 ) 包:业务处理逻辑文件包,包含业务包与基础包。
2 ) 配置:包含业务包要使用到的各种配置
3 ) 权限:包含支撑业务包正常运行时需要的数据库、内部鉴权系统等权限
4 ) 测试工具:包含业务包启动后,能否接入现网的测试标准
织云提倡的自动化理念是:标准化 -> 配置化 -> 自动化,让企业的常用操作固化成流程工具。不依赖容易过期的文档,不依赖容易流失的人的经验。
参考持续交付的原则“为软件的发布创建一个可重复且可靠的过程”,运维团队为了解决人肉操作经验差异的难题,将运维操作通过流程 DIY 编排能力,实现标准操作的固化。“ 18 岁照片”活动扩容,任何一个运维人员只需要执行 QQ 相册的扩容功能即可实现容量扩展,而织云流程会自动化的完成整个服务部署和上线的操作。(如下图)
前面我们说过,相册在当天的峰值下载量涨了 4 倍,且多是访问冷数据,但在短时间内无法筹集到 4 倍的资源,业务是如何应对的呢,在保证用户核心体验不受影响的前提下,我们采用了一些柔性手段。
回顾一下,当时我们在容量不足时碰到以下的问题,导致短时间内部分图片拉取耗时过长,影响用户体验。
1 ) 存储压力过大。
2 ) 自身模块压力过大。
针对存储压力过大的问题,我们采用了以下几个手段来降低业务负载:
减少拉取照片分批次数,降低后端存储处理压力。分批拉取照片列表数量增加 3 倍。交互次数直接下降近 2/3。
调整上传逻辑模块,从原来的本地内存缓存优化为内存+本地磁盘缓存,通过增加本地缓存空间减少后端存储高负载对用户侧上传图片 /视频的影响。虽然底层存储高负载了,但是用户还是可以不受底层影响,将图片通过接入上传到逻辑层缓存。存储压力释放后即可将逻辑层缓存的数据上传到存储层。
一张图片分为小、中、大三种规格,为了节约存储容量中图是通过图片压缩模块实时压缩返回给用户的,小图和大图真实存储在存储模块。为了降低图片下载的流量压力,我们调整了适配策略,用户访问大图,适配直接返回小图的 url,减少了图片压缩逻辑,并且降低了带宽。调整后图片下载带宽对比如下:
正常情况,在用户上传图片时到相册时,会检查相册是否存在,如相册已被删除,则直接报错。柔性策略跳过相册有效性检查,直接上传图片到后端存储,降低索引访问量,降低索引模块负载。
同时在业务逻辑上,也做了以下的柔性措施:
判断单机 cpu 使用率超过 80%时,会自动丢弃多余的请求,以保证业务逻辑模块在大量用户请求场景下不雪崩。
每张图片在高速存储会存储一份位置信息,图片裁剪时用于标示一张图片核心元素的位置。禁用此逻辑后,用户看到的图片无人脸中心点, 客户端裁剪可能不准确。
关闭用户删除标记,适配图片适配前会预先检测图片是否被删除,如已被删除则不会返回对应的图片列表。删除标记逻辑也会频繁和索引模块交互,高峰期时会占用大量计算资源。禁用此逻辑,用户访问相册时会看到已被删除的图片,但是会标记为灰色已删除。
调度:相册业务分布在三地,每地分别承载了约 33%的用户,某地请求过高时,我们可以调度用户至其他容量相对较低的地域。
从“ 18 岁照片全民怀旧”热点社交事件可以看到,事发过程中留给运维的时间相当少,只有严格贯彻“养兵千日用兵一时”的标准化运维理念,建设完善的运维体系,才能在突发事件中游刃有余。
这次 18 岁照片活动,相册通过多种手段顶住了业务压力。 同时通过这次活动,我们也对未来的运维工具进行了进一步规划,比如:
a) 基于容量的智能调度体系
b) 资源托管平台。
c) 自动演习系统。
织云平台的运维能力在不断迭代,期待在下一次活动来临时能够做到更加有条不紊。
1
zjp 2018-01-04 13:43:21 +08:00 via Android
|
2
Tink 2018-01-04 14:07:48 +08:00
可以可以,专业
|
3
psfang 2018-01-04 14:44:54 +08:00
同事,发帖能遵守下社区规则吗,注意节点。
|
5
firefox12 2018-01-04 17:36:00 +08:00
相册业务分布在三地,每地分别承载了约 33%的用户,某地请求过高时,我们可以调度用户至其他容量相对较低的地域。
但是数据是存了 3 份的? 所以存储空间使用率至少 300%? 通篇都是开发已经设计好的灰度开关,直接使用而已。 4 倍冷数据的读取,4 倍新数据,都是在系统设计的负载之内,而且数据读取大部分应该被 CDN 就挡掉了,如果真的系统可以突然把压力提高 4 倍,那么要么你们加了 4 倍的资源,要么你们的系统利用率不到 20%。 |
6
yanyandenuonuo 2018-01-04 18:41:11 +08:00
qq 空间现在日活只有百万级?
|
7
ctsed 2018-01-04 18:57:56 +08:00 via Android
@yanyandenuonuo 怎么可能,00 后的主战场
|
8
hanbing135 2018-01-05 07:53:17 +08:00 via Android
广告?
|
9
Livid MOD 提醒一下,以后这类软文请只发到 /go/promotions 节点。
|
10
TencentCOC OP @psfang 好的..虽然是热点标题,但是内容不虚,还是蛮多干货的,就放在这个节点了。下次会注意的哈,谢谢提醒~
|
11
TencentCOC OP @firefox12 数据没有存三份
每个地域存储当地用户上传的数据,不会同步其他地域用户上传的图片。异地访问,根据图片热度,直接 oc 加速或者回源到当地存储访问。 文章提到了,7 成用户访问的都是冷数据,会直接回源到内网机房访问。每个业务都会根据历史经验值预留 buffer 来应对请求量的增长,这里增长的倍数都是远超历史增长的。 所以我们需要在有限的资源基础上准确评估核心模块的增长,通过柔性策略来减少用户访问带给后端的压力。 |
12
firefox12 2018-01-09 10:21:01 +08:00 via iPhone
@TencentCOC 某地负载高,你把用户引导到其他区域,然后因为冷数据 请求会重新回源到这个负载高的地区,负载并没有减少,处理能力也没提高,这个问题就解决了?
|