使用 Amazon MSK Serverless 拆分整体式 Apache Kafka 集群

Original URL: https://thinkwithwp.com/blogs/big-data/split-your-monolithic-apache-kafka-clusters-using-amazon-msk-serverless/

如今，许多公司都在构建实时应用程序，用于改善其客户体验，并即时从数据中获得见解，以防数据失去价值。因此，各公司面临着需求的增长，需要为开发人员提供 Apache Kafka 等数据流式传输服务。为了满足这种需求，公司通常从中小型集中式Apache Kafka 集群开始着手构建全球流式传输服务。随着时间的推移，他们会扩展集群的容量来满足流式传输的需求。他们选择保留一个整体式集群，将所有专业技术人员集中在一个位置，从而简化人员配备和培训。这种方法还具有成本优势，因为它减少了技术债务、总体运营成本和复杂性。在整体式集群中，所有应用程序共享额外的容量，因此通常可以降低流式传输基础设施的总体成本。在这篇博文中，我说明了集中式方法面临的一些挑战，并介绍了使用 Amazon MSK Serverless 实施去中心化方法的两种策略。通过去中心化策略，您可以预置多个 Apache Kafka 集群，而不是一个整体式集群。我将讨论此策略如何帮助您根据应用程序的安全性、存储和性能需求优化集群。我还将讨论去中心化模型的好处，以及如何从整体式集群迁移到多集群部署模型。MSK Serverless 可以减少管理 Apache Kafka 集群的开销和成本。它会自动为 Apache Kafka 集群预置和扩展计算和存储资源，并自动管理集群容量。它监控分区在后端节点上的分布情况，并在必要时自动重新分配分区。它与其他 AWS 服务（例如 Amazon CloudWatch）集成，您可以在其中监控集群的运行状况。这篇博文选择 MSK Serverless 是经过深思熟虑的，不过这些概念也可以应用于 Amazon MSK 预置的产品。

解决方案概览

Apache Kafka 是一个开源平台，具备高性能、容错能力和可扩展性，可用于构建实时的流式传输数据管道和应用程序。Apache Kafka 通过将生产者与使用者分离，简化了流式传输数据的生成和使用。生产者只需与单个数据存储（Apache Kafka）交互即可发送其数据。使用者读取连续的数据流，不受生产者的架构或编程语言的影响。

Apache Kafka 是在许多使用案例中深受欢迎的选择，例如：

实时 Web 和日志分析
事务和事件溯源
消息传递
分离微服务
流式提取、转换和加载（ETL）
指标和日志聚合

整体式 Apache Kafka 集群面临的挑战

整体式 Apache Kafka 使公司不必在其数据中心安装和维护多个集群。但是，这种方法有一些共同的缺点：

全部流式处理容量整合到一个地方，这使得容量规划变得困难而复杂。通常，您需要更多时间来规划和重新配置集群。例如，在为销售或大型活动做准备时，很难预测和计算所有应用程序需要的容量总和。这也可能妨碍公司的发展，因为针对新工作负载重新配置大型集群通常需要比小型集群花费更长的时间。
组织中可能会因为 Apache Kafka 集群的所有权和维护发生冲突，因为整体式集群是一种共享的资源。
Apache Kafka 集群会成为单点故障。任何停机都意味着所有相关应用程序的中断。
如果您选择通过多数据中心部署来提高 Apache Kafka 的弹性，则通常必须在另一个数据中心部署相同大小的集群，这样做的成本很高。
由于 Apache Kafka 架构的分布式特性，大型集群的维护和操作活动（例如版本升级或安装 OS 补丁）所需的时间要长得多。
出现故障的应用程序可能会影响整个集群和其他应用程序的可靠性。
版本升级必须等到所有应用程序都已经完成了新 Apache Kafka 版本上的测试。这使得任意应用程序无法快速实验 Apache Kafka 功能。
这种模式难于将运行集群的成本归因到应用程序来进行计费。

下图显示了整体式 Apache Kafka 架构。

去中心化模型

去中心化的 Apache Kafka 部署模型涉及到预置、配置和维护多个集群。这通常不是首选策略，因为在本地环境中，管理多个集群需要对卓越运营、高级监控、基础设施即代码、安全性和硬件采购进行大量投资。

但是，使用 MSK Serverless 预置去中心化的 Apache Kafka 集群不需要这些投资。它可以根据应用程序需求即时纵向扩展和缩减容量和存储，无需复杂的容量规划，即可添加新的工作负载或扩展操作。它还提供基于吞吐量的定价模型，您只需为应用程序使用的存储和吞吐量付费。此外，使用 MSK Serverless，您不再需要执行标准维护任务，例如 Apache Kafka 版本升级、分区重新分配或 OS 补丁。

