一种基于Lasso回归的微服务性能建模方法
2020-12-25郑杰生谢彬瑜吴广财
郑杰生,谢彬瑜,吴广财,陈 非,花 磊
(1.广东电力信息科技有限公司,广东 广州 510000;2.苏州博纳讯动软件有限公司,江苏 苏州 215000)
0 引 言
近年来,微服务越来越多地与云计算技术相结合以构建弹性可伸缩的基于互联网的软件应用,大规模微服务通常部署在共享物理资源的云计算平台,广泛应用在众多领域[6]。云计算通过互联网方便访问共享计算、存储、网络等物理资源,云计算数据中心的物理服务器由云服务提供商管理及维护,以虚拟机或容器的形式将共享物理资源提供给用户使用,云计算用户仅支付实际使用费用,而无需维护物理设备。
当前云计算平台通常由虚拟机和容器等两个虚拟化层组成。容器是轻量级可独立部署执行的软件包,包含运行容器所需的依赖组件及运行环境,可以直接部署在主机或虚拟机上运行。基于容器的虚拟化技术可以在多个容器中实例化微服务,使用多个内核并行运行容器,以增加服务器的资源利用率,这样单个操作系统上可以运行多个隔离的微服务实例[7]。例如,大规模容器调度系统Kubernetes使用配置文件通过Pod对容器进行分组及资源约束,以共享物理或虚拟资源,调度和协调容器运行。但是由于物理设备配置、虚拟机类型、运行应用的差别,在云计算环境下,实际部署应用的性能与预期存在显著差异,因此难以为所有云应用创建通用的性能模型。
外部负载是影响交互式应用性能的关键因素,当并发数量超过某个数值后,服务质量会显著下降,通常表现为用户请求的响应时间超出服务提供商所定义的阈值。该文将微服务容量定义为在不违反服务质量约束的条件下,微服务可以处理的最大请求速率。使用微服务容量指标可有效检测应用性能瓶颈,实现自动化、智能化、精准化的应用容量规划。因此,使用能满足服务质量约束的负载并发量表示服务的容量,该值通过对应用或服务进行压力测试来确定,即不断增加负载直到违反服务质量约束,而后计算此时的并发数量。
应用容量规划是实现云计算的动态灵活伸缩,提升云应用的服务承载能力,实现高效资源利用的关键技术之一[8]。性能瓶颈检测用于分析造成应用性能衰减的关键微服务,通过水平扩展该微服务实例以提高应用的整体性能。应用容量规划是建立在性能瓶颈检测基础上,预测负载变化[9],制定应用资源分配计划,以实现自动化的容量规划。性能建模是准确发现应用的性能瓶颈,有效进行容量规划的关键,而现有技术难以对不同类型的虚拟机资源和部署环境进行性能评估。
文献[10]提出了面向多层应用的瓶颈检测和性能预测的分析模型。文献[11]使用容量分析的方法识别潜在的资源瓶颈,并提出了性能优化的建议。Root系统[12]自动检测部署在PaaS云计算环境中的Web应用性能异常。但现有方法多关注于层次较少、部署环境单一、规模受限的应用,且需要人工参与解释、分析结果,难以应对环境复杂的云计算环境下,规模巨大、类型多样的微服务应用。
为了应对云计算环境下微服务瓶颈检测和容量规划所面临的挑战,该文提出一种基于Lasso回归的微服务性能建模方法。首先将目标微服务放置在独立的Docker容器中,而后使用Istio为微服务模拟生成外部负载并搜集其性能监测数据,进而基于Lasso回归建立资源与性能的关联模型以评估微服务的请求处理能力,从而实现微服务的细粒度灵活水平扩展。
1 建模方法
1.1 基于Istio的微服务性能测试
Docker容器技术将目标微服务与依赖的系统资源或服务进行隔离,以便对目标服务进行有针对性的测试与分析[13]。Istio为微服务开发与管理提供服务网格基础平台,能够高效运行分布式微服务应用,并提供了统一的连接、监测和保护微服务的方式,以降低微服务部署的复杂性以减轻开发团队的工作量。该文将目标微服务实例放置在Docker容器环境中,通过Istio的服务代理机制使其与依赖的微服务隔离,而无需对原微服务做改动。Istio以边车模式为每个微服务部署服务代理,微服务接收对原微服务的API调用请求并响应以评估该微服务的性能。服务代理的URL作为环境变量形式传递给微服务,以保证能够截获每个请求并返回响应。
2016年,国务院总理李克强在政府工作报告中提出,“鼓励企业开展个性化定制、柔性化生产,培育精益求精的工匠精神”。[1]由此,“工匠精神”首次被政府提出,同时上升到国家发展层面,迅速成为舆论和社会争相关注的热点,并作为各行业严谨精确、锲而不舍的代名词。
该文通过Kubernetes将具有服务代理的微服务Docker容器部署在服务器集群中,线性增加外部负载,收集资源利用率和性能指标。当检测到性能度量违反服务质量约束时,将收集的数据持久化存储到数据库中,作为目标微服务的容量。在不同部署配置下,重复以上负载生成和数据搜集过程,不断修改容器配置对模型进行训练,直到生成的性能模型的精度不再明显提高为止。
1.2 基于Lasso回归的微服务性能建模
该文使用负载测试产生的Docker容器中微服务的监测数据,基于Lasso回归模型[14]刻画微服务容量与资源使用(虚拟CPU、内存、网络等度量)的关联关系。与其他回归模型相比,如支持向量回归(SVR)、简单线性回归、多项式回归,Lasso回归模型具有更高的准确性,并且能够在更短的时间内拟合收敛。该文基于该模型预测在特定部署配置条件下目标微服务的容量,判断处理特定数量请求所需的微服务副本数量。模型的输入为多维资源度量,输出为微服务容量,基于Lasso回归的性能建模过程具体如下:
约束条件的参数c通过广义交叉验证法来选择,其形式为:
2 建模工具
该文根据以上性能建模方法,设计并实现了性能建模工具,用来部署基于Kubernetes的微服务集群、生成工作负载、监测运行状态、建模微服务性能及实现微服务容量规划。
如图1所示,建模工具采用微服务架构,由配置及部署、容量规划、运行监管、负载生成、Docker容器等模块构成,通过Restful API进行模块间通信,将数据存储在MySQL数据库以供查询、分析。
图1 建模工具系统架构
配置及部署模块使用Yaml文件配置并构建微服务应用,将微服务包装在Docker容器中进行部署,并创建相应的Docker容器作为Docker容器;配置分配给每个微服务的副本数量,以及CPU和内存的物理资源限制,并部署Kubernetes集群。容量规划模块根据测试阶段收集的监测数据使用拟合的Lasso回归构建微服务的性能模型,基于Lasso回归模型刻画部署特征、资源消耗和性能之间的关联以估计在一定部署配置条件下的微服务容量;提供Restful API以设置配置参数,用户通过调用API可以启动测试,查看拟合的性能模型、估计的微服务容量、微服务副本数量。
运行监管模块使用监管代理监测每个微服务占用的物理资源,并将监测数据存储在MySQL数据库中;将Yaml文件、微服务名称和API作为配置信息以创建Docker容器。负载生成模块在Kubernetes集群上部署微服务后,使用JMeter生成线性增长的负载,用以测试在特定部署配置条件下的微服务。Docker容器模块利用Docker容器以隔离每个微服务,使用Istio为每个容器创建服务代理以接受请求并返回响应,并启动监管代理线程对Docker容器进行监测和管理。
用户通过Restful API设定目标应用及参数,如果应用包含多个微服务,则使用Docker容器包装每个微服务,并自动生成测试负载;而后,对于每个Docker容器中的微服务进行性能建模;最后,根据性能建模得到各微服务的容量,给出应用中各微服务运行实例数量的建议。
具体执行步骤包括:建模工具运行部署与配置模块将Kubernetes和Istio部署到云计算平台,设置Pod副本数量范围及资源约束条件;启动包装微服务的Docker容器镜像,并在容器启动时为微服务启动服务代理;负载生成模块产生线性增加的负载,监管代理监测容器的资源及性能度量,当检测到违反服务质量约束时,记录微服务的负载、性能、容量等监测数据;建立以部署配置及环境为输入,以容量为输出的基于Lasso回归的性能模型;在特定配置下预测微服务容量,根据当前微服务负载状况,规划各微服务副本的数量。
3 实验评价
3.1 实验环境
实验部署环境包括4台物理主机,其中1台为管理节点以部署建模工具的管理端程序,另外3台为工作节点以部署微服务Docker容器和建模工具模块。物理主机配置为Intel Xeon E5-2620 CPU,16 GB RAM内存,500 GB磁盘,100 Mbps网络连接,操作系统为CentOS 6.5,容器为Docker 1.13,容器编排为Yaml 1.11.1,容器管理系统为Kubernetes 1.11.0。
在目标应用方面,该文使用典型微服务架构应用MediaService[15],选取其中4个典型微服务评价方法及工具的有效性。其中,VideoStreaming为I/O密集型微服务,用以从后端NFS中读取流媒体格式的视频数据;Rating为数据库访问型微服务,连接到后端数据库MySQL,用以查询电影信息;ComposePage为Web访问型微服务,用户接受用户请求并返回相应字符串;php-fpm为服务网关微服务,用以接收用户请求,并将其分派给后端微服务,在收到所有微服务的响应后,组合响应信息并汇总返回结果。
在负载生成方面,实验根据每种微服务类型处理请求的资源利用情况,确定不同的负载生成率,负载数量引起资源利用率变化设定为每分钟约为0.05%。负载测试从单个请求开始,请求数量呈线性增加,VideoStreaming每分钟增加12次访问,Rating每分钟增加24次访问,ComposePage每分钟增加36次访问,Php-fpm每分钟增加48次访问。
3.2 实验结果
在容量预测准确性方面,该文使用平均绝对百分比误差(MAPE)将实际监测与模型预测的微服务容量进行比较,实验中VideoStreaming,Rating,Compose Page和Php-fpm的误差分别为2.71%,9.28%,9.74%和6.48%,实验结果表明建模工具具有较高的预测准确性。
在应用性能保障方面,该文对于是否使用建模工具进行微服务水平扩展,应用的整体性能变化进行对比。性能指标使用90%请求响应时间,即在给定时间间隔内,处理90%请求的响应时间。
如图2所示,实验首先未使用建模工具进行容量规划,以整个应用为管理单元,设置副本数量为3,监测应用性能变化。而后,使用建模工具进行容量规划,以微服务为管理单元,微服务副本数量根据微服务容量与负载数量动态变化,监测应用性能变化。
图2 性能比较
实验结果表明,负载数量在900以下时,由于应用未达到性能瓶颈,二者的响应时间差别不大。当负载数量大于1 050时,对于未使用建模工具进行容量规划的应用,由于在Rating微服务出现了性能瓶颈,应用的响应时间呈指数级增加。对于使用建模工具进行容量规划的应用,由于能够根据负载数量动态扩展Rating微服务实例数量,响应时间保持平稳,并未出现大幅上升。
4 结束语
微服务技术将应用划分为多个功能独立的微服务,并使用与语言和平台无关的API实现微服务间的通信,近年来在业界得到广泛应用。微服务的资源使用取决于其所实现的功能和外部负载,负载突增会造成应用违反服务质量约束,因此需要限制每个微服务的最大访问速率以保证其服务质量。然而,在云计算环境下,部署环境与应用种类的多样性与复杂性造成了难以准确评估每个微服务的服务能力。为了应对该挑战,提出一种基于Lasso回归的微服务应用性能建模方法。
该方法首先将目标微服务放置在Docker容器环境,而后生成外部负载并搜集微服务的性能及资源的监测数据,基于Lasso回归模型建立配置、资源与性能之间的关联关系,进而评估每个微服务的容量以实现细粒度灵活扩展。基于以上方法,实现了原型系统,基于云计算平台使用典型微服务进行验证,实验结果表明该方法具有较低的预测误差,能够有效保证系统性能。