热搜爆爆爆,热点流量咋应对?微博云原生运维最佳实践!
凌云时刻
编者按:2021年10月22日,在云栖大会的《云上运维最佳实践》分论坛,微博研发中心基础平台负责人马朕发表了“快速应对热点流量峰值,微博云原生运维最佳实践”的主题演讲,和大家分享交流了微博云原生运维如何快速应对热点流量峰值,希望给有同类型业务场景的同行提供一种思考方式。
基于云原生实现快速扩容以应对流量高峰
关于热点的应对,我们经过了三个阶段:成本考虑弹性资源的需求,热点弹性数量的需求,热点弹性速度的需求。
第二阶段,需求主要来源于网友吃瓜。这个弹性需求我们主要针对数量需求,于是以周为单位开始朝着以分钟为单位来准备。
第三阶段,是我们对弹性速度有了需求。我们现在弹性峰值的速度越来越快,所以我们的准备时间也越来越少。于是我们就开始思考,弹性能力怎么能够进一步再提升。
1. 吞吐率:提升了每分钟弹性的能力。
2. 创建速度:当我们收到机器之后,把机器快速部署到线上,降低单台机器扩容完成耗时,从而节约更多资源和时间。
3. 资源分配策略:要确保核心服务能够更快地分配到资源。
4. 在离线整合:想办法对在线、离线业务做一些整合,进一步提升供给。
微博DCP混合云平台资源分配策略优化
下面介绍我们在拿到DCP混合云平台设备之后,如何做一些优化,从而尽快地提升扩容效率。
这是我们整个扩容流通图,我们的DCP混合云平台也遇到了挑战。因为涉及的业务方比较多,所以谁先提交,资源就会侧重分配给谁。当核心业务慢时,却没有保障。其次,基础环境的初始化耗时比较高,镜像拉取的失败率也比较高。
针对这些问题,我们分别做了优化,包括建立扩容的策略、优化扩容链路、通过混合云决策来建立决策支持体系、接入ECI和闪电交付等服务。
我们默认的分配策略,是一种公平调度,保证每个产品在提交申请之后,都能均衡分配资源。就像餐厅就餐,每桌都要轮着上菜。这是我们常规的一种状态。当热点来的时候,为了能够优先保证核心服务,我们建立了优先级的队列。
这个优先级的队列有一定的唯一性。因为在热点下发的时候,它是一波一波。各业务方在一起商讨制定自己的容量,制定自己的热点机器数量,定好模板以后,我们就确定好了队列。
当我们向云厂商申请完资源之后,就按照这个策略80%的优先级核心服务。同时,普通队列也能满足我们日常的一些需求。当优先级队列的固定数量完成之后,在完成承载第一波峰值流量的任务后,他们开始转为普通队列。
我们的DCP整体关注三个点:库存、提交数和冗余度。我们自己业务的核心模块关注的点有:已经提交数、扩容成功率和慢速比。慢速比是我们的一个核心指标,我们会根据它来判断是否扩容、是否缩容。如果扩容的失败率高,出现了问题,我们就用IVR动员,让人工介入处理。
这是我们的一些分配策略,做了一些离线整合的实践。当有些服务流量大的时候,我们就把离线的服务先下来,然后部署上核心服务,优先去扛第一波流量。同时,当离线的服务冗余度不足,我们用常规队列慢慢补充。
这是我们在离线整合功能的使用时间情况,我们内部管它叫极速扩容。这里显示了我们的服务下线、驱逐任务、停止容器和环境清理等时间,整体可以在热点流量来的时候形成双保险,从而作为峰值流量机器运行时的补充。
在主动方面,我们会根据一些重点热点事件,比如春晚、体育赛事等,我们主动做一些准备。在容量里还有一个功能,即高水位判断。如果我们发现这个流量已经达到了日常的晚高峰,或者是超过一定的水位,我们可以打开高水位开关。系统里的容量会保持在一个充足的水位,当热点来的时候也会比较从容。
其次,对于系统来说稍显被动。我们会根据这个热点和运营合作,如果运营的同事觉得这个热点是一个比较爆的点,也可以同时触发扩容。如果运营在热点的文案里没有判断到问题,或者不好判断。我们会在PUSH的文案中进行截取。如果发现一些明星或者一些热点,我们也会触发扩容,为第一波的流量扛峰。
第二部分是热点联动的应对。我们内部通过IVR进行动员,通过热点联动机制,进行热点的扩容与降级。如果扩容之后流量未达到预期,会自动对资源回收。我们内部会把流量分成几个等级:一级热度到五级热度。随着级别越高,我们也会做一些预判,比如降低一些不影响服务的边缘功能,从而释放更多的可用资源。我们对每一次热点都进行记录和归档,方便未来进行复盘和技术上的建设。
第三部分,关于技术工具的改进。因为我们的服务关联很多部门,每个部门的业务模型都不相同。所以我们会进行全链路的压测系统。随着业务复杂度的变化,我们需要定时压测与评估,以便更新我们扩容的模板。同时在制度方面,我们会在公司内部形成虚拟小组,各业务方技术负责人参与其中,对我们的项目进行日常的制度建设。这是我们到目前为止,关于热点无状态的计算类资源,比较全的介绍。
在容量管理和提升利用率等方面开展实践
资源的利用率和成本控制一直是各公司关注的点。其中类型多样性、热点与容量规划、硬件这三点对我们影响比较大。类型多样性是指服务,无论是前端的计算资源,还是后端资源;我们的硬件也是不同的,各种厂商、各种配置;再加上我们对热点的常容量的规划;服务类型的多种多样就产生了一些冲击。
无论是自建机房还是云上,我们在阿里云上已经开始使用神龙,我们基于K8s自己来切割,对神龙进行一些混合的编排。我们会自研一些系统对它进行调度。我们使用CPU的密集型、IO密集型、内存密集型等,每一项密集型背后表示着其他资源利用率不高。所以我们从空间上进行混合的编排,时间上争取能够弹性调度。
每个服务流量都跟自己相关,比如常规业务有早晚峰值,超话服务在0点会签到等。我们根据业务的自画像,从这些角度进行不同的削峰填谷,包括内部一些离线服务。我们的一些前端类计算服务会有早晚峰值,我们在早晚峰值时把离线服务的机器挪到线上使用。到夜里,再把机器下线给计算资源使用,从而达到削峰平谷的目的。
我们的闪电交付和ECI主要是应对峰值流量时的动态扩容。在日常的时候,我们会根据成本做一些自动扩容。除此之外,我们针对自动流量也做了一些预警,可以做到10秒级动态流量追踪与预测。当流量来的时候,我们自动进行扩容。流量过去,我们自动进行缩容,极大地节约了成本。
关于有状态的服务,我们也有做一些建设和实践。我们把资源实例尽量小型化,建立数据的恢复中心。当流量来的时候,我们通过在多个机房节点拉取数据,快速地形成一种扩容,从而弥补前端类计算资源流量大、后端资源不足的情况。
1. 我们针对不同的规格进行混合编排,把它分成24个pod,在每个pod里用自研的程序进行编排,从而提升它的整体利用率。
2. 弹性调度与自动扩缩容也能进一步节约成本。
3. 我们把大多数流量都用弹性方式处理,通过离线整合、削峰平谷的方式,把这些资源合理利用起来。
4. 关于异地部署各厂商也都在做,因为外地的机房很便宜。厂商只需要在异地部署一整套服务,以弥补两地之间的延迟。最后是大型机,我们未来也会朝着这个方向继续建设。(完)