写点什么

上云还是下云:章文嵩博士解读真正的云原生 Kafka 十倍降本方案!

  • 2023-12-07
    北京
  • 本文字数:5037 字

    阅读完需:约 17 分钟

大小:2.46M时长:14:19
上云还是下云:章文嵩博士解读真正的云原生 Kafka 十倍降本方案!

作者 | 章文嵩、周新宇

 

近日,AutoMQ 团队发布了基于云的开源云原生 Kafka——AutoMQ for Kafka,所有的代码采用 Apache 2.0 开源许可。AutoMQ 充分挖掘了云原生的技术红利和成本优势,再结合 Serverless 弹性技术,实现了 Apache Kafka 十倍的降本增效。本文从技术架构的角度,来揭秘 AutoMQ 为 Kafka 量身打造的云原生十倍降本方案。

 

今天,我们看到云计算带来了两个趋势,一个是“上云的趋势”,另一个是“下云的趋势”,相信大家都关注到了最近 X(原 Twitter) 全力“下云”,成本降低了 60%。“上云”亦或是“下云”,到底谁在节约成本,谁在增加成本,这其中的差异可能三言两语很难讲清楚,但就 AutoMQ 核心团队在阿里云多年的工作经历来看,头部云厂商一直是以“让算力普惠、释放技术红利”为使命的,那到底为什么“上云”会给企业一种更贵的感受呢?

 

AutoMQ 团队认为这其中最主要的差异在于云原生(Cloud Native)和云托管(Cloud Hosted)的差异。以云托管的姿势上云,最终会发现云上成本比自建机房还高,将传统的软件架构 Rehost 到云上,其本质是将 IDC 架构平移上云,是无法发挥出云基础设施的规模化优势,也享受不到成本红利。只有以云原生的姿势上云,充分利用云的弹性能力,服务化的产品和自动化的 API,才能做出云上最优的成本解决方案。

 

云原生的能力

 

在引出 AutoMQ 为 Kafka 打造的云原生架构之前,我们先来看一下云的基础设施已经进化到什么程度了,有哪些能力和优势是跟成本息息相关的,而且是传统的 IDC 架构无法充分利用起来的。

 

服务化的产品

 

云计算技术迭代的路线可以总结为:云先用软件定义硬件,再把软件变成了服务。所以,我们今天看到网络环境变成了 VPC,存储介质变成了云盘,物理主机变成了虚拟的云主机 ECS。

 

这些云提供的基础产品在今天已经蜕变成了服务,服务一定是具备生产可用的 SLA,比如阿里云单个 ECS 实例的可用性达 99.975%,这意味着一个单节点的微服务也可以是生产可用的,这在 IDC 环境是无法想象的事情。再例如云盘 EBS,相对于物理存储介质,EBS 天然具备 3 副本,提供 5 个 9 ~ 9 个 9 的数据可靠性,同时具备可用区内和区域内的容灾能力。

 

所以,我们今天做云原生架构,第一个共识就是需要意识到,基于云的架构设计已经从依赖软硬件,变为依赖云服务了,真正的云原生架构一定要充分发挥出云产品的服务化能力。

 

弹性

 

弹性可以说是云最大的优势,云积累了大规模的算力,给了单个租户无限计算资源的视图,云原生的架构完全可以假设,在云上一切资源都是无限的,都是唾手可得的。

 

对于 IDC 环境,因为机器资源至少月级的交付时间,传统的软件架构并不会面向弹性能力进行设计,一般都会假设保有一定的机器资源来提供软件服务。这也意味着,当传统的软件 Rehost 到云上后,也是以预留资源的形式使用云资源,一方面存在资源的极大浪费,另一方面也无法享受到云的弹性能力。

 

不难发现,弹性能力的来源并不是资源交付时间变快了,完全是因为云厂商通过预留大量资源实现了租户级无限的弹性的能力,所以说“世上本没有真正的弹性,都是云厂商在负重前行”。正因为这样,云厂商各个地域都有大量的闲置资源,云厂商为了尽可能将闲置的资源转换为营收,推出了 Spot 计算实例,Spot 类型的实例相较于正价的 ECS 实例,至多有 90% 的成本节约。如何充分发挥出 Spot 实例的成本优势,也是云原生架构需要重点考虑的地方。

 

API 定义一切

 

