快速代理的最佳实践 - Amazon Managed Streaming for Apache Kafka
客户端注意事项服务器端注意事项

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

快速代理的最佳实践

本主题概述了使用快速代理时应遵循的一些最佳实践。快速代理已预先配置为实现高可用性和持久性。默认情况下，数据分布在三个可用区中，复制始终设置为 3，最小同步副本始终设置为 2。但是，要优化集群的可靠性和性能，仍需考虑几个因素。

客户端注意事项

应用程序的可用性和性能不仅取决于服务器端设置，还取决于客户端的设置。

  • 为您的客户端配置高可用性 在 Apache Kafka 这样的分布式系统中，确保高可用性对于维护可靠且容错的消息传递基础设施至关重要。代理将因计划内和计划外事件（例如升级、修补、硬件故障和网络问题）而离线。Kafka 集群可以容忍代理离线，因此 Kafka 客户端也必须妥善处理代理失效转移。有关全部详细信息，请参阅 Apache Kafka 客户端的最佳实践建议。

  • 运行性能测试，验证客户端配置是否允许用户即使在峰值负载下重启代理时，也能实现性能目标。您可以从 MSK 控制台或使用 MSK 重启集群中的代理。 APIs

服务器端注意事项

调整集群的大小：每个集群的代理数量

为基于快速代理的集群选择代理数量非常简单。每个快速代理都有定义的入口和出口吞吐能力。应使用这种吞吐能力作为调整集群大小的主要手段（然后考虑分区和连接数等其他因素，如下所述）。

例如，如果您的流媒体应用程序需要 45 MBps % 的数据入口（写入）和 90 MBps 个数据出口（读取）容量，则只需使用 3 个 express.m7g.large 代理即可满足您的吞吐量需求。每个 express.m7g.large 代理将处理 15 个入口和 30 个 MBps 出口。 MBps 有关每个快速代理大小的建议吞吐量限制，请参阅下表。如果吞吐量超过建议的限制，您可能会遇到性能下降的情况，因此应减小流量或扩展集群。如果吞吐量超过建议的限制并达到每个代理的配额，MSK 会限制客户端流量以免进一步过载。

您还可以查看 MSK 大小和定价电子表格来评估多种场景，并考虑分区数等其他因素。

下表列出了各个实例大小的每个代理的建议最大吞吐量。

实例大小 入口 () MBps 出口 () MBps

express.m7g.large

 15.6 31.2

express.m7g.xlarge

 31.2 62.5

express.m7g.2xlarge

 62.5 125.0

express.m7g.4xlarge

 124.9 249.8

express.m7g.8xlarge

 250.0 500.0

express.m7g.12xlarge

 375.0 750.0

express.m7g.16xlarge

 500.0 1000.0

监控 CPU 使用率

建议将代理的总 CPU 利用率（定义为 CPU 用户 + CPU 系统）保持在 60% 以下。当集群的总 CPU 可用率至少达到 40% 时，Apache Kafka 可以在必要时在集群中的代理之间重新分配 CPU 负载。由于计划内或计划外事件，可能需要这么做。计划内事件的一个示例是集群版本升级，在此期间，MSK 通过逐一重启来更新集群中的代理。计划外事件的一个示例是代理硬件故障，最坏的情况是可用区故障，可用区中的所有代理都因此受到影响。当具有分区领导副本的代理离线时，Apache Kafka 会重新分配分区领导权，以将工作重新分配给集群中的其他代理。通过遵循此最佳实践，您可以确保集群中有足够的 CPU 余量来容忍此类操作事件。

您可以使用亚马逊 CloudWatch 用户指南中的将数学表达式与 CloudWatch 指标结合使用来创建复合指标，即 CPU 用户 + CPU 系统。设置当复合指标达到 60% 的平均 CPU 利用率时触发的警报。触发此警报时，请使用以下选项之一扩展集群：

  • 选项 1：将您的代理大小更新为下一个较大的大小。请记住，当您更新集群中的代理大小时，Amazon MSK 会以滚动方式使代理离线，并暂时将分区领导权重新分配给其他代理。

  • 选项 2：通过添加代理来扩展集群，然后使用名为 kafka-reassign-partitions.sh 的分区重新分配工具来重新分配现有分区。

其他建议

  • 作为负载分配的代理，监控每个代理的 CPU 总利用率。如果代理的 CPU 利用率一直不均衡，则可能表明集群内的负载分布不均。我们建议使用 Cruise Control，通过分区分配持续管理负载分配。

  • 监控生成和使用延迟。生成和使用延迟会随着 CPU 利用率呈线性增加。

  • JMX 抓取间隔：如果您使用 Prometheus 功能启用开源监控系统，则建议您为 Prometheus 主机配置 (prometheus.yml) 使用 60 秒或更长的抓取间隔 (scrape_interval: 60s)。降低抓取间隔可能会导致集群上的 CPU 使用率过高。

调整集群的大小：每个快速代理的分区数量

如果遇到高分区、低吞吐量的用例，即分区数较高，但各分区之间没有发送流量，则每个代理可以打包多个分区，前提是您已进行了充分的测试和性能测试，证实集群在较高分区数下仍保持正常。如果每个代理的分区数量超过允许的最大值，并且您的集群过载，将会阻止您执行以下操作：

  • 更新集群配置

  • 将集群更新为较小的代理大小

  • 将AWS Secrets Manager密钥与具有 SASL/SCRAM 身份验证的集群关联

集群过载大量分区也可能导致在 Prometheus 抓取 CloudWatch 和抓取时缺少 Kafka 指标。

有关选择分区数的指导，请参阅 Apache Kafka 支持每个集群 20 万个分区。我们还建议您执行自己的测试，以确定适合您代理的大小。有关不同代理大小的更多信息，请参阅Amazon MSK 代理大小。

有关每个快速代理的建议分区数量（包括领导副本和跟随者副本），请参阅快速代理的分区配额。建议分区数量不是强制执行的，对于跨预置主题分区发送流量的场景，这是最佳的做法。

监控连接数

客户端连接至代理会消耗内存和 CPU 等系统资源。根据身份验证机制，应实施监控以确保在适用的限制范围内。要处理连接失败时的重试，可以在客户端设置 reconnect.backoff.ms 配置参数。例如，如果您希望客户端在 1 秒钟后重试连接，请将 reconnect.backoff.ms 设置为 1000。有关配置重试次数更多信息，请参阅 Apache Kafka 文档。

维度 配额

每个代理的最大 TCP 连接数（IAM 访问控制）

 3000

每个代理的最大 TCP 连接数 (IAM)

 每秒 100 个

每个代理的最大 TCP 连接数（非 IAM）

 MSK 不对非 IAM 身份验证强制执行连接限制。但应监控 CPU 和内存使用量等其他指标，以确保不会因为连接数过多而导致集群过载。

重新分配分区

要将分区移动到同一预置 MSK 集群上的不同代理，您可以使用名为 kafka-reassign-partitions.sh 的分区重新分配工具。为了安全操作，建议一次调用 kafka-reassign-partitions 时重新分配的分区数不要超过 20 个。例如，在添加新代理以扩展集群或移动分区以移除代理之后，您可以通过将分区重新分配给新代理来重新平衡该集群。有关如何向预置 MSK 集群添加代理的信息，请参阅扩展 Amazon MSK 集群中的代理数量。有关如何从预置 MSK 集群中移除代理的信息，请参阅从 Amazon MSK 集群中移除代理。有关分区重新分配工具的信息，请参阅 Apache Kafka 文档中的扩展集群。