作者：Dan Moore, Eric Sun, 吕璐, 刘新宇

Tl;博士：

抽象的

在 Coinbase，我们每天从我们的产品中的用户、应用程序和加密资源中摄取数十亿个事件。点击流数据是通过网络和移动客户端收集的，并使用本土的 Ruby 和 Golang SDK 摄取到 Kafka。此外，来自各种数据库的变更数据捕获 (CDC) 流由 Kafka Connect 提供支持。这些 Kafka 消息的一个主要消费者是我们的数据 ETL 管道，它将数据传输到我们的数据仓库 (Snowflake)，供我们的数据科学和数据分析师团队进一步分析。此外，整个公司的内部服务（如我们的 Prime Brokerage 和实时库存漂移产品）依赖我们的 Kafka 集群来运行关键任务、低延迟（低于 10 毫秒）的应用程序。

借助 AWS 管理的 Kafka (MSK)，我们的团队减轻了代理维护和恢复的日常 Kafka 运营开销，使我们能够将工程时间集中在核心业务需求上。我们发现使用 MSK 扩展/缩小 Kafka 集群并将代理升级到最新的 Kafka 版本既简单又安全。这篇文章概述了我们围绕 MSK 开发的核心架构和完整的工具生态系统。

MSK 的配置和优势

配置：

• TLS 认证集群
• 跨多个可用区的 30 个代理节点，以防止整个可用区中断
• 多集群支持
• ~17TB 存储/代理
• 来自 AWS 的99.9% 每月正常运行时间 SLA

好处：

由于 MSK 是 AWS 管理的，最大的好处之一是我们能够避免让内部工程师主动维护 ZooKeeper/代理节点。这为我们节省了 100 多个小时的工程工作，因为 AWS 以无缝方式处理所有代理安全补丁更新、节点恢复和 Kafka 版本升级。所有代理更新都以滚动方式完成（一次更新一个代理节点），因此不会影响用户读/写操作。

此外，MSK 提供灵活的网络配置。我们的集群有严格的安全组入口规则，服务可以围绕这些规则直接与 ZooKeeper 或 MSK 代理节点端口通信。 与 Terraform 的集成允许无缝添加代理、增加磁盘空间、对我们的集群进行配置更新，而无需停机。

最后，AWS 提供了出色的 MSK Enterprise 支持，多次与我们会面以回答棘手的网络和集群身份验证问题。

表现：

当从 Kinesis（约 200 毫秒 e2e 延迟）切换到 Kafka（<10 毫秒 e2e 延迟）时，我们将端到端 (e2e) 延迟（生成、存储和使用事件所需的时间）减少了约 95%。我们的 Kafka 堆栈对于高达 100KB 的有效负载的 p50 e2e 延迟平均 <10 毫秒（与LinkedIn 作为基准一致，该公司最初是 Kafka 的幕后推手）。这为我们的 Prime Brokerage 服务等超低延迟应用程序打开了大门。我们的产品集群压力测试的完整延迟细分，按有效负载大小，如下所示：

专有的 Kafka 安全服务 (KSS)

它是什么？

我们的 Kafka 安全服务 (KSS) 包含所有主题访问控制列表 (ACL)。在部署时，它会自动将所有主题读/写 ACL 更改与 MSK 的 ZooKeeper 节点同步；实际上，这就是我们能够在服务级别控制对单个 Kafka 主题的读/写访问的方式。

KSS 还使用 AWS ACM API签署证书签名请求 (CSR)。为此，我们利用了内部服务到服务身份验证 (S2S) 框架，该框架为我们提供了来自客户端的可信 service_id；然后，我们使用该 service_id 并将其添加为我们返回给用户的签名证书中的专有名称。

使用签名证书，具有与 service_id 匹配的专有名称，MSK 可以通过 TLS 身份验证轻松检测是否应允许给定服务从特定主题读/写。如果不允许服务（根据我们在 ZooKeeper 中设置的 acl.yml 文件和 ACL）执行给定的操作，客户端将发生错误，并且不会发生 Kafka 读/写操作。

也需要

