如何评估4亿用户线上容量性能上限：Linked Redliner架构解密

导读：架构师常被性能及容量问题困扰。如何准确评估线上服务容量？如何评估新开发的功能是否满足性能指标？新修改的代码是否有性能问题？ 本文介绍 Linkedin 开发的 Redliner 如何完美解决上述问题，由高可用架构翻译。

LinkedIn 在全球的基础架构上通过数百个内部服务，为超过 4.67 亿用户提供服务。在新功能上线，容量规划和机房故障转移分析等过程中，经常出现以下问题：

• 我的服务在其当前环境下可以承受的最大 QPS（每秒查询数）是多少？

• 当前数量的服务器能够处理比当前峰值流量高 50% 的流量吗？

• 服务的瓶颈在基础设施的哪个环节（CPU, IO...）？

作为 LinkedIn 的性能小组，我们的职责是希望能够随时给这些问题一个确切的答案。

由于公司 Web 服务快速增长情况，当尝试评估各个服务容量极限时，我们面临很大的挑战。这些挑战包括不断变化的访问流量形态，异构基础设施特性和不断变化的瓶颈点。为了准确地确定服务容量极限并有效地精确定位容量瓶颈，我们需要一个解决方案：

• 能够利用生产环境进行评估，克服实验环境限制 ;

• 使用实时流量作为工作负载 ;

• 对用户体验的影响降到最小 ;

• 降低运行成本开销 ;

• 能够自动化扩展

LinkedIn 容量规划解决方案：Redliner

Redliner 是我们的解决方案，用于在实时流量的生产环境中提供自动容量测量和精确的冗余能力分析。 Redliner 通过执行压力测试来评估服务的吞吐能力，压力测试会逐步增加目标服务实例的流量，直到它确定实例无法再处理任何额外负载。

Redliner 的设计提供了一种自动化的方式来转移生产环境流量，从而对网站和最终用户的影响达到最小。 我们以两个关键的设计原则为基础来构建这个解决方案：对生产环境的低影响和完全自动化。

低影响

重定向实时流量的一个主要问题是对用户的潜在影响。 Redliner 使用以下策略来减轻对生产环境的性能影响。 

1. 导入到测试目标的额外流量是逐步递增的过程。

2. Redliner 实时监控服务健康状况，并相应地调整流量压力分布。 Redliner 捕获实时性能指标，并根据 EKG 中的健康评估规则结果确定服务的运行状况（参见图 1 和图 2 中的入站和系统指标示例）。

3. 此外，Redliner 在测试期间也会评估 redline 测试对下游和上游依赖服务的影响。

Figure 1: Redliner inbound metrics rules 示例，点击图片可缩放

Figure 2: Redliner system metrics rules 示例，点击图片可缩放

完全自动化

为了克服手动测试的缺点（如缺乏一致性，高维护成本等），我们需要一种非手动的方法。该方法用于启动性能测试、确定吞吐量容量、对系统性能下降的告警进行检查，以及在出现问题时优雅的停止测试以及进行回退。

我们在 Redliner 中自动化了上述过程，同时使用 LinkedIn 技术能力使其具备可靠性和可扩展性。Redliner 可以根据计划启动测试，通过 EKG 监控性能状况，并利用 A / B 测试平台 XLNT [1] 动态调整转移到目标服务实例的流量。

经过几次迭代（如下所述）后， Redliner 最终可以确定单个实例可以处理的最大吞吐量 QPS。整个端到端测试过程通常可以在不到一个小时完成。 Redliner 还可以生成测试报告，并在每个测试结束时识别服务的响应延迟变化，以及定位资源瓶颈（如果有）。如果服务资源过度冗余或不足， Redliner 会向服务相关人员发送电子邮件并提供具体建议。

Redliner 架构及生态

图 3 表示了 Redliner 的架构，并展示了与关键组件的交互，以实现流量转移和容量评估。 有几个关键组件：

1. 业务分流层（代理/负载平衡器）

2. 服务健康分析器

3. 服务运行数据收集器

Figure 3: Redliner 及依赖模块，点击图片可缩放

业务分流层（代理/负载平衡器）

目前， Redliner 仅支持无状态服务；即那些请求流量可以路由到机房中任意 SUT（Service Under Test）服务器或实例。这些访问的流量通过在负载均衡层的重新路由机制进行控制，使得动态流量转移成为可能。

业务转向层是 Redliner 实现动态业务转移的关键组件。 Redliner 确定要应用于目标实例的流量级别，并与 LiX（ LinkedIn 实验服务）进行通信，相应对代理和负载均衡上的特定配置进行更改。

LiX 是 LinkedIn 转移流量的默认方式（包括 A / B 测试体系）; 它通过底层基础设施提供了一种可控和安全的流量控制方式。通过更改代理和负载均衡的配置， Redliner 能够自动控制从调用客户端流向目标服务实例的流量。

