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

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

最佳实践

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

将集群设置为正确大小

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

每个代理的分区数

下表显示了您可以拥有的每个代理的最大分区数(包括主管和关注副本)。

代理类型 每个代理的最大分区数(包括主管和关注副本)
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 版本

  • 将集群更新为较小的经纪商类型

  • 关联Amazon Secrets Manager使用具有 SASL/SCRAM 身份验证的群集保密

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

每个集群的代理数

要确定 MSK 集群的适当代理数量并了解成本,请参阅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 负载。一个必要的例子是亚马逊 MSK 检测到经纪商故障并从中恢复过来;在这种情况下,亚马逊 MSK 执行自动维护,例如修补。另一个例子是,当用户请求经纪商类型更改或版本升级时;在这两种情况下,Amazon MSK 部署滚动工作流程,一次使一个经纪商离线。当拥有潜在客户分区的经纪商离线时,Apache Kafka 会重新分配分区领导层,将工作重新分配给集群中的其他经纪商。通过遵循此最佳实践,您可以确保群集中有足够的 CPU 余量来容忍类似的操作事件。

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

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

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

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

其他建议:

  • 作为负载分配的代理,监控每个代理的 CPU 总使用率。如果经纪商的 CPU 利用率始终不均衡,那可能是集群内负载分配不均匀的迹象。Amazon MSK 建议使用控制巡航通过分区分配持续管理负载分配。

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

监控磁盘空间

要避免出现因磁盘空间不足而无法保存消息的情况,您可以创建一个用于监视KafkaDataLogsDiskUsed指标。当此指标的值达到或超过 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 文档中的扩展集群