Skip to main content

与“众”不同的 AutoMQ 云原生架构

本文中提及的 AutoMQ Kafka 术语,均特指安托盟丘(杭州)科技有限公司通过 GitHub AutoMQ 组织下开源的 automq-for-kafka 项目。

随着 AutoMQ 的开源,社区近几周对 AutoMQ 的架构展开了广泛的讨论,大家特别关注 AutoMQ 的架构相对于现有的开源或商业的解决方案有何不同之处。这篇文档主要用来回答这类型问题。

与多级存储的区别

随着 Apache Kafka 3.6.0 的发布,KIP-405 多级存储存储方案终于问世,虽然该特性仍处于早期访问阶段,但社区包括 Twitter 上有不少开发者询问 AutoMQ 的架构相较于 KIP-405 核心优势在哪里。

如果我们在云上部署 Apache Kafka 或者 AutoMQ Kafka,确实两个架构有一定的相似性,都是基于 EBS 和 对象存储(S3)的部署形态,虽然在存储介质的选型上是一致的,但实际上如何用这两类存储的思想是不同的。

首先来讲 EBS:

  • Apache Kafka 的架构将 EBS 视作普通的块设备存储介质,跟本地机房的一块物理硬盘没有本质的区别,所以 Apache Kafka 会基于 EBS 做数据复制,一般要求 3 副本。
  • AutoMQ Kafka 将 EBS 视作高可靠、高可用的云存储服务,充分利用 EBS 自带 3 副本的可靠性(5 个 9 ~ 9 个 9 的可靠性)以及其在可用区内和可用区之间的故障转移能力,这使得 AutoMQ Kafka 可以避免在 EBS 之上做额外的复制,从而节省大量的存储、网络和计算资源。

再来看对象存储(S3):

  • Apache Kafka 将 S3 用于第二级存储,第一级存储构建在 EBS 之上,从设计上来看,每个 Kafka Topic 的分区,至少最后一个活跃的 Segment 需要留在第一级存储之上。这也导致多级存储方案中的第一级 EBS 存储将使用多少存储空间是不固定的,往往跟分区数量有关系。
  • AutoMQ Kafka 将 S3 作为主存,EBS 定位为高速写入缓冲区,更多的是一个低延迟的持久化缓存。因此 AutoMQ Kafka 的每个 Broker 仅需要 2GB 的 EBS 卷,其中仅 500MB 不在 S3 上的 Delta 数据(可配置)。

EBS 作为缓冲区,所以存储空间具备确定性,使得 AutoMQ Kafka 架构在 EBS 存储上开销极低,一块 2GB 的 EBS 卷每月花费仅 1 元,同时缓冲区里面仅最多有不超过 500MB 的数据是在 S3 上不存在的,可以做到秒级完成 S3 上传,进而能支持秒级的分区转移。

相反,多级存储架构中的一级存储空间不固定,需要对 EBS 进行容量评估,这往往是一件很困难的事情,所以我们仍然需要为每个 Broker 节点预置大容量的 EBS 卷。另一方面,每个分区遗留在 EBS 上的数据也不固定,所以分区移动时间也不确定,也没办法快速伸缩。以 Confluent 给出的案例来看,在一个大流量集群,扩容操作在非多级存储架构需要耗时 43 小时,在多级存储架构需要耗时 1.4 小时。可以看出,多级存储方案虽然大大缓解了 Kafka 架构上固有的问题,但无法像 AutoMQ Kafka 架构一样做到无状态。

总结一下,AutoMQ Kafka 的云原生架构相较于多级存储方案,是一个量变引起质变的过程,通过架构优化,使得 AutoMQ Kafka 做到「无状态」,任意伸缩,秒级分区转移。相反,多级存储架构是一个优化方案,仍然是有状态。

与 WarpStream 的区别

WarpStream 重新实现了 Kafka 协议,将 Kafka 直接构建在了对象存储 S3 上,Kafka 的协议主要由一个 Agent 组件来实现,因为 Agent 本地不需要挂载 EBS,可以说是完全无状态。但因为 S3 的 IO 特征,S3 会根据 API 计费,且 S3 API 调用本身有百毫秒级的延迟,所以 WarpStream 只能在同步链路上攒批写入,会有 ~400ms 的 P99 写入延迟,1s 的 P99 端到端延迟。

无状态

从无状态角度来看,WarpStream 本地 0 存储空间,可以说是彻底的无状态,自然很容易进行分区迁移和扩缩容相关的运维操作。

但 AutoMQ Kafka,本地存储空间仅需 2GB,其中仅 500MB Delta 数据,依然能做到秒级的分区迁移和节点的扩缩容,也可以说是无状态的解决方案。

成本

从成本角度来看,因为一块 2GB 的 EBS,每月仅花费 1 元,可以忽略不计。故而在成本这块 AutoMQ 和 WarpStream 基本一致,都能做到理论上的成本最优。

延迟

WarpStream 做了明确的取舍,牺牲了延迟指标,采用 WarpStream 方案的用户必须接受 400ms 的 P99 延迟。

相反,AutoMQ Kafka 的 Delta WAL 机制提供了极具竞争力的延迟,因为 WAL 简单的存储结构,我们可以通过写裸设备的方式写入 WAL,完全抛弃了文件系统的开销,将延迟优化到了极致。

可用性

在 S3 依赖方面,两个产品的可用性是对齐的,但 AutoMQ 额外依赖了 EBS,所以需要依赖 EBS 的 Detach/Attach API 以及 NVMe 相关的 API 来实现故障转移能力。

兼容性

WarpStream 选择了协议适配,目前仅适配了主要的 API,事务相关的高级 API 还未适配。实际上,适配 Kafka 协议的难度非常大,Kafka 发展这么多年,有些 API 有数十个版本,要完全适配好,难度可想而知,适配完成后也会有相当长的成熟周期。

AutoMQ Kafka 基于 Apache Kafka 的 LogSegment 切面进行开发,替换了 Apache Kafka 的存储层,改动切面足够小,所以仍旧可以持续合并跟进 Apache Kafka 的代码,保持功能和缺陷修复与 Apache Kafka 一致。

当前 AutoMQ Kafka 通过了社区全部的 E2E 测试,可以说 100% 兼容 Apache Kafka。

与 Redpanda 的区别

Redpanda 跟 AutoMQ 的架构和理念是大相径庭的,Redpanda 通过 Native 的语言重写了 Kafka,获得了 Native 语言的一些性能优势,但在复制、对象存储等方面的方案跟 Apache Kafka 没有太大的区别。

另外,Redpanda 强调单机、甚至单 Core 的极限性能,这种思想其实更加适用于本地机房,有利于将已经闲置的物理资源充分利用起来。但实际上在云端,云厂商提供的资源是比较均衡,且基本上都是按量付费,如何更加经济地使用物理资源是 AutoMQ 更看重的事情。