GKE上的可扩展性测试,提前规避扩展风险

构建大型系统可能具有挑战性。在较小规模上可预测且可靠的系统在扩大规模时可能会变得混乱和无法控制,从而暴露设计的局限性,表现出次优性能,甚至无法正常工作。


为了减轻这些影响,在将大型系统部署到生产环境之前对其进行测试非常重要。但在扩展时预测系统性能和可靠性可能是一项复杂的任务,需要格外小心。通常,计算资源的数量可以预测系统的扩展能力。在其他情况下,其他维度更重要,例如并发连接数、租户数或可以应用的安全规则。此外,你如何执行可伸缩性测试取决于应用程序的性质——它是未开发的产品、你从另一个云提供商迁移的应用程序,还是你正在调整大小的系统?根据谷歌评估大型Google Kubernetes Engine(GKE) 集群的经验,让我们来看看谷歌云在 GKE 客户想要扩展其工作负载时提供的最佳实践和建议


可扩展性测试的好处

对系统进行可扩展性测试的主要好处是识别瓶颈和优化机会,这些瓶颈和优化机会在较小的规模下可能并不明显,因此你可以确认它是可靠的并且在规模上表现良好。还有其他好处:


  • 获得对系统的信任。如果你成功地将它扩展到当前大小的两倍,你应该对以常规比例运行它感到满意。


  • 尽早发现潜在问题。这可能会提示你增强可观察性指标。例如,许多客户不跟踪 GKE API 延迟。但是,一旦他们注意到 Kubernetes API 延迟检测控制平面问题的早期迹象的能力如何,他们就决定将其添加到 Google Cloud 的可观察性套件 Cloud Operations 中。


  • 确认系统大规模运行的成本。特别是,当你考虑会话数、用户数或完成的作业数时,GKE 客户可能会惊讶地发现运行大型系统的成本可能更低。



设置可扩展性测试目标

为你的可扩展性测试设定适当的目标尤为重要。一方面,测试错误的假设可能代价高昂。然后,除了测试的实际成本之外,定义不当的目标会在系统中建立一种错误的信任感,当系统在生产中扩展时,这可能会导致严重的事件。


根据经验,你的高级目标应该表示为面向业务的价值并且应该是可衡量的,例如,将并发处理的作业数量增加一倍,将每秒的用户查询数量增加三倍,或者优雅的区域故障。实现这个目标并将其显着显示在你的测试仪表板上。


你还应该将你的高级目标映射到特定资源。例如,如果你要重新扩展现有系统,最常见的方法是假设资源利用率呈线性增长,并添加一个安全缓冲。如果你的系统使用 100k CPU 可靠地工作,并且你希望将性能提高一倍,则可以使用 250k CPU。这些原始假设只是提供了一个估计,并帮助你评估你离硬性系统限制有多远;你需要在测试期间确认实际数字。



设定目标时,请务必检查以下资源,以确保在扩展系统后它们就足够了:

  • 节点/Pod/容器的数量

  • 服务数量

  • 命名空间数量

  • CPU/GPU/内存数量

  • secret/ConfigMap/CRD 的数量


此外,验证典型的 Google Cloud 资源利用率,例如 VPC 的数量、它们的实例和别名,或者项目中集群或节点池的总数。


只要事情稳定,大型系统就可以非常可靠。在变革时期,事情可能会出错。要构建适当的测试用例,请务必在测试期间验证常见的摩擦点。这些包括集群升级、区域中断或大型 PVM 抢占。检查在测试过程中是否正确收集了所有基本指标和日志。


确定可扩展性测试成本

毫无疑问,可伸缩性测试的成本非常高。在极端情况下,一些测试需要数十万美元才能运行!而在 Google Cloud,每周至少两次在 15,000 个节点上使用多达 20 种不同的测试配置测试 GKE 版本。谷歌还验证开源 Kubernetes 版本的规模,每天执行 5,000 个节点测试。


即使你临时运行可扩展性测试,你仍然需要优化成本。最常见的方法是使测试尽可能短。谷歌的内部测试就是一个很好的例子:他们将 15 小时的测试过程减少到不到 3 小时,同时保持测试范围不变。


以下是你可以使用的其他一些优化方法:


  • 切换到成本较低的计算资源。如果可能,请在 Spot VM 上运行测试,这比常规实例便宜高达 91%。


  • 简化存储层。只要你不测试存储层,就可以将默认目标(Cloud Storage、LocalSSD)替换为标准永久性磁盘上的存根。


  • 如果合适,优化测试工作负载以使用比生产中所需更少的内存/CPU 来“存根”实际容器。


