作者｜周新宇，AutoMQ 联合创始人 & CTO
导读
AutoMQ[1] 是新一代基于共享存储架构实现的云原生 Kafka。得益于其存算分离的共享存储架构，通过和阿里云合作，深度使用阿里云可靠、先进的云服务如对象存储OSS、块存储 ESSD、弹性伸缩ESS以及抢占式实例实现了相比 Apache Kafka 10倍的成本优势并且提供了自动弹性的能力。
引领消息和流存储走向云原生时代，助力客户实现云端业务能力提升是包括阿里云、Auto MQ等在内的每一家云服务提供商的使命。随着服务的不断深入，我们也发现，很多产品突然宣称自己是云原生的，实际上对云计算能力的应用并没有发生本质的变化。也有产品支持部署到 Kubernetes 后就认为自己达到了云原生的阶段。我们认为真正的云原生产品是要能够深度把云计算原生的能力、弹性的能力和规模化的优势充分利用起来，在成本和效率上都要有数量级的优势。
今天，这篇文章，主要是立足于阿里云，盘点 AutoMQ 深度使用的云原生技术，以及分别用这些技术解决什么样的实际问题。
01
对象存储 OSS
海量的数据正在往云端聚集，对象存储已经成为了大数据和数据湖生态事实上的存储引擎，我们今天可以发现大量的数据密集型软件正在从文件 API 迁移到对象 API，以 Kafka 为代表的流式数据入湖也是大势所趋。
AutoMQ 基于对象存储研发了 S3Stream[1] 流存储库，能够基于 Object API 提供流式数据的高效的读取和摄入，然后通过存算分离的架构方式将 Apache Kafka 的存储层对接至对象存储，充分获得了共享存储带来的技术和成本优势：
OSS 同城冗余的标准版存储单价为 0.12 元/GiB/月，相较于 ESSD PL1 的单价（1 元/1 GiB/月）便宜 8 倍以上。同时，OSS 天然具备多可用区的可用性和持久性，数据无需额外再做复制，使得相比较传统的基于云盘的 3 副本架构，成本能节省 25 倍。
共享存储架构相比较 Shared-Nothing 架构，是真正的存算分离，数据跟计算节点无绑定关系。因此，AutoMQ 在进行分区移动时无需复制数据，能够做到真正的秒级无损分区迁移。这也是支撑 AutoMQ 流量实时重平衡和秒级节点水平扩缩容的原子能力。
AutoMQ 从成本和架构上对 OSS 提供的能力进行了充分挖掘，但这仅仅是起步，共享存储将为 AutoMQ 带来丰富的技术和产品创新上的想象力。
灾难恢复：作为基础软件，最担心的莫过于集群出现故障后无法继续提供服务，或者数据无法恢复，可能的故障有软件缺陷、机房级故障等。因为有了共享存储，结合简单的元数据快照机制，可以在关闭故障集群后，基于 OSS 上的数据状态重新打开为一个全新的集群，用于恢复业务。
跨地域容灾：OSS 提供地域间的准实时复制，业务无需自己组建跨地域网络，也无需搭建昂贵的数据 Connect 集群，结合上述提到的灾难恢复技术，可以很容易 0 编码实现跨地域容灾的解决方案。
共享只读副本：高扇出是消费流式数据的一个重要的业务场景，在一家 Data 驱动的企业里面，一份数据可能存在数十个订阅方，原集群无法承担数十倍的读取流量。基于 OSS，无需数据复制，就可以以共享存储的形式直接从 OSS 上打开只读副本，提供极具扩展性的高扇出能力。
Zero ETL：现代的数据技术栈都在基于对象存储来构建，当数据在同一个存储池，且具备一定的自描述能力后，数据孤岛就能够被低成本打破，不需要构建 ETL 通道，不同的分析软件或者计算引擎，可以共享来自不同数据源的数据。
另一方面，流式数据入湖，现代化数据栈完成了最后一块拼图，流湖一体的架构有了落地的基础，这也是 Confluent 推出的 TableFlow[2] 带来的巨大想象力。数据以流的形式产生和存储，符合真实世界中信息不断生成和变化的特征，实时生成的数据一定要以流的形式存在，从而流计算框架有机会挖掘更多实时的价值。当一段时间后数据失去新鲜度后，再转换为 Iceberg[3] 等表的形态进行存储，做进一步大规模的数据分析。从数据的生命周期来看，从流到表，是非常符合数据从高频变低频，从热变冷的自然特征，在对象存储之上构建流表一体的数据技术栈是未来的趋势。
02
云服务器 ECS
从过去十年的上云历程来看，大部分企业上云的方式是以 Rehost 的形式进行上云。这里 Host 的替换实际上就是拿云服务器 ECS 去替换传统线下的物理主机，但实际上，ECS 与线下物理主机的最大区别在于 ECS 提供了服务 SLA，它能借助虚拟化的一些技术规避部分物理主机软硬件故障，对于无法规避的物理主机故障，云服务器也能在宕机后快速在新的物理主机上恢复，缩短业务的受损时长。阿里云单 ECS 实例承诺的 SLA 为 99.975%，也就是说，在云上以单 ECS 节点的形式部署一个服务，能做到 3 个 9 以上的可用性，这实际上已经是生产可用的，能满足很多业务的可用性要求。以 AutoMQ 为例，选取一个 2C16G 的 ECS 部署一个单节点的 AutoMQ 集群，就能提供 3 个 9 的可用性以及 80MiB/s 的写入能力，成本可以说是做到了极致。AutoMQ 在设计之初就将 ECS 当成了云服务来看待，而不是物理主机，在 ECS 出现故障时，我们更多地依赖 ECS 节点能快速恢复，比如宕机的时候能自动迁移和自动拉起。只有在失去某个节点连续的数个心跳后，AutoMQ 的主动 Failover 能力才会进行介入。这样设计的考虑点主要有以下两点：
对于物理机硬件故障或内核故障问题，ECS 能做到宕机后秒级恢复，所以 AutoMQ 依赖 ECS 的快速恢复能力来处理这类故障，同时也避免主动 Failover 能力过于灵敏带来不必要的容灾处理。
当出现 ECS 宕机、网络分区、甚至 AZ 级故障时，AutoMQ 的 Failover 能力才会生效，通过 ESSD 和 OSS 提供的能力做进一步主动的容灾。
03
弹性伸缩 ESS
在 2024 的 3 月份，AutoMQ 与阿里云进行了联合发布，正式上架阿里云云市场进行售卖。从 AutoMQ 内核的 GA 到快速登陆阿里云市场，这背后有两款产品的助力，第一款是阿里云计算巢，它为服务商提供了标准化的交付流程，另一款就是弹性伸缩 ESS。AutoMQ 存算分离的架构虽然天然亲和弹性伸缩，但想要提供自动伸缩的能力，也并非易事[4]，AutoMQ 使用 ESS 来简化最后一公里的交付之路。AutoMQ 在公有云上的交付在 Kubernetes 和 ESS 之间选择了 ESS，背后主要有几点考虑：
AutoMQ 推出的第一个产品形态是 BYOC，为了简化依赖，避免每个用户在部署 AutoMQ 时都需要准备一套 K8s 集群。
弹性伸缩 ESS 具备配置管理、自动弹性伸缩、定时扩缩容、机型管理、多 AZ 形态、健康检查等能力已经能媲美 K8s 核心的 Deployment 能力，我们认为 ESS 就是 IaaS 层提供的轻量级 K8s 形态。
后文会提到 AutoMQ 依赖的多重挂载，Regional ESSD 等云厂商提供的新特性，K8s 很难第一时间支持。纯粹利用 IaaS 层的 API 相较于使用 K8s 的 API，有类似 C++ 语言和 Java 语言的区别，Native 的特性需要在 K8s 层面进行透出才能使用。
当然，K8s 是一款非常优秀软件，我们在后续也会支持部署到 K8s，特别是在私有云环境，能够屏蔽大量的 IaaS 层差异。
04
抢占式实例
弹性的能力并不是云厂商与生俱来的，云厂商为了给客户提供充足的弹性供给，需要承担巨大的保有成本，从而不可避免地导致了云厂商有大量的闲置的计算资源。这部分闲置的资源通过抢占式实例进行售卖，其性能与常规 ECS 实例无任何区别，相比较按量付费的实例成本最高能节省 90%。抢占式实例相比较按量付费实例，有一个重要的特征，就是其价格随供需变化而浮动，比如如果晚上业务对算力的需求小，价格自然就更加便宜。所以，在一定程度上抢占式实例的定价包含了时间的维度，如果所有的用户都能将抢占式实例用起来，自然就会被价格所调节，会促使大家为自己的工作负载选择最合适的运行时间段。比如，AutoMQ 会在晚上运行一些大规模的测试用例，通过使用抢占式实例，大幅度降低测试的成本。另一个特征，抢占式实例会被随时中断回收，这确实为使用它带来了很高的门槛。但 AutoMQ 推出的存算分离架构，使得 Broker 节点无任何本地状态，能够从容应对抢占式实例被回收的情形。下图演示了AutoMQ 在抢占式实例回收时通过ESSD API 完成 WAL 恢复的流程。AutoMQ 能达到十倍降本的效果，抢占式实例在计算降本的维度起到了重要的作用。
05
块存储 ESSD
如果说大家仍然将 ECS 当做物理机来看待，云盘 ESSD 也有类似的命运。用户对 ESSD 通常有两类误解：
将 ESSD 类比本地盘，担心数据的持久性，认为坏盘、坏道等专属于物理盘的错误类型仍然会出现。
认为 ESSD 是云盘，所以远程写入性能差，延迟不可控，容易抖动。
实际上，ESSD 背后是一套完整的分布式文件系统，内置了三副本技术，能够提供 9 个 9 的数据持久性。用户对物理存储介质的错误完全无需感知，底层系统能自动运维容错数百万块物理盘。同时，ESSD 也是共享存储的形态，ESSD 卷可以在 ECS 故障时，挂载至其他节点继续提供读写服务。从这个角度来看，ESSD 跟 OSS 都是共享存储，而非有状态的本地磁盘，这也是 AutoMQ 声称自己是无状态数据软件的主要原因。在性能方面，ESSD 背后有软硬件一体的优化，通过将 ESSD 客户端卸载到神龙 MOC[5] 来实现硬件加速，同时与远端服务器之间采用基于 RDMA 技术的自研高性能网络协议和拥塞控制算法，而非 TCP 技术栈，以适应数据中心内低延迟和低丢包率的特点。这些优化带来了稳定的 IOPS 和吞吐性能，以及高度可扩展的存储容量。AutoMQ 使用 ESSD 有三个创新点：
可靠性分离，充分利用 ESSD 背后的多副本技术，避免在应用层引入 Raft 或者 ISR 等复制机制，在存储成本，网络复制带宽成本方面都有大幅度降低。
将 ESSD 作为 WAL，以裸设备、Direct IO 的形式循环写入 ESSD，仅用于故障场景下的恢复。得益于 ESSD 的共享属性，AutoMQ 的 WAL 是一个远程的可共享的 WAL，能被集群中的任何节点进行接管恢复。
面向云服务的计费项设计，ESSD 给任意容量的卷提供至少 100 MiB/s 左右的吞吐和 1800 左右的 IOPS。AutoMQ 仅需要一块最小规格的 ESSD 卷作为 WAL 盘，比如一块 2GiB 的 ESSD PL0 卷，每月仅需 1 块钱，即可提供上述性能。如果单机需要更高的存储性能，仅需组合多块小规格的 WAL 盘即可线性扩展。
ESSD 和 OSS 拥有截然不同的存储特征，ESSD 是高性能，低延迟和高 IOPS 的存储介质，但成本高昂，不过 AutoMQ 找到了一种最经济的使用 ESSD 的方法。OSS 不擅长于高 IOPS 的场景，它会为每一次 IO 进行计费，但 OSS 存储成本低，吞吐和容量近乎“无限地”扩展。OSS 作为主存储提供了高吞吐、低成本、高可用、无限扩展的存储能力；ESSD 提供了用于存储 WAL 的持久化、高可用、低延迟的存储能力，并且由于其虚拟化的性质可以申请非常小的存储空间。AutoMQ 自研的流存储库 S3Stream[1] 巧妙地将 ESSD 和 OSS 两类共享存储的优势集中到了一起，提供了低延迟、高吞吐、低成本和容量“无限”的的流存储能力。
06
多重挂载和 NVMe 协议
诚然，ESSD 虽说是共享存储，但使用上是块设备的形态，所以要将 ESSD 高效地共享起来，需要额外的存储技术支撑，即多重挂载和 NVMe PR 协议。云盘本身支持在卸载后重新挂载到其他节点用于恢复，但当原挂载节点出现 ECS Hang 等类型的故障时，云盘的卸载耗时比较不可控，所以可以依赖 ESSD 提供的多重挂载能力，可以做到不进行云盘的卸载，直接多重挂载到另一个 ECS 节点。以 AutoMQ Failover 流程为例，当某 Broker 节点被识别为 Failed Broker 后，将其上的云盘，多重挂载到健康的 Broker 进行数据恢复。在进入真正的 Recovery 流程前，需要确保原节点没有在持续写入，AutoMQ 通过 NVMe 协议的 PR 锁对原节点进行 IO Fencing。这两个过程均是毫秒级的操作，可以将 ESSD 在 AutoMQ 场景下真正地变为共享存储。
07
Regional ESSD
ESSD 背后虽然是多副本架构，但常规的 ESSD 其多副本是分布在单个 AZ 内的，这也导致 ESSD 无法应对 AZ 级的故障，Regional EBS[6] 就是用于解决该问题的。通过将底层的多副本冗余分布在多个 AZ 内，采用强一致的读写技术，能够容忍单 AZ 故障。在共享挂载方面，支持 Region 内 ECS 跨可用区挂载以及多可用区共享挂载，支持抢占式的 IO Fencing 和 NVMe PR 锁形式的 IO Fencing。对于 Regional ESSD，国外主流云厂商均有对应的产品形态，同时在阿里云上也即将发布，该产品使 AutoMQ 能够以极低的成本容忍单 AZ 故障，满足可用性较高的业务场景需求。
08
结束语
今天，基础软件的大半壁江山，大都诞生于 10 年前，它们高效地支撑了大数据和互联网的快速发展。但面向 IDC 环境设计的基础软件，在云计算成熟的今天来看，并不是那么的高效和低成本，所以我们观察到今天大量的基础软件在基于云重新设计，比如可观测性存储组件、TP 和 AP 数据库、数据湖软件等。Kafka 作为重要的流存储软件，在大数据生态系统中占据了举足轻重的位置，在数据驱动型企业的整个 IT 支出中占比 10% ~ 20%，基于云原生的能力重新设计 Kafka，为企业降本增效，在当前降本的大背景下，有重大的意义。AutoMQ 通过深度用云，以云原生的能力重构了 Apache Kafka，创造了 10 倍的成本优势。相较于Kafka，AutoMQ的共享存储架构使得在分区迁移、节点动态扩缩容、流量自动重平衡等运维方面的耗时指标得到了数百倍的优化。云计算，开辟了一个新的时代，以云原生的姿势上云，是不会有下云的忧虑，我们坚信，所有的基础软件，都值得基于云重新设计，以发挥出云全部的优势。
引用文章
- 开源的云原生版 Kafka——AutoMQ：https://github.com/AutoMQ/automq
- Confluent 全新发布 Tableflow，统一流和分析型计算：https://www.confluent.io/blog/introducing-tableflow/
- 开放表格式 Iceberg 官网：https://iceberg.apache.org/
- 为什么公共云的弹性能力很难被发挥出来？https://www.infoq.cn/article/tugbtfhemdiqlxm1x63y
- 阿里云自研神龙架构：https://developer.aliyun.com/article/743920
- 2023 云栖大会抢先发布 Regional ESSD：https://developer.aliyun.com/article/1390447
END
关于我们
我们是来自 Apache RocketMQ 和 Linux LVS 项目的核心团队，曾经见证并应对过消息队列基础设施在大型互联网公司和云计算公司的挑战。现在我们基于对象存储优先、存算分离、多云原生等技术理念，重新设计并实现了 Apache Kafka 和 Apache RocketMQ，带来高达 10 倍的成本优势和百倍的弹性效率提升。
🌟 GitHub 地址：https://github.com/AutoMQ/automq
💻 官网：https://www.automq.com
👀 B站：AutoMQ官方账号
🔍 视频号：AutoMQ
