基于空闲资源的弹性计算实践

项目背景

微信,QQ,空间等用户每天上传了海量图片及视频,图片上传下载时需压缩,视频播放前需转码;AI热潮兴起后,围棋,游戏等对弈数据的生成需要大量的计算能力;计算成本逐步成为不可承受之重。同时由于公司业务的多样化,难以均衡用满各类资源;现网服务器主要承载在线业务,有明显的波峰波谷效应;同时设备购买,裁撤,流转形成了大量的短期空闲设备,公司整体资源利用并不充分,故架平虚拟化团队建设了弹性计算平台,致力于挖掘复用现网的空闲资源,以满足当前对海量计算能力的需求。

关键挑战

复现网的空间资源主要存在2个挑战:

易影响现网在线业务的服务质量,如下图所示:

计算业务可能与在线业务共享cpu执行单元,L1,L2,L3 cache,内存,磁盘,网络等,哪一个环节没控制好,都会影响在线业务的服务质量,比如仅仅L3 cache的冲突,便可能使得计算性能下降60%以上。

挖掘出来的弹性资源本身难以用好,如上图所示,弹性资源非常多样,资源规格不一,可用端口不同等,且资源非常易变,比如资源份额(quota)随在线业务负载变化可能动态调整,影响了在线业务时会立即被清除,业务用好这些资源很难。

技术架构

为解决上述挑战,我们设计了弹性计算技术架构下图所示,其中:

接入层:负责提供服务化接口,包括服务访问,服务配置,镜像管理等;

调度层:通过名字服务屏蔽多样易变资源,实现负载均衡,扩缩容调度,故障调度,错峰调度,灰度变更等能力;

节点层:实现资源隔离,冲突检测,容器管理监控等机制,供上层使用;

下面针对关键挑战详细描述技术解决方案。

避免影响在线业务

本节主要从避免影响在线业务计算容量,计算质量(计算延时),调度延时,故障率等4个方面来分别阐述。

避免在线业务容量受影响

为保障在线业务的容量,首先要做好业务间合理混搭,如下图所示,消耗CPU资源多,但网络带宽少的,尽量混搭到消耗网络带宽多但CPU空闲的,实现混搭关键点在于提炼合理的性能模型,因为现网业务资源需求差异大,服务器硬件资源规格也不统一,性能模型要能抽象这种差异,用最简单的公式表达出性能特点,弹性计算平台首先通过cpu相对模型来识别是否适合混搭,比如万兆服务器每核配比带宽73M/s,A业务1核跑满消耗100M/s,B业务1核跑满消耗40M/s,那A与B适合1:1混搭;在此基础上再通过规格模型来隔离计算业务,比如用C4-8-100,表示分配给容器业务4核CPU,8GB内存,100GB磁盘。分核心时会综合考虑是否通过超线程共享物理核,设置合理的软硬配额,由于当前内核协议栈对网络及磁盘IO的隔离并不理想,我们主要是通过业务性能模型匹配解决网络及磁盘冲突的问题。

在线业务有明显的波峰波谷效应,如下图所示,在波谷时有更多的资源容量可让出供给给计算使用,所以我们也广泛应用了错峰调度,在线业务波谷时,比如0点到6点,让出更多的资源给离线计算型业务使用,比如围棋AI的对局演绎。

避免在线业务计算延时受影响

解决在线业务资源容量保障后,业务计算延时的影响主要来源于指令执行延时: 计算型指令由硬件执行,时间基本固定(温度影响带来的差异可忽略不计); 控制型(主要跳转等)指令主要由业务逻辑本身决定,业务逻辑没优化好时频繁分支预测失败可能造成延时增加; 访存型指令:这块由于cpu cache结构,可能造成延时的波动,如下表所示,一级cache访问延时与内存相差了40倍以上,共享时主要影响的是访存指令的延时;

L1

L2

L3

MEM

2ns

6ns

15ns

80ns