服务运行数据收集器

容量评估和余量分析是基于对性能度量的评估，以确定 SUT 是否接近容量。 所有 LinkedIn 服务向 Autometrics [2] 发送指标。 Autometrics 是基于推送的实时指标收集系统。 Redliner 利用 Autometrics 实现系统级和服务级性能指标（如 QPS，请求延迟，错误率和 CPU /内存利用率）的实时数据获取。

服务健康分析器

Redliner 的服务健康工具 EKG [3] 可以分析上述性能指标，以确定服务的整体健康状况。 EKG 通过对选定的性能指标运行状况检查规则以进行分析。 Redliner 通过查询 EKG，以便在正常流量负载和测试负载之间进行性能比较。 它还为后续一些步骤查询健康检查结果。

Redliner 实战

为了确定服务的容量限制， Redliner 对不同的 SUT 实例使用不同的流量级别。将流量负载更改应用到目标实例后， Redliner 通过 EKG 收集实例的健康状况。如果健康检查出现问题，Redliner 将降低目标的流量水平；否则继续增加流量，以增加额外的压力。 Redliner 依赖这种性能反馈环路来进行流量决策。它迭代上述步骤，直到它有足够的置信度产生有效的结果（红线），它就是服务可以处理的最高吞吐量容量。

图 4 显示了 Redliner 测试细节。在这种情况下，由于 SUT 生成了红线数据（以红色虚线标记为“目标红线”），所以 Redliner 通过在几个步骤中将业务负载增加到目标红线 QPS 以提升测试效率和减少测试持续时间。

然后，它将流量保持在目标实例，直到达到测试实例 CPU 利用率和延迟显著增加的 QPS。 之后 Redliner 将到达目标实例的流量负载降低。在多次这样的流量调整迭代之后， Redliner 确定服务红线数据。

Figure 4: Redliner 测试结果: QPS and Latency vs Time

使用案例

Redliner 已广泛应用于 LinkedIn 并实现多种用途，包括以下方面。

降低数据中心开销

通常服务自身需要提供资源和未来增长预测。但是由于许多因素，已经提供的资源有时可能未充分利用。 通过创建定期红线，我们可以识别这种过度冗余的服务，并回收/重用到其他服务。

过度冗余的示例是当 Redliner 测试终止时，因为 100％ 的流量已经转移到目标 redline 实例，而没有遇到服务运行状况评估失败。 工程师就可以减少生产中的 redline 实例的数量，或者利用 LPS [4] 来更有效地重新分配资源。 图 5 显示了在使用 Redliner 容量指导回收资源后，服务器成本降低的示例。

Figure 5: 服务资源占用下降示例

主动容量规划

在生产环境中识别容量问题的代价高昂。 通过  Redliner  自动化对服务进行测试，服务开发者和运维团队将收到潜在容量风险的告警。由于 Redliner 会识别确切的资源争用（无论是 CPU，内存，网络，线程池等），解决性能问题变得更容易。 此外，通过容量历史以及可视化 QPS 趋势，工程师可以使用预测模型进行适当的资源预估，从而可以提前规划所需的资源。

性能回归测试

工程师可以使用 Redliner 的自动化测试来检测程序版本之间的性能回归及识别新的资源瓶颈。 Redliner 支持并行测试和生产环境。 这允许工程师在两个不同的服务实例上运行相同级别的流量：

1. 新版本的运行实例，包含代码、配置等变更

2. 当前版本的运行实例。

这些负载测试的情况是日常发布流程决策的一个环节，并已成功阻止了数次有潜在性能问题的代码发布。

致谢

Redliner 设计和开发是一个跨团队努力的结果。 Tom Goetze 和 Ritesh Maheshwari 帮助建立第一版本的 Redliner。 Greg Cochard，Jimmy Zhang，Melvin Du，Yuzhe He，Yi Feng，Ramya Pasumarti，Richard Hsu，Jason Johnson 和 Haricharan Ramachandra 都对近年来的发展和支持做出了贡献。

Co-authors: Susie Xia and Anant Rao

参考资源

1. https://engineering.linkedin.com/ab-testing/xlnt-platform-driving-ab-testing-linkedin

2. https://engineering.linkedin.com/52/autometrics-self-service-metrics-collection

3. https://engineering.linkedin.com/blog/2015/11/monitoring-the-pulse-of-linkedin

4. https://engineering.linkedin.com/blog/2016/04/faster-and-easier-service-deployment-with-lps--our-new-private-c
   

5. 本文英文原文：https://engineering.linkedin.com/blog/2017/02/redliner--how-linkedin-determines-the-capacity-limits-of-its-ser

推荐阅读

本文最初出现在LinkedIn官方技术博客，由高可用架构翻译，转载请注明出处，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式

长按二维码 关注「高可用架构」公众号