服务器cpu负载和内存负载_ShadowReader：无服务器负载测试，用于重放生产流量

服务器cpu负载和内存负载

尽管负载测试变得越来越容易，但是配置如实重新创建生产条件的负载测试可能很困难。 良好的负载测试必须使用一组代表生产流量的URL，并达到模仿真实用户的请求率。 即使执行分布式负载测试，也需要维护一组服务器。

ShadowReader旨在解决这些问题。 它直接从生产日志中收集URL和请求费率，并使用AWS Lambda重播它们。 由于没有服务器，因此它比传统的分布式负载测试更具成本效益和性能。 实际上，它已扩展到每分钟50,000个以上的请求。

在Edmunds，我们能够通过在我们的QA环境中重新创建相同的条件来利用这些功能来解决问题，例如仅在生产中发生的Node.js内存泄漏。 我们还每天使用它来为生产前的金丝雀部署生成负载。

我们在Node.js应用程序中遇到的内存泄漏问题使我们的工程团队感到困惑。 因为它只发生在我们的生产环境中； 在引入ShadowReader将生产流量重播到质量检查之前，我们无法在质量检查中对其进行重现。

事件

在2017年圣诞节前夕，我们发生了一起事件，整个响应时间都有所增加，错误率翻了三倍，并影响了我们网站的许多用户。

事件期间的监视有助于快速识别和解决问题，但是我们仍然需要了解根本原因。

在埃德蒙兹（Edmunds），我们利用强大的连续交付（CD）管道，该管道每天多次发布新的生产更新。 我们还动态扩展应用程序以适应高峰流量，并缩减规模以节省成本。 不幸的是，这具有掩盖内存泄漏的副作用。

在我们的调查中，我们发现自12月初以来内存泄漏已经存在了数周。 内存使用率将攀升至60％，同时第99个百分点的响应时间将缓慢增加。

在CD流水线和自动缩放事件之间，长时间运行的容器经常被关闭，并被更新的容器替换。 这无意间掩盖了内存泄漏，直到12月，我们决定停止发布软件以确保在假期期间保持稳定。

我们的CD管道

乍一看，Edmunds的CD管道如下所示：

1. 单元测试
2. 为应用程序构建Docker映像
3. 整合测试
4. 负载测试/性能测试
5. 金丝雀释放

该解决方案是完全自动化的，不需要手动切换。 最后一步是将金丝雀直接部署到实时网站中，使我们每天可以发布多次。

对于负载测试，我们利用了构建在JMeter之上的自定义工具。 它随机抽取生产URL样本，并可以模拟各种百分比的流量。 但是不幸的是，我们的负载测试无法在任何预生产环境中重现内存泄漏。

解决内存泄漏

查看质量检查中的记忆模式时，我们注意到存在非常健康的模式。 我们最初的假设是，QA中的JMeter负载测试无法以允许我们预测应用程序性能的方式模拟生产流量。

虽然负载测试从生产URL中获取样本，但它无法精确模拟客户使用的URL和准确的呼叫频率（即突发速率）。

我们的第一步是在质量检查中重新创建问题。 我们使用了一个名为ShadowReader的新工具，该工具是从我们的黑客马拉松演变而来的。 尽管我们认为许多项目都以产品为重点，但这是唯一以运营为中心的项目。 它是一个在AWS Lambda上运行的负载测试工具，可以针对我们的QA环境重播生产流量和使用模式。

它返回的结果是立即的：

知道我们可以在QA中重新创建问题后，我们采取了额外的步骤将ShadowReader指向我们的本地环境，因为这使我们能够触发Node.js堆转储。 在分析转储的内容之后，很明显内存泄漏是由两个只包含字符串的过大对象引起的。 转储快照时，这些对象包含373MB和63MB的字符串！

我们发现这两个对象都是临时查找缓存，其中包含要在客户端使用的元数据。 这些缓存都不打算持久保存在服务器端。 用户的浏览器仅缓存自己的元数据，但是在服务器端，它为所有用户缓存元数据。 这就是为什么我们无法通过综合测试重现泄漏的原因。 综合测试始终在服务器端缓存中产生相同的固定元数据集。 仅当我们从各种用户生成足够数量的唯一元数据时，泄漏才浮出水面。