在估算测试成本时,请确保将所有成本因素(计算、网络、存储)都包含在其最高预期值中。要估计测试的长度,不要忘记包括按比例放大和缩小的时间。根据谷歌的经验,你至少需要进行两到三个完整的测试才能达到目标。


归根结底,请记住这里没有黄金法则。你需要在优化成本与实现尽可能接近生产系统的结果之间取得平衡。


准备基础设施

运行大型可伸缩性测试时,最好在具有专用结算帐户的单独Google Cloud 项目中运行测试。项目级别的分离有助于使配额的使用独立于你的其他环境。由于这是一个单独的项目,你需要为可能使用的所有资源申请增加配额。遵循 GKE 文档中列出的准则很有帮助,规划大型工作负载 | 谷歌 Kubernetes 引擎(GKE)。特别注意网络配置。正确定义 CIDR 寻址或负载均衡器以在多个维度上进行扩展,包括最常见的维度,例如节点数、Pod 或服务。谷歌也建议你关注GKE 地址管理:简介和概述 | 云架构中心。


尽管在没有客户团队支持的情况下运行可扩展性测试在技术上是可行的,但最好尽早将它们包括在流程中,这样它们可以帮助你了解平台限制并将你与主题专家联系起来。你甚至可以在公开可用之前获得最佳实践和已知解决方法。


你还应该在准备阶段通知并让 Google 的能力团队参与进来。一年中的某些时间运行大型测试比其他时间差,例如黑色星期五/网络星期一或新年。准备考试的最佳时间是一年中的第一季度,而进行实际测试的最佳时间是第二季度。


一旦你确定了测试的时间框架,在实际测试前几天安排一个快速的空运行,在那里你运行一个小测试来证明所有的电线都正确连接。当你写下所有测试用例并证明它们有效、将配置存储在存储库中并开发仪表板以显示你的测试结果时,你就可以开始了。


运行测试

尽管每个测试执行都不同,但成功的测试彼此之间有很多共同点。最常见的规则之一是与一支优秀的团队一起运行测试。你的测试运行者可能包括 DevOps、架构师或开发人员。有一些客户在团队的日历中预留一天,并设立一个作战室。如果出现问题,将架构师和开发人员集中在一处还可以帮助你找出快速解决方法。


准备好在运行期间,系统的某些元素可能会不稳定。测试运行器的目标是收集尽可能多的数据来调试问题。为了将来的调查,谷歌倾向于记录在测试期间进行的所有讨论和调查。结合收集的日志和指标,这些记录的数据可以极大地帮助后期调试。


测试运行的摘要不仅应包括技术指标,还应包括定价明细。很难高估大规模运行成本估算的价值。


经过多次测试,谷歌的工程师是可扩展性领域的专家。即便如此,他们通常会在第一次测试运行时检测到多个问题,而单次运行很少足以满足可扩展性测试目标。根据额外调整的数量,你通常需要在大约一个月内执行另一次运行。有时,你需要执行更深入的重构或另一轮测试。没有测试,你永远不会学到这些!


长话短说

迁移到云端让你有机会从一个有趣的新角度来审视你用来运行工作负载的机器。事实上,云计算是由软件驱动的。软件是网络和存储、你的工作负载以及管理它们的系统的主要接口。这开辟了无数种集成、想象和使用它的方式。


测试对代码的更改是现代软件开发生命周期文化不可或缺的一部分。通过将云系统视为软件,很明显这些系统的每次更改——无论是新的 Kuberentes 版本、新组件(如内存数据库或缓存系统),还是架构更改(如从单集群迁移)到多集群场景——是更改推出或新版本,应该这样对待。


尽管运行可伸缩性测试的成本可能相当可观,但它通常是了解如何准备系统以在更大规模上运行的最有效和最快的方法。谷歌相信 GKE 是运行大型复杂工作负载的最佳平台,并且遵循其多年来开发的测试 Kubernetes 和 GKE 的最佳实践可以使流程易于管理。


———

WebEye是中国大陆地区首家获得 Google Cloud MSP 资质的合作伙伴。WebEye致力于用创新的技术向中国企业提供数字化效率创新服务,实现数字化赋能。我们不断帮助客户打造新的运营与协作方式,打造新的竞争优势,构建资源高效链接,共创价值生长空间。

WebEye整合全球资源,打造全球数字化营销体系,为企业提供营销增长服务营销增长引擎以及企业上云三大板块业务,涵盖数字营销、数字创意、游戏发行、流量变现、程序化广告、数据洞察、云计算等一站式全链条增长产品矩阵,是中国互联网出海领军企业。


返回全部