我们如何使用 AWS MSK 在 Coinbase 扩展数据流

作者 | Coinbase
译者 | Sambodhi
策划 | 闫园园

摘要：Coinbase 正在利用 AWS 的 Managed Streaming for Kafka（MSK）进行超低延迟、无缝的服务间通信、数据 ETL 和数据库变更数据捕获（Change Data Capture，CDC）。在 2021 年 11 月的 AWS Re:Invent 会议上，我们数据平台团队的工程师将会进一步介绍这一成果。

梗概

在 Coinbase，我们每天都会从我们的产品中的用户、应用程序和加密源摄取数十亿的事件。Clickstream 通过 Web 和移动客户端收集，利用自制的 Ruby 和 Golang SDK 摄取到 Kafka。另外，通过 Kafka 链接提供了来自不同数据库的变更数据捕获（CDC）流。这些 Kafka 消息的主要消费者之一是我们的数据 ETL 管道，它将数据传输到我们的数据仓库（Snowflake），供我们的数据科学和数据分析师团队进一步分析。此外，整个公司的内部服务（比如我们的 Prime Brokerage 和实时 Inventory Drift 产品）都依赖我们的 Kafka 集群来运行关键任务、低延迟（低于 10 毫秒）的应用。

通过 AWS 管理的 Kafka（AWS-managed Kafka，MSK），我们的团队减少了 broker 维护和恢复的日常 Kafka 运营开销，使我们能够把工程时间集中于核心业务需求。我们发现，通过 MSK，放大/缩小 Kafka 集群，并将 broker 升级为最新的 Kafka 版本变得简单且安全。本文概述了我们的核心架构以及我们围绕 MSK 开发的完整的工具生态系统。

MSK 的配置和优势

配置：

• TLS 认证的集群；
• 跨多个 AZ 的 30 个 broker 节点，以防止整个 AZ 的中断；
• 多集群的支持；
• 约 17TB 存储/broker；
• 来自 AWS 的 99.9% 每月正常运行时间 SLA。

优势：

由于 MSK 是由 AWS 管理的，所以它最大的好处之一就是我们能够避免让内部工程师主动维护 ZooKeeper / broker 节点。因为 AWS 无缝地处理所有的 broker 安全补丁更新、节点恢复以及 Kafka 版本升级，因此这将节省我们超过 100 小时的工程工作时间。对 broker 的所有更新都是按滚动方式进行的（每次更新一个 broker 节点），因此对用户的读写操作没有任何影响。

MSK 还提供灵活的网络配置。我们的集群具有严格的安全组入口规则，围绕哪些服务可以直接与 ZooKeeper 或 MSK broker 节点端口进行通信。与 Terraform 的集成可以无缝地添加 broker，增加磁盘空间，无需停机就可以更新集群的配置。

最后，AWS 为我们提供了出色的 MSK 企业支持，并多次会见我们，解答棘手的网络和集群授权问题。

性能：

当从 Kinesis（约 200 毫秒的端到端延迟）切换到 Kafka（<10 毫秒的端到端延迟）时，我们的端到端延迟（生成、存储和消费一个事件所需的时间）降低了大约 95%。Kafka 栈 p50 的端到端延迟为 100KB，平均 <10 毫秒（与 LinkedIn 作为基准相一致，Kafka 最初开发的公司）。这为超低延迟的应用打开了大门，例如我们的 Prime Brokerage 服务。下面列出了 prod 集群上所做压力测试的全部延迟细分，按有效负载大小列出：

专有的 Kafka 安全服务（KSS）

这是什么？

我们的 Kafka 安全服务（Kafka Security Service，KSS）包含了所有的主题访问控制列表（Access Control List，ACL）。在部署时，它会自动将所有主题读/写 ACL 更改与 MSK 的 ZooKeeper 节点同步；实际上，这就是我们如何在服务层面控制对单个 Kafka 主题的读/写访问。

KSS 还使用 AWS ACM API 来对证书签署请求（Certificate Signing Request，CSR）进行签署。为此，我们利用内部的服务到服务（Service-to-Service，S2S）认证框架，该框架从客户端提供给我们一个可信任的 service_id；然后我们使用该 service_id，并将其作为 Distinguished Name（识别名）添加到我们返回给用户的签署证书中。

有了签署的证书，有了与自己的 service_id 相匹配的 Distinguished Name，MSK 能够轻松地通过 TLS 身份验证检测一个给定的服务是否允许对某个特定主题进行读/写。如果不允许这个服务（根据 acl.yml 文件和 ZooKeeper 中设置的 ACL）执行给定的操作，那么客户端就会出现错误，Kafka 的读/写操作就不会发生。

