腾讯云大规模任务调度系统的架构蜕变—王旻—全球架构师峰会2017

0. 导言

下文根据 腾讯云高级技术专家 王旻 在全球架构师峰会2017上的演讲《腾讯云大规模任务调度的架构蜕变》结合自己的理解整理得到。
如果想从事调度系统相关工作，除了要阅读一些经典调度系统论文外还需要了解目前工业界的具体实践。通常云服务公司会针对特定的业务场景对调度系统进行完善和优化。

• 作者简介：王旻（alexmwang） 腾讯云高级技术专家，硕士就读于中科院计算所，有丰富的分布式调度系统理论和实践经验，2015年加入腾讯，负责腾讯云CVM（云主机）和批量计算产品设计和开发，致力于打造高吞吐、高可用的调度系统和计算产品。
• 大纲
  • 聚焦任务调度
  • 任务调度和核心挑战
  • 调度系统架构蜕变
  • 调度系统实现细节
  • 总结心得

1. 聚焦任务调度

• 分布式调度系统需要处理的基础问题：用户之间，优先为哪些用户分配资源；任务之间优先为哪些任务分配资源；任务调度，为任务分配合适的机器资源。
• 任务调度的两个核心角色：task和machine
• 公有云中的任务调度：通常task运行在VM中，多个machine可以组成一个HOST（大型计算机），因此任务调度需要处理的问题就是为VM分配HOST的过程。

2. 任务调度的核心挑战

• 保证调度质量前提下，显著提升调度吞吐率
• 异构性与调度质量：HOST：数据中心维护周期长、集群规模大、不同批次的HOST在软硬件方面存在很大不同；HOST新特性灰度；VM：VM不同实例机型例如不同代次、CPU.FPGA等；VM反亲和性，并发创建打散、镜像缓存；趋势：不是所有的HOST都能够满足VM的需求（硬件约束）；满足VM需求的HOST，其满足程度不同（软件约束）；VM和HOST是调度的主角，异构性更加了二者匹配的复杂程度，必须要考虑约束。
• 可扩展性与吞吐率：HOST：单Region包含数万台物理服务器；VM：云计算需求爆发式增长，潮汐式海量并发购买（CVM的直接用户：爬虫、秒杀抢购等；CVM的间接用户：弹性伸缩、批量计算、竞价实例；规模大，时效性强）；每小时数万台VM购买请求，峰值每分钟上千台VM购买请求。
• 问题：CVM当时的生产吞吐率为100台/分钟，无法满足用户海量购买需求；调度器成为整个系统的性能瓶颈，调度吞吐率不足，处理延迟增加，影响系统的扩展性；用户等待时间长；影响业务时效性和用户体验；

3. 调度系统架构演变

• 单层调度器；两级调度器；共享状态调度架构；
• 典型代表Mesos：通过资源offer和上层调度器通信实现多个计算框架共享集群资源。缺点：每个计算框架没有全局的资源视图，无法保证调度决策全局最优，无法跨调度器抢占；并发度较低，offer-based的本质是不同计算框架之间串行轮询。
• 对于共享状态调度器来说需要解决调度冲突问题，Omega中采用无锁乐观并发的方式进行资源竞争的处理。

4. VSTation调度系统的设计与实现

• 共享状态调度架构
  • 多调度器进行并发调度。调度系统中存在多个调度器，可以进行并发调度，提高了系统并发度；
  • 基于全局资源视图，支持调度算法最优解。每个调度器中都维护一个全量的集群资源信息，可以保证在调度过程中的最优调度；
  • 乐观无锁并发，提交调度结果保证事务性。无锁乐观并发可以有效解决资源竞争的问题，提交调度结果保证事务性则能够保证在调度过程中不被抢占或破坏；
  • 优化调度冲突
• 调度流程
  • 资源同步：背景：调度器中需要保存全量的集群资源信息，需要拉取集群的状态信息，但是HOST的规模庞大，调度器的数量也比较庞大，因此需要设计合理的集群状态更新机制。方案：调度器私有缓存+增量更新，首次启动时进行全量更新，后续进行增量更新。效果：同步数据量平均减少90%以上。
  • 调度决策：背景：如何在保证用户需求的前提下，提高调度质量，避免调度冲突。方案：过滤，首先对于不符合硬件要求的HOST进行过滤；然后根据反亲和性、镜像缓存、资源利用率等纬度进行多维排序；然后对于前K个HOST进行随机打散，防止调度冲突。
  • 提交结果：按序遍历HOST候选列表，模拟扣减资源；提交资源变更事物，包括资源数据和反亲和性记录；事物成功则调度成功同时更新私有缓存中的数据；事物多次失败则发生调度冲突尝试下一台HOST。

5. 其他优化细节

• 消息流转：使用MQ，通过step_config配置流程步骤，根据每一步骤的配置投递到指定消息队列再由消费者进行处理
• 内部回滚：某个步骤失败后，根据step_config配置生成回滚流程，开始回滚，保证流程事务性；
• 消息压缩：兼顾数据压缩比、压缩速率、以及对于资源的额外开销，压缩比为20%。
• 镜像缓存：HOST缓存高频使用镜像，主要是公有镜像；调度策略中，同等条件下优先选择命中镜像缓存的HOST。
• CBS快照回滚：创建使用云盘的CVM，如果CBS后台存在对应快照，会进行秒级快照回滚，避免下载镜像，显著减少创建时间；
• HSOT数万台，调度器数百个；生产吞吐率提升30倍，生产时间下降90%。

6. 心得体会

• 面对相同挑战，不同系统可能会进化成为相近样子，不同文明都独自发明出轮子；
• 异构化是客观挑战，而非主观追求。异构化造成资源的逻辑分化，与云计算初衷相对立，需求方提供明确的灰度和资源供给计划，防止资源不足。
• 评价标准方面：调度处于系统中央，需求方立场不同，对调度器的要求和评价标准也不同。

一些思考

• 腾讯云中主要做的是VM调度，根据用户的具体需求进行调度，这种方式的调度与多维背包问题非常相似。从算法角度来看还有优化的空间，在满足用户需求的前提下尽可能多的提高系统的资源利用率。
• 适当做一些任务调度的优化。虚拟机调度与任务调度有很大的不同，某些运行的虚拟机可能并不是一直在运行，如果从全局来看，虚拟机调度势必会造成一定的资源碎片，集群的实际利用率肯定不够理想。因此是否可以考虑将一些用户需求（例如只是跑一个爬虫任务、跑一个机器学习任务，目前来看需要租赁云平台的客户主要是企业、研究学者和有计算需求的学生，而对于研究来说大部分的计算任务并不需要复杂的软件栈）转化为任务调度，不提供具体的虚拟机，而是提供一个平台。因为对于这些用户来说其关注的是结果，而不是程序运行的位置，这样一方面可以提交集群的资源利用率减少购买服务器带来的成本 ，另外一方面也可以为用户提供更多的便利，同时成本的降低可以适当考虑服务降价以此来吸引更多的用户，扩大市场份额。
• 文中没有针对弹性伸缩进行详细的说明，弹性伸缩也应该是云服务平台最需要考虑的问题。因为对于用户任务来说，很多时候用户自己都无法对其业务量进行准确预估。并且在正常情况下，对负载进行资源预估也是一个很难的挑战，如果支持弹性伸缩调度就可以解决这个问题，用户可以按需进行服务购买。