# VMware Tanzu CloudHealth 如何从自管理 Kafka 迁移到 Amazon

VMware Tanzu CloudHealth 从自管理 Kafka 迁移到 Amazon MSK 的历程

作者：Rivlin Pereira Raj Ramasubbu Satya Pattanaik Todd McGrath Vaibhav Pandey日期：2024年3月14日在 Amazon Managed Streaming for Apache Kafka (Amazon MSK) 和 Customer Solutions

关键要点

在这篇文章中，我们将探讨 VMware Tanzu CloudHealth 如何成功将自管理的 Apache Kafka 迁移至 Amazon MSK。我们将讨论迁移动因、架构设计、实施过程、面临的挑战和获得的成果。

VMware Tanzu CloudHealth 的情况概述

VMware Tanzu CloudHealth 是全球超过 20000 个组织选择的云成本管理平台，旨在优化和治理其最庞大且复杂的多云环境。本篇文章将详细介绍 VMware Tanzu CloudHealth DevOps 团队如何将其自管理的 Apache Kafka 工作负载运行版本 20迁移到 Amazon Managed Streaming for Apache KafkaAmazon MSK运行版本 262。我们将涵盖系统架构、部署流水线、主题创建、可观察性、访问控制、主题迁移以及与现有基础架构相关的所有问题，并阐述我们迁移至新 Kafka 设置的原因以及一些经验教训。

Kafka 群集概述

在分布式系统快速发展的背景下，VMware Tanzu CloudHealth 的下一代微服务平台依赖于 Kafka 作为其消息传递基础。对我们来说，Kafka 的高性能分布式日志系统在处理海量数据流方面表现出色，使得其在无缝通信中不可或缺。Kafka 作为分布式日志系统，有效捕获并存储多种日志，从 HTTP 服务器访问日志到安全事件审计日志。

Kafka 的多功能性在于支持关键消息模式，将消息视为基本日志或结构化键值存储。动态分区和一致性排序确保消息的有效组织。Kafka 的可靠性与我们对数据完整性的承诺高度契合。

通过 Karafka 库，Ruby 服务与 Kafka 的集成变得更加简洁，这一库充当了更高级别的封装器。我们的其他语言栈服务也使用了类似的封装。Kafka 强大的调试功能和管理命令在确保顺利运转和基础架构健康方面发挥了关键作用。

迁移至 Amazon MSK 的理由

我们迁移至 Amazon MSK 的关键决策点为：

决策点描述简化技术操作在自管理基础架构上运行 Kafka 带来了运营负担，自 Kafka 版本 200 后我们并未更新，生产环境中的 Kafka broker 经常宕机，导致主题下线。并且，手动运行脚本以增加复制因子和重新平衡领导者造成了额外的人工工作。弃用遗留流水线与简化权限管理我们希望摆脱旧的 Ansible 流水线，以简化对 Kafka 机器的访问，这一过程非常繁琐。成本管理、补丁及支持由于 Apache Zookeeper 完全由 AWS 管理和打补丁，迁移至 Amazon MSK 将节省我们大量时间和资金。此外，我们发现，在 Amazon EC2 上运行相同类型的 broker 的成本比在 Amazon MSK 上低，迁移的决定愈加简单。与此同时，获得 AWS 的企业支持也是我们最终选用托管解决方案的关键因素。

迁移至 Amazon MSK 的实施过程

确定关键驱动因素后，我们提出了迁移现有自管理 Kafka 至 Amazon MSK 的设计并进行了以下的迁移前步骤：

步骤描述评估细致评估现有 EC2 Kafka 群集，了解其配置和依赖关系。确认与 Amazon MSK 的版本兼容性。使用 Terraform 设置 Amazon MSK采用 Terraform 来提供 MSK 群集，遵循基础设施即代码 (IaC) 原则以实现可重复性和版本控制。配置 Amazon VPC 安全组、AWS IAM 角色 和 VPC 设置。网络配置确保 EC2 Kafka 和 MSK 群集之间的网络连接顺畅，调整安全组和防火墙设置。

