写点什么

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

作者:LigaAI
  • 2022-11-18
    广东
  • 本文字数:4602 字

    阅读完需:约 15 分钟

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

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

一、当前遇到的环境问题


初期,根据实际研发需要,LigaAI 主要应用了以下四套环境:



  • Dev 环境是开发环境,专供前/后端开发人员进行功能开发自测、联调等;

  • Sit 环境为测试环境,供测试成员进行迭代功能验收;

  • Pre 环境为预发布环境,主要承担整体测试、回归测试等;

  • 最后,Prod 环境为生产环境。


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


  • 对迭代有风险的复杂需求需要剥离迭代,进行单独测试;

  • 开发人员需要不同的 Dev 环境进行联调;

  • 迭代小组的迭代进度各异,需要分批提测;

  • 紧急 Hotfix 急需测试,但环境已被占用;

  • 需要进行系统压测,却缺乏一套压测环境;


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



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



二、测试环境的改造目标


开始正式改造前,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,支持环境生成/释放信息、环境到期提醒等通知的及时触达。



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


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



左边:环境模板生成流程


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


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


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


右边:环境申请流程


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


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


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


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



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


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



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


  • Pod 级别的资源伸缩为 HPA,是 Kubernetes 的内置服务,主要用于副本数量的调整;

  • Node 级别的资源伸缩为 Cluster Autoscaler,非 Kubernetes 内置服务,需要手动部署 Deployment 安装;


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


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


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



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


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


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



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


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


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



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

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

01 中间件资源复用


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


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



02 合理分配资源


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


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


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


Java 应用分配内存则可以通过分析 GC 日志、应用监控信息、JVM 监控信息等,根据 GC 频率和 GC 耗时的表现,找到一个可接受的内存设置平衡点,用较小的内存满足当前的服务需要。



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


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


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



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


03 控制云上的成本


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


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


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


  • 按需实例/On-Demand Instances:按小时或秒(最少 60 秒)收费。

  • 预留实例/Reserved Instances:类似按年付费;相比按需实例,最高可提供 72% 折扣。

  • 竞价实例/Spot Instances:在服务器需求不高时,可出售空闲服务器资源;相比按需实例,最多可享 90% 折扣。


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


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


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



  • 配置节点亲和性和污点


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


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


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


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


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


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


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



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


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


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


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


04 账单费用监控告警


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


  • Amazon Cost Explorer

  • Amazon Budgets

  • AWS Tweaker


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


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


关注LigaAI获取更多咨讯,LigaAI-新一代智能研发管理平台 期待与你一路同行,助力开发者扬帆远航!


发布于: 刚刚阅读数: 4
用户头像

LigaAI

关注

新一代智能研发协作平台 2021-02-23 加入

AI赋能工作场景,想要做最懂开发者的智能研发管理平台~

评论

发布
暂无评论
技术分享 | 多测试环境的动态伸缩实践_云原生_LigaAI_InfoQ写作社区