技术分享 | 多测试环境的动态伸缩实践

本文将从敏捷研发团队的环境需求与痛点出发,分享如何基于云构建可弹性伸缩的自动化生成式多测试环境;更在经济效益层面,提供了多种成本优化方案,以满足研发团队低成本、高效益的多测试环境运行目标。

一、当前遇到的环境问题

初期,根据实际研发需要,LigaAI主要应用了以下四套环境:
技术分享 | 多测试环境的动态伸缩实践_第1张图片

  • Dev环境是开发环境,专供前/后端开发人员进行功能开发自测、联调等;
  • Sit环境为测试环境,供测试成员进行迭代功能验收;
  • Pre环境为预发布环境,主要承担整体测试、回归测试等;
  • 最后,Prod环境为生产环境。

随着团队规模不断扩大、业务组划分走向清晰,以及微服务拆分愈发精细,环境资源开始逐步缩紧,资源紧张带来的冲突频繁制约着团队发展。

  • 对迭代有风险的复杂需求需要剥离迭代,进行单独测试;
  • 开发人员需要不同的Dev环境进行联调;
  • 迭代小组的迭代进度各异,需要分批提测;
  • 紧急Hotfix急需测试,但环境已被占用;
  • 需要进行系统压测,却缺乏一套压测环境;

为缓解环境资源紧张问题,LigaAI对原有的Dev环境和Sit环境做了如下扩展。

技术分享 | 多测试环境的动态伸缩实践_第2张图片

如此虽一定程度上满足了不断增加的环境需求,但不可避免地导致了其他问题。因此,针对以下环境需求痛点,LigaAI着手搭建了一套高弹性、可伸缩的测试环境。

技术分享 | 多测试环境的动态伸缩实践_第3张图片

二、测试环境的改造目标

开始正式改造前,LigaAI结合研发流程和环境需求,对目标测试环境提出了几点要求:

  • 多环境:针对不同的测试场景,可以提供不同的测试环境。
  • 互相区隔:数据、配置信息和应用访问在不同环境之间要相互隔离。
  • 高效稳定:环境要保持稳定且高效地运转,不能影响正常迭代进度。
  • 低成本:产生尽可能较低的额外成本,任何时期都要将资源用在刀刃上。
  • 可复用:针对特殊需求可快速扩展新环境;简化测试环境维护,让团队聚焦研发与测试。

第一步:测试环境的标准化改造

Step 1:搭建底层基础设施

围绕弹性、扩展和部署等关键词,LigaAI最终选用Amazon EKS作为环境伸缩的底层基础设施。

Amazon EKS即Amazon Elastic Kubernetes Service,是一项完全托管的服务。无需安装、操作或维护集群也可轻松运行Kubernetes,而其内置的控制面板则为LigaAI的集群管理提供了便利。

Step 2:规范中间件资源

为方便应用接入,我们梳理了系统中需要改造或命名规范化的基础资源和中间件,包括域名命名、数据库地址、消息队列、Redis和Elasticsearch等。

命名规范化可以以环境名称为统一标识,采用「资源名称_环境名称」等形式完成。

Step 3:应用改造

下一步,依据梳理好的基础资源和中间件规范,重新整理并统一测试环境配置信息,规范化应用配置和持久化数据。

应用改造目标是,只需注入环境名称,即可替换所有与环境相关的配置信息,如回调地址、消息队列、数据库信息等;而持久化的数据不应保存与环境信息相关的数据。

该阶段可能涉及到一部分代码改造,需要开发团队参与配合。

Step 4:制作环境模板

想要自动生成环境,首先必须有一套含有持久化数据、配置文件和应用包的环境模板;其中,应用包数据包括后端镜像和前端资源包。

在本次改造中,LigaAI指定Pre环境作为基准环境模板来源。

Step 5:一键搭建环境

为最大程度提高产研团队效率,环境搭建必须方便快捷,且满足可复用要求。

将环境搭建流程的各个环节脚本化,并将这些脚本集成到流水线任务当中,实现环境搭建的一键生成效果;其中,将部分流程并行处理,也会加快环境生成速度。
在这里插入图片描述

Step 6:环境登记责任人

除一键生成环境外,制定标准化的环境管理流程也很重要。明确环境负责人,将环境生成、重置与释放流程集成到运维平台,让申请信息可视化;

同时,通过信息通知集成IM,支持环境生成/释放信息、环境到期提醒等通知的及时触达。

技术分享 | 多测试环境的动态伸缩实践_第4张图片

四、标准化改造成果:环境生成自动化

至此,测试环境的标准化改造告一段落,而LigaAI也成功打通了环境模板生成流程和环境申请流程的数据传递通道。

技术分享 | 多测试环境的动态伸缩实践_第5张图片