云计算所有的能力都是通过 API 来进行描述的,比如用 API 创建一台 ECS,用 API 重新挂载一块云盘,用 API 去调整云服务的 Quota 和 Limitation。

 

正因为此,云原生的软件有机会利用 API 去编排资源,去实现 Auto Scaling,实现容灾的切换。通过利用云的 API 完成软件核心的能力建设,甚至容灾能力的建设,这也是传统的软件架构无法办到的事情。

 

云服务依赖选型

 

云厂商提供了数百种的全托管云服务,但这些云服务成熟度完全不一样,不少小的云服务研发团队仅仅有个位数的人力投入。所以,我们在进行云原生架构设计时,需要谨慎进行云服务依赖选型,我们总结了两个原则:

  • 选择云厂商投入最大、规模最大的云服务,这类服务成熟度往往是最高的,不能单纯看云厂商承诺的 SLA。

  • 选择标准化的云服务以避免厂商锁定,我们设计的云原生架构必须是所有云的原生架构,而不能单纯是某朵云的原生架构。

 

在这两个原则的约束下的云服务,也是云厂商真正释放云原生能力的出口,它们往往有以下几个特征:

  • 真正的按量计费,以最小的资源粒度按使用量进行计费,比如 Lambda 按调用次数计费,没有任何保有成本。将实例规格包装成按时间进行计费不是真正的按量计费。

  • 无限的容量,给单个租户的视图一定是无限的容量,无限的存储和计算资源,业务再也不需要进行容量评估了。

  • 低成本,真正地通过技术而不是通过亏损,通过规模去优化成本,比如对象存储 S3 是业界最便宜的存储产品之一。

 

选择性地依赖云服务,可以让我们的云原生架构更加灵活,充分享受到云的红利,多云原生的灵活度,更高的稳定性保障。

 

AutoMQ 云原生架构

 

AutoMQ 将消息和流存储最流行的两款开源软件 Kafka 和 RocketMQ 基于云重新设计,将这两款面向 IDC 进行架构的软件带向云原生领域。Kafka 和 RocketMQ 的核心分别是流存储和消息存储,对于存储类型的软件,要完全把云的能力用起来并不是一件容易的事情。

 

AutoMQ 在进行 Kafka 和 RocketMQ 重新设计之初,就定义了几个设计目标:

  • 尽可能发挥出云的弹性能力,将弹性作为核心能力去设计,根据负载变化系统能进行弹性伸缩。

  • 尽可能使用 Spot 实例,Spot 实例有随时被中断的风险,能否实现存储软件的“无状态”是能否利用 Spot 实例的关键。

  • 尽可能将数据全放在对象存储上,S3 极具成本优势,存储系统降本的关键一定在于能否将 S3 的能力发挥到极致。

  • 尽可能利用 EBS 的低延时和高性价比,解决业务对数据写入的低延时需求,通过 EBS 和 S3 组合出高可用能力即可提供低成本、高可用和高可靠的存储服务。

 

结合云已经有的能力,以及我们对流存储和消息存储软件的理解,我们设计了一套真正的云原生架构,同时满足了以上几个设计目标。

 


该架构主要包含三个核心设计思想。

 

一、存算分离至服务

 

存算分离拥有状态卸载、弹性等好处,这已经是行业共识,但如何实现存算分离没有统一的方案,我们今天认为存算分离的核心是将存储分离至服务而不是软件。如果,我们为了存算分离将存算一体架构的存储部分,分离出一套分布式存储软件,这会带来额外的部署、运维以及治理的复杂度。

 

RocketMQ 早期的架构是完全零依赖,正因为架构极简,让它在生产系统的实际可用性非常高,今天存算分离的优势已经被众多开发者所喜爱,但是任何一个软件的可用性是由软件本身和后台运维的工程师组成,如果这个软件还依赖其他软件,那么它就类似一个串联电路,任何一个环节出问题,就会影响最终用户,尤其是依赖一个无人运维的存储系统,更是会让整个系统的复杂度和可用性失控。 而云厂商的对象存储、块存储等大规模使用的系统背后有全世界最优秀的工程师在运维,理论上这样的系统一定是可用性最高的。

 

另外一点就是存储能否做到完全卸载,有些观点认为多级存储也是存算分离,实际上业界大部分多级存储方案都有很重的一级存储,一级存储包含了大量的存储状态。如果无法做到存储的完全分离,也就无法将存算分离的弹性优势发挥到极致。

 

