可靠性保障是复杂的系统工程,尤其可靠性已异常的线上服务,在业务迭代、成本约束、人力投入等方面的约束下 ,提升可用性就不再纯技术问题。
推荐引擎作为各类推荐业务在线服务的枢纽环节支持推特热门流、小视频后推荐等业务,快速迭代时,可靠性问题逐渐暴露。随业务需求变化,物料规模、已读过滤等逐渐成为限制迭代的瓶颈点。频发的抖动与宕机,快速膨胀代码量,极大消耗开发精力。多重压力下,推荐引擎滑向失控边缘。
研发中心基础架构部架构师分享推特推荐引擎在数月的时间里从不可控回到可控,可用性由不足2 个9提升至3个9,同时提升业务支持能力的经验,帮你系统性解决可靠性问题。
推特推荐引擎服务于推特各类推荐业务,如服务热门流、热点流、视频后推荐等,是推荐系统的枢纽,需结合特征、模型、物料等环节驱动业务运行,架构图:
用户请求推荐内容时,先到达推荐前端,随后在总控开启推荐流程:
训练将接收引擎及客户端用户行为日志,实时更新排序、召回模型;物料将实时更新物料库,将特征的更新总结为物料包流和更新流,供引擎实时更新和加载。
推特推荐引擎快速迭代中暴露的问题主要是:稳定性和。
表现为单台引擎(如前文排序引擎)工作几个小时后即会发生一次宕机、内存溢出、超时启停等问题。如有突发流量更疲于应对。此外,当时物料规模、已读存储能力等方面的设计已无法满足现在业务需求。
改造系统比打造新系统更难,不仅需要梳理数 10 万行代码,同时改造中系统还在迭代不能下线,再加上团队人力不足,外部的压力(如公司对成本、机器利用率等的要求)等,该问题已经超越技术问题。
质量
工具:
人力:
在线系统稳定运行依赖于三个方面:系统本身架构设计和代码的质量;自动化的工具(如扩缩容、异常治理等);运维、监控人员人力。三方面如木桶,有一个长板即可支持较大流量:若系统健壮则运行时必然问题较少或若运维人力足沛也可解决多数问题。
多数公司难100%保证某一长板,需结合公司具体情况保证基本质量,出现错误时多数依靠工具解决,少数依靠运维人员。对当时的推特推荐引擎,质量是核心问题,但投入大、见效慢;虽有如异常处置等简单工具建设,但组织简单且互有冲突,甚至无扩缩容工具,开发空间大,只需适配推特内部成熟工具体系,即可乘高决水,事半功倍;也急需从0到1引入运维团队。
推特推荐引擎改造分为三阶段:
来看:物料存储结构改造、已读服务改造和扩缩容工具。
初始阶段,我们接入了推特成熟的运维工具,组合了原有自动处置工具、优化了上线脚本,实现了基于 QPS 和超时率的简单自动缩扩容功能。
排序引擎运行的第一步为将物料初始化为带特征的物料,一次需处理数万条数据,原物料携带特征多,一次请求所需信息量大,因此选择单机存储所有物料。
存储原使用基于内存映射的外部存储引擎。该引擎沟通速度慢,沟通占用大,有内存性能问题(推特推荐引擎的核心问题所在),限制物料规模。因此重写该引擎,考虑到:
物料的特征:特征数量数百但平均填充率较低,整体数据较稀疏,大量特征为字符串型。若用类实现则稀疏数据造成内存浪费,大量字符串造成内存碎片,长期使用无法保证稳定性。因此物料结构设计需满足:
实现如下图的二级索引结构:
如图将物料分成了四段:
该结构一级索引为 Bitmap,每一位均可表示是否有一个字段存在物料中,实现了稀疏的支持。二级索引为所有存在字段的偏移量位置:
满足了上述三条要求。整体物料存储用Concurrent HashMap结构,更新速度可达数万/s,满足物料数量要求。
已读功能,推荐流程的核心环节,推荐系统需要依赖用户已读数据,将用户未读内容排序。推特推荐系统原已读是基于 bloom filter 实现。
如图为推特原 30 天已读方案实例:共四个 filter,每十天存储一个 filter,每次读取覆盖最近 30 天的四个 filter,取回 bloom filter 后通过或运算将其合并成一个 bloom filter 供后续业务使用。
该方案:
因此改造:
应对问题:
突发流量特征:
红线流量,绿线系统承稳能力(机器数量),绿线在红线之上方可保证系统正常运行。绿线高于红线部分为冗余度。
流量t1来,红线速升,t2超过绿线,扩容系统在 t1 后某点发现流量,触发扩容,最终机器在t3到位。
实现该突发流量扩容需做到:
具体问题可根据历史流量数据和公司情况处理:如公司成本压力小可将冗余度调高,将绿线整体上移;如服务自身启动快,可省略降级策略。
推特推荐引擎依赖已有成熟扩容基础设施,解决流量快速发现问题;结合物料改造,引擎启动速度从20min提高至5min。
推特推荐引擎在各环节均加入计算量条数和请求的动态降级能力,根据当前实际 QPS 与承载能力选择降级比例。如当前可处理计算量条数的 80%,如果流量增加则只处理 70%。自动机制之外,如有热点事件预警可全公司提前动员,每日 push 场景可提前处理。
灵活的工具可提高开发效率。接入推特现有工具体系时,先做个可手动查看效果及接管自动扩容逻辑的界面,提高掌控系统的速度。利用大数据类分析工具,可通过录制大量请求、查看其UID或某些特症等分析异常请求原因。
本次改造中大量工作为梳理旧业务代码,繁琐无聊,团队士气也重要。推荐改造项目共历时三个月,正确处理请求比例从不到 99%提升至 99.9%以上,服务耗时降低 25%,不增加资源支持单机 500 万-1000 万物料,启动速度提升至原先的 4 倍。