项目背景
微信，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倍以上，共享时主要影响的是访存指令的延时；
为监控业务计算延时，我们引入了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%，基本与不共享时持平，某场景的优化效果如下表所示。
避免在线业务故障率提升
CPU，网络IO及磁盘IO是可压缩资源，共享时可能使得在线业务延时增加，内存是不可压缩资源，如果冲突，可能导致在线业务或关键系统进程被OOM，而导致业务异常；为解决这个问题，平台与内核结合一起研发了OOM优先级调度，如下图所示：
➡平台主要解决可预测，持续性的OOM调度，比如平台收到内存不足预警通知时，如果近期内存一直持续上升，会立即调走计算型业务；
➡内核主要解决不可预测，突发性的OOM调度，比如计算型业务或在线业务收到异常业务请求，导致内存突然暴涨时，Kill掉低优先级的计算型业务容器，并给平台发送事件通知，平台做清理善后。
用好弹性资源
本节主要从筛选业务提供场景式服务，封装资源的多样与易变性及更上层的服务接口三方面阐述。
筛选业务提供场景式服务
由于弹性资源的多样易变，短期难以成为通用的计算平台，故结合实际需求选择了图片压缩，视频转码，AI计算，日志计算4个场景，该4个场景总结起来的共同点是单核流量小于10M/s，且业务平台能容忍节点的变动或失效，如下图所示。
对于无计算状态的业务，比如图片压缩，弹性计算平台提供服务化接口，接管计算节点的扩缩容，对于有状态的计算，比如视频转码切片，AI计算中间数据缓存，日志计算map/reduce模型等，则提供API接口，让业务自行发起扩缩容等调度。
弹性资源由于其特殊性难以保障所有接入业务的计算质量，故我们区分优先级，提供差异化服务，优先保障在线计算型服务质量，如下表所示。
对业务屏蔽资源的多样与易变性
现网弹性资源的多样及易变主要来源于3点：
➡可弹性资源规格不一样，比如有些服务器可复用2核，有的可复用4核；
➡ 硬件性能有差异，如下表所示，最好的cpu与最差的cpu性能可差距一倍；
➡计算业务容器可用配额（quota）会随着在线业务负载变化，甚至被销毁；
我们采用了CL5名字服务来屏蔽弹性资源的多样易变性，如下图所示，用户只看到服务名字，无须关心背后绑定的资源及权重动态变化，扩缩容，冲突调度，错峰调度，灰度调度时修改资源的绑定，权重调度修改资源的权重，如下表所示：
权重的设置如下表所示，综合考虑资源规格（核心数），资源能力（性能基准值），可用配额（quota）等设置总权重，并记录单核权重作为负载均衡参考。
提供更上层的服务接口
使用好弹性资源，仍然需要业务了解弹性资源本身，并做适配处理，比如和弹性计算平台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从业人员的职责，欢迎大家一起探讨，今后一起提升做到更好。
来源：微信架构师
地址：https://mp.weixin.qq.com/s/c-QGtlSF1aTgiqW-euPuPQ
原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/257151.html