弹性伸缩具有应突发、省成本、自动化的业务价值。平台侧将各业务零散、闲置资源进行整合,形成一个大规模资源池,通过弹性调度、库存管控技术在公司运营成本和业务体感中寻求较好的平衡。
本文将介绍美团弹性伸缩系统落地过程中面临的技术挑战、推广以及在运营层面的一些思考。在美团这种多样化的业务场景中落地弹性伸缩,与业界公有云、自建私有云的公司相比,既有共性又有自己的特点,希望能为大家提供新的思路或者启发。
稳定、高效、可靠的基础设施是互联网企业应对业务高峰流量的底层基石。作为美团统一的基础技术平台,基础技术部一直致力于通过业内前沿技术的落地,保障公司内部所有业务在线生产系统所依赖的基础技术平台能稳定、安全、低成本、可持续地运行与发展。
弹性伸缩系统是基于Docker开发的自动弹性伸缩平台,在美团经历了多年的发展。
早在2016年,美团就在线上环境中尝试使用容器环境,推出了基于OpenStack的容器集群平台Hulk 1.0。随着容器的落地,弹性伸缩1.0版本应运而生,它解决了扩容实例慢、扩容上线慢、资源回收慢、计算资源冗余等问题。
结合前两年的探索和实践以及业界相关领域技术的成熟度,2018年至今,我们对容器集群平台进行了一次自底向上的的整体升级,也就是现在的Hulk 2.0平台。在底层,Hulk 2.0建设了自研的操作系统、容器引擎,并将OpenStack替换成了容器编排的事实标准Kubernetes;在上层弹性伸缩系统PaaS层面,推出了弹性伸缩系统2.0,解决了弹性伸缩1.0实践过程中面临的很多业务痛点,包括:
弹性伸缩1.0架构
我们首先看一下,产品演进路线和弹性伸缩1.0架构图。
自左向右、自上而下进行模块介绍:
弹性伸缩2.0架构
弹性伸缩系统2.0主要在以下四个方面进行了架构演进:
1)调度系统-替换:将OpenStack替换成了容器编排的事实标准Kubernetes,并且在常驻资源池的基础上,新托管了专区资源池以及应急资源池。 2)单体服务-微服务化。 a. API-Server:弹性伸缩-网关服务。 b. Engine:弹性伸缩-引擎,负责各服务实例扩缩的发起、终止,主从架构模式,使用Zookeeper进行Master选举,从是热备。 c. Metrics-Server、Metrics-Data:【新增】弹性伸缩指标服务,负责Raptor、OCTO等数据源的采集&聚合。 d. Resource-Server:【新增】弹性伸缩-库存管控服务,为各服务自动扩缩的资源需求保驾护航。 3)服务画像-数据平台化:Portrait-Server、Portrait-Data,弹性伸缩系统内部自建的服务画像数据体系。 4)可观测性:【新增】Alarm、Scanner,负责弹性伸缩的监控告警、运营治理等工作。
在介绍前,有必要重点说明下2018年这个时间节点。如前言中所述,2018年以前弹性伸缩1.0这个PaaS平台存在的一些问题,以及整体Hulk 1.0容器平台落地过程中遇到的一些问题,在产品战略上我们提出了Hulk 2.0的计划,它涵盖调度系统、容器引擎、内核隔离增强、弹性伸缩增强等领域;在战术上,遵循自顶向下的设计原则、自底向上的实施原则。
在2018年4月前比较长的一段时间内,Hulk容器平台的研发主要聚焦在底层系统的升级上(优先打通Hulk 2.0容器编排Kubernetes、容器创建/销毁的流程),在弹性伸缩PaaS平台的投入约为0.5个人力,增量业务停止接入,存量业务继续维护。在Hulk 2.0底层系统基本成型后,容器平台团队一方面开始着手将未接入弹性伸缩平台的Hulk 1.0容器平滑迁移至Hulk 2.0容器。另外一方面,开始着手组建人力建设可对接Hulk 2.0容器平台编排能力的弹性伸缩2.0系统,为已接入弹性伸缩平台的Hulk 1.0容器平滑迁移过来做技术储备。
在弹性伸缩2.0系统的演进过程中遵循“技术”、“推广”、“运营”的演进策略。我们可以先来看下在搭建平台的过程中面临的一些挑战以及解法。
结合当下弹性伸缩系统面临的处境,并对业界弹性伸缩产品做过一番调研后,在平台搭建上确定了如下三期目标:
在上述三期目标基本落地后,弹性伸缩2.0系统基本可以跑起来,处于一个不比弹性伸缩1.0系统差的阶段,接下来基于过往运维问题汇总以及业务访谈诉求,在后端架构上做了几个比较大的升级。
2.1.1 弹性调度
正如前言所述,和大部分弹性伸缩产品类似,早期启用弹性伸缩的过程如下:
在美团的落地场景中,我们遇到如下问题:
基于以上种种原因,我们拉通了各PaaS方,梳理了流量分组、弹性分组、发布分组之间的关系,以保证弹性伸缩在美团私有云中的扩容准确性。
同地域访问的方式比较有代表性,这里对同地域调用&未SET化、同地域调用&SET化的业务集群自动扩容方式进行展开说明,其他组合可依次类推。
2.1.2 库存管控
弹性伸缩系统如果只是单纯地提供一个IaaS资源的自动供给能力,这件事情并不难。然而实际情况下,弹性伸缩系统在落地过程中需要解决资源上面临的问题。
针对业务的这个关注点,目前业界公有云厂商的做法基本是不做SLA承诺或者说很难做到SLA承诺,因此也自然不会面临到组织的关注点问题。具体来说,在美团主要是通过以下几个措施来解决。
2.1.2.1 多租户管理
平台给到每个业务线的资源并非无限,会给每个业务集群的弹性分组,设置一个默认的资源Quota。如果业务觉得默认Quota不够,可通过工单的方式进行一轮评估调整(从实践来看,绝大部分情况无需调整)。针对这个资源Quota,平台侧承诺的SLA:99.9%的扩容成功率。
这里会有个问题:是不是给业务Quota后,这部分资源就直接划分给这个业务独占了?答案:不是的。这只是一个逻辑上的划分,资源本身是各业务混用的,平台需控制资源闲置率,本身会做些“超售”,但过程中需解决好“超售”可能面临的问题,这就是水位线监管机制。
2.1.2.2 常态-资源保障
常规-资源保障,指的是平日、小节假日下的资源供给机制,这部分的资源来源于常驻资源池(架构图所示),平台会对已接入平台的所有服务,进行小时粒度的资源重预估。具体示意图如下:
新增/更新服务的伸缩任务、伸缩规则时,会对当前变更对整体资源池水位的影响进行预估,如果在叠加时间点将超过整体资源池的水位,平台会拒绝执行变更操作,并给到用户和平台管理员消息推送,用户可通过工单方式进行资源请求说明(需保障存量服务的资源可靠性)。
2.1.2.3 应急-资源保障
常驻资源池的大小是有限的,应急-资源保障指的是业务拉新、大促、大节假日等非常态的资源供给机制,这部分的资源来源于常驻资源池+应急资源池(如架构图所示)。应急资源池简单来说就是,我们按用量计费模式购买的公有云资源,这是一种更灵活的资源池模式(具备一定的租约)。在此基础上,我们构建了更省成本的混合云弹性调度能力(在此之前仅在私有云的常驻资源池调度)。
以下示意图展示的是一个服务在大促期间(维持T天)需要208台容器实例,其中8台为常态下的资源诉求,200台为应急资源诉求。
大促前:
大促后(T+1):
T+1天后,这些应急资源池将被腾退回公有云厂商,公司无需为后续继续付费。多业务都应急的场景其实会偏复杂些;特殊情况下,需要采用重调度、治理。
在2020年之前,是弹性伸缩2.0系统的练内功阶段,并未大规模向业务推广Hulk 2.0弹性伸缩系统,主要原因归结为两方面:
截止2020年年底,共接入了约500个服务。这里主要以弹性伸缩1.0系统中平滑迁移过来的服务,同部门的服务(Eat Your Own Dog Food)为主。
在2020年-2021年,是弹性伸缩2.0系统的规模化阶段。
经过以上这些工作,我们80%+的服务接入了弹性,覆盖了公司90%+的业务线。回到那句话,如果弹性伸缩系统只是单纯地提供一个IaaS资源的自动供给能力,这件事情并不难,而我们的定位是PaaS平台。
这部分主要介绍向业务交付弹性容器实例后,碰到的三类典型问题:配置、启动、性能。这些问题大部分不是弹性伸缩2.0这个PaaS平台本身领域内可直接闭环解决的事项,这往往取决于各PaaS平台是否已全量标准化、业务自身逻辑、以及基础设施层性能等因素,催化我们多去做这一步的原因只有一个:弹性扩容出的实例只有很好的帮助业务分担负载,才可真正帮助业务解决问题。
2.3.1 配置问题
2.3.2 启动问题
启动问题,大部分解决的是容器的这种开箱即用方式所面临的问题,而非过往的采用先申请机器、再在这上面发布代码包的方式。而且这里面会经常要面临着业务的质疑,为什么我手动发布的时候不存在这个问题,采用弹性扩容就出现了?
2.3.3 性能问题
生产环境中,业务容器的性能问题其实是比较复杂的,可能涉及到重IO容器影响、宿主机Load过高、多个容器突发占用CPU过高导致影响某个业务容器问题。相对于不使用弹性时囤积算力的稳定场景,弹性扩缩容场景中,因对资源的频繁调配会更容易遇到资源性能的问题。为了保障使用效果,Hulk项目组主要从三个角度对性能问题完整解决:
业务场景:有着明显的“七节二月”特性,就流量而言周末是工作日的1.5倍左右,节假日流量是周末的3~5倍左右。服务机器基本上是按照节假日的流量部署,平时机器使用率很低。
如何使用弹性伸缩:
接入效果:业务侧平均节约成本20.4%。
业务场景:配送是外卖服务的下游,具有明显的午高峰特性。
如何使用弹性伸缩:
接入效果:接入弹性之前,为应对午高峰流量,该服务需要常驻机器2420台;接入弹性之后常驻机器释放了365台,高峰期弹性机器占总机器数的15%。
业务场景:风控反爬服务,是公司业务的服务安全盾和数据安全盾。目前,已有上百个业务方接入反爬服务,每天处理百亿级重点流量,为各大业务方防控恶意流量,保障业务稳定、数据安全及统计数据的正确性。风控反爬相关服务,活动节假日期间,服务负载会受业务影响增长明显,需要活动节假日期间补充大量资源。
如何使用弹性策略:活动节假日期间,风控反爬业务,申请弹性应急资源(采购公有云宿主机),提升活动期间弹性扩容总量,提升服务稳定性。活动节假日过后,缩容应急资源,腾退公有云宿主机,节约资源。
接入效果:为风控业务支持了5次大规模线上活动,基于弹性伸缩的应急-资源保障机制,累计提供公有云资源700+台高配容器,约7000+CPU资源。
业务场景:餐饮SaaS采取“火车模型发布的模式”交付功能,需要为70+服务申请专用的灰度链路机器,用于云端功能的灰度验证。但机器每月仅需使用2~3个工作日,一直持有机器,造成机器资源浪费;最初团队是通过每月定时手动申请、释放机器来解决,耗费较大人力,一定程度上影响到了研发的效率。
如何使用弹性策略:
接入效果
随着弹性伸缩系统2.0在美团的规模化落地,我们未来会从稳定性、易用性、业务解决方案、新技术探索四个方面去做深、做广:
(1)稳定性:基础服务的稳定性是一切的基石,而这往往是不少研发同学容易忽视的一点,研发同学需“在晴天时修屋顶”。
(2)易用性
(3)业务解决方案
(4)新技术探索:借鉴Knative、Keda的设计理念,为云原生业务场景的弹性伸缩做技术储备。
涂扬,现任基础架构部弹性策略团队负责人。
美团基础架构团队诚招高级、资深技术专家,Base北京、上海。我们致力于建设美团全公司统一的高并发高性能分布式基础架构平台,涵盖数据库、分布式监控、服务治理、高性能通信、消息中间件、基础存储、容器化、集群调度等基础架构主要的技术领域。欢迎有兴趣的同学投送简历至:edp.itu.zhaopin@meituan.com。