这是与 Tanzu CloudHealth（VMware by Broadcom）的 Rivlin Pereira 和 Vaibhav Pandey 共同撰写的帖子。
VMware Tanzu CloudHealth 是全球 20,000 多个组织首选的云成本管理平台，这些组织依靠它来优化和管理其最大、最复杂的多云环境。在这篇文章中，我们讨论 VMware Tanzu CloudHealth DevOps 团队如何将其自我管理的 Apache Kafka 工作负载（运行 2.0 版）迁移到 适用于Apache Kafka的Amazon托管流 (Amazon MSK) 运行版本 2.6.2。我们讨论系统架构、部署管道、主题创建、可观察性、访问控制、主题迁移以及我们在现有基础设施方面面临的所有问题，以及我们如何以及为何迁移到新的 Kafka 设置以及吸取的一些经验教训。
Kafka集群概述
在快速发展的分布式系统环境中，VMware Tanzu CloudHealth 的下一代微服务平台依赖 Kafka 作为其消息传递骨干。对于我们来说，Kafka的高性能分布式日志系统擅长处理海量数据流，对于无缝通信来说是不可或缺的。 Kafka作为分布式日志系统，可以高效地捕获和存储各种日志，从HTTP服务器访问日志到安全事件审计日志。
Kafka 的多功能性在支持关键消息传递模式、将消息视为基本日志或结构化键值存储方面表现出色。动态分区和一致的排序确保了高效的消息组织。 Kafka 坚定不移的可靠性与我们对数据完整性的承诺是一致的。
Ruby 服务与 Kafka 的集成通过 Karafka 库简化，充当更高级别的包装器。我们的其他语言堆栈服务使用类似的包装器。 Kafka 强大的调试功能和管理命令在确保平稳运行和基础设施健康方面发挥着关键作用。
卡夫卡作为建筑支柱
在 VMware Tanzu CloudHealth 的下一代微服务平台中，Kafka 成为关键的架构支柱。它能够处理高数据速率、支持多种消息传递模式并保证消息传递与我们的运营需求无缝匹配。随着我们不断创新和扩展，Kafka 仍然是我们坚定的伴侣，使我们能够构建弹性且高效的基础设施。
为什么我们迁移到 Amazon MSK
对于我们来说，迁移到 Amazon MSK 归结为三个关键决策点：
- 简化技术操作 – 在自我管理的基础设施上运行 Kafka 对我们来说是一项运营开销。我们已经有一段时间没有更新 Kafka 2.0.0 版本了，Kafka 代理正在生产中停止运行，导致主题离线的问题。我们还必须手动运行脚本来增加复制因子并重新平衡领导者，这是额外的手动工作。
- 弃用的旧管道和简化的权限 – 我们希望摆脱用以下语言编写的现有管道 Ansible 在集群上创建 Kafka 主题。我们还经历了一个繁琐的流程，让团队成员在暂存和生产中访问 Kafka 机器，我们希望简化这一过程。
- 成本、补丁和支持 –因为 阿帕奇动物园管理员 完全由 AWS 管理和修补，迁移到 Amazon MSK 将节省我们的时间和金钱。此外，我们发现在相同类型的代理上运行 Amazon MSK 亚马逊弹性计算云 (Amazon EC2) 在 Amazon MSK 上运行的成本更低。结合我们通过 AWS 在代理上应用的安全补丁这一事实，迁移到 Amazon MSK 是一个简单的决定。这也意味着团队可以腾出时间来处理其他重要的事情。最后，获得 AWS 的企业支持对于我们最终决定转向托管解决方案也至关重要。
我们如何迁移到 Amazon MSK
确定了关键驱动因素后，我们继续推进拟议的设计，将现有的自我管理 Kafka 迁移到 Amazon MSK。在实际实施之前，我们进行了以下预迁移步骤：
- 评定：
- 对现有 EC2 Kafka 集群进行了细致的评估，了解其配置和依赖关系
- 已验证 Kafka 版本与 Amazon MSK 的兼容性
- 使用 Terraform 设置 Amazon MSK
- 网络配置：
- 确保 EC2 Kafka 和 MSK 集群之间的无缝网络连接，微调安全组和防火墙设置
完成预迁移步骤后，我们对新设计实施了以下操作：
- MSK 集群的自动部署、升级和主题创建管道：
- 在新设置中，我们希望使用 IaC 工具以可重复的方式自动部署和升级 MSK 集群。因此，我们为 MSK 集群部署和升级创建了自定义 Terraform 模块。这些模块是从 詹金斯 用于自动部署和升级 MSK 集群的管道。对于 Kafka 主题创建，我们使用的是基于 Ansible 的自行开发的管道，该管道不稳定，并导致了开发团队的大量投诉。因此，我们评估了部署选项 Kubernetes 集群并使用 Strimzi 主题运算符 在 MSK 集群上创建主题。使用 Jenkins 管道自动创建主题，开发团队可以自助服务。
- 更好的集群可观测性：
- 改进的 COGS 和更好的计算基础设施：
- 对于我们旧的 Kafka 基础设施，我们必须支付管理 Kafka、Zookeeper 实例的费用，以及任何额外的代理存储成本和数据传输成本。迁移到 Amazon MSK 后，由于 Zookeeper 完全由 AWS 管理，我们只需支付 Kafka 节点、代理存储和数据传输成本。因此，在最终的 Amazon MSK 生产设置中，我们不仅节省了基础设施成本，还节省了运营成本。
- 简化操作并增强安全性：
- 迁移到 Amazon MSK 后，我们无需管理任何 Zookeeper 实例。 AWS 还为我们处理了代理安全补丁。
- 迁移到 Amazon MSK 后，集群升级变得更加简单；这是一个从 Amazon MSK 控制台启动的简单过程。
- 有了 Amazon MSK，我们就有了经纪人 自动缩放 盒子外面。因此，我们不必担心代理耗尽磁盘空间，从而提高了 MSK 集群的稳定性。
- 我们还为集群提供了额外的安全性，因为 Amazon MSK 默认支持静态加密，并且还提供了各种传输中加密选项。欲了解更多信息，请参阅 Amazon Managed Streaming for Apache Kafka 中的数据保护.
在预迁移步骤中，我们在继续生产之前验证了临时环境中的设置。
Kafka主题迁移策略
MSK 集群设置完成后，我们将 Kafka 主题从 Amazon EC2 上运行的旧集群迁移到新的 MSK 集群。为了实现这一目标，我们执行了以下步骤：
- 使用 Terraform 设置 MirrorMaker – 我们使用 Terraform 来协调部署 制镜师 集群由 15 个节点组成。这证明了通过根据迁移的并发复制需求调整节点数量的可扩展性和灵活性。
- 实施并发复制策略 – 我们实施了具有 15 个 MirrorMaker 节点的并发复制策略，以加快迁移过程。我们的 Terraform 驱动方法通过在迁移过程中有效管理资源来实现成本优化，并确保 MSK 和 MirrorMaker 集群的可靠性和一致性。它还展示了所选设置如何加速数据传输，优化时间和资源。
- 迁移数据 – 我们在极短的时间内成功迁移了 2 TB 数据，最大限度地减少了停机时间并展示了并发复制策略的效率。
- 设置迁移后监控 – 我们在迁移过程中实施了强有力的监控和警报，通过及时识别和解决问题来促进流程的顺利进行。
下图展示了主题迁移完成后的架构。
挑战和经验教训
踏上迁移之旅，尤其是大型数据集，通常会伴随着不可预见的挑战。在本部分中，我们将深入研究使用 MirrorMaker 将主题从 EC2 Kafka 迁移到 Amazon MSK 期间遇到的挑战，并分享有助于我们成功迁移的宝贵见解和解决方案。
挑战 1：偏移差异
我们遇到的挑战之一是源集群和目标集群之间的主题偏移不匹配，即使在 MirrorMaker 中启用了偏移同步。这里学到的教训是，只要启用偏移同步，偏移值不一定需要相同，这可以确保主题具有正确的位置来读取数据。
我们通过使用自定义工具对消费者组运行测试来解决此问题，确认转换后的偏移量较小或已赶上，这表明按照 MirrorMaker 进行了同步。
挑战二：数据迁移速度慢
迁移过程面临瓶颈——数据传输速度比预期慢，尤其是对于 2 TB 的大量数据集。尽管有 20 个节点的 MirrorMaker 集群，但速度还是不够。
为了克服这个问题，团队根据唯一的端口号对 MirrorMaker 节点进行了战略性分组。由五个 MirrorMaker 节点组成的集群（每个节点都有一个不同的端口）显着提高了吞吐量，使我们能够在几小时而不是几天内迁移数据。
挑战3：缺乏详细的流程文档
使用 MirrorMaker 探索迁移大型数据集的未知领域，突显了此类场景缺乏详细文档。
经过反复试验，团队使用 Terraform 制作了一个 IaC 模块。该模块通过优化设置简化了整个集群创建过程，从而能够在几分钟内无缝启动迁移。
最终设置和后续步骤
由于迁移到 Amazon MSK，主题迁移后的最终设置如下图所示。
我们正在考虑以下未来改进：
结论。
在本文中，我们讨论了 VMware Tanzu CloudHealth 如何将其现有的基于 Amazon EC2 的 Kafka 基础设施迁移到 Amazon MSK。我们向您介绍了新的架构、部署和主题创建管道、可观察性和访问控制的改进、主题迁移挑战以及我们在现有基础设施方面面临的问题，以及我们迁移到新的 Amazon MSK 设置的方式和原因。我们还讨论了 Amazon MSK 为我们带来的所有优势、我们通过此次迁移实现的最终架构以及吸取的经验教训。
对于我们来说，事实证明，偏移同步、战略节点分组和 IaC 的相互作用对于克服障碍并确保从 Amazon EC2 Kafka 成功迁移到 Amazon MSK 至关重要。这篇文章证明了在迁移挑战中适应性和创新的力量，为其他走类似道路的人提供了见解。
如果您在 AWS 上运行自我管理的 Kafka，我们鼓励您尝试托管 Kafka 产品， 亚马逊 MSK.
作者简介
里夫林·佩雷拉 是 VMware Tanzu 部门的高级 DevOps 工程师。他对 Kubernetes 充满热情，致力于 CloudHealth Platform 构建和运营可扩展、可靠且具有成本效益的云解决方案。
瓦巴夫·潘迪是 Broadcom 的一名高级软件工程师，是云计算解决方案开发的关键贡献者。他专门从事数据存储层的架构和工程设计，热衷于构建和扩展 SaaS 应用程序以实现最佳性能。
拉吉拉马苏布 是一名高级分析专家解决方案架构师，专注于 Amazon Web Services 的大数据和分析以及 AI/ML。 他帮助客户在 AWS 上设计和构建高度可扩展、高性能和安全的基于云的解决方案。 在加入 AWS 之前，Raj 在构建数据工程、大数据分析、商业智能和数据科学解决方案方面提供了超过 18 年的技术专长和领导能力。 他为医疗保健、医疗器械、生命科学、零售、资产管理、汽车保险、住宅 REIT、农业、产权保险、供应链、文件管理和房地产等各个垂直行业的客户提供帮助。
托德·麦格拉思 是 Amazon Web Services 的数据流专家，他为客户提供有关流策略、集成、架构和解决方案的建议。就个人而言，他喜欢观看和支持他的 3 个孩子进行他们喜欢的活动，也喜欢追求自己的爱好，例如钓鱼、泡菜球、冰球以及在浮船上与朋友和家人度过欢乐时光。在 LinkedIn 上与他联系。
萨蒂亚·帕塔奈克 是 AWS 的高级解决方案架构师。他一直在帮助 ISV 在 AWS 云上构建可扩展且具有弹性的应用程序。在加入 AWS 之前，他在企业领域的发展和成功中发挥了重要作用。工作之余，他花时间学习“如何烹饪美味的烧烤”并尝试新食谱。
