淘宝TPP系统解析
TPP(Taobao Personalization Platform, 也称阿里推荐平台 ) 平台承接了阿里集团300+重要个性化推荐场景,包括手淘首页猜你喜欢、首图个性化、购物链路等。除了提供应用层面的支持和封装,还肩负着机器分配和维护各场景运行稳定的重任。
理想情况下,TPP平台上的场景owner不需要关注底层的资源分配情况,平台尽可能的提高CPU利用率,同时保证平台上场景的稳定。QPS(每秒查询率)增加的时候扩容,QPS减少的时候缩容,未来这些在夜间被拿掉的机器可以用来混部离线任务等;另外,在2016年双11的时候,总的机器数目不足以维持所有的场景以最高性能运行,需要有经验的算法同学判断场景的优先级,从低优先级的场景上拿出来机器,补充到高优先级的场景中保证成交额。这些平台稳定性工作都是需要繁琐的人工调度,会有如下的缺点:
1.人力成本巨大:人肉无法监控和处理所有的场景;
2.反应时间较长:从发现场景出问题,找出可以匀出机器的不重要场景,到加到重要场景所需要的时间相对过长,而程序天然的有反应时间短的优势;
3.人力无法全局高效的调度资源, 而程序可以更敏感的发现场景的问题,更全面的搜索可以拿出来机器的场景,并可以准确计算拿出机器的数目,有更好的全局观。
基于如上的两点:日常的时候提高资源利用率,大促的时候解放人力,TPP智能调度系统就产生了。TPP智能调度系统以每个集群(一组机器,承载一个或多个场景)的CPU利用率,LOAD,降级QPS,当前场景QPS,压测所得的单机QPS为输入,综合判断每个集群是否需要增加或者减少机器,并计算每个场景需要增减机器的确切数目,输出到执行模块自动增减容器。 TPP智能调度系统有如下的贡献点:
1.日常运行期间,保证服务质量的情况下最大化资源利用率;、
2.大促运行期间,能够更快速、更准确的完成集群之间的错峰资源调度;3.支持定时活动事件的录入,如红包雨、手淘首页定时的Push,程序自动提前扩容,活动结束自动收回;
4.对重要场景提前预热,完成秒级扩容。
该系统由TPP工程团队和猜你喜欢算同学联合搭建而成,从2017年9月开始规划,到10月1日小批量场景上线,到10月13日三机房全量上线;经过一个月的磨合,参加了2017年双11当天从 00:15 %到 23:59的调度,峰值QPS达到百万级别。在日常运行中,集群平均CPU利用率提高3.37 倍, 从原来平均8%到27%;在大促期间,完成造势场景,导购场景和购后场景的错峰资源调度,重要服务资源利用率保持在 30% ,非重要服务资源利用率保持在50%, 99%的重要场景降级率低于2%。同时TPP智能调度系统的"时间录入"功能支持定时活动,如首页红包的提前录入,提前扩容,活动结束收回机器,改变了以前每天需要定时手动分机器的情况。
问题和挑战
TPP智能调度系统要解决的问题为: 如何在机器总数有限的前提下,根据每一个场景上核心服务指标KPI(异常QPS等)和场景所在集群物理层指标KPI(CPU,IO等),最优化每一个场景机器数目,从而使得总体资源利用率最高。
更为直白一点,就是回答以下问题:
1.怎么判断一个集群需要扩容?扩容多少机器?
简单的CPU超水位并不能解决问题,不同场景的判断标准并不一致,有IO密集型的(大量访问igraph)。有CPU密集型的。一个场景可能在CPU使用率不超过30%的情况下,就已经出现大量异常的QPS。load很高,需要增加机器。
2.如何给不同的场景自适应的判断水位?
有的场景30% CPU运行的很好,但是有的场景10%可能就出问题了。
3.如何防止某些实现有问题的场景,不停的出现异常,不停的触发扩容,从而掏空整个集群,相反,实现效率高的场景反而得不到机器,引发不公平。
4.如何用一套算法同时解决日常运行和大促运行的需求
当总的机器数目有限的情况,如何分配不同场景之间的机器,最大化收益,如何实现从某些场景中拿一些资源去补充重要场景的运行。
posted on 2018-06-28 20:09 sichenzhao 阅读(707) 评论(0) 编辑 收藏 举报