在完成这些迁移前步骤后，我们实施了以下新的设计：

梯子加速MSK 群集的自动化部署、升级和主题创建流水线：以上述目标为导向，我们创建了自定义 Terraform 模块用于 MSK 群集的部署和升级，并使用 Jenkins 流水线进行自动化管理。使用 Ansible 创建 Kafka 主题的做法并不稳定，导致开发团队投诉不断。因此，我们评估了部署至 Kubernetes 群集的选项，并使用 Strimzi Topic Operator 在 MSK 群集上创建主题，实现主题创建的自动化。 增强群集的可观察性：旧的 Kafka 群集缺乏可观察性。借助 Amazon MSK，我们利用 开放监控 结合 Prometheus 来实现监控，随后将指标传送至我们的内部可观察性工具。通过改进的可观察性，我们能够为 Amazon MSK 设置强健的警报，而这是旧设置中无法实现的。 优化成本和改善计算基础架构：在旧 Kafka 基础架构中，我们需要为 Kafka 和 Zookeeper 实例的管理以及任何额外的 broker 存储费用和数据传输费用买单。迁移至 Amazon MSK 后，由于 Zookeeper 完全由 AWS 管理，我们仅需为 Kafka 节点、broker 存储和数据传输费用付费。因此，在生产环境下的最终 Amazon MSK 设置中，我们不仅节省了基础设施成本，还减少了运营成本。 简化操作和增强安全性：迁移至 Amazon MSK 后，我们无需管理任何 Zookeeper 实例，broker 的安全补丁也是由 AWS 处理。群集升级变得更简单，并且可以直接从 Amazon MSK 控制台发起。借助 Amazon MSK，我们享受到了 broker 自动扩展的特性，避免了磁盘空间耗尽的情形，从而提升了 MSK 群集的稳定性。同时，Amazon MSK 默认支持静态加密，提供多种传输加密选项，确保了群集的安全性，更多信息请参见 Amazon Managed Streaming for Apache Kafka 中的数据保护。

在进行迁移前的步骤中，我们在过渡至生产环节前对设置进行了验证。

Kafka 主题迁移策略

在 MSK 群集设置完成后，我们开始将旧 EC2 上的 Kafka 主题迁移至新 MSK 群集。为此，我们执行了以下步骤：

使用 Terraform 设置 MirrorMaker：我们使用 Terraform 协调部署一个由 15 个节点构成的 MirrorMaker 群集。此举展示了根据迁移的并发复制需求灵活调整节点数目的可扩展性。实施并发复制策略：我们实施了 15 个 MirrorMaker 节点的并发复制策略，以加速迁移过程。借助 Terraform 驱动的方法，有效管理迁移过程中这些资源，使其不仅优化了资源，还确保了 MSK 和 MirrorMaker 群集的可靠性和一致性。这种设置展示了加速数据传输的能力，优化了时间和资源。数据迁移：我们在短时间内成功迁移了 2 TB 的数据，最大限度减少了停机时间，展现了并发复制策略的高效性。迁移后的监控设置：在整个迁移过程中，我们实施了强有力的监控和警报机制，以便迅速识别和解决问题，确保迁移过程顺利。

下图展示了迁移主题后架构的完成情况。

面临的挑战与经验教训

在进行大规模数据集迁移的过程中，通常伴随着不可预见的挑战。我们将讨论在使用 MirrorMaker 从 EC2 Kafka 迁移至 Amazon MSK 的过程中遇到的难题，并分享我们为确保迁移成功而获得的宝贵见解和解决方案。

挑战一：偏移量差异

我们遇到的一个挑战是，即使在启用偏移量同步的情况下，源集群和目标集群之间的主题偏移量仍存在不匹配。这里获得的经验是，偏移量值不必完全相同，只需启用偏移同步，确保主题从正确的位置读取数据即可。

