从自建 Apache Kafka 集群迁移至 Amazon MSK

用户742405778335
183 阅读7分钟

在本文中，我们将讲解如何从IDC自建 Apache Kafka 集群迁移至Amazon Managed Streaming for Apache Kafka (Amazon MSK)的整个流程与相关操作步骤。

自托管 Apache Kafka 的难题

Apache Kafka 上的传入消息与事件主要以稳定常规流量与间歇峰值流量组成，这两类情况的流量区间分别为每秒 10000 到 12000 条消息、以及每秒 50000 到 55000 条消息。

Apache Kafka 则作为这些依赖系统与服务之间的核心消息与事件主干，位置十分关键。

如何自建Apache Kafka，那么相关代理及其相关组件（例如 Apache Zookeeper）也需要自建和维护，而且一旦架构设计不好，容易出现故障。

随着业务规模的不断增长，管理这些组件并保证正常运行时间已经成为一项重要的资源密集操作，需要专门指派额外的开发人员管理 Apache Kafka 基础设施并维持其正常运作。由于这些开发人员无法继续为业务功能的开发做出有效贡献，这种无差别的繁重工作已经在事实上导致生产力下降。

迁移至 Amazon MSK 以节约时间

因此，替换IDC的自托管 Apache Kafka，最终的选择了 Amazon MSK。借助 Amazon MSK，可以继续使用原生 Apache Kafka API，并在不更改任何代码的前提下在 AWS 上运行现有应用程序。它还能为我们提供、配置并维护 Apache Kafka 集群与 Apache Zookeeper 节点。以此为基础，能够将开发人员从基础设施管理当中解放出来，为业务编写更多创新应用。

具体实施步骤：

  1. 调整 MSK 集群大小。

  2. 将各 Apache Kafka 主题迁移至 Amazon MSK。

  3. 监控 Amazon MSK 运行状态。

调整 MSK 集群大小

为了适当调整 MSK 集群的大小，我们需要了解当前工作负载的基本动态。我们从当前基于 IDC 的 Apache Kafka 集群中检索出以下指标：

  • 生产者的写入效率——考虑监控 broker 上的指标BytesInPerSec，选择各代理的平均值，并汇总了集群中全部代理的值以估算净摄取率（请与ReplicationBytesInPerSec指标区分开来，ReplicationBytesInPerSec代表的是与其他代理间的摄取率）。

  • 消费者的消费速率——在 broker 上监控指标BytesOutPerSec，选择单一代理的平均值，而后将集群中所有代理的值进行汇总，借此估算集群的净消费率（请与ReplicationBytesOutPerSec指标区分开来，ReplicationBytesOutPerSec代表的是指向其他代理的消费率。

  • 数据复制策略——通过集群全局参数default.replication.factor以及为每个主题设定的独立参数之间进行了评估，并借此确定了复制因子的最大值。

  • 数据保留策略与磁盘利用率的目标百分比——通过集群全局参数log.retention.hours 以及为每个主题设定的独立参数之间进行了评估确定了数据保留的最高保留值。指定了已用存储空间的百分比，并估算满足用例所需要的净空间。

将各 Apache Kafka 主题迁移至 Amazon MSK

整理了将各主题迁移至 Amazon MSK 的几种可行选择：

  • MirrorMaker 2.0，这是 Apache Kafka 中随附的一款独立工具，能够以最低停机时间将数据从自托管 Apache Kafka 集群迁移至 Amazon MSK。

  • 使用消费者从自托管 Apache Kafka 集群读取数据，而后将数据写入至 Amazon MSK。这种迁移方法需要一定的停机时间。

在实践操作中，将前两种方法结合起来进行迁移。对于无法容忍长时间停机的主题，使用 MirroMaker 2.0 将数据迁移至 Amazon MSK。对于能够承受一定停机的主题，我们的内部 SLA 允许通过应用程序流量将数据从自托管 Apache Kafka 集群重新定向至 Amazon MSK。