也是必需的：

与 KSS 平行，我们构建了一个定制的 Kafka sidecar Docker 容器：

1. 简单地插入到现有的 docker-compose 文件中；
2. 在引导时自动生成 CSR，并调用 KSS 以获得签署的证书，以及
3. 将证书存储在用户服务的 Docker 共享卷中，这可以用于实例化 Kafka 生产者/消费者客户端，以便进行 TLS 身份验证。

丰富的数据流工具

通过以下强大的工具，我们扩展了我们的核心 Kafka 集群：

Kafka Connect

它是一个 EC2 节点的分布式集群（AWS 自动扩展组），在各种数据库系统上执行变更数据捕获（CDC）。目前，我们正在利用 MongoDB、Snowflake、S3 和 Postgres 源/汇连接器。许多其他的连接器可以通过 Confluent 获取源代码：
https://www.confluent.io/product/connectors/

Kafdrop

通过使用开源的 Kafdrop 产品，我们可以实现一流的主题/分区偏移监测和用户消费滞后检查。
源代码：
https://github.com/obsidiandynamics/kafdrop

Cruise Control

这是另一个开源项目，它提供了自动分区再平衡，以保持我们的集群负载/磁盘空间在所有 broker 节点上的平衡。
源代码：
https://github.com/linkedin/cruise-control

Confluent Schema Registry

利用 Confluent 的开源 Schema Registry 来存储版本化的 proto 定义（在 Coinbase gRPC 中广泛使用）。
源代码：
https://github.com/confluentinc/schema-registry

Internal Kafka SDK

对我们的流栈至关重要的是一个内部开发的定制 Golang Kafka SDK，它基于 segmentio/kafka 版本。内部 SDK 与我们的 Schema Registry 集成，这样当生产者写入时，proto 定义会自动注册/更新。另外，该 SDK 为用户提供了以下好处：

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

Streaming SDK

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

• 将一个事件传递到多个目的地，通常被描述为“扇出”（fanout）或“镜像”（mirroring）。例如，将相同消息同时发送到 Kafka 主题和 SQS 队列。
• 接收来自一个 Kafka 主题的消息，向另一个主题发送新消息，甚至 Kinesis 流也是数据处理结果。
• 对动态消息路由的支持，例如，消息可以在多个 Kafka 集群或 AWS 区域之间故障切换。
• 对每一个流媒体平台提供了优化配置，以减少人为错误、最大化吞吐量和性能，并提醒用户错误配置。

Upcoming

即将到来的是与我们的 Delta Lake 整合，这会给我们的数据分析师和数据科学团队带来更好的性能、及时的数据 ETL。除此之外，随着内部需求的增加，我们能够将 prod 集群中的 broker 节点数量增加 3 倍（30→90 个节点，这是一个软限制，可以通过 AWS 支持票（support ticket）增加。

总结

总的说来，我们对 AWS MSK 相当满意。在安全补丁、维护和 Kafka 版本升级期间的自动 broker 恢复，以及围绕磁盘空间使用/broker CPU 的高级 broker/主题级监控指标，节省了我们自行配置和维护broker和ZooKeeper节点的数百个小时的时间。通过与Terraform的集成，初始集群配置、部署和配置更新相对简单（将3AZS应用于集群可以使它更具弹性，并能防止完全的 AZ 中断）。

其性能已经超出预期，低于 10 毫秒的延迟为超高速应用打开了大门。集群的正常运行时间一直很好，超过了 AWS 提供的 99.9%的 SLA。此外，当出现任何安全补丁时，它总是以滚动 broker 的方式进行，因此不会影响读 / 写操作（将默认的主题复制系数设置为 3，因此即使出现节点故障，最小同步复制也是 2）。

我们发现，在 MSK 的基础上进行构建具有高度的可扩展性，可以毫无问题地集成 Kafka Connect、Confluent Schema Registry、Kafdrop、Cruise Control 等。最终，MSK 为我们维护系统的工程师（减少维护节点的开销）和利用超低延迟数据流的能力解锁我们的内部用户和服务带来了好处。

作者介绍：

Coinbase，其使命是增加世界经济自由。

本文作者为 Dan Moore、Eric Sun、LV Lu、Xinyu Liu。

原文链接：

https://blog.coinbase.com/how-we-scaled-data-streaming-at-coinbase-using-aws-msk-4595f171266c