【阅读原文】戳：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
我们是阿里巴巴云计算和大数据技术幕后的核心技术输出者。
获取关于我们的更多信息~