使用 MSK Serverless，您可以从去中心化部署中受益，而无需承担自行管理的 Apache Kafka 部署通常带来的运营负担。在此策略中，DevOps 经理不必花时间预置、配置、监控和运营多个集群。相反，他们可以将更多的时间投入到构建更多的运营工具上，以载入更多实时应用程序。

在本文的剩余部分中，我将讨论实现去中心化模型的不同策略。此外，我还会重点介绍每种策略的好处和挑战，以便您决定哪种策略最适合您的组织。

写入集群和读取集群

在此策略中，写入集群负责从生产者那里提取数据。您可以通过创建新主题或创建新的 MSK Serverless 集群来添加新的工作负载。在您需要扩展当前工作负载的大小时，如果顺序不重要，则只需增加主题的分区数量。MSK Serverless 根据新配置即时管理容量。

每个 MSK Serverless 集群提供高达 200 MBps 的写入吞吐量和 400 MBps 的读取吞吐量。它还为每个分区分配高达 5 MBps 的写入吞吐量和 10 MBps 的读取吞吐量。

任何组织内的数据使用者通常可以分为两个主要类别：

时间敏感型工作负载，这些工作负载需要延迟极低（例如毫秒或亚秒）的数据，并且只能容忍非常短的恢复时间目标（RTO）
对时间不敏感的工作负载，这些工作负载可以承受较高的延迟（低于 10 秒到几分钟的延迟）和更长的 RTO

每个这些类别还可以根据某些条件来进一步划分为子类别，例如数据分类、监管合规性或服务级别协议（SLA）。读取集群可以根据您的业务或技术要求来设置，甚至可以根据组织边界来设置，以便供特定的使用者群体使用。最后，将使用者配置为在关联的读取集群上运行。

要将写入集群连接到读取集群，需要有数据复制管道。您可以通过多种方式构建数据复制管道。由于 MSK Serverless 支持标准的 Apache Kafka API，所以您可以使用标准 Apache Kafka 工具（例如 MirrorMaker 2）在 Apache Kafka 集群之间设置复制。

下图显示了此策略的架构。

这种方法具有以下好处：

生产者与使用者隔离；因此，您的写入吞吐量可以独立于读取吞吐量进行扩展。例如，如果您已达到现有集群的最大读取吞吐量并且需要添加新的使用者组，则只需预置一个新的 MSK Serverless 集群，然后在写入集群与新的读取集群之间设置复制即可。
这有助于加强安全和监管合规性。您可以构建流式处理作业，在复制数据时掩盖或删除数据事件的敏感字段，例如个人身份信息（PII）。
不同的集群可以采用不同的保留配置。例如，读取集群可以配置不同的最大保留期，以根据其要求节省存储成本。
您可以将一些集群在中断时的响应时间设置为优先于其他集群。
为了实施更好的弹性，您只需复制写入集群中的数据，这样可以减少备份区域中的集群数量。其他集群，例如读取集群，可以在调用工作负载失效转移时预置。在此模型中，使用 MSK Serverless 定价模式，您需要为备份区域中的使用量（较少数量的副本）额外付费。

选择此策略时，需要注意一些重要事项：

它需要在集群之间设置多个复制，这会带来额外的操作和维护复杂性。
诸如 MirrorMaker 2 之类的复制工具仅支持至少一次处理语义。这意味着在故障和重启期间，数据事件可能会重复。如果您的使用者无法容忍数据重复，我建议构建支持精确一次处理语义的数据管道进行数据复制，例如 Apache Flink，而不是使用 MirrorMaker 2。
由于使用者不直接从写入集群使用数据，因此写入器和读取器之间的延迟会增加。
在此策略中，尽管有多个 Apache Kafka 集群，但所有权和控制权仍然属于一个团队，资源位于一个 AWS 账户中。

隔离集群

对于一些公司来说，通过集中数据平台提供对 Apache Kafka 的访问可能会造成在扩展、所有权和问责制方面的挑战。基础设施团队可能不了解应用程序的特定业务需求，例如数据新鲜度或延迟要求、安全性、数据架构或数据摄取所需的特定方法。

通常，您可以通过向拥有应用程序的团队赋予所有权和自主权来减少这些挑战。您允许他们构建和管理自己的应用程序以及所需的基础设施，而不只是能够使用共用的集中平台。例如，开发团队负责预置、配置、维护和运营自己的 Apache Kafka 集群。他们是应用程序需求领域方面的专家，可以根据自己的应用程序需求管理集群。这减少了整体摩擦，并让应用程序团队对其宣称的 SLA 负责。