与 KSS 并行，我们构建了一个自定义的 Kafka sidecar Docker 容器：1) 简单地插入现有的 docker-compose 文件 2) 在启动时自动生成 CSR 并调用 KSS 以获取签名证书，以及 3) 将凭据存储在共享的 Docker 中用户服务的数量，可在实例化 Kafka 生产者/消费者客户端时使用，以便进行 TLS 身份验证。

丰富的数据流工具

我们使用以下强大的工具扩展了我们的核心 Kafka 集群：

卡夫卡连接

这是一个 EC2 节点（AWS 自动扩展组）的分布式集群，可在各种数据库系统上执行变更数据捕获 (CDC)。目前，我们正在利用 MongoDB、Snowflake、S3 和 Postgres 源/接收器连接器。许多其他连接器可通过此处的 Confluent 开源

卡夫洛普

我们正在利用开源 Kafdrop 产品进行一流的主题/分区偏移监控和检查用户消费滞后：源代码在这里

巡航控制

这是另一个开源项目，它提供自动分区重新平衡以保持我们的集群负载/磁盘空间甚至跨所有代理节点：源代码在这里

合流模式注册表

我们使用 Confluent 的开源架构注册表来存储版本化的 proto 定义（广泛用于 Coinbase gRPC）：源代码在这里

内部 Kafka SDK

对我们的流堆栈至关重要的是内部开发的自定义 Golang Kafka SDK，基于segmentio/kafka 版本。内部 SDK 与我们的架构注册表集成，以便在生产者写入时自动注册/更新 proto 定义。此外，SDK 为用户提供了以下开箱即用的好处：

• 消费者可以根据魔术字节和匹配的SR记录自动反序列化
• 消息来源标头（例如 service_id、event_time、event_type），有助于对事件流完整性和延迟指标进行端到端审计
• 这些标头还通过避免反序列化整个有效负载的惩罚来加速消息过滤和路由

流媒体 SDK

除了 Kafka，我们可能还需要利用其他流媒体解决方案，包括 Kinesis、SNS 和 SQS。我们引入了统一的 Streaming-SDK 来满足以下要求：

• 将单个事件传送到多个目的地，通常被描述为“扇出”或“镜像”。例如，同时向 Kafka 主题和 SQS 队列发送相同的消息
• 作为数据处理的结果，从一个 Kafka 主题接收消息，向另一个主题甚至 Kinesis 流发送新消息
• 支持动态消息路由，例如消息可以跨多个Kafka集群或AWS区域进行故障转移
• 为每个流媒体平台提供优化的配置，以最大限度地减少人为错误，最大限度地提高吞吐量和性能，并提醒用户配置错误

即将到来

即将与我们的Delta Lake集成，这将为我们的数据分析师和数据科学团队提供更高效、更及时的数据 ETL。除此之外，随着内部需求的增加，我们可以将 prod 集群中的代理节点数量（30 -> 90 个节点）增加 3 倍——这是一个软限制，可以通过 AWS 支持票来增加。

外卖

总的来说，我们对 AWS MSK 非常满意。安全补丁、维护和 Kafka 版本升级期间的自动代理恢复以及围绕磁盘空间使用率/代理 CPU 的高级代理/主题级别监控指标，为我们节省了数百小时的配置和维护代理和 ZooKeeper 节点的时间。与 Terraform 的集成使初始集群配置、部署和配置更新变得相对轻松（为您的集群使用 3AZ 以使其更具弹性并防止全可用区中断的影响）。

性能超出预期，低于 10 毫秒的延迟为超高速应用打开了大门。集群的正常运行时间一直不错，超过了 AWS 给出的 99.9% 的 SLA。此外，当任何安全补丁发生时，它总是以滚动代理方式完成，因此不会影响读/写操作（将默认主题复制因子设置为 3，这样即使节点故障，最小同步副本也是 2）。

我们发现在 MSK 之上构建高度可扩展，集成了 Kafka Connect、Confluent Schema Registry、Kafdrop、Cruise Control 等，没有问题。最终，MSK 对我们的工程师维护系统（减少维护节点的开销）和利用超低延迟数据流的力量解锁我们的内部用户和服务都有好处。

我们如何使用 AWS MSK 在 Coinbase 扩展数据流最初发表在媒体上的 Coinbase 博客中，人们通过突出显示和回应这个故事来继续对话。