亚马逊云科技-监控Redis工作负载GenAI最佳实践
关键字: [yt, Amazon ElastiCache, Amazon Elasticache Monitoring, Redis Performance Monitoring, Cloudwatch Metrics Analysis, Latency Impact Analysis, Slow Command Logging]
本文字数: 400, 阅读完需: 2 分钟
导读
在一场亚马逊云科技网络研讨会上,演讲者阐释了”在Amazon ElastiCache上监控Redis工作负载:最佳实践”。演讲者详细探讨了如何监控在Amazon ElastiCache上运行的Redis工作负载的性能,并解释了需要监控的关键指标,包括CPU利用率、网络流量、内存使用情况和命令延迟。演讲重点介绍了如何利用Amazon ElastiCache和Amazon CloudWatch来监控Redis集群的性能,识别潜在的瓶颈,并为运行缓慢的命令设置警报,从而优化资源利用率和应用程序性能。
演讲精华
以下是小编为您整理的本次演讲的精华，共100字，阅读时间大约是0分钟。
亚马逊云科技 - 监控 Redis 工作负载 GenAI 最佳实践
在本次网络研讨会中,我们将探讨在 Amazon ElastiCache 上监控 Redis 工作负载的一些最佳实践。作为 ElastiCache 专家解决方案架构师,我很高兴能与您分享关于这个主题的见解。
我们将简要介绍 Amazon CloudWatch 和 Amazon ElastiCache 是如何协同工作的。我们将讨论性能监控的基础知识,并深入探讨性能的最重要方面之一——延迟。最后,我将演示如何查看 CloudWatch 日志,以识别可能运行缓慢并导致延迟的命令。
今天,我们将重点关注从服务器角度监控 Redis 工作负载。我们的讨论主要集中在如何根据各种无服务器指标观察和了解 Amazon ElastiCache 集群的性能表现,以及这些指标的含义。我们今天将讨论的所有指标都可通过 Amazon CloudWatch 访问。
CloudWatch 允许我们监控资源、响应变化并优化资源利用率。通过 Amazon CloudWatch,我们每 60 秒从集群中的每个 Amazon ElastiCache 节点收集性能数据。这使客户能够了解可能影响性能的因素,根据与其工作负载相对应的阈值设置警报等。今天我将展示来自 Amazon CloudWatch 的几个图表,在演示环节,我们将浏览 Amazon CloudWatch 日志组以识别运行缓慢的命令。因此,Amazon CloudWatch 是帮助客户更好地了解集群性能的关键资源。
在 Amazon ElastiCache 中,监控实际上包括两个方面。第一个方面是从可用性的角度。Amazon ElastiCache 是一项全面托管的服务,这意味着客户无需监控节点故障、副本是否与主节点保持同步等。Amazon ElastiCache 服务会持续监控 Redis 集群和节点的运行状况和可用性,并根据事件(如节点故障)自动采取行动,如替换节点并重新同步。
我们今天要关注的是另一个方面,可以称之为客户监控,它不太关注集群的运行状况和可用性,而更多关注整体利用率和性能。每个工作负载都是不同的,每个工作负载都有自己的特征。从性能角度来看,对于缓存工作负载来说重要的事情,可能对于发布/订阅或流工作负载(如影响可用内存的驱逐)来说并不那么重要。
使用 Amazon ElastiCache 和 Amazon CloudWatch 进行性能监控,也可以从主机级别和引擎级别来观察。每个 Amazon ElastiCache 集群由一个或多个 Amazon EC2 计算节点组成。事实上,截至今天,客户可以拥有最多 500 个节点的 Amazon ElastiCache for Redis 集群,每个节点都会发出主机级别的信息,如 CPU、内存和网络利用率。即使不使用 Amazon ElastiCache,这些指标也很重要。
现在,由于 ElastiCache 运行在这些节点上,这些指标可能会影响 Redis 引擎。第二组指标来自 Redis 引擎本身。我们可以观察与 CPU 和内存效率相关的指标,但我们也可以获得与 Redis 特别相关的详细信息,如命令执行、引擎内延迟、数据复制如何影响整体性能等。
再次强调,ElastiCache 性能监控更多是关于了解集群节点的性能表现,这可能会影响应用程序的性能表现。如果节点利用率过高,客户希望知道这一点,以便可以扩大或扩展规模来提高性能。相反,如果节点利用率过低,客户也希望知道这一点,以便可以缩小规模或缩减规模来节省成本。
监控 ElastiCache 集群时,最重要的测量指标之一是延迟。延迟通常被计算为发送某物并接收响应所需的时间。Amazon ElastiCache for Redis 可通过网络提供亚毫秒级的数据访问,在引擎内部的延迟为微秒级。对于它执行的许多操作而言,延迟可被视为性能的第一个指示器。
重要的是要注意,即使某个指标可能接近高水位线或最大值,也不一定意味着集群运行不正常。例如,ElastiCache for Redis 完全在内存中运行,旨在提供非常快的速度。它还旨在高效利用内存,并根据所谓的驱逐或最大内存策略删除数据。因此,在缓存用例中,客户通常希望最大限度利用内存来存储预计算查询的结果。这意味着在某些用例中,内存利用率接近上限实际上是期望的状态,并不一定意味着存在问题。即使内存使用率很高,延迟仍可能很低。
相反,即使关键指标并未呈现高值趋势,客户仍可能会遇到延迟。例如,内存利用率可能很低,网络利用率也可能很低,但如果客户运行的命令具有较高的时间复杂度,那么可能会注意到 CPU 利用率很高,而其他指标则没有。再举一个例子,这种情况很容易发生,ElastiCache for Redis 处理数据的速度如此之快,以至于可以利用 100% 的可用网络容量。在这种情况下,内存和 CPU 可能较低,但网络利用率可能很高。
在我们深入探讨性能监控的主要组成部分之前,我想指出 Amazon ElastiCache 发出了一些非常有用的指标,涉及执行命令时的延迟。客户可以看到其中一些,会注意到它们都带有”命令延迟”一词。这些指标在调查应用程序或客户端性能不佳时非常有用。这些值以微秒为单位测量执行相关命令所需的时间。
因此,如果客户非常了解工作负载,可能希望在这些指标上设置一些 CloudWatch 警报。例如,客户可能会看到与”基于 EVAL 的命令延迟”相关的高值,这与在服务器上运行的 Lua 脚本有关。Lua 脚本在客户希望在靠近数据的服务器上运行逻辑而不是在客户端处理时非常有用。但是,Lua 脚本通常会一直运行直到执行完毕。由于 Redis 是单线程的,因此 Lua 脚本可能会阻止 Redis 引擎运行任何其他命令,直到它完成。
因此,对于监控Amazon ElastiCache for Redis集群的性能,两个最有用的指标是”SET_TYPE_CMD_DELAY”和”GET_TYPE_CMD_DELAY”。“SET_TYPE_CMD_DELAY”给出了修改或改变数据的命令的延迟,例如设置字符串值、更新哈希或将新条目添加到地理空间索引等。“GET_TYPE_CMD_DELAY”给出了只读命令的延迟,例如获取字符串的值、从哈希中获取字段等。
这两个指标独一无二,因为它们不局限于Redis中的特定数据结构,可以让人一眼了解写入和读取工作负载的性能。这一点很重要,因为Redis为其只读副本提供了复制。因此,如果出现较高的”GET_TYPE_CMD_DELAY”值,则可能表明应该扩大集群中的副本数量。如果出现较高的”SET_TYPE_CMD_DELAY”,则可能表明应该考虑通过添加分片来水平扩展集群,从而增加集群的写入能力。
需要注意的是,这些指标不是基于从客户端到服务器再返回的往返时间,而是Redis引擎本身的执行时间,不包括网络延迟。
影响延迟的因素包括CPU、网络容量和内存。由于Redis是单线程进程,密切关注CPU非常重要。网络容量会根据所选的ElastiCache节点类型而有所不同。由于ElastiCache for Redis可以从内存读取和写入内存,完全避免从磁盘获取数据,因此它比基于磁盘的数据库更有可能达到集群的最大网络容量。
当接近Redis集群的最大内存时,Redis引擎需要更密切地跟踪内存,并可能开始驱逐键,这会为每个周期增加额外的CPU时间。
客户端连接也可能影响性能。需要监控的两个主要指标是”curr_connections”(Redis引擎注册的并发和活动连接数)和”new_connections”(Redis在特定时间段内接受的连接数)。大量新连接快速打开和关闭可能会影响节点的性能。因此,建议客户端在可能的情况下重用现有连接,方法是在所选客户端中实现连接池。
除了通过Amazon CloudWatch监控的指标之外,从集群获取性能的标准基线也是一个好主意。Redis提供了一些实用程序,可以帮助人们了解集群的性能和延迟能力,如Redis CLI命令行实用程序和redis-benchmark实用程序。
ElastiCache节点可以提供大量网络容量、CPU和内存。但除此之外,人们还可以进行水平扩展。最近的测试显示,使用250个节点的ElastiCache for Redis集群实现了每秒超过900万次写入和每秒超过4000万次读取。ElastiCache for Redis集群现在可以扩展到500个节点,这将提供更快的性能。
最后,Amazon ElastiCache for Redis引入了一项新功能,允许客户将来自Redis慢日志的事件发送到Amazon CloudWatch日志组,以便人们可以监控并在某些命令违反定义的阈值时发出警报。人们可以在创建新集群或修改现有集群时启用慢日志传递。
在这个演示中,演示者选择了要修改的集群,单击操作下拉菜单并选择”查看管理日志”。从这里,演示者单击”启用慢日志”按钮。演示者将日志格式选择为JSON,然后选择CloudWatch Logs作为目的地。现在演示者可以选择创建新的日志组或选择现有的日志组。演示者只需选择一个为此网络研讨会创建的名为”monitoring-cluster-logs”的日志组,然后单击保存。我们可以看到日志状态已更改为”启用中”。因此,我们现在执行的任何命令,如果执行时间超过10毫秒,都将发送到我们指定的Amazon CloudWatch日志组。顺便说一下,10毫秒是默认值。您可以通过更新集群参数组中的”slowlog-log-slower-than”参数来更改此值。
在实际运行将最终向CloudWatch发送慢日志事件的命令之前,让我们先设置一个警报,当我们收到一个时它会提醒我们。因此,让我们回到Amazon CloudWatch控制台。演示者将单击”所有指标”,然后在”日志指标”部分,再单击”日志组指标”。现在演示者将向下滚动,直到看到名为”monitoring-cluster-logs”的日志组,然后选择与该日志组关联的”IncomingLogEvents”指标。演示者将切换到”图形指标”选项卡,然后单击右下角的警报铃图标。我们可以看到大部分警报已为我们填写好了。演示者将把周期从5分钟改为1分钟。然后演示者将更改条件,以便当此指标大于零时触发警报。现在演示者将单击”下一步”,为简单起见,演示者将删除通知。但请记住,如果警报进入警报状态,您可以使用SNS主题进行通知。演示者将向下滚动并单击”下一步”。最后,演示者将此警报命名为”slow-log-alarm”,然后单击”下一步”。我们可以预览演示者的警报。因此,演示者现在将向下滚动并单击”创建警报”。
现在我们已经设置了日志传递,并且还设置了一个CloudWatch警报,如果记录了任何命令在慢日志中,它会提醒我们,让我们去测试一下。
现在我们在Redis CLI中,演示者将运行一个您实际上不应在生产环境中运行的命令,但演示者在这里运行它,以便您可以看到它的影响。演示者预先在此集群中填充了大约100万个键,演示者将运行”keys”命令,它将遍历所有键并在终端窗口中列出它们。此命令将需要几秒钟才能运行。
好的,我们可以看到它花费的时间远远超过10毫秒的阈值。那么让我们转到Amazon CloudWatch查看结果。
现在我们在Amazon CloudWatch控制台中。演示者将单击”日志”部分左侧的”日志组”,然后向下滚动到演示者之前选择的名为”monitoring-cluster-logs”的日志组。您可以看到我们拥有的日志流。请注意,如果您愿意,可以让多个ElastiCache集群将日志传送到同一个日志组。演示者可以单击想查看的日志流。演示者将看到最近从ElastiCache传送到CloudWatch的慢日志事件。
让我们展开最新条目。现在我们对Redis引擎内部发生的任何导致高延迟的命令有了很好的了解。在这里,我们可以看到执行”keys”命令的客户端的IP地址,然后它花费了近半秒的时间运行。那么我们在Redis终端看到的时间是怎么回事呢,可能需要一段时间通过网络传输100万个键名,但这与Redis引擎迭代键的速度无关。这里最高的延迟显然是在网络上,但重要的是要注意,“keys”命令本身在引擎内部执行时花费了近半秒钟,在此期间,任何其他命令都无法在该节点上运行。
那么我们之前创建的警报呢?让我们看看它的样子。我们可以单击左侧的”处于警报状态”链接,在这里我们可以看到我们创建的警报处于警报状态。
因此,总结一下,除了我们可以通过Amazon CloudWatch监控主机和引擎级别的指标之外,我们还能够将运行缓慢的命令记录到Amazon CloudWatch,这可以让我们深入了解可能导致集群和应用程序延迟的原因。
总结
在这个富有洞见力的网络研讨会中,演讲者深入探讨了在Amazon ElastiCache上监控Redis工作负载的最佳实践,强调了理解和优化性能的重要性。主要涉及的要点包括:
- Amazon CloudWatch在监控ElastiCache资源方面发挥着关键作用,每60秒收集一次性能数据,并允许客户根据阈值设置警报。
- 监控ElastiCache涉及两个方面:可用性(由服务处理)和性能(客户监控),重点关注利用率和整体集群性能。
- 延迟是一个关键的性能指标,受CPU、内存、网络容量和客户端连接等因素的影响。监控诸如”SET类型命令延迟”和”GET类型命令延迟”等指标可以洞察写入和读取工作负载的性能。
- 有效的监控需要分析各种指标,包括CPU利用率(引擎和主机)、网络流量(入站字节数/出站字节数、复制字节数)、内存使用情况(用于缓存的字节数、数据库内存使用百分比、驱逐)以及连接管理(当前连接数、新建连接数)。
演讲者强调根据这些指标主动扩展集群的重要性,并演示了如何启用将慢日志传送到Amazon CloudWatch,从而允许客户监控和获得关于可能导致延迟的慢运行命令的警报。总的来说,这个网络研讨会为与会者提供了优化Amazon ElastiCache上Redis工作负载性能的宝贵知识和工具。
亚马逊云科技（Amazon Web Services）是全球云计算的开创者和引领者。提供200多类广泛而深入的云服务，服务全球245个国家和地区的数百万客户。亚马逊云科技致力于成为企业构建和应用生成式AI的首选，通过生成式AI技术栈，提供用于模型训练和推理的基础设施服务、构建生成式AI应用的大模型等工具、以及开箱即用的生成式AI应用。深耕本地、链接全球 – 在中国，亚马逊云科技通过安全、稳定、可信赖的云服务，助力中国企业加速数字化转型和创新，并深度参与全球化市场。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