为监控业务计算延时,我们引入了CPI(cycles-per-instruction)监控,简单来说,CPI = CPU周期数/CPU指令数,CPI放映了业务整体的指令执行延时,如下图所示,通过历史数据可提炼合理的CPI标准值及方差值,监控当前实际值,对比模型来判断业务计算延时是否正常。这个值与业务指令模型(主要是访存指令的比例等)及CPU型号相关,故需区分业务模块及CPU型号建模。

CPI延时变化时,反应了真实的指令执行延时增加,但指令延时的增加不一定对业务有实际影响,所以监控的关键点在于怎么确认实际业务影响,解决误报的问题,我们主要是通过三种办法来解决:

对接业务延时监控,但业务延时监控精度可能不一致,且可能无便捷的数据访问接口,故这种方案只能在重点业务上采用;

增加确认值,比如监控cpu cache miss的次数及计算型业务的cpu利用率,利用这些值来反推计算业务是否影响了在线业务质量;

消除监控噪点,比如连续3个点以上延时增加才真正告警处理;

检测到CPI异常时,我们会先通过本地动态调整计算业务CPU配额减轻影响,效果不明显时,才会将计算业务调度至其它服务器,先本地调度有利于于避免瞬时的计算毛刺造成频繁的分布式调度。

避免在线业务调度延时受影响

前面通过资源隔离解决了在线业务计算容量保障问题,通过CPI监控及调度解决了计算质量保障的问题,剩下的便是在线业务调度延时保障了,如下图所示。由于Linux是非抢占内核,默认情况下在线业务获取时间片的时间是无保障的,混搭上计算型业务后,调度延时更不可控,为解决这个问题,我们在内核层面实现了业务优先级调度。

我们通过设置不同docker容器cpu.share的值,将业务优先级传导至内核,指导内核调度,比如默认1024代表普通优先级,4096代表高优先级,3代表低优先级,配置了4096的容器,可抢占配置为3的容器的时间片。应用优先级调度后,在线业务的毛刺(这里为平均延时10倍)点,对比优化前缩减了32.6%,基本与不共享时持平,某场景的优化效果如下表所示。

4096:3

无共享

共享优化前

共享优化后

优化效果

平均延时 ms

1.59

1.65

1.62

1.8%

最大延时 ms

23.85

29.67

23.79

19.8%

毛刺数

19768

31576

21282

32.6%

避免在线业务故障率提升

CPU,网络IO及磁盘IO是可压缩资源,共享时可能使得在线业务延时增加,内存是不可压缩资源,如果冲突,可能导致在线业务或关键系统进程被OOM,而导致业务异常;为解决这个问题,平台与内核结合一起研发了OOM优先级调度,如下图所示:

平台主要解决可预测,持续性的OOM调度,比如平台收到内存不足预警通知时,如果近期内存一直持续上升,会立即调走计算型业务;

内核主要解决不可预测,突发性的OOM调度,比如计算型业务或在线业务收到异常业务请求,导致内存突然暴涨时,Kill掉低优先级的计算型业务容器,并给平台发送事件通知,平台做清理善后。

用好弹性资源

本节主要从筛选业务提供场景式服务,封装资源的多样与易变性及更上层的服务接口三方面阐述。

筛选业务提供场景式服务

由于弹性资源的多样易变,短期难以成为通用的计算平台,故结合实际需求选择了图片压缩,视频转码,AI计算,日志计算4个场景,该4个场景总结起来的共同点是单核流量小于10M/s,且业务平台能容忍节点的变动或失效,如下图所示。

对于无计算状态的业务,比如图片压缩,弹性计算平台提供服务化接口,接管计算节点的扩缩容,对于有状态的计算,比如视频转码切片,AI计算中间数据缓存,日志计算map/reduce模型等,则提供API接口,让业务自行发起扩缩容等调度。

弹性资源由于其特殊性难以保障所有接入业务的计算质量,故我们区分优先级,提供差异化服务,优先保障在线计算型服务质量,如下表所示。

计算优先级

场景举例

资源类型

在线计算型-关键路径

图片上传压缩

资源规格固定,调度少

在线计算型-非关键路径

图片下载压缩/视屏转码

资源规格固定,调度较多

离线计算型

AI/日志计算

资源规格不固定,调度多

