最佳实践 - Amazon Managed Streaming for Apache Kafka
将集群设置为正确大小：每个代理的分区数 将集群设置为正确大小：每个集群的代理数构建高度可用的集群监控 CPU 使用率监控磁盘空间调整数据保留参数监控 Amaze Kafka 内存请勿添加非 MSK 代理启用传输中加密重新分配分区
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅中国的 Amazon Web Services 服务入门。

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

最佳实践

本主题概述了使用 Amazon MSK 时应遵循的一些最佳实践。

将集群设置为正确大小：每个代理的分区数

下表显示了您可以每个代理拥有的最大分区数（包括领导和关注副本）。

代理类型 每个代理的最大分区数（包括领导和关注副本）
kafka.t3.small 300
kafka.m5.large 或者 kafka.m5.xlarge 1000
kafka.m5.2xlarge 2000
kafka.m5.4xlarge、kafka.m5.8xlarge、kafka.m5.12xlarge、kafka.m5.16xlarge，或者kafka.m5.24xlarge 4000

如果每个 Broker 的分区数超过上表中指定的最大值，则无法在集群上执行以下任何操作：

  • 更新集群配置

  • 更新集群的 Apache Kafka 版本

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

  • 关联一个Amazon Secrets Manager具有 SASL/SCRAM 身份验证的集群的密钥

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

将集群设置为正确大小：每个集群的代理数

要确定的正确代理数量并了解成本，请参阅MSK 规模和定价电子表格。此电子表格提供了与类似的、自我管理的基于EC2 的 Amazon Kafka 相比，估计的大小和相关 Amazon MSK 成本。有关电子表格中的输入参数的更多信息，请将鼠标指针悬停在参数描述的上方。本表提供的估计是保守的，为新集群提供了一个起点。集群性能、大小和成本取决于您的使用案例，我们建议您通过实际测试进行验证。

要了解底层基础架构对 Apache Kafka 性能的影响，请参阅调整您的 Apache Kafka 集群大小以优化性能和成本的最佳实践中的Amazon大数据博客。博客文章提供了有关如何调整集群大小以满足吞吐量、可用性和延迟要求的信息。它还提供了诸如何时应该扩展等问题的答案向上与比例出，以及有关如何持续验证生产集群大小的指导。

构建高度可用的集群

使用以下建议，以便在更新期间（例如在更新代理类型或 Amazon MSK 更换代理时），您可以高度可用 MSK。

  • 设置一个三可用区集群。

  • 确保重复因子 (RF) 至少为 3。请注意，在滚动更新期间，RF 为 1 可能会导致脱机分区；RF 为 1 可能会导致数据丢失。

  • 将最小同步副本数 (minISR) 设置为最多 RF - 1。minISR 等于 RF 可能会阻止在滚动更新期间生成到集群。当一个副本处于脱机状态时，minISR 为 2 使三向复制主题可用。

  • 确保客户端连接字符串至少包含来自每个可用区的一个 Broker。在客户端的连接字符串中具有多个代理允许在特定代理脱机进行更新时进行故障转移。有关如何获取具有多个代理的连接字符串的信息，请参阅获取 Amazon MSK 集群的引导代理。

监控 CPU 使用率

Amazon MSK 强烈建议您保持代理的总 CPU 使用率（定义为CPU User + CPU System) 低于 60%。当你有至少 40% 的集群总 CPU 可用时，Apache Kafka 可以在必要时在集群中的代理之间重新分配 CPU 负载。例如，当 Amazon MSK 检测到代理故障并从中恢复时，就说明了何时需要执行此操作；在这种情况下，Amazon MSK 会执行自动维护，例如修补。另一个例子是当用户请求代理类型更改或版本升级时；在这两种情况下，Amazon MSK 部署的滚动工作流程一次让一个代理下线。当具有潜在分区的代理下线时，Apache Kafka 会重新分配分区领导以将工作重新分配给集群中的其他代理。通过遵循此最佳实践，您可以确保集群中有足够的 CPU 余量来容忍此类操作事件。