一旦确定了问题，便可以删除堆转储中观察到的大型缓存。 此后，我们对应用程序进行了检测，以开始收集指标，以帮助更快地检测到此类问题。

在质量检查中进行修复后，我们看到内存使用率是恒定的，并且泄漏被堵塞了。

什么是ShadowReader？

ShadowReader是一个无服务器负载测试框架，由AWS Lambda和S3支持，以重播生产流量。 它通过以与实时网站相同的速度重放生产中的URL来模拟真实的用户流量。 我们很高兴地宣布，经过数月的内部使用，我们已将其发布为开源！

特征

• ShadowReader通过重播用户请求（URL）来模拟实际的用户流量。 它还可以与URL一起重放某些标头，例如True-Client-IP和User-Agent。

• 与在一组服务器上运行的传统分布式负载测试相比，它在成本和性能方面更为有效。 管理一组服务器以进行分布式负载测试的费用每月为$ 1,000或更多； 如果使用无服务器堆栈，则可通过按需配置计算资源将其每月减少至100美元。

• 我们已将其扩展为每分钟50,000个请求，但它应该能够处理超过100,000个请求/分钟。

• 与传统的负载测试工具不同，新的负载测试可以立即启动并停止，传统的负载测试工具可能需要花费几分钟来生成测试计划并将测试数据分发到负载测试服务器。

• 它可以将流量按百分比增加或减少，以充当更传统的负载测试。

• 它的插件系统使您可以切换插件以更改其行为。 例如，您可以从过去的重播（即，重播过去的请求）切换到实时重播（即，当请求进入时重播请求）。

• 当前，它可以从Application Load Balancer和Classic Load Balancer弹性负载均衡器（ELB）重放日志，并且即将推出对其他负载均衡器的支持。

这个怎么运作

ShadowReader由四个不同的Lambda组成：一个解析器，一个Orchestrator，一个Master和一个Worker。

当用户访问网站时，负载均衡器（在这种情况下为ELB）通常会路由请求。 ELB路由请求时，它将记录事件并将其发送到S3。

接下来，ShadowReader通过CloudWatch事件每分钟触发一次解析器Lambda，该事件解析该分钟在S3上的最新访问（ELB）日志，然后将解析的URL传送到另一个S3存储桶中。

在系统的另一侧，ShadowReader也会每分钟触发一次Orchestrator lambda。 该Lambda保存系统的配置和状态。

然后，协调器调用Master Lambda函数。 主服务器从协调器接收有关要重播哪个时间片的信息，并从S3解析URL的存储桶（由解析器存储在其中）下载相应的数据。

Master Lambda将负载测试URL分成较小的批次，然后调用并将每个批次传递到Worker Lambda。 如果必须发出800个请求，则将调用八个辅助Lambda，每个处理100个URL。

最后，Worker接收从主服务器传递的URL，并开始对所选测试环境进行负载测试。

大局观

随着我们从稳态应用程序规模调整到按需模型，在无服务器基础架构的负载测试中，可重现性的挑战变得越来越重要。 设计ShadowReader并考虑到Edmunds的基础结构时，任何利用ELB的应用程序都可以充分利用它。 很快，它将支持重播任何生成流量日志的服务的流量。

随着项目的进行，我们希望看到它能够与下一代无服务器运行时（例如Knative）兼容。 我们也希望随着无服务器的普及，其他开放源代码社区也为其基础架构构建类似的工具链。

入门

如果您想测试驱动器ShadowReader，请查看GitHub存储库 。 README包含操作方法指南和包含电池的演示 ，该演示将部署所有必要的资源以尝试在您的AWS账户中进行实时重播。

我们很想听听您的想法并欢迎您的贡献。 请参阅参与指南以开始使用！

---

本文基于在 Carlos Macasaet，Sharath Gowda和Joey Davis的帮助下 ，在 Edmunds技术博客 上发布的“ 如何通过使用ShadowReader修复Node.js内存泄漏来将生产流量重播到QA中” 。 Yuki Sawa 还 于3月7日至10日在加利福尼亚州帕萨迪纳（ SCaLE 17x ） 上将 其作为ShadowReader进行 了演示 ， 以无服务器负载测试的方式重放生产流量 。

翻译自: https://opensource.com/article/19/3/shadowreader-serverless

服务器cpu负载和内存负载