LinkedIn 在它的基础设施上运行着数百个应用,它们为 4 亿 6 千 7 百万 LinkedIn 会员提供服务。在发布新功能、规划流量增长规模和分析数据中心失效备援方案的过程中,我们经常会遇到以下几个问题。
- 以服务目前的配置最大可以承担多大的 QPS(每秒查询数)?
- 这些服务器能够处理比当前峰值高出 50% 的流量吗?
- 从基础设施来看,服务潜在的容量瓶颈是什么?
作为 LinkedIn 的性能团队工程师,我们的工作就是要在短时间内为上述的问题寻找准确的答案。
不过,因为服务的增长过于迅速,在对服务的容量极限进行评估时,我们面临着巨大的挑战。这些挑战来自于持续变化的流量模式、不均衡的基础设施特征,以及持续变化的瓶颈。为了能够准确地对服务容量极限进行评估,并有效地识别出容量瓶颈,我们的解决方案需要具备如下特点。
- 利用生产环境来突破实验室的局限
- 使用真实的流量作为负载
- 最小化对用户体验造成的影响
- 低运营成本和开销
- 自动伸缩
我们的解决方案:Redliner
我们使用生产环境的真实流量,通过 Redliner 实现自动化的容量评估和准确的余量分析。Redliner 在目标服务上运行压力测试,逐步增加流量,直到服务无法处理更多的流量为止,以此来评估服务的吞吐量。
Redliner 自动从生产环境引入流量,并确保对用户只有很小的影响。在设计 Redliner 时,我们遵循了两个原则:影响最小化和完全自动化。
影响最小化
在进行流量重定向时,最主要的问题是如何避免对站点和用户造成影响。Redliner 使用以下的策略来缓解对生产环境性能造成的影响。首先,通过增量的方式将流量导向 redline 实例。其次,Redliner 对服务进行实时的监控,并根据实际情况来分发流量。Redliner 捕捉实时的性能指标,并基于 EKG 健康评估规则(见图 1 和图 2)的计算结果来确定服务的健康状况。另外,在进行 redline 实例的测试过程中,Redliner 也会评估流量测试对上游和下游服务所产生的影响。
(点击放大图像)
图1: Redliner 内部度量指标规则示例
(点击放大图像)
图2:Redliner 系统度量指标规则示例
完全自动化
为了克服手动测试的缺点(缺乏一致性、高昂的运营成本,等等),我们需要一个完全自动化的方式来运行测试、确定吞吐容量、检测系统性能衰退告警,并在出现问题时停止测试或回滚。我们借助LinkedIn 的技术平台保证Redliner 自动化的健壮性和伸缩性。Redliner 能够运行调度测试,通过EKG 检测性能状态,还能利用A/B 测试平台 XLNT 来动态地调整导向目标服务的流量。在经过几轮的迭代之后,Redliner 就可以确定单个服务能够处理的最大 QPS。一般整个过程需要不到一个小时的时间。Redliner 会生成测试报告,报告里包含了 QPS 和延迟趋势走向以及资源瓶颈信息。如果某个服务出现过载或者尚有余量,Redliner 会向相关人员发送邮件,邮件里会为他们提供具体的建议。
Redliner 生态系统
图 3 是 Redliner 的架构图,包含导流组件和容量评估组件。主要组件如下:导流层(代理 / 负载均衡器)、服务健康状态分析器和服务度量指标收集器。
(点击放大图像)
图3:Redliner 和它的依赖组件
导流层(代理/ 负载均衡器)
Redliner 目前只支持无状态的服务。也就是说,发送给这些服务的请求可以被路由到数据中心 SUT(Service Under Test)的任意服务实例上,不涉及粘性会话(sticky session)。负载均衡机制负责控制流量负载,从而能够实现动态导流。
导流层是 Redliner 实现动态调整流量的关键组件。Redliner 确定目标服务的流量等级,并通过 LiX(LinkedIn 实验服务)将其转换成代理和负载均衡器的配置变更。LinkedIn 使用 LiX(以及 A/B 测试)作为默认的流量探测工具,它提供了更为可控和安全的导流。通过改变代理和负载均衡器的配置,Redliner 就可以自由地控制从客户端发送给目标服务的流量。
度量指标收集器
容量评估和余量分析通过分析性能度量指标来确定 SUT 是否已经达到了容量极限。LinkedIn 所有的服务都会向 Autometrics 发送度量指标,Autometrics 是一个基于推送的实时度量指标收集系统。Autometrics 会收集实时的系统数据和服务数据,比如 QPS、请求延迟、错误率,以及 CPU 和内存的使用情况。
服务健康分析器
EKG 是 Redliner 的服务健康检测工具,它通过分析上述的性能指标来确定服务的整体健康情况。Redliner 向 EKG 查询正常流量负载性能与当前流量负载性能之间的比较结果,也会通过查询服务的健康检测结果来决定后续的导流操作。
Redliner 实战
Redliner 通过在目标服务上增量运行不同的流量压力测试来确定服务的容量极限。在对目标服务的流量负载做出变动后,Redliner 等待 EKG 返回健康检测结果。如果健康检测失败,Redliner 会降低流量等级,否则,它会增加流量,给服务施加更大的压力。Redliner 就是通过这样的反馈闭环来确定服务的流量等级的。在得到一个令人信服的红线(redline)数字之前,这个迭代过程会一直进行,而这个数字就是服务能够处理的最高吞吐容量。
图 4 展示了 Redliner 一个测试案例的细节。SUT 设定了一个红线数字(红色虚线),Redliner 触发快速坡道(ramp)算法,逐步增加流量负载,直至达到目标 QPS。这个过程改进了测试效率,同时降低了测试之间的时间间隔。之后,Redliner 一直保持流量的逐步增加,直到目标服务的 CPU 使用率和调用延迟出现显著的增长,这个时候的健康检测会返回异常。Redliner 随之降低目标服务的流量负载。在经过几轮的迭代调整之后,Redliner 就得到了目标服务的红线数字。
(点击放大图像)
图4:Redliner 测试结果概要:QPS 和延迟vs 时间
使用案例
Redliner 在 LinkedIn 内部被用于多种用途,包括下面的几种。
降低数据中心的成本
一般来说,服务所需要的资源需要根据未来的增长规模来调配。不过受多种因素的影响,比如功能弃用和不准确的增长规模预测,分配给服务的资源可能不够用,所以资源分配是一件很复杂的工作。通过指定红线区间,我们可以识别出过度分配资源的服务,并将资源收回,用作其他用途。举个例子,当 100% 的流量被导向目标服务,健康检测没有返回错误,Redliner 测试就随之结束。根据这个测试结果,工程师们可以减少生产环境的服务实例,或者利用 LPS 对资源进行更有效的分配。图 5 展示了使用 Redliner 对生产环境的服务器资源进行回收的例子。
(点击放大图像)
图5:服务资源减持趋势示例
前瞻性容量规划
生产环境的容量问题总是很难缓解。通过运行Redliner 的自动化测试,服务所有者和运维团队会收到潜在的容量告警。在Redliner 识别出资源竞争问题(CPU、内存、网络、线程池)之后,做出缓解计划就会变得相对容易。另外,通过分析容量历史和可视化红线QPS 趋势,工程师们可以建立评估模型,并作出适当的预测,提前为流量增长规划好资源。
吞吐量衰退检测
工程师们可以使用Redliner 来检测应用程序的衰退情况,还可以通过自动化测试识别出新的资源瓶颈。Redliner 支持同时运行canary 环境的测试和生产环境的测试。工程师们可以在不同的服务实例上运行相同等级的流量负载:一个服务实例包含了新的配置、属性变更或者代码变更,另一个服务实例是当前的生产环境版本。负载测试结果可以作为部署的参考,可以避免部署包含了可能导致性能衰退的代码。
查看英文原文: Redliner: How LinkedIn Determines the Capacity Limits of Its Services
感谢郭蕾对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ , @丁晓昀),微信(微信号: InfoQChina )关注我们。
评论