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

项目背景

微信,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 条评论
登录 后参与评论

相关文章

来自专栏CSDN技术头条

微服务的鉴定与思考

微服务有且仅有一种非常专项的功能,通过远程API来提供系统其余功能。举个例子:试想一下仓库的管理系统,这样的系统中微服务可能提供的一些功能有: 接收库存 计算新...

1886
来自专栏华章科技

不懂这37个数据中心术语,怎么混数据圈饭局!

在今天的IT行业佼佼者中,“现代数据中心”这个概念得到了越来越多的重视。当然,它受到如此多的关注也是理所应当的。云计算,闪存存储,软件网络,容器以及大量的编排和...

622
来自专栏原创

高并发大容量NoSQL解决方案探索

1068
来自专栏CSDN技术头条

世上没有完美的架构

微服务架构的技术体系、社区目前已经越来越成熟。在最初系统架构的搭建,或者当现有架构已到达瓶颈需要进行架构演进时,很多架构师、运维工程师会考虑是否需要搭建微服务架...

1287
来自专栏大数据技术学习

0基础怎么学习大数据?成为大数据构架师入门到精通的学习路线

近几年我们经常听到AI人工智能、大数据、机械进修等等,似乎良多企业都已经涉足这些行业停止研究,那么想体味、想进入这些行业我们应该怎样做呢?科多大数据带你来进修一...

1534
来自专栏北京马哥教育

游族网络运维总监:如何运维千台以上游戏云服务器

? 作者:李志勇 来源: http://www.csdn.net/article/2016-03-21/2826611 偶然在网上看到游族网络运维总监李志勇先...

3618
来自专栏Java职业技术分享

分布式系统关注点——初识「高可用」

咳咳,从这篇开始,正式拉开分布式系统关注点中,我认为第二重要的内容 —— 「高可用」。

480
来自专栏AI研习社

如何在微服务架构下构建高效的运维管理平台?

黎明带领团队自主研发了全栈 DevOps 运维管理平台—EasyOps,是目前行业领先的智能化运维管理平台。作为前腾讯运维研发负责人,黎明主导了多个运维系统研发...

2849
来自专栏Java进阶干货

三思!大规模MySQL运维陷阱之基于MyCat的伪分布式架构

分布式数据库,已经进入了全面快速发展阶段,这种发展,是与时俱进的,与人的需求是分不开的,因为现在信息时代的高速发展,导致数据量和交易量越来越大。这种现象首先导致...

1051
来自专栏云计算

你需要了解的37个现代数据中心术语

让我们深入研究一下最重要的现代数据中心术语中37个术语和定义的汇编清单。

4626

扫码关注云+社区