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

本文涉及的产品
云服务器 ECS,每月免费额度200元 3个月
对象存储 OSS,20GB 3个月
云服务器ECS,u1 2核4GB 1个月
简介: AutoMQ:如何基于阿里云计算与存储产品实现云原生架构升级

【阅读原文】戳:AutoMQ:如何基于阿里云计算与存储产品实现云原生架构升级

导读:AutoMQ[1]是新一代基于共享存储架构实现的云原生Kafka。得益于其存算分离的共享存储架构,通过和阿里云合作,深度使用阿里云可靠、先进的云服务如对象存储OSS、块存储ESSD、弹性伸缩ESS以及抢占式实例实现了相比Apache Kafka 10倍的成本优势并且提供了自动弹性的能力。

 

引领消息和流存储走向云原生时代,助力客户实现云端业务能力提升是包括阿里云、AutoMQ等在内的每一家云服务提供商的使命。但在具体的项目实践中会发现很多产品虽然宣称自己是云原生的,实际上却并没有对云计算能力的应用产生本质的变化。也有一些产品支持部署到Kubernetes后,就认为自己达到了云原生的阶段。笔者认为真正的云原生产品是要能够深度把云计算原生的能力、弹性的能力和规模化的优势充分利用起来,在成本和效率上都要有数量级的优势。

 

2024年3月,作为阿里云产品生态合作伙伴,AutoMQ与阿里云进行了产品及解决方案的联合发布,并正式上架阿里云云市场进行售卖。本文将盘点 AutoMQ立足于阿里云是如何深度使用计算和存储产品,以及基于这些产品和技术为用户解决什么样的实际问题。

 

一、基于存储服务的成本优化与性能提升

 

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]等表的形态进行存储,做进一步大规模的数据分析。从数据的生命周期来看,从流到表,是非常符合数据从高频变低频,从热变冷的自然特征,在对象存储之上构建流表一体的数据技术栈是未来的趋势。

 

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两类共享存储的优势集中到了一起,提供了低延迟、高吞吐、低成本和容量“无限”的的流存储能力。

 

 

1)多重挂载和NVMe协议

 

诚然,ESSD虽说是共享存储,但使用上是块设备的形态,所以要将ESSD高效地共享起来,需要额外的存储技术支撑,即多重挂载和NVMe PR协议。

 

云盘本身支持在卸载后重新挂载到其他节点用于恢复,但当原挂载节点出现ECS Hang等类型的故障时,云盘的卸载耗时比较不可控,所以可以依赖ESSD提供的多重挂载能力,可以做到不进行云盘的卸载,直接多重挂载到另一个ECS节点。

 

以AutoMQ Failover流程为例,当某Broker节点被识别为Failed Broker后,将其上的云盘,多重挂载到健康的Broker进行数据恢复。在进入真正的Recovery 流程前,需要确保原节点没有在持续写入,AutoMQ通过NVMe协议的PR锁对原节点进行IO Fencing。

 

这两个过程均是毫秒级的操作,可以将ESSD在AutoMQ场景下真正地变为共享存储。

 

2)Regional ESSD

 

ESSD背后虽然是多副本架构,但常规的ESSD其多副本是分布在单个AZ内的,这也导致ESSD无法应对AZ级的故障,Regional EBS[5]就是用于解决该问题的。通过将底层的多副本冗余分布在多个AZ内,采用强一致的读写技术,能够容忍单AZ故障。

 

在共享挂载方面,支持Region内ECS跨可用区挂载以及多可用区共享挂载,支持抢占式的IO Fencing和NVMe PR锁形式的IO Fencing。对于Regional ESSD,国外主流云厂商均有对应的产品形态,同时在阿里云上也即将发布,该产品使AutoMQ能够以极低的成本容忍单AZ故障,满足可用性较高的业务场景需求。

 

二、基于计算服务的可用性和弹性能力提升

 

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、弹性伸缩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层差异。

 

3、抢占式实例

 

弹性的能力并不是云厂商与生俱来的,云厂商为了给客户提供充足的弹性供给,需要承担巨大的保有成本,从而不可避免地导致了云厂商有大量的闲置的计算资源。这部分闲置的资源通过抢占式实例进行售卖,其性能与常规ECS实例无任何区别,相比较按量付费的实例成本最高能节省90%。

 

抢占式实例相比较按量付费实例,有一个重要的特征,就是其价格随供需变化而浮动,比如如果晚上业务对算力的需求小,价格自然就更加便宜。所以,在一定程度上抢占式实例的定价包含了时间的维度,如果所有的用户都能将抢占式实例用起来,自然就会被价格所调节,会促使大家为自己的工作负载选择最合适的运行时间段。比如,AutoMQ会在晚上运行一些大规模的测试用例,通过使用抢占式实例,大幅度降低测试的成本。

 

另一个特征,抢占式实例会被随时中断回收,这确实为使用它带来了很高的门槛。但AutoMQ推出的存算分离架构,使得Broker节点无任何本地状态,能够从容应对抢占式实例被回收的情形。下图演示了AutoMQ在抢占式实例回收时通过ESSD API完成WAL恢复的流程。AutoMQ能达到十倍降本的效果,抢占式实例在计算降本的维度起到了重要的作用。

 

 