对业务屏蔽资源的多样与易变性

现网弹性资源的多样及易变主要来源于3点:

可弹性资源规格不一样,比如有些服务器可复用2核,有的可复用4核;

硬件性能有差异,如下表所示,最好的cpu与最差的cpu性能可差距一倍;

计算业务容器可用配额(quota)会随着在线业务负载变化,甚至被销毁;

CPU

性能

Intel E3-1230v2

1.00

Intel X3440

0.57

Intel E5-2680v4

0.92

...

...

我们采用了CL5名字服务来屏蔽弹性资源的多样易变性,如下图所示,用户只看到服务名字,无须关心背后绑定的资源及权重动态变化,扩缩容,冲突调度,错峰调度,灰度调度时修改资源的绑定,权重调度修改资源的权重,如下表所示:

权重的设置如下表所示,综合考虑资源规格(核心数),资源能力(性能基准值),可用配额(quota)等设置总权重,并记录单核权重作为负载均衡参考。

容器 ID

核数

性能

quota

单核权重

总权重

1

4

1.00

90%

0.90

3.6

2

6

0.92

60%

0.55

3.3

3

8

0.57

70%

0.40

3.2

提供更上层的服务接口

使用好弹性资源,仍然需要业务了解弹性资源本身,并做适配处理,比如和弹性计算平台API集成,协调可用端口等,使用门槛依然较高,为解决这个问题,我们提供了云函数使用接口,如下图所示,类比S3存储,数据以文件为载体,用户上传下载数据无须关心S3分布,容灾,扩容等;计算以函数为载体,用户提交函数后无须了解函数执行背后的资源调度,容灾,扩缩容等,可更专注于业务逻辑创新。从弹性计算平台孵化出了腾讯云-无服务器云函数,欢迎大家试用。

实践的经验教训

在建设弹性计算平台实践过程中,我们有一些经验教训,在这里和大家分享下。

提供机制还是策略?

故事1:A业务利用率扩缩容阈值设置不合理,高峰期保留大量资源没充分利用;B业务设置很合理,高峰期确没资源扩容了。---让用户自身做策略,难以达到整体最优,造成业务间资源利用不均衡,老实人反而容易吃亏; 故事2:平台默认打开自动扩缩容,自动调配资源;A业务对自动扩缩容机制不知情,发起了版本变更,造成现网多版本共存。---平台来做策略,难以了解完整业务流程,可能影响业务的可用性; 在提供机制或策略的选择上我们有过反复,对于平台方,最理想的是将策略控制起来,以达到整体资源调度的最优化,但这里需要一个前提,平台能够收拢所有业务变更入口,如果做不到闭环,只能优先保障业务可用性,平台提供机制,由业务方自身实现策略,平台方通过其它手段,比如定期公布低负载业务,推动业务方主动关注资源高效利用。

扩缩容前先要负载均衡

扩缩容的目标在于将计算型业务维持在合理的负载,以实现质量和成本的均衡,但如果业务负载不均衡,扩缩容难以达到预期的效果,如下图所示:

当业务不均时,同计算业务下不同实例表现为个别实例负载高,以图片压缩为例,出现此场景的一般由于收到大图,此时扩容不能缓解高负载,反而容易导致更多实例空闲;

当资源性能不均时,同计算业务下不同实例表现为部分实例负载高,出现的原因可能由于CPU性能或在线业务负载差异,此时如果以整体平均负载扩容容易导致部分实例高负载,以前50%实例平均负载扩容,容易导致另一部分实例低负载;

最完美的状态是同计算业务下各实例负载波动上下波动不超过5%,此时在扩缩容调度下,整体能保持在较高的负载而不影响服务质量,但这个需要业务和平台方共同努力才能实现:

对业务方来说,要实现用户请求轻重分离,发送给同业务模块的请求,后台消耗的资源需基本一致,以图片压缩为例,需要业务方做好大小图分离;

对平台方来说,需要更综合更动态的权重,为计算实例设置权重时,需综合考虑资源规格,硬件性能基准值,动态可用配额等多方面因素。

重视底层风险及能力

