V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
TencentCOC
V2EX  ›  推广

看腾讯运维应对“18 岁照片全民怀旧”事件的方案,你一定不后悔!

  •  
  •   TencentCOC · 2018-01-04 13:25:12 +08:00 · 3649 次点击
    这是一个创建于 2520 天前的主题,其中的信息可能已经有所发展或是发生改变。

    作者丨魏旸:腾讯高级工程师,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 倍。

    1.jpg

    业务架构剖析

    面对突然涌入的用户请求,相册开发与和运维是如何坚守阵地,度过这次难关的呢?

    在介绍一系列的措施之前,首先不得不介绍下相册业务架构,下图较为抽像地介绍了相册的主要架构:

    4.png

    1. 上传链路: 用户上传图片 /视频,数据流主要由上图中间链路处理,经过 proxy->逻辑(分片、权限、缓存等)->存储接入(分片整合、生成文件地址等)->落地存储
    2. 下载链路:
    • 用户通过空间(说说、日志、动态等)访问相册图片,图片适配模块根据用户请求、终端、请求量等场景适配出最优图片规格,返回用户图片、视频 URL。
    • 用户通过上一步获取的 URL 访问后端存储的图片、视频。

    日常运维工作

    同时,我们介绍一下腾讯 SNG 社交网络运营部平时进行的一些日常容量管理工作。

    1 ) 链路梳理

    如上节所述,我们梳理出相册核心链路,常用梳理过程有几种:

    • 通过抓包形式确定链路模块
    • 通过设备上报的主被调数据确定调用链路
    • 名字服务中获取相关的调用链数据。
    • 通过全链路数据汇总出相关的链路。

    2 )压测:

    定期对整条链路做压测,压测手段有异地调度压测,或单机压测,通过压测找出链路内存在瓶颈的模块,及时修正链路模型。

    3 )高低负载处理:

    依据压测容量数据,分配设备扩容。负载较低的模块设备进行缩容下线以节省成本。

    3.1.PNG

    容量应急措施

    但是这里的问题是显而易见的:以上常规性的工作,只能发现常规场景下内部存在的瓶颈。像 18 岁照片这种特殊场景(用户大量读取空间相册,获取冷数据),无法通过常规压测检测出来问题, 这就需要一系列的机制来解决

    1) 监控和容量弹性机制:

    通过 IaaS 层监控对系统的基础特征进行监控,(如 CPU 负载,出入流量),当模块容量出现异常时,弹性扩容机制需要介入处理,进行扩容。

    如何快速支持短时间扩容上千台设备呢?不得不介绍一下腾讯 SNG 的织云运维理念。

    如上文所述,我们的设备被分配到不同的“业务模块”,而每一个模块有如下的属性:

    1 ) 包:业务处理逻辑文件包,包含业务包与基础包。

    2 ) 配置:包含业务包要使用到的各种配置

    3 ) 权限:包含支撑业务包正常运行时需要的数据库、内部鉴权系统等权限

    4 ) 测试工具:包含业务包启动后,能否接入现网的测试标准

    织云提倡的自动化理念是:标准化 -> 配置化 -> 自动化,让企业的常用操作固化成流程工具。不依赖容易过期的文档,不依赖容易流失的人的经验。

    6.jpg

    参考持续交付的原则“为软件的发布创建一个可重复且可靠的过程”,运维团队为了解决人肉操作经验差异的难题,将运维操作通过流程 DIY 编排能力,实现标准操作的固化。“ 18 岁照片”活动扩容,任何一个运维人员只需要执行 QQ 相册的扩容功能即可实现容量扩展,而织云流程会自动化的完成整个服务部署和上线的操作。(如下图)

    3.jpg

    柔性业务架构

    前面我们说过,相册在当天的峰值下载量涨了 4 倍,且多是访问冷数据,但在短时间内无法筹集到 4 倍的资源,业务是如何应对的呢,在保证用户核心体验不受影响的前提下,我们采用了一些柔性手段。

    回顾一下,当时我们在容量不足时碰到以下的问题,导致短时间内部分图片拉取耗时过长,影响用户体验。

    1 ) 存储压力过大。

    2 ) 自身模块压力过大。

    针对存储压力过大的问题,我们采用了以下几个手段来降低业务负载:

    1 ) 存储手段

    a. 图片适配优化索引策略减少存储压力

    减少拉取照片分批次数,降低后端存储处理压力。分批拉取照片列表数量增加 3 倍。交互次数直接下降近 2/3。

    b. 图片上传增加本地缓存空间减少存储高负载造成的用户上传失败

    调整上传逻辑模块,从原来的本地内存缓存优化为内存+本地磁盘缓存,通过增加本地缓存空间减少后端存储高负载对用户侧上传图片 /视频的影响。虽然底层存储高负载了,但是用户还是可以不受底层影响,将图片通过接入上传到逻辑层缓存。存储压力释放后即可将逻辑层缓存的数据上传到存储层。

    c. 降低图片规则,减少图片下载流量:

    一张图片分为小、中、大三种规格,为了节约存储容量中图是通过图片压缩模块实时压缩返回给用户的,小图和大图真实存储在存储模块。为了降低图片下载的流量压力,我们调整了适配策略,用户访问大图,适配直接返回小图的 url,减少了图片压缩逻辑,并且降低了带宽。调整后图片下载带宽对比如下:

    d. 上传不检查相册有效性,减少存储索引访问量:

    正常情况,在用户上传图片时到相册时,会检查相册是否存在,如相册已被删除,则直接报错。柔性策略跳过相册有效性检查,直接上传图片到后端存储,降低索引访问量,降低索引模块负载。

    同时在业务逻辑上,也做了以下的柔性措施:

    a. 核心模块启用过载保护机制:

    判断单机 cpu 使用率超过 80%时,会自动丢弃多余的请求,以保证业务逻辑模块在大量用户请求场景下不雪崩。

    b. 柔性关闭非核心业务功能减少业务自身负载

    每张图片在高速存储会存储一份位置信息,图片裁剪时用于标示一张图片核心元素的位置。禁用此逻辑后,用户看到的图片无人脸中心点, 客户端裁剪可能不准确。

    关闭用户删除标记,适配图片适配前会预先检测图片是否被删除,如已被删除则不会返回对应的图片列表。删除标记逻辑也会频繁和索引模块交互,高峰期时会占用大量计算资源。禁用此逻辑,用户访问相册时会看到已被删除的图片,但是会标记为灰色已删除。

    调度:相册业务分布在三地,每地分别承载了约 33%的用户,某地请求过高时,我们可以调度用户至其他容量相对较低的地域。

    5.png

    小结

    从“ 18 岁照片全民怀旧”热点社交事件可以看到,事发过程中留给运维的时间相当少,只有严格贯彻“养兵千日用兵一时”的标准化运维理念,建设完善的运维体系,才能在突发事件中游刃有余。

    2.jpg

    后记

    这次 18 岁照片活动,相册通过多种手段顶住了业务压力。 同时通过这次活动,我们也对未来的运维工具进行了进一步规划,比如:

    a) 基于容量的智能调度体系

    b) 资源托管平台。

    c) 自动演习系统。

    织云平台的运维能力在不断迭代,期待在下一次活动来临时能够做到更加有条不紊。

    12 条回复    2018-01-09 10:21:01 +08:00
    zjp
        1
    zjp  
       2018-01-04 13:43:21 +08:00 via Android
    Tink
        2
    Tink  
       2018-01-04 14:07:48 +08:00
    可以可以,专业
    psfang
        3
    psfang  
       2018-01-04 14:44:54 +08:00
    同事,发帖能遵守下社区规则吗,注意节点。
    dong3580
        4
    dong3580  
       2018-01-04 14:52:42 +08:00   ❤️ 1
    firefox12
        5
    firefox12  
       2018-01-04 17:36:00 +08:00
    相册业务分布在三地,每地分别承载了约 33%的用户,某地请求过高时,我们可以调度用户至其他容量相对较低的地域。

    但是数据是存了 3 份的? 所以存储空间使用率至少 300%?

    通篇都是开发已经设计好的灰度开关,直接使用而已。

    4 倍冷数据的读取,4 倍新数据,都是在系统设计的负载之内,而且数据读取大部分应该被 CDN 就挡掉了,如果真的系统可以突然把压力提高 4 倍,那么要么你们加了 4 倍的资源,要么你们的系统利用率不到 20%。
    yanyandenuonuo
        6
    yanyandenuonuo  
       2018-01-04 18:41:11 +08:00
    qq 空间现在日活只有百万级?
    ctsed
        7
    ctsed  
       2018-01-04 18:57:56 +08:00 via Android
    @yanyandenuonuo 怎么可能,00 后的主战场
    hanbing135
        8
    hanbing135  
       2018-01-05 07:53:17 +08:00 via Android
    广告?
    Livid
        9
    Livid  
    MOD
       2018-01-05 10:05:03 +08:00
    提醒一下,以后这类软文请只发到 /go/promotions 节点。
    TencentCOC
        10
    TencentCOC  
    OP
       2018-01-08 16:04:15 +08:00
    @psfang 好的..虽然是热点标题,但是内容不虚,还是蛮多干货的,就放在这个节点了。下次会注意的哈,谢谢提醒~
    TencentCOC
        11
    TencentCOC  
    OP
       2018-01-08 17:11:42 +08:00
    @firefox12 数据没有存三份
    每个地域存储当地用户上传的数据,不会同步其他地域用户上传的图片。异地访问,根据图片热度,直接 oc 加速或者回源到当地存储访问。
    文章提到了,7 成用户访问的都是冷数据,会直接回源到内网机房访问。每个业务都会根据历史经验值预留 buffer 来应对请求量的增长,这里增长的倍数都是远超历史增长的。
    所以我们需要在有限的资源基础上准确评估核心模块的增长,通过柔性策略来减少用户访问带给后端的压力。
    firefox12
        12
    firefox12  
       2018-01-09 10:21:01 +08:00 via iPhone
    @TencentCOC 某地负载高,你把用户引导到其他区域,然后因为冷数据 请求会重新回源到这个负载高的地区,负载并没有减少,处理能力也没提高,这个问题就解决了?
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3962 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 10:18 · PVG 18:18 · LAX 02:18 · JFK 05:18
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.