阿里巴巴搜索混部解密

现实与梦想

  阿里集团搜索在线集群非大促部署下CPU利用率日均值不高，除了少部分国际业务流量全天相对比较稳定外，国内在线业务流量全天有明显的波峰波谷现象，集团内以及蚂蚁等的业务大多如此。虽然搜索2015年就基于T4(阿里开源容器技术Pouch前身)实现了如索引构建这种离线任务和在线混部，但是因为当时资源隔离上还不够完善，部分延时特别敏感的业务不敢与之混部，没能充分利用闲置的CPU处理能力。反观离线集群有大量排队的数据预处理、特征抽取、选品、模型训练等任务以很高的负载运行，一些新兴业务因为预算有限申请不到资源而不能快速启动迭代起来，这将严重制约我们探索新业务新方向步伐。
  根据业务特点采购合适的几种机型，保证在线业务SLA的前提下，进行合理的任务编排和调度，将闲置资源交给离线使用来提高集群利用率，解决大促前后大规模扩缩容和新兴业务资源需求是我们的梦想。

让梦想照进现实

  站在内核，Pouch (阿里开源容器技术），网络，服务器研发等巨人的肩膀上的Hippo分布式调度系统，让梦想逐步照进了现实。
  Hippo是搜索调度团队根据搜索、推荐、广告等业务特点从2013年开始打造并逐步完善的一套分布式调度系统，支持了集团内外多个事业部的搜索、推荐、广告等相关业务。   
  搜索在离线混部于2017日5月2日拉开了与YARN（Hadoop资源管理和任务调度框架）混部的序幕，由于搜索集群内存资源是主资源，可以超卖给离线的内存有限，通过优化图搜等任务离线计算框架和Tensorflow机器学习框架性能，在相同内存使用下提升了一倍以上的CPU使用，并于9月28日14:00至9月29日20:00进行了生产离线任务与在线任务的强压力验证，在尽量控制单机水位不超过50%和保证在线业务SLA条件下，如下图所示CPU均值接近50%。

  搜索在离线混部的上线，一方面受益于硬件升级、Pouch容器技术、内核隔离能力的不断完善和提升，另一方面也面临如何实现资源弹性以及上层业务框架和Hippo自身改造升级和性能优化等问题。在这个过程中，我们推动上层业务架构基本实现了随时可通知迁移的能力，业务上线gig:自带负载均衡和降级功能的高可用RPC解决方案，图搜离线海量处理计算框架和TF机器学习框架的性能优化(相同或更少的内存发挥更多的CPU计算能力)，搜索监控数据链路的完善和对外输出应用，如动态扩缩容能力等，支持业务采用镜像容器开发方式解决环境依赖、发布上线和快速部署，Hippo自身镜像化容器化、快速部署、渐进升级、快速建站和更快接入其他资源系统如Sigma（阿里集团caas层）/ECS(阿里云服务器)，新内核版本和Pouch版本回归准入测试和渐进升级等问题。
  2017双11期间，搜索在离线混部实现了全时段无干预无降级稳定运行，提供了搜索双11所有TF模型离线批次训练所需资源，并在2017/11/10晚上23点因为离线训练集群负载过高首次在混部上不间断运行了超过2万core的双11实时训练流程并一直在稳定运行。
  与iDST(阿里巴巴数据科学和技术研究院)合作的智能调度一期在双11不间断运行，进行任务迁移和碎片整理，将分配率保持在90%以上，保障了大粒度资源需求和不同业务资源缩扩容的及时响应，开启了持续微操作调配资源的先河。从11月10日20点至11月12日0点，生产应用实例搬迁超12113次，集群资源申请释放超693万次。往年搜索也是给各个应用分好资源后很少调整，而今年资源调配和调整从未停歇，特别是TPP（个性化推荐平台）利用fiber(hippo的二层调度)动态扩缩技术，实现了自动化资源调配。下图示例，每格标识一台物理机，黄线标识业务容器迁移，蓝点是容器分配，紫点是容器释放，黑色是物理机上既有容器分配也有容器释放。

  下面我们就从Hippo总体架构，业务和资源接入方式，资源分配协议，重要特性和新落地场景Yarn on Hippo等几个方面来讲讲搜索是如何实现在离线混部的。

Hippo架构

  Hippo是典型的master-slave架构，多个master通过ZooKeeper选主做failover和调度结果的持久化，master上主要是根据业务资源需求和资源供给进行资源预估、匹配算分和合理资源分配，资源分配的结果通过心跳发向各个slave作为资源目标，App Master获取资源分配结果后向slave发送业务worker相关描述目标，slave以不断趋向目标的方式异步执行并自动进行QoS调控。周边使用Themis进行资源管控，HippoWeb可视化展示，HippoPE运维升级。

Hippo业务和资源接入

  Hippo通过API-server，libCarbon和SDK三种方式提供业务接入，SDK是最老的接入方式，目前主流方式是通过API-Server，如Yarn实现必要的协议对接，基于libCarbon（Hippo二层调度库）的Drogo管控平台接入相对简单的一维服务（如搜索应用Searchweb）和Suez-ops管控平台接入较复杂的多维服务（如多行多列淘宝、天猫搜索引擎）。Hippo支持自身和业务的镜像化、容器化和服务化，系统服务如DP2(数据分发), Amon(指标收集)等基于二层Carbon服务通过POD模式(类似于Kubernets的POD)组织部署。Hippo on Host是最早支持的对接物理机的资源接入方式，得益于Hippo自身镜像化、容器化，Hippo on Sigma仅两个月个半月便对接联调成功，经过双11大促检验，Hippo on ECS仅两个月即上线支持了ElasticSearch业务的接入和上云对外售卖。

Hippo资源分配协议

  Hippo是目标驱动、异步执行、最终一致、面向业务的分布式调度系统，实现了如Offline协议、不强制回收、保证最小服务数渐进更新、单点故障failover等服务保障。基本的业务流程是App Client向Hippo Master提交App描述，设置App Master的资源需求目标(1)，Hippo Master根据App Master资源目标异步执行，在资源分配后启动App Master(2-3)，App Master再向Hippo Master发送申请App Worker资源的目标(4)，Hippo Master根据App Worker资源目标异步执行进行资源分配，App Master根据返回的已分配资源向对应的Hippo Slave发送启动App Worker请求目标，Hippo Slave再拉起App Worker(5-6)。

Hippo重要特性

Hippo镜像化容器化运行

  Hippo的Master和Slave实现了镜像化和容器化运行，具备了快速部署和渐进升级的能力。

资源隔离

  Hippo Slave上目前主要使用内核提供的cgroup子系统如blkio, cpu, cpuacct, cpuset,intel_rdt, memory, net_cls和特定内核接口实现了对CPU/Memory/Disk/Network等不同层次和维度的资源隔离，Pouch对容器级别的隔离进行了较好的封装，期间隔离也踩过不少坑，更多的隔离手段和更强大的隔离能力仍在不断演进中。

资源预估

   Hippo Master上一个插件管理的资源预估模块，通过对Slave上返回的心跳信息中的每个slot的cpu/memory使用情况汇总，进行了相对简单的app+role级别的资源预估，资源预估的结果将作为资源超卖的主要依据之一，从而引入了类似Resource Guaranteed和Resource Limit的概念，也将影响资源弹性，这块仍有很大的提升空间去做的更加精准。

资源超卖  

Hippo Slave将单机划分成在线和离线两个cgroup大组，在线空闲资源超卖给离线，离线间资源超卖。在线负载低时，离线可以借用在线空闲资源，在线负载上升时，借出去的资源要回来，也就是完全动态自主不断调整。目前主要做了CPU/Memory两个维度的超卖。CPU维度主要是基于水位控制的思想，因为超线程以及其他资源的争抢的影响，水位超过一定限制CPU真实处理能力开始非线性增长，在设置的安全水位下，可以将在线的闲置CPU资源超卖给离线使用，并有最小使用量保证，防止调度饿死宕机。Memory本身是非弹性资源，超卖策略上相对弹性资源CPU会保守一些，借用的闲置资源比例在某个阈值后借用比例会降低，Memory如果不能在约定时间内释放出来将综合考虑优先级、运行时间、Memory使用比例等因素选择某个离线进行用户态kill，并由Kernel根据优先级兜底kill。Hippo Slave上每轮调度会计算离线任务的保底Resource Guaranteed和上限Resource Limit资源并以文件方式通知对应的slot，以便slot对应的业务做出决策。高峰期CPU和Memory在离线分配百分比在115%左右。

• CPU
  
• Memory
  

资源弹性

  通过上述资源预估和资源超卖策略，在Hippo Master上动态更新在线和离线预测的资源使用情况，在Hippo Slave上动态调整离线根组和离线任务的可用CPU和Memory资源上限，基本实现了这2个维度资源弹性利用。

负载调控

  资源超卖的约束条件是有效控制Slave上负载，保证在线业务的SLA，根据不同时期的资源需求设置不同的负载控制目标，甚至单台机器的负载控制目标，基本能实现集群负载的动态调控。

POD

  Hippo支持了类似Kubernetes任务编排方式POD，在容器化环境中建立一个面向应用的“逻辑主机”模型，它可以包含一个或多个相互间紧密联系的容器，多个业务进程容器可共享slot资源，如PID, IPC, NET, USE, NS, UTS和数据等，每个容器也可单独设置不超过slot总资源的资源限制。相比原生的容器接口，POD通过提供更高层次的抽象，简化了应用的部署和管理。Hippo上的一些系统服务已经使用这种模式部署。

ReserveSlot

  应用动态扩缩容和渐进升级的时候通过ReserveSlot实现资源预留和保证机器不漂移，ReserveSlot占用的资源在线服务不可见，可以被系统服务和离线任务使用，申请ReserveSlot的App+role有优先使用权，能从系统服务和离线任务中抢占回来。阿里云售卖的OpenSearch已经使用该功能实现渐进升级过程。

Resource Reserve

  为了给系统服务和离线任务有一定的资源保障，Hippo开发了资源预留功能，这些预留的资源对在线服务不可见，系统服务和离线任务可见，可以进行集群级别的统一配置，也可以针对单台机器配置。
优先级抢占
  SYS/PROD/NONPROD三大优先级，在线可抢占离线，高优先级离线可抢占低优先级离线，NONPROD中最高优先级是NONPROD_PLATFORM平台框架型任务如Yarn，可选择配置不被抢占，有最小资源保障Resource Guaranteed和弹性资源上限Resource Limit。

cpusetMode绑核策略

  Hippo slave上支持不同的绑核策略以应对不同业务需求，并根据需要进行重绑核，以解决绑核碎片的问题。
EXCLUSIVE: 在线独占模式，其他在线应用、离线和系统服务不能用，适用延时特别敏感的应用
RESERVED: 在线预留模式，其他在线应用不能用，离线和系统服务可以用，在线默认使用方式
SHARE: 在线应用之间共享模式，离线和系统服务可以用，非EXCLUSIVE和RESERVED的core都可以调度上去，适合长尾少于一个核或希望有较大CPU弹性的在线应用使用
NONE: 离线和系统服务共享模式，非EXCLUSIVE的core都可以调度上去

自定义算分

  目前可以根据集群情况、资源稀缺性和控制目标等自定义各个资源维度的分数权重，控制在线和离线使用不同的平铺或堆叠的策略。后续和算法同学合作面向终态的实时决策智能调度，以期实现提升资源分配率和申请成功率，降低资源申请等待时间和碎片，优雅支持应用容器资源水平和垂直扩容，相同机器不同应用错峰部署和share绑核，有效控制整机负载和容器负载，动态扩缩容保证业务SLA等目标。

Timeline

  Hippo Master和Slave上的各自分配、释放、调整、提交、管理等事件，通过日志形式保存下来，并通过Kmon(监控指标采集系统)收集到Timeline Server，可方便用户查询、展示、问题排查和离线训练等。

流控

  流控主要是能在一定程度上保护重要业务的资源分配成功率，避免被一瞬间大量涌入的离线业务资源分配请求拖累。Hippo Master在对资源请求进行分组归类、合并打分时，会进行资源请求流量控制。

在离线混部

  在介绍在离线混部之前有必要先讲下在线间混部，搜索在线间混部的诉求是拆除各个大业务线不同机器池子的藩篱，共享机器资源池，让各个在线业务能在机器上混合部署，降低分不出资源的概率，没有这一步先行，在离线混部将会被严重掣肘，搜索在2016年双11基本实现了在线间混部。在选择新的在离线方案时，我们本着对现有系统侵入性小，对当前运行在Hippo上的在离线业务完全透明无感知，类似Mesos支持多种调度框架，可快速迭代和落地的原则，最终选择了业界广泛使用、相对成熟的Yarn计算调度框架进行试点。

Yarn on Hippo

  在离线混部，搜索这边除了之前的构建索引这类离线任务形态外，其他离线任务并不是很多，通过Yarn on Hippo项目，实现了Yarn这样的框架平台型的任务在Hippo上调度，打开了离线任务的巧克力盒子。离线Topia(离线运维平台)通过Hippo-API-Server对接Hippo，向Hippo申请资源，根据返回的分配结果在相应的Hippo Slave上启动NM容器，这些NM(NodeManager)组成Yarn的一个Online Partition，和离线自己的Offline Partition被Yarn统一管理。这样离线任务就可以被调度到在线集群的NM上运行，通过上述资源隔离、预估、超卖、弹性和负载调控，在保证在线业务服务质量的前提下，将闲置资源超卖给Yarn，从而可以通过在线集群承接运行在Yarn上的任务。在大促场景，可以借用离线的机器部署在线任务，从而实现在线和离线之间的资源流转。实现方案上，对于其他框架平台型的任务也能较方便的接入。混部集群Yarn上面运行着“拍立淘”、“图同款”、“实拍保护” 和“OCR图像识别”等业务的离线图像处理任务，运行于Blink上的OLAP和Batch任务，基于Blink的Porsche机器学习平台上的任务。

  当前还有一些问题如Memory DoS Attack，百万级网络PPS引发softirq高，磁盘io控制，coredump限速，memory QoS等，需要和内核，网络，Pouch，业务等团队进一步合作优化，让在线业务SLA有更好的保证，并逐步建立起离线任务的SLA。   
  Hippo目前已支持GPU和FPGA等异构计算设备的调度，有需要的离线任务也可以分时段使用在线释放出来的GPU和FPGA设备。搜索在离线混部基于Sigma/Pouch容器和内核隔离等技术构建，经历双11的检验，在线服务集群和离线计算集群全混部后，必将成为大家值得信赖的基础设施。
  最后，热忱期待和热烈欢迎对整个分布式调度生态感兴趣的同学加盟一起共创更好的系统。可邮件yeliang.job@gmail.com。

职位链接
职位：搜索事业部-分布式系统研发专家-杭州、成都、深圳
职位描述：负责阿里巴巴电商线搜索以及推荐链路的分布式调度系统及DevOPS平台研发，专注于“效率”和“成本“，以系统工程思想推动基础架构升级、打造业界领先的在线服务调度和分布式计算基础架构。
职位要求：

1. 精通c/c++、java、golang其中一种语言，良好的数据结构和算法基础。
2. 具有分布式系统研发经验特别是高性能计算、mesos、yarn、k8s等相关系统的优先。
3. 熟悉linux内核、容器技术、异构计算、网络虚拟化等有加分。
4. 具有良好的系统化思维和大局观，有协同软件、OS、硬件全链路分析和解决问题的能力。具有良好的执行力以及强大的责任心。

附录：
https://github.com/kubernetes/kubernetes
http://mesos.apache.org/
https://hadoop.apache.org/
https://github.com/alibaba/pouch
https://www.aliyun.com/