我们通过使用自定义工具测试消费者组来解决此问题，确认翻译后的偏移量要么较小，要么已达到同步状态。

挑战二：数据迁移速度缓慢

迁移过程中出现了瓶颈，数据传输速度低于预期，尤其是在处理 2 TB 的大数据集时。尽管有 20 节点的 MirrorMaker 群集，速度依旧不够快。

为了解决这个问题，团队根据独特的端口号有策略地对 MirrorMaker 节点进行分组。五个具有不同端口的 MirrorMaker 节点集群大幅提升了吞吐量，使我们能够在数小时内迁移数据，而不是数天。

挑战三：缺少详细的过程文档

在使用 MirrorMaker 迁移大数据集的未知领域中，缺乏详细文档的问题显现无疑。

通过不断尝试，团队使用 Terraform 制作了一个 IaC 模块。这个模块简化了整个集群创建过程，优化了设置，使得迁移可以在几分钟内无缝启动。

最终设置与后续步伐

迁移至 Amazon MSK 后，我们的最终设置如以下图所示。我们在考虑未来的以下改进：

迁移至基于 AWS Graviton 的 Amazon MSK 节点，以提高性能并节约成本。有关 Graviton 与 Amazon MSK 的更多信息，请参见 Amazon MSK 现在支持新的 Graviton3 基于 M7g 的实例。使用 分级存储 进一步节省成本。创建专用的群集来满足特定需求，由于现在能更快速地使用自动化创建这些群集。

结论

本文讨论了 VMware Tanzu CloudHealth 如何将现有的 Amazon EC2 基础的 Kafka 基础架构迁移至 Amazon MSK。我们回顾了新架构、部署及主题创建流水线、可观察性和访问控制的提升、主题迁移中的挑战，以及我们与现有基础架构相关的问题，还讲述了如何以及为什么迁移至新的 Amazon MSK 设置，以及所获得的所有好处、最终架构以及所吸取的经验教训。

对我们来说，偏移同步、策略性节点分组和基础设施即代码IaC的结合在克服障碍和确保成功迁移的过程中起到了关键作用。此文见证了在迁移挑战中的适应性与创新力，提供了对其他正在经历类似路径的人的见解。

如果您在 AWS 上运行自管理的 Kafka，我们鼓励您尝试托管的 Kafka 解决方案 Amazon MSK。

关于作者

Rivlin Pereira 是 VMware Tanzu 部门的员工 DevOps 工程师，热衷于 Kubernetes，专注于构建和运营可扩展、可靠和经济高效的云解决方案。

Vaibhav Pandey 是 Broadcom 的员工软件工程师，是云计算解决方案开发的关键贡献者，专注于数据存储层的架构和工程，热衷于构建和扩展最优性能的 SaaS 应用程序。

Raj Ramasubbu 是 AWS 的高级分析专家解决方案架构师，专注于大数据、分析和 AI/ML。他帮助客户在 AWS 上架构和构建高度可扩展、高性能和安全的云基础解决方案。在加入 AWS 之前，他在数据工程、大数据分析、商业智能和数据科学方案领域积累了超过18年的经验，为多行业垂直客户提供技术专业知识和领导力。

Todd McGrath 是 AWS 的数据流技术专家，向客户提供关于流媒体策略、集成、架构和解决方案的建议。个人生活中，他很享受观看和支持他的3个青少年参与他们喜欢的活动，也喜欢钓鱼、打皮克球、冰球以及与家人与朋友在室外电动船上欢聚的时光。

Satya Pattanaik 是 AWS 的高级解决方案架构师，致力于帮助 ISV 构建可扩展和可靠的 AWS 云应用程序。他在加入 AWS 前在企业部门取得了一定的成功。工作之余，他喜欢琢磨美味 BBQ 的烹饪技巧，并尝试新食谱。

加载评论