您可以使用亚马逊 CloudWatch 指标数学创建复合指标是CPU User + CPU System. 设置当复合指标达到平均 CPU 利用率达到 60% 时触发的警报。触发此警报警报后，使用下列选项之一扩展集群：

  • 选项 1（推荐）：更新您的经纪商类型到下一个较大的类型。例如，如果当前类型是kafka.m5.large，更新集群以使用kafka.m5.xlarge. 请记住，当您更新集群中的代理类型时，Amazon MSK 会以滚动方式使代理脱机，并暂时将分区领导重新分配给其他代理。每个经纪商的规模更新通常需要 10-15 分钟。

  • 选项 2：如果有一些主题包含从使用循环写入的生产者那里摄取的所有消息（换句话说，消息没有键入，排序对消费者来说并不重要），扩展你的集群通过添加经纪人。同时向吞吐量最高的现有主题添加分区。接下来，使用kafka-topics.sh --describe以确保将新添加的分区分配给新代理。与前一个选项相比，此选项的主要好处是您可以更精细地管理资源和成本。此外，如果CPU负载明显超过60％，则可以使用此选项，因为这种形式的扩展通常不会导致现有代理的负载增加。

  • 选项 3：通过添加 broker 扩展集群，然后使用名为的分区重新分配工具重新分配现有分区kafka-reassign-partitions.sh. 但是，如果您使用此选项，则在重新分配分区后，集群将需要花费资源将数据从代理复制到代理。与之前的两个选项相比，这可以显著增加集群的负载。因此，当 CPU 利用率高于 70% 时，Amazon MSK 不建议使用此选项，因为复制会导致额外的 CPU 负载和网络流量。仅当前两个选项不可行时，Amazon MSK 才建议使用此选项。

其他建议：

  • 监视每个代理的总 CPU 利用率，作为负载分配的代理。如果 broker 的 CPU 利用率一直不均衡，则可能表明负载在集群内分布不均匀。Amazon MSK 建议使用巡航控制通过分区分配持续管理负载分配。

  • 监视生产和使用延迟。生产和消费延迟会随着 CPU 利用率呈线性增长。

监控磁盘空间

要避免出现因磁盘空间不足而无法保存消息的情况，您可以创建一个 CloudWatch 警报器监视KafkaDataLogsDiskUsed指标。当此指标的值达到或超过 85% 时，请执行下列一项或多项操作：

  • 使用 自动扩展。您也可以手动增加代理存储空间，如中所述手动扩展.

  • 缩短消息保留期或减小日志大小。有关如何做到这一点的信息，请参阅调整数据保留参数。

  • 删除未使用的主题。

有关如何设置和使用警报的信息，请参阅使用 Amazon CloudWatch Alarms. 有关 Amazon MSK 指标的完整列表，请参阅监控 Amazon MSK 集群.

调整数据保留参数

使用消息不会将其从日志中删除。要定期释放磁盘空间，您可以明确指定一个保留时间段，即消息在日志中保留的时间。您也可以指定保留日志大小。当达到保留时间段或保留日志大小时，Apache Kafka 会开始从日志中删除非活动段。

要在集群级别指定保留策略，请设置以下一个或多个参数：log.retention.hours、log.retention.minutes、log.retention.ms 或 log.retention.bytes。有关更多信息，请参阅 自定义 MSK 配置。

您也可以在主题级别指定保留参数：

  • 要为每个主题指定一个保留时间段，请使用以下命令。

    kafka-configs.sh --zookeeper ZooKeeperConnectionString --alter --entity-type topics --entity-name TopicName --add-config retention.ms=DesiredRetentionTimePeriod

  • 要为每个主题指定一个保留日志大小，请使用以下命令。

    kafka-configs.sh --zookeeper ZooKeeperConnectionString --alter --entity-type topics --entity-name TopicName --add-config retention.bytes=DesiredRetentionLogSize

您在主题级别指定的保留参数优先于集群级别参数。

监控 Amaze Kafka 内存

我们建议您监控 Apache Kafka 使用的内存。否则，可能会导致集群不可用。

要确定 Apache Kafka 使用了多少内存，您可以监视HeapMemoryAfterGC指标。HeapMemoryAfterGC是垃圾回收后使用中的总堆内存的百分比。建议您创建一个 CloudWatch 警报在以下情况下采取行动HeapMemoryAfterGC增加到 60% 以上。

您可以执行的减少内存使用率的步骤各不相同。它们取决于你配置 Apache Kafka 的方式。例如，如果您使用事务性消息传递，则可以减少transactional.id.expiration.ms你的 Apache Kafka 配置中的值来自604800000ms 到86400000毫秒（从 7 天到 1 天）。这减少了每个事务的内存占用。

请勿添加非 MSK 代理

如果你使用 Apache ZooKeeper 命令添加代理，这些代理将不会被添加到您的 MSK 集群和您的 Apache ZooKeeper 将包含有关集群的错误信息。这可能会导致丢失数据。有关受支持的集群操作，请参阅Amazon MSK：工作方式。

启用传输中加密

有关传输中加密以及如何启用此加密的信息，请参阅传输中加密。

重新分配分区

要将分区移动到同一集群上的不同代理，您可以使用名为 kafka-reassign-partitions.sh 的分区重新分配工具。例如，在添加新代理来扩展集群后，您可以通过将分区重新分配给新代理来重新使集群达到平衡。有关如何向集群添加代理的信息，请参阅扩展 Amazon MSK 集群。有关分区重新分配工具的信息，请参阅 Apache Kafka 文档中的扩展集群。