如前所述，MSK Serverless 最大限度地减少了与 Apache Kafka 集群相关的运营和维护工作。这使得有自主权的应用程序团队能够根据行业最佳实践管理其集群，而无需成为在 AWS 上运行高可用的 Apache Kafka 集群的专家。如果 MSK Serverless 集群是在其 AWS 账户中预置的，则他们还承担与运营应用程序和数据流服务相关的所有费用。

下图显示了此策略的架构。

这种方法具有以下好处：

MSK Serverless 集群由不同的团队管理；因此，整体管理工作已降至最低。
应用程序相互隔离。应用程序故障或集群停机不会影响其他应用程序。
使用者以低延迟直接从写入数据的同一个集群读取数据。
每个 MSK Serverless 集群可根据其写入和读取吞吐量分别进行扩展。
简单的成本归因意味着应用团队负责自己的基础设施及其成本。
全权管理流基础设施使开发人员能够更快地采用流并提供更多功能。它还可以帮助他们缩短对故障和中断的响应时间。

与之前的策略相比，这种方法有以下缺点：

难于跨多个团队强制执行统一的安全性或监管合规性。
可能会在多个集群中提取相同数据的重复副本。这增加了总成本。
为了提高弹性，每个团队都需要单独在 MSK Serverless 集群之间设置复制。

从集中策略转向去中心化策略

MSK Serverless 提供 AWS 命令行界面（AWS CLI）工具，并支持 AWS CloudFormation 模板，可在几分钟内预置集群。您可以通过 AWS 提供的方法实施我之前提到的任何策略，并在新集群准备就绪时迁移您的生产者和使用者。

以下步骤为实施这些策略提供了进一步的指导：

首先，重点介绍整体式 Apache Kafka 当前的问题。接下来列出了每种策略下的挑战与优缺点的比较。这可以帮助您决定哪种策略最适合您的公司。
分别确定并记录每个应用程序的性能、弹性、SLA 和所有权要求。
尝试对具有相似要求的应用程序进行分组。例如，您可能会发现一些应用程序运行批量分析；因此，它们对数据新鲜度不敏感，也不需要访问敏感（或 PII）数据。如果您认为隔离集群是适合公司的策略，则可以选择按照拥有应用程序的团队来对应用程序分组。
根据 MSK 无服务器配额，比较每组应用程序的存储和流式传输吞吐量要求。这可以帮助您确定一个 MSK Serverless 集群是否可以提供所需的聚合流式传输容量。如果不能，则将较大的组进一步划分为较小的组。
根据您之前通过 AWS 管理控制台、AWS CLI 或 CloudFormation 模板确定的每个组创建 MSK Serverless 集群。
确定与每个新 MSK Serverless 集群对应的主题。
根据复制要求选择迁移到 Amazon MSK 的最佳模式。例如，当您不需要数据转换并且应用程序可以容忍重复的数据事件时，您可以使用 Apache Kafka 迁移工具，例如 MirrorMaker 2.0。
验证数据已正确复制到新集群后，首先针对新集群重新启动使用者。这样可以确保不会因为迁移而丢失任何数据。
使用者恢复处理数据后，针对新集群重新启动生产者，然后关闭您之前创建的复制管道。

截至撰写本文时，MSK Serverless 仅支持使用 AWS Identity and Access Management（IAM）进行身份验证和访问控制。有关更多信息，请参阅 Securing Apache Kafka is easy and familiar with IAM Access Control for Amazon MSK（使用适用于 Amazon MSK 的 IAM 访问控制，以熟悉的方法轻松保护 Apache Kafka）。如果您的应用程序使用 Apache Kafka 支持的其他方法，则需要修改应用程序代码以改用 IAM 访问控制或使用 Amazon MSK 预置的产品。

总结

MSK Serverless 消除了运营开销，包括预置、配置和维护高度可用的 Apache Kafka 的开销。在这篇博文中，我展示了如何通过拆分 Apache Kafka 集群，帮助提高数据流式传输服务和应用程序的整体安全性、性能、可扩展性及可靠性。我还描述了使用 MSK Serverless 拆分整体式 Apache Kafka 集群的两种主要策略。如果您使用的是 Amazon MSK 预置产品，那么在考虑从集中模式转向去中心化模式时，这些策略仍然有用。您可以根据公司的具体需求决定合适的策略。

有关 Amazon MSK 的更多信息，请访问官方产品页面。

关于作者

Ali Alemi 是 AWS 的流式传输专家解决方案架构师。Ali 为 AWS 客户提供架构最佳实践建议，并帮助他们设计可靠、安全、高效且具有成本效益的实时分析数据系统。他根据客户的使用场景逆向工作，设计数据解决方案来解决他们的业务问题。在加入 AWS 之前，Ali 为多个公共部门客户和 AWS 咨询合作伙伴的应用程序现代化之旅和向云迁移提供支持。

亚马逊AWS官方博客