AutoMQ:基于阿里云计算与存储产品实现云原生架构升级

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,内容安全 1000次 1年
文件存储 NAS,50GB 3个月
简介: AutoMQ[1] 是新一代基于共享存储架构实现的云原生 Kafka。得益于其存算分离的共享存储架构,通过和阿里云合作,深度使用阿里云可靠、先进的云服务如对象存储OSS、块存储 ESSD、弹性伸缩ESS以及抢占式实例实现了相比 Apache Kafka 10倍的成本优势并且提供了自动弹性的能力。


引领消息和流存储走向云原生时代,助力客户实现云端业务能力提升是包括阿里云、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 左右的 IOPSAutoMQ 仅需要一块最小规格的 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 两类共享存储的优势集中到了一起,提供了低延迟、高吞吐、低成本和容量无限的的流存储能力。


Four primary data flows of AutoMQ.png


多重挂载和 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 到快速登陆阿里云市场,这背后有两款产品的助力,第一款是阿里云计算巢,它为服务商提供了标准化的交付流程,另一款就是弹性伸缩 ESSAutoMQ 存算分离的架构虽然天然亲和弹性伸缩,但想要提供自动伸缩的能力,也并非易事[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 能达到十倍降本的效果,抢占式实例在计算降本的维度起到了重要的作用。


Reattach idle data volume to other ECS instance.png


3. 结束语

今天,基础软件的大半壁江山,大都诞生于 10 年前,它们高效地支撑了大数据和互联网的快速发展。但面向 IDC 环境设计的基础软件,在云计算成熟的今天来看,并不是那么的高效和低成本,今天大量的基础软件在基于云重新设计,比如可观测性存储组件、TP AP 数据库、数据湖软件等。Kafka 作为重要的流存储软件,在大数据生态系统中占据了举足轻重的位置,在数据驱动型企业的整个 IT 支出中占比 10% ~ 20%,基于云原生的能力重新设计 Kafka,为企业降本增效,在当前降本的大背景下,有重大的意义。AutoMQ 通过深度用云,以云原生的能力重构了 Apache Kafka,创造了 10 倍的成本优势。相较于KafkaAutoMQ的共享存储架构使得在分区迁移、节点动态扩缩容、流量自动重平衡等运维方面的耗时指标得到了数百倍的优化。

 

4. 引用

1.       开源的云原生版 Kafka——AutoMQ

2.       Confluent 全新发布 Tableflow,统一流和分析型计算

3.       开放表格式 Iceberg 官网

4.       阿里云自研神龙架构

5.       2023 云栖大会抢先发布 Regional ESSD

6.       为什么公共云的弹性能力很难被发挥出来?


作者:周新宇  AutoMQ联合创始人&CTO

相关文章
|
18天前
|
Cloud Native Serverless 数据中心
阿里云ACK One:注册集群支持ACS算力——云原生时代的计算新引擎
ACK One注册集群已正式支持ACS(容器计算服务)算力,为企业的容器化工作负载提供更多选择和更强大的计算能力。
|
1天前
|
Cloud Native Serverless 数据中心
阿里云ACK One:注册集群支持ACS算力——云原生时代的计算新引擎
阿里云ACK One:注册集群支持ACS算力——云原生时代的计算新引擎
17 10
|
22天前
|
运维 Cloud Native 应用服务中间件
阿里云微服务引擎 MSE 及 云原生 API 网关 2025 年 1 月产品动态
阿里云微服务引擎 MSE 面向业界主流开源微服务项目, 提供注册配置中心和分布式协调(原生支持 Nacos/ZooKeeper/Eureka )、云原生网关(原生支持Higress/Nginx/Envoy,遵循Ingress标准)、微服务治理(原生支持 Spring Cloud/Dubbo/Sentinel,遵循 OpenSergo 服务治理规范)能力。API 网关 (API Gateway),提供 APl 托管服务,覆盖设计、开发、测试、发布、售卖、运维监测、安全管控、下线等 API 生命周期阶段。帮助您快速构建以 API 为核心的系统架构.满足新技术引入、系统集成、业务中台等诸多场景需要
阿里云微服务引擎 MSE 及 云原生 API 网关 2025 年 1 月产品动态
|
2天前
|
Cloud Native 安全 Serverless
云原生应用实战:基于阿里云Serverless的API服务开发与部署
随着云计算的发展,Serverless架构日益流行。阿里云函数计算(Function Compute)作为Serverless服务,让开发者无需管理服务器即可运行代码,按需付费,简化开发运维流程。本文从零开始,介绍如何使用阿里云函数计算开发简单的API服务,并探讨其核心优势与最佳实践。通过Python示例,演示创建、部署及优化API的过程,涵盖环境准备、代码实现、性能优化和安全管理等内容,帮助读者快速上手Serverless开发。
|
18天前
|
弹性计算 开发工具 云计算
产品动态丨阿里云计算巢月刊-2025年第1期
让优秀的企业软件生于云、长于云
|
2天前
|
人工智能 关系型数据库 分布式数据库
阿里云PolarDB重磅发布云原生与Data+AI新特性,打造智能时代数据引擎
阿里云PolarDB重磅发布云原生与Data+AI新特性,打造智能时代数据引擎
|
2月前
|
存储 弹性计算 运维
阿里云云原生NDR发布:全流量防御能力升级
阿里云发布云原生NDR,提供全流量威胁检测与响应能力。该产品无需部署,支持一键接入、自动留存攻击报文,并具备多引擎关联分析、资产风险管理等功能,有效提升高级威胁应对能力。典型客户案例显示,NDR在重保防护、敏感数据泄露和日志合规等场景中表现出色。总结来看,NDR强调原生化、性价比和强检测,帮助用户简化安全运营并降低成本。
52 11
|
2月前
|
运维 Cloud Native 应用服务中间件
阿里云微服务引擎 MSE 及 云原生 API 网关 2024 年 12 月产品动态
阿里云微服务引擎 MSE 面向业界主流开源微服务项目, 提供注册配置中心和分布式协调(原生支持 Nacos/ZooKeeper/Eureka )、云原生网关(原生支持Higress/Nginx/Envoy,遵循Ingress标准)、微服务治理(原生支持 Spring Cloud/Dubbo/Sentinel,遵循 OpenSergo 服务治理规范)能力。API 网关 (API Gateway),提供 APl 托管服务,覆盖设计、开发、测试、发布、售卖、运维监测、安全管控、下线等 API 生命周期阶段。帮助您快速构建以 API 为核心的系统架构.满足新技术引入、系统集成、业务中台等诸多场景需要
169 12
|
2月前
|
运维 关系型数据库 分布式数据库
阿里云PolarDB:引领云原生数据库创新发展
阿里云PolarDB引领云原生数据库创新,2024云栖大会将分享其最新发展及在游戏行业的应用。PolarDB凭借弹性、高可用性、多写技术等优势,支持全球80多个站点,服务1万多家企业。特别是针对游戏行业,PolarDB助力Funplus等公司实现高效运维、成本优化和业务扩展。通过云原生能力,PolarDB推动游戏业务的全球化部署与快速响应,提升用户体验并保障数据安全。未来,PolarDB将继续探索AI、多云管理等前沿技术,为用户提供更智能的数据基础设施。
|
2月前
|
机器学习/深度学习 弹性计算 人工智能
阿里云服务器ECS架构区别及选择参考:X86计算、ARM计算等架构介绍
在我们选购阿里云服务器的时候,云服务器架构有X86计算、ARM计算、GPU/FPGA/ASIC、弹性裸金属服务器、高性能计算可选,有的用户并不清楚他们之间有何区别,本文主要简单介绍下这些架构各自的主要性能及适用场景,以便大家了解不同类型的架构有何不同,主要特点及适用场景有哪些。
188 10

热门文章

最新文章