我们对存算分离理念的实践都体现在 S3 Stream 这一基于 S3 的流存储库之上,S3 Stream 组合 EBS 和 S3 的能力,实现了低成本、高可用、高可靠以及无限容量的流存储能力,更多的技术细节详见我们的文档(https://docs.automq.com/)。

 

二、共享存储优于 Shared Nothing 架构

 

Shared Storage 和 Shared Nothing 架构各有优劣,但今天在云上,存储已经变得弹性,容量近乎于“无限”,我们认为共享存储是一个更优的架构。

 

通过将存储单元进行共享,状态可以快速转移,分区迁移、节点扩缩容将变得非常简单。共享存储也是云原生架构能否充分利用 Spot 实例的关键。

 

三、可靠性与可用性实现

 

回到 Kafka 和 RocketMQ 的核心能力上,这两款软件都自带多副本机制,目前分布式架构不管是 Raft 共识算法还是其他变种的副本机制,都是通过副本的冗余,一方面实现数据的高可靠,另一方面多余的副本可以快速提供故障转移的能力,从而实现高可用。

 

但在云上,云存储 EBS 已经自带 3 副本了,如果上层应用继续采用复制的方案,将带来 9 副本的数据冗余,以及多倍的存储和网络成本。所以,在 Kafka 和 RocketMQ 层面没有必要自己实现 3 副本。另外,EBS 是第二大存储系统,仅次于第一大存储系统 S3,云厂商对 EBS 进行深入的软硬一体优化,把 EBS 客户端卸载到神龙 CIPU(智能网卡)通过硬件来做,EBS 客户端跟 EBS 服务器的通讯针对数据中心内低延时低丢包率的特点实现自定义的传输协议而不是用 TCP,这些软硬一体优化带来的效果远远好于自己搭建的 3 副本高可靠系统。还有,在云上使用 EBS 来存储不消耗网络带宽,自建的 3 副本复制会大量消耗网络带宽。

 

鉴于此,AutoMQ 提出了服务的可靠性与可用性实现方案,依赖 EBS 的可靠性,可以采用单个写入计算节点,把数据先写入到存储在 EBS 裸设备的 WAL 中,若当前写入计算节点故障了,其他计算节点接管这个 EBS,从 WAL 中恢复数据。通过基于 EBS 的 Detach/Attach API 以及 NVMe 相关的 API 实现一次只有一个计算节点可以写入 EBS,确保 EBS 数据写入的一致性。

 

架构优势

 

AutoMQ 云原生架构为 Apache Kafka 带来了单副本高可用,秒级分区迁移,持续数据重平衡,分钟级平滑扩缩容等技术架构优势(更多细节参看官方文档)。

 


十倍降本增效解读

 

AutoMQ 团队将云原生架构的技术优势,兑现为成本优势和运维效率,为 Apache Kafka 带来的十倍的降本增效。

 


运维效率提升

 

Kafka 运维有两个痛点,给运维人员带来了极大的运维成本:

  • 分区迁移,Kafka 迁移分区需要进行数据复制,一方面额外的复制流量对生产环境会产生稳定性影响,另一方面复制耗时一般比较长,导致迁移分区的操作需要长时间进行观察,以确保系统达到终态。

  • 扩容,当 Kafka 集群流量不足时,运维人员需要对集群进行扩容,但扩容后的节点无法承担任何流量,需要从其他节点移动分区过来,也就是说扩容需要移动大量的分区,才能达到流量的重平衡。扩容操作需要提前扩容,如果在业务高峰时进行扩容是无法缓解生产压力,反而会进一步将生产集群推向高风险状态。

 

AutoMQ 的云原生架构得益于将存储状态卸载到共享存储上,移动一个 TB 级的分区能将时间从 3 小时缩减为 1.5 秒,扩容后流量重平衡时间从 43 小时缩减为 1 分钟,成功地将 Kafka 高风险的常规运维动作,变成了可自动化,基本无感的低风险运维操作,大幅度降低了运维人员的工作负担。

 

计算和存储降本

 

成本方面,我们提供了一个 80 MB/s ~ 1 GB/s 的弹性工作负载用于压测真实的云账单,在该负载下,AutoMQ 提供的云原生 Kafka 版本每月仅需 5632 元,相比于自建 Apache Kafka 承担该负载需要 62,431 元,AutoMQ 的云原生架构成功降本 11.09 倍。AutoMQ 获取成本优势的核心主要有几点:

  • 充分利用对象存储和 EBS 的低成本特性,将存储成本降低了 90%。

  • 通过无状态的架构设计,内置 Auto Balancing 组件,实现自动扩缩容能力,再充分利用 Spot 实例,能做到计算成本降低 11.09 倍。

 

近期,我们发布了完整的成本分析报告,详情见 AutoMQ 的官方文档。

 

总结

 

AutoMQ 团队通过对 Apache Kafka 进行全新的云原生架构设计,成功做到了 10 倍的降本增效,充分验证了真正的云原生架构是能充分发挥云的规模化优势的,能做到超出预期的、十倍的降本效果,能大幅度降低运维复杂度,真正做到共享云的一切优势。

 

云计算,开辟了一个新的时代,以云原生的姿势上云,是不会有下云的忧虑,我们坚信,所有的基础软件,都值得基于云重新设计,以发挥出云全部的优势。

 

作者简介:

章文嵩,AutoMQ 联合创始人 & 首席战略官,开源项⽬ LVS 创始⼈。

周新宇,AutoMQ 联合创始人 & CTO,Apache RocketMQ 联合创始⼈。

 

活动推荐

 

在“AutoMQ 云原生创新论坛”上,周新宇将深度分享这一创新架构,同时,还邀请到了阿里云和亚马逊云科技的顶尖专家,揭秘云上存储与计算服务的关键技术原理。另外,我们也很荣幸请到 LVS 之父章文嵩博士、贝联珠贯的创始人林昊(毕玄),以及 RocketMQ 的作者王小瑞,将围绕“上云与下云的决策”及其核心挑战展开精彩圆桌对话。扫码图中二维码报名,与行业大咖一起,洞察云原生的未来趋势!

 


2023-12-07 20:298574

评论 10 条评论

发布
用户头像
automq是开源的,有兴趣的可以关注下我们github项目:https://github.com/AutoMQ/automq-for-kafka
2023-12-08 18:05 · 浙江
回复
用户头像
这玩意感觉就是pulsar + pravage结合体呢,整体存算分离 + 灵活扩缩容。10x降本这个感觉有点大了,一般中小公司体量一般不会太大,成本这块基本上都是可控的,选择kafka或者rocketmq更多的还是看重周边生态建设以及相关的运维便利性,上云是大趋势,这个毋庸置疑,每款云产品都有它独自的应用场景,这种无法被替代的场景本文好像并没有提及,如果纯粹为了降低机器成本,而提高了运维成本,感觉有点得不偿失,个人拙见,仅供参考
2023-12-08 16:44 · 浙江
回复
10x 降本的话,官方文档有说如何做到的。小规模下如果部署在云上,充分利用云的spot实例、对象存储、云盘也是可以有显著降本效果的。此外 AutoMQ Kafka 不仅仅是降本,由于依托对象存储作为主存,将broker无状态话,运维时的扩缩容、升降级的成本是大大降低的。以 Apache Kafka 为例,在数据量比较大时候,完成分区复制是个非常重和危险的操作,但是在 AutoMQ Kafka 上可以秒级完成。有兴趣的话可以看看咱们官网文档细节哈~
2023-12-08 18:03 · 浙江
回复
比较同意你的观点。中小公司其实数据量很少,机器本身很少。面对主要问题是运维层面的,运维的话如有有故障或者需要做迁移,做个业务层面的迁移就行。=。=
2023-12-11 12:51 · 北京
回复
用户头像
10x 降本咋做到的,有白皮书详细介绍么
2023-12-08 11:05 · 浙江
回复
白皮书有兴趣的话可以官网https://www.automq.com/zh/home.html右上角加微信交流群获取的。10x降本的话,官方文档有说如何做到的,也可以了解下: https://docs.automq.com/zh/docs/automq-s3kafka/EJBvwM3dNic6uYkZAWwc7nmrnae
2023-12-08 11:08 · 浙江
回复
用户头像
公有云是未来的主流,虽然迈向这个方向的过程中会遇到各种挑战,但是确实不可否认这种时代的浪潮。人类社会总朝着更加高效的方式去发展,公有云规模化的技术红利和成本优势是传统IDC软件完全不具备的。当然不同企业的不同阶段针对是否上云会有不同决策,不能一概而论,期待圆桌大佬们的真知灼见~
2023-12-08 10:38 · 浙江
回复
还很难说,说内经济主体是国企和政务主导,这类公司很难上云,可能也是各种行业或者公司内部云,云厂商做不大体量,技术、产品能力、稳定性投入巨大,成本上很难说有优势。如果云上服务总共超过2k cpu,可能就没有什么成本优势。
2023-12-08 17:39 · 浙江
回复
当前国内经济结构,国企传统政务以及一些传统厂商因为一些数据监管和政策的要求,有一些确实很难上云,不过这不意味着当前公有云上所有服务没有形成规模优势和成本优势。像计算实例、云盘、对象存储这类云上重要基础设施服务现在已经形成体量优势了。另外就是无论从全球趋势还是国家云战略层面都在推进这个进程的,可以看看中国通信院2023的报告:http://www.caict.ac.cn/kxyj/qwfb/bps/202307/P020230725521473129120.pdf
2023-12-13 14:34 · 浙江
回复
用户头像
云原生上云正确姿势,点赞!!!
2023-12-08 10:37 · 浙江
回复
没有更多了
发现更多内容

前端需要的免费在线api接口

德育处主任

JavaScript ajax 前端 Postman API

重磅!中国红十字基金会固生堂中医惠民专项基金成立

E科讯

斗罗大陆真3D手游实力上线,带你感受魂兽猎杀的超燃时刻

华为云开发者联盟

数据库 华为云数据库 rds for mysql 3D手游 PITR

进程ID及进程间的关系

mazhen

Linux Shell Linux Kenel

你怎么总是能写出两三千行的controller类?

CRMEB

CODING x 百果园,水果零售龙头迈出 DevOps 体系建设第一步

CODING DevOps

DevOps CODING 百果园 合作

【软件开发】直播带货App如何开发

青山一叶秋

记录一次win10更新版本后IIS无法启动的解决办法

为自己带盐

28天写作 12月日更

CSS之选择器(六)::before和::after

Augus

CSS 12月日更

依赖 jar 没有传递,导致找不到类文件而启动失败了

程序员小航

Java maven

【HZERO微服务平台6】源码分析之数据权限、sql拦截

qiaoxingxing

签约计划第二季

微服务架构 | 如何利用好日志链路追踪做性能分析?

码农架构

Java 链路追踪 微服务治理 性能调试 微服务调用链

工业企业能耗在线监测系统开发建设

a13823115807

潮玩盲盒系统开发元气部落盲盒app开发

风行无疆

一张图看懂融云直播 SDK

融云 RongCloud

Flutter流畅度优化神器-开源组件keframe详解

贝壳大前端技术团队

flutter 性能 滑动优化

声网把七年无全网事故的实时传输网络SD-RTN全面开放了——这就是FPA!

声网

人工智能 网络 SD-RTN

你想知道的Kotlin version

Changing Lin

12月日更

元宇宙时代的业务、场景、技术机遇探索

融云 RongCloud

基于融云直播 SDK,快速实现连麦布局

融云 RongCloud

Aeron 是如何实现的?—— Ipc 异常情况处理

BUG侦探

Aeron ipc

人工成本上升+设备停机率高,制造企业该如何破而后立?

优秀

低代码 制造业

解决远程办公安全隐患,就用行云管家!

行云管家

远程办公 IT运维

行云管家荣获第二届国际科创节“2021年度高成长性企业奖”!

行云管家

云计算 混合云 IT运维

Flutter for Web 在贝壳容灾降级中的应用

贝壳大前端技术团队

flutter 容灾 降级 flutter for web

融云直播 SDK 2.0 重磅上线,两步接入即可获得视频直播能力

融云 RongCloud

架构设计之MQ选型

无心水

RocketMQ MQ RabbitMQ Kakfa Activemq

iOS内卷面试题-你以为你够卷了,面试官更卷!

iOSer

ios 内卷 iOS面试

【修复升级】腾讯容器安全首个发布开源 Log4j2 漏洞缓解工具

腾讯安全云鼎实验室

可视化神器背后的奥秘

百度开发者中心

大数据 百度开发者沙龙

2021年12月国产数据库排行榜: openGauss节节攀升拿下榜眼,GaussDB与TDSQL你争我夺各进一位

墨天轮

数据库 opengauss TiDB 国产数据库

上云还是下云:章文嵩博士解读真正的云原生 Kafka 十倍降本方案!_实时计算_章文嵩_InfoQ精选文章