提升 Apache Kafka 的可扩展性与弹性

关键要点

在这篇文章中，我们探讨了如何使用 Amazon MSK 的分层存储功能来优化 Apache Kafka 的存储成本和性能，提升系统的可扩展性与可靠性。通过简化数据管理流程，分层存储助力快速代理恢复、高效负载均衡和无缝扩展，大大增强了 Kafka 集群的可用性。

自从分层存储在Amazon Managed Streaming for Apache KafkaAmazon MSK推出以来，众多客户已经借助此功能来优化存储成本并提升性能。我们在之前的文章中探讨了Kafka 的内部机制、最大化Amazon MSK 的潜力以及深入分析Amazon MSK 的分层存储。本文将深入探讨分层存储如何帮助更快地恢复代理以及快速进行分区迁移，促进更快的负载均衡和代理扩展。

Apache Kafka 的可用性

Apache Kafka 是一种分布式日志服务，旨在提供高可用性和故障容忍能力。Kafka 的核心机制包括：

Kafka 复制：Kafka 将数据组织成主题，然后再划分为多个分区。每个分区在多个代理中复制，其中一个代理充当领导者，其他则为跟随者。如果领导者代理失败，系统会自动选举一个跟随者成为新的领导者，从而确保持续的数据可用性。复制因子决定了每个分区的副本数量。Kafka 会维护一个同步副本列表ISRs，这些副本与领导者保持同步。

生产者确认：Kafka 生产者可以指定写入操作的确认级别，确保在生产者收到确认之前，数据已经在指定数量的副本上持久化，降低数据丢失的风险。

消费者组再平衡：Kafka 消费者组成消费者组，组内每个消费者负责消费子集的分区。如果某个消费者失败，其所消费的分区会自动重新分配给组内其他消费者，以保证数据持续消费。

Zookeeper 或 KRaft 进行集群协调：Kafka 使用 Apache ZooKeeper 或 KRaft 来进行集群协调和元数据管理，确保在失败恢复时保持集群的一致状态。

Kafka 的存储架构对可用性与弹性的影响

尽管 Kafka 提供了健全的容错机制，但在传统的 Kafka 架构中，代理本地存储附加的存储卷。这种存储与计算资源的紧密耦合可能引发多种问题，从而影响集群的可用性和弹性：

代理恢复缓慢：当代理失败时，恢复过程需要将数据从剩余的副本转移到新的代理。对于大数据量而言，这一过程可能较慢，导致可用性周期过长和恢复时间增加。

负载均衡效率低：在 Kafka 中，负载均衡需要在代理之间移动分区以均匀分配负载。这一过程可能资源密集且耗时，因为需要在代理间传输大量数据。

扩展限制：传统上，扩展 Kafka 集群，需要添加新代理并在扩展后的代理上重新平衡分区。这个过程可能具有破坏性且耗时，尤其是对拥有大量数据的大型集群来说。

Amazon MSK 分层存储如何改善可用性和弹性

Amazon MSK 的分层存储功能允许配置本地和远程层。通过将计算和存储资源有效解耦，它解决了上述挑战，提升了 Kafka 集群的可用性和弹性。您可以获得以下好处：

更快的代理恢复：使用分层存储时，数据会自动从速度较快的 Amazon 弹性块存储Amazon EBS转移到更具成本效益的存储层。新消息最初写入 Amazon EBS，以确保性能快速。根据本地数据保留策略，Amazon MSK 会透明地将数据传输到分层存储，从而为新消息释放 EBS 存储空间。代理一旦出现故障并恢复因节点或卷故障，其追赶过程更快，因为它只需追赶存储在本地层的数据。

高效的负载均衡：通过 Amazon MSK 的分层存储，负载均衡变得更加高效，因为重新分配分区时需要移动的数据更少。这一过程更快，资源消耗更低，使得负载均衡操作可以更频繁、无缝进行。

更快的扩展：使用分层存储扩展 MSK 集群是一个无缝的过程。可以向集群添加新代理，而无需大量的数据传输和更长的分区重新平衡时间。新代理能够更快地分担流量，因其追赶过程所需的时间更少，从而提高整体集群吞吐量，减少扩展操作中的停机时间。

如下面的图所示，MSK 代理和 EBS 存储卷是紧密耦合的。在部署了三个可用区的集群时，当您创建一个复制因子为三的主题时，Amazon MSK 会将这三个副本分散到所有三条可用区中，而与该代理连接的 EBS 存储卷将存储在所有这三个可用区中传播的主题数据。如需将分区从一个代理移动到另一个代理，Amazon MSK 需要在现有代理与新的代理之间转移所有段数据包括活动和闭合的数据段。