左边:环境模板生成流程

发布生产后,触发模板构建任务;

通过提取Pre环境的数据,找出当前的镜像信息,打上Tag并标记为模板镜像;

再将环境模板所需要的数据库、配置文件和前端资源等数据上传到Amazon S3进行保存。

右边:环境申请流程

环境申请人先在运营平台登记申请,填写使用时间和使用范围;

提交申请后,触发任务:从Amazon S3拉取配置数据,初始化中间件资源,从镜像仓库拉取模板镜像部署应用,一键生成环境;

环境到期后会自动释放,如需继续使用,提交延长登记信息即可。

环境生成的标准化改造通过流水线任务自动搭建、环境自动释放和申请人登记,解决了环境需求的三大痛点。想要进一步解决环境资源紧缺或浪费的问题,需要继续完成测试环境的弹性伸缩改造。

技术分享 | 多测试环境的动态伸缩实践_第6张图片

第二步:测试环境的弹性伸缩改造

容器资源主要分为Pod级别和Node级别。每个Pod包含一个或多个应用容器,并以整体的形式在Node之上运行。

技术分享 | 多测试环境的动态伸缩实践_第7张图片

与资源分类对应,资源伸缩也有两种模式:

  • Pod级别的资源伸缩为HPA,是Kubernetes的内置服务,主要用于副本数量的调整;
  • Node级别的资源伸缩为Cluster Autoscaler,非Kubernetes内置服务,需要手动部署Deployment安装;

想要让服务器资源满足变化频繁的研发环境需求,则需要对Node级别进行弹性伸缩改造。

Amazon EC2 Auto Scaling groups(以下简称自动伸缩组)提供了弹性扩展服务器实例的功能,支持设置服务器的初始生成数量、最小数量以及最大数量限制。

当扩展策略生效时,自动伸缩组会在指定的最小和最大容量值之间调整组的所需容量,并根据需要启动或终止实例。

技术分享 | 多测试环境的动态伸缩实践_第8张图片

痛点4:服务器资源不足时,如何扩容?

环境申请成功后,Pod数量增加,但因节点资源饱和/不足,此时新的Pod会处于Pending状态。

Cluster Autoscaler定期(默认间隔 10 秒)检测节点资源的使用情况。一旦监测到Pending状态的Pod,便会触发节点扩容,调用Cloud Provider,创建新的Node以满足增加的环境需求。

技术分享 | 多测试环境的动态伸缩实践_第9张图片

痛点5:服务器资源过剩时,如何缩容?

测试完成后,环境资源释放,Pod被删除。此时,Node资源呈闲置状态。

当检测到一个Node已超过 10 分钟没有执行任何扩展操作,或资源利用率均低于 50% 时,Cluster Autoscaler会控制自动伸缩组进行回收节点,自动将其删除;原来的Pod也会自动调度到其他Node上。
技术分享 | 多测试环境的动态伸缩实践_第10张图片

以上,Cluster Autoscaler通过Cloud Provider插件,操作自动伸缩组完成服务器资源的扩展与回收,达成测试环境的弹性伸缩改造。

六、如何实现低成本,高效运行环境?

1. 中间件资源复用

云环境下,对数据库、Redis、Elasticsearch、配置中心和注册中心等中间件资源进行复用,可大幅节省使用成本和资源,降低环境扩展难度。

比如,在一个数据库实例上,以环境名称为索引标识,创建不同环境的数据库,以节省资源。

技术分享 | 多测试环境的动态伸缩实践_第11张图片

2. 合理分配资源

此外,还可以通过以下几个方面,控制云服务器上的成本支出。

第一,合理分配CPU和内存的Pod资源预留与资源限制。 资源预留(Requests)表示Pod需要占用的最小资源,即节点上必须有大于Request值的资源,才能调度这个节点;而资源限制(Limits)则表示Pod可使用资源的最大值,当容器占用资源超过Limit值时,就会被终止或重启。

CPU是弹性资源,而大部分IO密集型应用在测试时对CPU的使用率和消耗都比较低,因此建议将CPU的Requests设置小一些,将Limits调大一点。

Java应用分配内存则可以通过分析GC日志、应用监控信息、JVM监控信息等,根据GC频率和GC耗时的表现,找到一个可接受的内存设置平衡点,用较小的内存满足当前的服务需要。
技术分享 | 多测试环境的动态伸缩实践_第12张图片

第二,关注节点的配置比例和大小选取。CPU和内存的节点配置比例需要根据实际业务系统的需求确定。比例设置原则是避免CPU或内存成为明显的短板,常见的应用比例是 1:4 或者 1:8。

节点的选择上,一方面要避免选择配置低的小节点。因为节点上需要部署Kubernetes的基础组件,这会消耗固定的资源,且节点越多,整体开销和成本越大;此外,过小的节点还可能出现资源碎片的问题,所以建议适当挑选大一些的节点。

