阿里巴巴搜索无状态服务的秒级弹性调度

背景

目前阿里巴巴搜索的分布式服务一般都是基于Hippo+Carbon来调度的,包括部署、扩缩容、名字服务注册。如下图:
阿里巴巴搜索无状态服务的秒级弹性调度

其中:

  • Hippo:一层调度(资源调度),解决机器资源分配问题,将一个物理机分成很多资源,根据应用单机不同的资源需求动态创建不同规格的容器(Docker)。一个容器被视作一个Slot。可以参考阿里巴巴搜索混部解密
  • Carbon:二层调度(业务调度),基于各种服务状态决策单机服务是否正常,以决策是否需要自动做机器迁移。同时实现服务的各种运维操作。
  • Drogo:业务管控系统,管理由多个二层调度管理的多个业务集群,并封装成用户操作的UI及API,作为用户及三方服务对接的入口。

Hippo + Carbon 的组合,可以简单理解为Yarn + Slider,或者Cloud Provider + Kubernetes。

这个架构提供了轻量容器的管理、异常机器的自动替换、应用的一键部署,包揽了用户日常的所有运维操作,达到了自动化、自助化的运维效果。但是对于服务容量来说,它不是弹性的。弹性的服务调度,主要解决服务容量自动化扩缩问题。

弹性调度

在目标服务流量上涨时,服务各种指标(例如CPU)上涨,导致服务质量下降。弹性调度自动发现这种情况,并做出扩容请求。相反,在服务流量较低时,弹性调度能够自动缩容,让服务始终保持在一个健康且不浪费的容量状态。

弹性调度在实现上包含以下部分:

  • 指标的透出:无论是服务主动汇报还是被动收集,需要有metric系统持有服务的实时指标。
  • 决策:决策系统是整个弹性调度的大脑,决策算法需要的数据(如metrics)需要各个系统透出,并决策出扩缩容的目标,然后提交给“执行”系统
  • 执行:执行系统真正地去完成决策目标,例如扩缩容,也可能是动态改变单容器资源

对应到搜索中无数据服务的弹性调度,如图:

阿里巴巴搜索无状态服务的秒级弹性调度

原有方案:基于Carbon调度

无论是基于什么调度器来调度应用服务,流程上目前是相差无几的。2017年双11 SP服务是基于Carbon来调度的。整体的结构如下图:

阿里巴巴搜索无状态服务的秒级弹性调度

上图中:

  • 一个服务就是一个Role,服务下有多个instance,本质上是一个Hippo Slot
  • 一个Slot由动态创建的容器、容器中的包(镜像)、进程构成
  • Drogo 引导用户将服务的部署plan提交给Carbon
  • Carbon 对服务做稳定性调度,确保服务的instance健康可服务;一个Carbon可以调度若干个Role
  • Hippo 提供Slot的管理,提供拉起Slot的能力 (拉包、启动进程及守护)
  • Carbon 向Hippo请求及归还Slot
  • Decision 是让整个服务动态化(动态扩缩容)的决策大脑,决策的依据是服务instance的各种指标(主要还是CPU),决策的结果提交给Drogo
  • Kmonitor 收集服务各个Slot的各种指标,并提供统一的数据查询

在整个系统中主要有两个问题:

  • Decision决策扩容时,扩容速度达不到秒级
  • Decision的决策在面临复杂业务服务时,不够智能

第一个问题中,扩容的速度受很多方面的影响,需要针对每个问题进行优化:

阿里巴巴搜索无状态服务的秒级弹性调度

对于第二个问题,我们准备与算法团队合作,让专业的人做专业的事。接下来讲讲围绕Fiber调度器的弹性调度。

新的方案:基于Fiber调度

Fiber是一个同Carbon相同角色的调度器。Fiber服务本身只能解弹性调度执行的问题。基于Fiber,我们优化了整个系统的各个部分。

Fiber

在Fiber调度中,我们整个系统演化成下图:

阿里巴巴搜索无状态服务的秒级弹性调度

在Fiber中增加了一个Slot Buffer,用作调度过程中向Hippo申请分配及归还Slot的一个中间缓冲。前面提到一个Slot从无到有是有代价的,而Slot Buffer的提出,则是让Slot提前准备好,Role的扩容请求只是在Fiber进程内改变下Slot的数据结构归属关系。但是Buffer本质上还是存在浪费资源的嫌疑,占用了整个Hippo集群的公共资源。因此,在Fiber中我们预期的使用方式:

  • 若干个Role共用同一个Buffer,整个系统的调度是努力在多个服务(Role)间取得资源的最高性价比使用。这也是Decision需要升级的地方。
  • 共用同一个Buffer意味着多个服务具有相同的服务启动Plan,服务之间的差异性(一般就是业务数据)需要调度器与应用之间确定一个新的交互协议,也就是服务需要由调度器驱动来热加载业务数据。