然而，当您为该主题启用分层存储时，Amazon MSK 会透明地将主题的所有闭合段从 EBS 存储卷转移到分层存储。该存储提供了内置的耐持久性和高可用性，几乎具备无限的存储能力。通过将闭合段移动到分层存储，并仅在本地卷上保留活动段，您无需关心主题大小而保持本地存储占用最小。如果需要将分区移动到新代理，代理之间的数据移动将非常有限。以下图展示了这种更新的配置。

Amazon MSK 的分层存储解决了 Kafka 传统存储架构所面临的问题，使更快的代理恢复、高效的负载均衡和无缝扩展成为可能，从而增强了集群的可用性和弹性。想了解更多 Amazon MSK 分层存储的核心组件，请参考深入了解 Amazon MSK 分层存储。

真实世界测试

希望您现在理解 Amazon MSK 分层存储如何提升 Kafka 的弹性和可用性。为了进行测试，我们创建了一个三节点集群，使用新的 m7g 实例类型。我们创建了一个复制因子为 3 的主题，并且没有使用分层存储。使用 Kafka 性能工具，我们向该主题中注入了 300 GB 的数据。接着，我们向集群中添加了三个新代理。由于 Amazon MSK 不会自动将分区移动到这三个新代理中，因此在重新平衡分区之前，它们将保持空闲状态。

假设我们需要将所有分区从现有的三台代理移动到这三台新代理上。我们使用 kafkareassignpartitions 工具将分区从现有三台代理移动到新添加的三台代理。在这个分区移动操作期间，我们观察到 CPU 使用率较高，即使我们没有对集群执行其他操作。这表明高 CPU 使用率是由于向新代理复制数据。如下图所示，分区从代理 1 移动到代理 2 的操作大约花费了 75 分钟。

此外，在此期间，CPU 利用率也较高。

测试完成后，我们为主题启用了分层存储，设置 localretentionms=36000001小时和 retentionms=31536000000。我们持续监测 RemoteCopyBytesPerSec 指标，以确认数据迁移到分层存储的操作完成。经过 6 小时，我们观察到在 RemoteCopyBytesPerSec 指标上没有活动，这表明所有闭合段已成功移动到分层存储。有关如何在现有主题上启用分层存储的指南，请参考在现有主题上启用和禁用分层存储。

随后，我们再次执行相同的测试，将分区移动到三台空置的代理上。这一次，分区移动操作在不足 15 分钟内完成，且 CPU 使用率没有显著变化，如下图所示。这是因为启用分层存储后，所有数据已移动到分层存储，EBS 存储卷中只保留了活动段。分区移动操作仅需移动小型活动段，因此所需时间较少，CPU 消耗也微乎其微。

结论

本文探讨了 Amazon MSK 分层存储如何显著提升 Kafka 的可扩展性和弹性。通过自动将旧数据移动到成本更低的分层存储，Amazon MSK 减少了必须在本地 EBS 存储卷上管理的数据量。这显著提高了关键 Kafka 操作，如代理恢复、领导者选举和分区重新分配的速度和效率。在测试场景中，启用分层存储将分区在代理之间移动的时间从 75 分钟减少到不足 15 分钟，且影响 CPU 的程度很小。这增强了 Kafka 集群的响应能力和自我修复能力，对于确保高性能运营至关重要，即使在数据量持续增长的情况下也是如此。

如果您在运行 Kafka 时面临可扩展性或弹性问题，我们强烈建议您使用带有分层存储功能的 Amazon MSK。利用这一强大功能，您可以释放 Kafka 的真正可扩展性，确保您的关键应用能够跟上不断增长的数据需求。

要开始使用，请参考在现有主题上启用和禁用分层存储。此外，还可以查看针对 Amazon MSK 的 Cruise Control 自动部署模板，以轻松地重新平衡您的工作负载。

作者介绍

Sai Maddali 是 AWS 的高级产品管理经理，负责 Amazon MSK 的产品团队。他热衷于了解客户需求，并利用技术提供服务，帮助客户构建创新应用。业余时间，他喜欢旅行、烹饪和跑步。

Nagarjuna Koduru 是 AWS 的首席工程师，目前在 AWS 管理流媒体 KafkaMSK工作。他领导了 MSK Serverless 和 MSK 分层存储产品的开发团队。此前，他领导了负责实时跟踪商店内顾客位置的 Amazon JustWalkOutJWO团队。他在扩展有状态流处理架构以支持更大的商店格式和降低系统总体成本方面发挥了关键作用。他对流处理、消息传递和分布式存储架构有着浓厚的兴趣。

Masudur Rahaman Sayem 是 AWS 的流数据架构师。他与全球的 AWS 客户合作，设计和构建数据流架构以解决现实世界中的业务问题。他专注于优化使用流数据服务和 NoSQL 的解决方案。Sayem 对分布式计算充满热情。

标签 Amazon Managed Streaming for Apache Kafka Analytics

加载评论