在 MirrorMaker 方案中，我们需要在自托管实例上设置 MirrorMaker 2.0 守护程序以使用来自源集群的消息，而后将其重新发布至目标 MSK 集群。每个 MirrorMaker 2.0 线程都配备一个单独的消费程序实例，且共享同一通用生产程序。整个流程如下：

  • MirrorMaker 2.0 实例产生一个消费者进程，该进程与 Apache Zookeeper 整体交互，以支持源 Apache Kafka 集群进行主题发现。

  • 消费者进程从相关主题中读取消息。

  • MirrorMaker 2.0 生成一个生产者进程，该进程通过 Apache Zookeeper 端点与 Amazon MSK 上托管的 Apache Zookeeper fleet 进行交互。

  • 该生产程序进程通过代理端点将消费程序进程检索到的消息，转发至 Amazon MSK 的相应主题。

下图所示，为整个迁移拓扑结构。

MSK 集群创建流程需要将子网 ID 作为输入，以便代理与 Pache ZooKeeper 节点能够正确映射至客户 VPC。通过在具有主专用 IPv4 地址的各子网 ID 中创建 ENI，我们能够轻松实现这一映射。MSK 集群中随附的代理与 Apache ZooKeeper 端点将实际解析这些专用 IPv4 地址。

使用以下命令，将所有主题从基于IDC 的源集群以镜像形式保存至 Amazon MSK：

kafka-mirror-maker.sh--consumer.config config/mirrormaker-consumer.properties--producer.config config/mirrormaker-producer.properties--whitelist '*'

复制代码

上述命令包含以下细节：

  • 其中的kafka-mirror-maker.sh shell 脚本用于创建一个 tools.MirrorMaker类实例。

  • 在 mirrormaker-consumer.properties 文件中的bootstrap.servers 、group.id等由换行符分隔的键/值对下，包含有消费者配置参数。

  • 其中mirrormaker-producer.propertiesfile在bootstrap.servers、acks等由换行符分隔的键值对下，包含有生产者配置参数。

  • --whitelist选项允许大家使用 Java 样式的正则表达式，保证我们可以仅对特定主题进行镜像复制，例如使用--whitelist 'A|B'镜像复制 A 与 B 主题。

在稳定状态下，生产环境中的 MSK 集群使用以下配置举例：

  • broker 节点——6 x m5.2xlarge

  • 复制因子——3

  • 生产者数量——110 个以上

  • 消费者数量——300 个以上

  • 主题——500 个以上

  • broker 上运行的 Kstreams——55 个以上

监控 Amazon MSK 运行状态

Amazon MSK 以三种粒度级别提供多项 Amazon CloudWatch 监控指标：

  • DEFAULT

  • PER_BROKER

  • PER_TOPIC_PER_BROKER

使用最精细的PER_TOPIC_PER_BROKER粒度以实现最佳系统运行可见性。为了自动检测各类运营问题，还使用以下指标开发出自定义 CloudWatch 警报。

Amazon MSK 还支持通过端口 11001（面向 JMX Exporter）与端口 11002（面向 Node Exporter）使用 Prometheus 等监控工具与 Prometheus 格式的指标（例如 Datadog、New Relic 以及 SumoLogic 等）捕捉公开指标。关于更多详细信息，请参阅使用Prometheus实现公开监控。关于配置公开监控的更多操作说明，请参阅 Open Monitoring 实验室。

总结

在使用自建 Apache Kafka 代理时，需要保证 Apache ZooKeeper 始终发挥仲裁作用、监控代理之间的网络连接，同时监控 LogCleaner 等不同 Apache Kafka 辅助进程。一旦某个要素发生故障，我们还需要通过基础设施管理与监控等方式解决问题。这部分被耗费在 Apache Kafka 运营层面的精力与时间，本应被用于更好地实现实际业务价值。

Amazon MSK 能够降低基础设施的维护强度，简化问题的识别与解决，缩短代理维护时间，最终将生产力提升至新的层面。它在后台承担起 Apache Kafka 的维护工作，结合实际需求为提供监控级别选择，让团队能够腾出更多精力改善业务应用程序并为客户提供价值回报。

avatar
文章
阅读
粉丝