最佳实践 - Amazon Managed Streaming for Apache Kafka
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅中国的 Amazon Web Services 服务入门

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

最佳实践

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

将集群设置为正确大小

创建 MSK 集群时,可以指定代理的类型和数量。

每个代理的分区数

下表显示了建议的每个代理的最大分区数(包括前导和跟随者副本)。但是,每个代理的分区数受用例和配置的影响。我们还建议您自己执行测试,以确定适合您的代理的类型。有关不同代理类型的更多信息,请参阅代理类型

Broker 类型 每个代理的最大分区数(包括前导和跟随副本)
kafka.t3.small 300
kafka.m5.large 或者 kafka.m5.xlarge 1000
kafka.m5.2xlarge 2000
kafka.m5.4xlargekafka.m5.8xlargekafka.m5.12xlargekafka.m5.16xlarge,或者kafka.m5.24xlarge 4000

有关选择分区数的指导,请参阅 Apache Kafka 支持每个集群 20 万个分区

每个集群的代理数

要确定的适当代理数量并了解成本,请参阅MSK 尺寸和定价电子表格。此电子表格提供了与类似的、自我管理的基于 EC2 的 Apache Kafka 集群相比,估计的大小和相关 Amazon MSK 成本。有关电子表格中的输入参数的更多信息,请将鼠标指针悬停在参数描述的上方。此电子表格是由三个生成器和三个使用器运行测试工作负载并确保 P99 写入延迟少于 100 毫秒来生成的。这可能不会反映您的工作负载或性能预期。因此,我们建议您在预置集群后测试工作负载。

构建高度可用的集群

使用以下建议,以便在更新期间(例如,更新代理类型或 Apache Kafka 版本时)或 Amazon MSK 更换代理时可以高度可用。

  • 确保双可用区集群的重复因子 (RF) 至少为 2,三可用区集群的 RF 至少为 3。在滚动更新期间,RF 为 1 可能会导致脱机分区。

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

  • 确保客户端连接字符串包含多个代理。在客户端的连接字符串中具有多个代理允许在特定代理脱机进行更新时进行故障转移。有关如何获取具有多个代理的连接字符串的信息,请参阅为亚马逊 MSK 集群获取引导经纪商

监控 CPU 使用率

亚马逊 MSK 强烈建议您将经纪商的总 CPU 利用率保持在 60% 以下。总 CPU 使用率是CpuUserCpuSystem指标。当您至少有 40% 的集群总 CPU 可用时,Apache Kafka 可以根据需要在集群中的代理程序之间重新分配 CPU 负载。当 Amazon MSK 检测到代理故障并从中恢复时,这是必要的一个示例;在这种情况下,Amazon MSK 会执行自动维护,如修补。另一个示例是当用户请求经纪商类型更改或版本升级时;在这两种情况下,Amazon MSK 会部署滚动工作流,使一个经纪商一次脱机。当具有潜在客户分区的经纪商脱机时,Apache Kafka 会重新分配分区领导层,以将工作重新分配给集群中的其他经纪商。通过遵循这一最佳实践,您可以确保您的集群中有足够的 CPU 空间来容忍这些操作事件。

您可以使用Amazon CloudWatch 指标数学创建一个复合 CPU 指标,该指标是CpuUserCpuSystem。设置当复合 CPU 指标达到 60% 的 P95 时触发的警报。触发警报时,使用以下选项之一扩展集群:

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

  • 选项 2:如果存在从使用循环写入的生产者接收的所有消息的主题(换句话说,消息没有键入,排序对消费者并不重要),扩展您的集群通过添加经纪人。还可以向具有最高吞吐量的现有主题添加分区。然后,使用kafka-topics.sh --describe以确保新添加的分区被分配给新的代理。与前一个选项相比,此选项的主要优点是您可以更精细地管理资源和成本。此外,如果 CPU 负载显著超过 60%,则可以使用此选项,因为这种扩展形式通常不会导致现有代理商的负载增加。

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

其他建议:

  • 监视每个代理的总 CPU 利用率,作为负载分配的代理。如果代理程序的 CPU 利用率始终不均衡,则可能表明负载在群集中分布不均匀。Amazon MSK 建议使用巡航控制通过分区分配连续管理负载分配。

  • 监控生成和消耗延迟。生成和消耗延迟可能会随 CPU 利用率而线性增加。

监控磁盘空间

要避免出现因磁盘空间不足而无法保存消息的情况,您可以创建一个用于 CloudWatchKafkaDataLogsDiskUsed指标。当此指标的值达到或超过 85% 时,请执行下列一项或多项操作:

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

调整数据保留参数

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

要在集群级别指定保留策略,请设置以下一个或多个参数:log.retention.hourslog.retention.minuteslog.retention.mslog.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

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

请勿添加非 MSK 代理

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

启用传输中加密

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

重新分配分区

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