结束语

 

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

 

周新宇,AutoMQ联合创始人&CTO,是Apache软件基金会成员,Apache RocketMQ联合创始人&PMC成员。有近十年的云计算从业经历,完整经历了阿里云中间件上云历程,是云原生上云理念的倡导者。

 

引用

 

1. 开源的云原生版 Kafka——AutoMQ:https://github.com/AutoMQ/automq

2. Confluent 全新发布 Tableflow,统一流和分析型计算:https://www.confluent.io/blog/introducing-tableflow/

3. 开放表格式 Iceberg 官网:https://iceberg.apache.org/

4. 阿里云自研神龙架构:https://developer.aliyun.com/article/743920

5. 2023云栖大会抢先发布Regional ESSD:https://developer.aliyun.com/article/1390447

6. 为什么公共云的弹性能力很难被发挥出来?https://www.infoq.cn/article/tugbtfhemdiqlxm1x63y

 


我们是阿里巴巴云计算和大数据技术幕后的核心技术输出者。

欢迎关注 “阿里云基础设施”同名微信微博知乎

获取关于我们的更多信息~

相关文章
|
3天前
|
存储 Cloud Native 持续交付
云原生架构:未来软件开发的引擎
【6月更文挑战第13天】随着企业数字化转型的加速,云原生技术已成为推动现代软件交付和运维的关键力量。本文将深入探讨云原生架构的核心概念、优势以及它如何重塑软件开发流程,为企业带来前所未有的敏捷性、可扩展性和成本效率。
16 1
|
4天前
|
监控 Cloud Native 开发者
云原生技术浪潮下的微服务架构实践
云原生技术正引领着现代软件开发的潮流,其中微服务架构作为其核心理念之一,为复杂应用提供了灵活、可扩展的解决方案。本文将探讨在云原生环境下实施微服务架构的策略和挑战,并结合实际案例分析微服务设计的最佳实践,旨在为开发者提供一套可行的微服务部署与管理指南。
|
6天前
|
监控 Cloud Native 安全
云原生架构:现代应用的未来之路
随着数字化转型的推进,云原生架构成为了现代应用开发的关键。本文将探讨云原生架构的基本概念、优势以及实践指南,帮助读者更好地理解并应用云原生技术,为未来的应用开发之路铺平道路。
|
3天前
|
运维 Cloud Native 开发者
云原生技术:构建未来软件架构的基石
【6月更文挑战第13天】随着云计算的不断演进,云原生技术已成为推动现代软件开发、部署和运维的关键力量。本文深入探讨了云原生的核心概念、优势以及它在企业中的应用,旨在揭示如何借助云原生技术实现更高效、灵活和可靠的软件解决方案。
14 2
|
4天前
|
人工智能 监控 Cloud Native
多款可观测产品全面升级丨阿里云云原生 5 月产品月报
多款可观测产品全面升级丨阿里云云原生 5 月产品月报。
|
4天前
|
运维 Cloud Native Devops
云原生架构:未来软件开发的引擎
【6月更文挑战第12天】随着数字化转型的不断深入,企业对软件交付速度和质量的要求日益提高。本文将探讨云原生架构如何成为推动现代软件开发的关键力量,通过其灵活性、可扩展性和自动化特性,帮助企业快速响应市场变化,实现持续创新。
14 0
|
4天前
|
Cloud Native 持续交付 云计算
云端架构的未来:探索云原生技术的无限可能
【6月更文挑战第12天】随着企业数字化转型的加速,云计算已成为推动现代IT发展的核心力量。本文深入探讨了云原生技术如何重新定义软件开发、部署和运维,以及它如何使组织能够更快速、更灵活地响应市场变化。我们将分析云原生的关键组成部分,包括容器化、微服务架构、持续集成/持续部署(CI/CD)和无服务器计算,并探讨这些技术如何共同塑造了一个更加高效、可扩展和成本效益高的IT环境。
|
6天前
|
监控 Cloud Native 持续交付
云原生架构:从理念到实践的全面解析
云原生架构已经成为现代软件开发和部署的核心理念。它不仅改变了传统的软件开发模式,还为企业提供了更高的灵活性、可扩展性和可靠性。本篇文章将深入探讨云原生架构的基本概念、关键组件以及实际应用案例,帮助读者更好地理解和应用这一先进的技术框架。
33 3
|
6天前
|
Cloud Native Java Devops
【Quarkus 技术系列】「云原生架构体系」在云原生时代下的 Java“拯救者”是 Quarkus,那云原生是什么呢?
【Quarkus 技术系列】「云原生架构体系」在云原生时代下的 Java“拯救者”是 Quarkus,那云原生是什么呢?
20 3
|
6天前
|
运维 Cloud Native 持续交付
云原生架构的演进之路
在数字化转型的浪潮中,云原生技术以其灵活性和可扩展性引领了软件开发的新纪元。本文将探讨云原生架构从概念提出到实践应用的发展历程,解析其核心价值,并展望未来趋势。

热门文章

最新文章