首先，

本文是New Relic Advent Calendar 2023系列1的第13天。

我要告诉你一个关于注意到 ElasticCache for Redis 正在使用到带宽限制的故事，是通过检查 New Relic 的分布式追踪而发现的。

在New Relic平台上进行确认。

通过New Relic的分布式追踪功能，可以在时间轴上分析一个事务内所进行操作的详细情况。

这是关于我们公司的《朝日新闻数字》文章页面（例如：https://www.asahi.com/articles/ASRDF3R1GRDFUTFK003.html）的交易。

当我使用New Relic监视事务时，我注意到这些跨度出现了多次。

课题

问题是Redis的响应速度太慢了。
即使考虑到并发处理，从Redis得到的响应时间为6毫秒或5毫秒，这让人感到意外。
我们希望Redis的慢查询日志的默认值应该在微秒级别。

根据Redis官方提供的优化指南资料，看起来情况可能并不理想。

调查 chá)

首先，我确认了CPU和内存的使用率。
由于AWS指标尚未与New Relic连接，因此我使用Cloudwatch Metrics来确认这两个指标。

我们正在使用的实例是cache.m4.large，但是CPU使用率和剩余内存都看起来正常。

※本次调查的ElastiCache for Redis启用了集群模式，但只有两个节点，并且未发出READONLY命令，因此所有请求都被重定向到主实例。

The reason (原因)

工作负载的通信量达到了cache.m4.large的基本带宽上限。

解决方式

此外，cache.m4.large每月的费用是0.226美元，而cache.m7g.large则是0.202美元。

在规模扩大前后，文章页面的整体响应时间缩短约30毫秒，达到99%分位数水平。

虽然只是一项小改进，但很高兴发现了ElastiCache带宽存在瓶颈的问题。

总结

通过New Relic的分布式追踪功能，我们发现了Redis的响应速度较慢的问题，并解决了带宽瓶颈。通过分布式追踪功能，我们可以跨服务查看每个处理的详细情况，这样更容易发现瓶颈问题。AWS资源根据实例类型设置带宽，但是小型实例类型的文档往往没有明确标注为小型或中型。由于设计初期以来，缓存到Redis的对象越来越大，导致最初并不需要严格考虑的带宽限制已经达到了。