另一方面,切忌盲目追求大节点。大节点允许的Pod数量较多,一旦节点出现问题,影响范围也会更大。同时,大节点的自动伸缩成本更高,容易出现「杀鸡用牛刀」的情况。

技术分享 | 多测试环境的动态伸缩实践_第13张图片

第三,奉行勤俭节约原则。 一次性运行的任务或执行频率较低的周期任务,可以通过K8S Job和CronJob执行。另外,资源节约意识也表现在环境不用时及时回收、没有特别情况不随便申请环境、避免非常规环境空置等习惯之中。

3. 控制云上的成本

LigaAI的测试环境改造采用了多项亚马逊云科技服务,因此我们也通过减少云服务商的成本费用,进一步实现低成本的高效运行。

首先,挑选合适的区域很重要。就亚马逊云服务而言,不同区域的费用标准也会有所差异。可以多多对比中国区和外国区,或宁夏区域和北京区域的相关费用标准,选择最合适的区域服务。

其次,还可以关注云服务器的不同定价方案。以Amazon EC2云服务为例,我们主要考虑按需实例、预留实例和竞价实例三种定价方案。

  • 按需实例/On-Demand Instances:按小时或秒(最少 60 秒)收费。
  • 预留实例/Reserved Instances:类似按年付费;相比按需实例,最高可提供 72% 折扣。
  • 竞价实例/Spot Instances:在服务器需求不高时,可出售空闲服务器资源;相比按需实例,最多可享 90% 折扣。

采用「预留实例+竞价实例」的组合方式,也能进一步实现经济效益最大化。

对于固定的环境,提前计算好需要的服务器数量,申请预留实例,并将其设置为自动伸缩组中的最小实例数量;再将额外的扩展环境设置为最大数量,以此实现弹性扩容。

对稳定性要求不高的环境或应用(如开发环境),可以通过Spot自动伸缩组进行环境扩容。

技术分享 | 多测试环境的动态伸缩实践_第14张图片

01 配置节点亲和性和污点

设置节点亲和性或污点,让对的Pod被调度到正确的节点上。节点亲和性使得Pod被吸引到一类具有特定标签的节点上,而节点污点(Taint)则相反,它使得Pod避免被调度到这些节点上。

通过将需要稳定运行的Pod固定在按需实例或预留实例的节点组上,将可容忍中断的Pod限制在Spot节点组上,也可满足成本控制的需要。

为了方便环境回收时的节点释放,按环境名称设置Pod亲和性,将同一环境的Pod尽量放置到相同的节点,减少节点中的Pod转移,提高节点回收率。

02 如何降低Spot节点中断的影响?

第一,选择多个可用区和多种实例类型。 注意,同一个节点组的实例类型的CPU核心数量跟内存大小必须一致,这样会有更充足的资源。

第二,设置Pod优先级。 对非关键Pod设置低优先级,可以在节点回收时,率先将重要的Pod转移到其它空闲资源中去;

第三,还可以在节点关闭前,先将Pod调度转移。具体实现路径如下:

技术分享 | 多测试环境的动态伸缩实践_第15张图片

首先,开启自动伸缩组的「容量再平衡设置」。开启后,如果Spot节点有中断风险,自动伸缩组就会提前发出容量再平衡通知,并重新分配一个新的Spot节点。

旧节点关闭前两分钟,自动伸缩组会发出终止实例的通知(需手动开启相应的通知配置)。

而在Kubernetes中,我们需要部署AWS Node Termination Handler服务,并通过它来接收事件,驱逐旧节点里的Pod;Pod驱逐完成后,再关闭旧的节点。

以上步骤可以基本保证Spot节点的相对稳定性。

4. 账单费用监控告警

最后,做好费用的监控预警也很重要。以下服务可用于监控费用明细,提供资源优化支撑,也可以对账单费用突增、预留实例覆盖率进行告警通知。

  • Amazon Cost Explorer
  • Amazon Budgets
  • AWS Tweaker

本文内容整理自Apps Everywhere系列活动 - 深圳站(线上直播)的主题分享。该活动由亚马逊云科技User Group举办,聚焦云原生开发技术,探索云原生技术下的测试、交付、安全等话题的全新思维碰撞。

未来,LigaAI将持续为开发者社区提供高质量技术分享,与更多开发者和团队一起探索高效益的研发管理之道。

阅读更多「LigaAI」的趣味分享与敏捷实践,请关注 LigaAI@CSDN,持续接收更多干货分享~ 进一步了解我们的产品,请访问 LigaAI -新一代智能研发协作平台

你可能感兴趣的:(技术分享,java,微服务,运维,测试工具,云原生)