针对第二点,Fiber调度器中相应发生了些变化:

  • Slot的构成,在进程之上增加了app data,称为业务数据。进程最好能支持热加载业务数据(热加载更快)。举个例子,一个支持servlet的web容器(如tomat)是一个进程,各个servlet的包就是业务数据,希望在tomcat中可以热加载不同的servlet。这样就可以省掉tomcat的启动时间。
  • Fiber需要在某个Slot从Buffer中重新分配给新的Role时,及时通知更新hot plan。为了实现的容错性,我们实现为类似Carbon中设置Slot启动Plan一样的目标式方式,自然地也需要支持rolling、甚至最小可用度保证等功能。

总结下来可以看出,在Carbon中某个服务的启动/更新是Carbon与Hippo协作的结果;而在Fiber中,还包括了Fiber与服务之间的协作。理想中Fiber的使用方式,举个tomcat加载web .war包的例子:

  • buffer中提前准备好了很多已经运行的tomcat进程,整体上就是很多Slot
  • 业务方A需要部署服务A,提供了自己开发的业务.war包,提交到Fiber中
  • Fiber从Buffer拿出指定数量的Slot,并通知这些Slot上的tomcat进程热加载用户的.war包
  • Decision发现服务A负载较高,发出扩容请求
  • Fiber从Buffer拿出更多Slot,并热加载.war包
  • Buffer容量不足,从Hippo集群补充冷Slot,并准备好Slot (拉包、启动容器、启动tomcat)
  • Decision发现服务A负载过低,发出缩容请求
  • Fiber归还Slot到Buffer,Buffer过大则归还部分Slot回Hippo

Decision

Decision的改进主要是站在决策服务的角度,把服务框架化,能够让算法同学比较容易地参与进来。Decision的主要挑战还是在算法上。在基于Carbon的决策系统中,决策的参照还只是单个服务(Role)的数据。而在基于Fiber的系统中,Decision在决策某个服务扩缩容情况时,还需要参考其他服务的负载情况。例如,在资源紧缺的情况下,Decision需要优先保障高优先级的服务A,那么就需要牺牲低优先级的服务的可服务性,调配资源过来。

应用及成果

今年双11 基于Fiber的弹性调度主要在TPP上应用。双11当天过了0点高峰后全天开启,扩缩容次数超过万次,调度的Role上百个。

TPP单机房所有Role (主要用作TPP场景的物理隔离) 都在一个Fiber调度器中调度。TPP对Fiber中的app data应用得比较轻量,仅仅是一个集群标识,用于某个从Buffer中拿出来的Slot被分配到某个Role时,可以正确地将该Slot同步到名字服务中。Fiber中除掉app data的调度外,最主要的是解决了Slot Buffer的问题。但影响扩容速度的还有很大一部分取决于服务的预热,尤其是TPP这种Java应用。

Fiber目前并没有解决服务预热的问题。所以预热的控制完全交给了TPP自己。目前TPP针对容量大的Role(通常也是优先级高的业务),会定时对Buffer中的Slot做预热,以保障这些Role拿到的Slot可以尽可能快地对外服务。而其他Role则是在Slot交给Role时进行预热。关于TPP的资源隔离,可以参考TPP多租户隔离之资源清理 以及TPP稳定性之场景隔离和多租户

在整个链路中,总结下来,为了提高扩容的响应速度,除了Fiber的实现外,还包括:

  • TPP管控系统中对Buffer Slot的预热
  • TPP Glaucus启动中对预热的支持,以及服务的稳定性,避免新Slot接流量时出现毛刺
  • 为了Decision获得快速的决策效果,metric系统Kmonitor也做了不少优化,将metric的实时性提高到了5s精度
  • Decision 中的算法部分为了贴合TPP各种复杂的场景,例如突增流量,做了不少贴近TPP特点的优化。
  • 算法部分在Decision框架中,由Kmon Watch驱动以5s一次的频率进行决策 (metric精度是5s)

双11当天Decision决策出的扩缩容中,扩容速度整体上可以达到20秒:

  • metric的实时性5秒
  • 分配到进程运行的Slot消耗5秒
  • 预热时间分两种情况

    • 在Buffer中被预热:Slot拿出来后到可提供服务消耗10s
    • 未在Buffer预热:预热时间50s (跟踪样本)

未来

基于Fiber的弹性调度,在2017年的双11与TPP合作上,更多的是一次大胆的尝试,离我们理想中的秒级弹性调度还有很大差距。在未来我们还有很多需要突破的地方,例如:

  • Fiber 对app data的管理形成闭环,从部署到名字服务同步,到物理Role的迁移等有自己的体系,而不是部分依赖于Role的管理
  • Fiber 中对Buffer的管理能够适应更多的需求,例如Buffer Slot的健康、Buffer的资源分级
  • 进一步地能否降低Buffer的大小依赖,让其只是一个Slot缓冲带(较小的size),而不是Slot池
  • Drogo对Fiber的接入及运维包装,让应用接入更容易;在servless方向做尝试
  • Decision 在算法模型方面能够更统一地处理相似服务的决策,摒除掉各种特殊情况的处理
  • SP不存在预热问题,配合运维系统的完善迁移上来实现<10s级的扩容调度
  • TPP在Java服务方面的预热能否发生质变
  • 借助于集团的存储计算分离,也许能支持部分有状态服务

参考

上一篇:双11黑科技大揭秘,护航企业创造商业奇迹


下一篇:屏蔽优酷、土豆等所有视频网站的15秒广告