引领消息和流存储走向云原生时代，助力客户实现云端业务能力提升是包括阿里云、Auto MQ等在内的每一家云服务提供商的使命。但在具体的项目实践中会发现很多产品虽然宣称自己是云原生的，实际上却并没有对云计算能力的应用产生本质的变化。也有一些产品支持部署到 Kubernetes 后，就认为自己达到了云原生的阶段。笔者认为真正的云原生产品是要能够深度把云计算原生的能力、弹性的能力和规模化的优势充分利用起来，在成本和效率上都要有数量级的优势。
在 2024 的 3 月份，作为阿里云产品生态合作伙伴，AutoMQ 与阿里云进行了产品及解决方案的联合发布，并正式上架阿里云云市场进行售卖。本文将盘点 AutoMQ 立足于阿里云是如何深度使用计算和存储产品，以及基于这些产品和技术为用户解决什么样的实际问题。
1. 基于存储服务的成本优化与性能提升
1.1 对象存储 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] 等表的形态进行存储，做进一步大规模的数据分析。从数据的生命周期来看，从流到表，是非常符合数据从高频变低频，从热变冷的自然特征，在对象存储之上构建流表一体的数据技术栈是未来的趋势。
1.2 块存储 ESSD
如果说大家仍然将 ECS 当做物理机来看待，云盘 ESSD 也有类似的命运。用户对 ESSD 通常有两类误解：
● 将 ESSD 类比本地盘，担心数据的持久性，认为坏盘、坏道等专属于物理盘的错误类型仍然会出现。
● 认为 ESSD 是云盘，所以远程写入性能差，延迟不可控，容易抖动。
实际上，ESSD 背后是一套完整的分布式文件系统，内置了多副本技术，能够提供 9 个 9 的数据持久性。用户对物理存储介质的错误完全无需感知，底层系统能自动运维容错数百万块物理盘。
同时，ESSD 也是共享存储的形态，ESSD 卷可以在 ECS 故障时，挂载至其他节点继续提供读写服务。从这个角度来看，ESSD 跟 OSS 都是共享存储，而非有状态的本地磁盘，这也是 AutoMQ 声称自己是无状态数据软件的主要原因。
在性能方面，ESSD 背后有软硬件一体的优化，通过将 ESSD 客户端卸载到神龙 MOC[4] 来实现硬件加速，同时与远端服务器之间采用基于 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 两类共享存储的优势集中到了一起，提供了低延迟、高吞吐、低成本和容量“无限”的的流存储能力。
多重挂载和 NVMe 协议
诚然，ESSD 虽说是共享存储，但使用上是块设备的形态，所以要将 ESSD 高效地共享起来，需要额外的存储技术支撑，即多重挂载和 NVMe PR 协议。
云盘本身支持在卸载后重新挂载到其他节点用于恢复，但当原挂载节点出现 ECS Hang 等类型的故障时，云盘的卸载耗时比较不可控，所以可以依赖 ESSD 提供的多重挂载能力，可以做到不进行云盘的卸载，直接多重挂载到另一个 ECS 节点。
以 AutoMQ Failover 流程为例，当某 Broker 节点被识别为 Failed Broker 后，将其上的云盘，多重挂载到健康的 Broker 进行数据恢复。在进入真正的 Recovery 流程前，需要确保原节点没有在持续写入，AutoMQ 通过 NVMe 协议的 PR 锁对原节点进行 IO Fencing。
这两个过程均是毫秒级的操作，可以将 ESSD 在 AutoMQ 场景下真正地变为共享存储。
Regional ESSD
ESSD 背后虽然是多副本架构，但常规的 ESSD 其多副本是分布在单个 AZ 内的，这也导致 ESSD 无法应对 AZ 级的故障，Regional EBS[5] 就是用于解决该问题的。通过将底层的多副本冗余分布在多个 AZ 内，采用强一致的读写技术，能够容忍单 AZ 故障。
在共享挂载方面，支持 Region 内 ECS 跨可用区挂载以及多可用区共享挂载，支持抢占式的 IO Fencing 和 NVMe PR 锁形式的 IO Fencing。对于 Regional ESSD，国外主流云厂商均有对应的产品形态，同时在阿里云上也即将发布，该产品使 AutoMQ 能够以极低的成本容忍单 AZ 故障，满足可用性较高的业务场景需求。
2. 基于计算服务的可用性和弹性能力提升
2.1 云服务器 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 提供的能力做进一步主动的容灾。
2.2 弹性伸缩 ESS
在 2024 的 3 月份，AutoMQ 与阿里云进行了联合发布，正式上架阿里云云市场进行售卖。从 AutoMQ 内核的 GA 到快速登陆阿里云市场，这背后有两款产品的助力，第一款是阿里云计算巢，它为服务商提供了标准化的交付流程，另一款就是弹性伸缩 ESS。AutoMQ 存算分离的架构虽然天然亲和弹性伸缩，但想要提供自动伸缩的能力，也并非易事[6]，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 是一款非常优秀软件，AutoMQ 后续也会支持部署到 K8s，特别是在私有云环境，能够屏蔽大量的 IaaS 层差异。
2.3 抢占式实例
弹性的能力并不是云厂商与生俱来的，云厂商为了给客户提供充足的弹性供给，需要承担巨大的保有成本，从而不可避免地导致了云厂商有大量的闲置的计算资源。这部分闲置的资源通过抢占式实例进行售卖，其性能与常规 ECS 实例无任何区别，相比较按量付费的实例成本最高能节省 90%。
抢占式实例相比较按量付费实例，有一个重要的特征，就是其价格随供需变化而浮动，比如如果晚上业务对算力的需求小，价格自然就更加便宜。所以，在一定程度上抢占式实例的定价包含了时间的维度，如果所有的用户都能将抢占式实例用起来，自然就会被价格所调节，会促使大家为自己的工作负载选择最合适的运行时间段。比如，AutoMQ 会在晚上运行一些大规模的测试用例，通过使用抢占式实例，大幅度降低测试的成本。
另一个特征，抢占式实例会被随时中断回收，这确实为使用它带来了很高的门槛。但 AutoMQ 推出的存算分离架构，使得 Broker 节点无任何本地状态，能够从容应对抢占式实例被回收的情形。下图演示了AutoMQ 在抢占式实例回收时通过ESSD API 完成 WAL 恢复的流程。AutoMQ 能达到十倍降本的效果，抢占式实例在计算降本的维度起到了重要的作用。
3. 结束语
今天，基础软件的大半壁江山，大都诞生于 10 年前，它们高效地支撑了大数据和互联网的快速发展。但面向 IDC 环境设计的基础软件，在云计算成熟的今天来看，并不是那么的高效和低成本，今天大量的基础软件在基于云重新设计，比如可观测性存储组件、TP 和 AP 数据库、数据湖软件等。Kafka 作为重要的流存储软件，在大数据生态系统中占据了举足轻重的位置，在数据驱动型企业的整个 IT 支出中占比 10% ~ 20%，基于云原生的能力重新设计 Kafka，为企业降本增效，在当前降本的大背景下，有重大的意义。AutoMQ 通过深度用云，以云原生的能力重构了 Apache Kafka，创造了 10 倍的成本优势。相较于Kafka，AutoMQ的共享存储架构使得在分区迁移、节点动态扩缩容、流量自动重平衡等运维方面的耗时指标得到了数百倍的优化。
4. 引用
2. Confluent 全新发布 Tableflow，统一流和分析型计算
4. 阿里云自研神龙架构
5. 2023 云栖大会抢先发布 Regional ESSD
作者：周新宇 AutoMQ联合创始人&CTO