弹性计算依赖底层提供资源隔离,优先级调度等机制,底层的稳定性会影响整个平台的稳定性,且修复代价很大,在弹性计算早期,如下图所示,为了避免平台建设打扰到正常业务运营,规避机房间穿越流量,在容器存储选型上,我们选择了loopback+devicemapper方案,因为此方案无须格式化磁盘。使用之前已了解到社区对此方案的应用存在很多问题,所以打齐了补丁,并采用灰度部署的方式以及时发现并解决问题,在规模不大时,问题并不突出,但上1w台规模,经常现网出现dm设备ioutil 100%, cpu100%等问题,有时需重启才能修复,影响了在线业务的体验。由于loopback+dm机制实现比较复杂,我们对短期内完全修复信心不足,不得已花大代价重新格式化,切换至实现上更简单的XFS+Overlay方案。

从这个例子,我们得到的经验是,底层技术要选择最简单,主流,被大家广为认可的,而不是存侥幸心理选择在当前条件下最容易实现的方案。另外由于底层故障修复代价过大,在规模上线前,最好配备热补丁修复能力,以在底层故障出现时低成本的修复问题。

结束语

感谢大家参加腾讯弹性计算的分享,希望通过此分享能抛砖引玉,能引发一些大家对资源高效利用的思考和实践,当前整个行业大概6%~12%的CPU平均利用率,有较大的提升空间,怎么去提升利用效率,减少对能源的浪费,应该是我们每一位IT从业人员的职责,欢迎大家一起探讨,今后一起提升做到更好。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏龙渊阁测试精英

<转>性能测试浅谈

本文主要针对WEB系统的性能测试。不涉及具体的执行操作,只是本人对性能测试的一点理解和认识。

774
来自专栏HappenLee的技术杂谈

可靠的、可扩展的、可维护的数据系统 ------《Designing Data-Intensive Applications》读书笔记1

作为一个开发者来说,目前绝大多数应用程序都是数据密集型的,而不是计算密集型的。CPU的计算能力不再成为这些应用程序的限制因素,而更加亟待解决的问题是海量的数据、...

972
来自专栏程序员互动联盟

为什么有些网站打开这么慢?

为什么你的网站打开慢? 为什么流量来了,服务器却挂了? 你的用户体验是12306还是天猫双十一? 作为一个专业的IT运维,你能够获得足够多的服务器数据,让你做出...

2858
来自专栏SDNLAB

【8点20】深入了解Facebook 的Altoona数据中心网络

Facebook最近秀了一下Altoona数据中心网络的高度模块化和可扩展性。这个社交网络巨头高调公布了数据中心网络解决方案,因为Facebook想围绕开放计算...

3095
来自专栏SDNLAB

网络可编程与验证

作者简介:唐昊,现就职于华为,从事云网络研发工作。本文所有观点仅代表作者个人观点,与作者现在或者之前所在的公司无关。

892
来自专栏重庆的技术分享区

微服务介绍

原文地址:https://medium.freecodecamp.org/an-introduction-to-microservices-2705e7758f...

1362
来自专栏带你撸出一手好代码

做游戏与web的区别 - 服务器篇【1】

在一间游戏公司的两个部门待过, 前一个部门以做web开发为主,后一个部门做游戏开发,我在两边都是做后端的。

762
来自专栏大史住在大前端

一统江湖的大前端(7)React.js-从开发者到工程师

许多入职前端的开发者,都是从熟练使用框架进行业务逻辑开发而开始的。说到框架,Vue,React,Angular三大框架都已经圈定了自己的用户群,从粉丝的数量...

922
来自专栏SDNLAB

SDN实战团分享(三十九):我的SDN入坑之路

首先介绍一下自己的来路,我是一个纯粹的开发出身,比较熟悉的开发语言是Java和Python。之前的工作也基本上都是和开发相关,对于云计算仅仅懂得“调用调用API...

3736
来自专栏章鱼的慢慢技术路

游戏服务器概述

(1)了解常见查找/排序算法的特点:利用算法来改善性能,胜于通过编译器选项、编程技巧;

1422

扫码关注云+社区