PCon全球产品创新大会即将开幕,抢占最后的交流席位! 了解详情
写点什么

Kafka 降本实用指南

  • 2021 年 8 月 02 日
  • 本文字数:4864 字

    阅读完需:约 16 分钟

Kafka降本实用指南

本文最初发布于 leevs.dev 网站,经原作者授权由 InfoQ 中文站翻译并分享。

根据 Gartner 的预测,预计在 2021 年,全球终端用户在公共云服务上的支出将在 2020 年的 2700 亿美元基础上增长 23%,达到 3320 亿美元。


Kafka 的市场增长趋势也是一样的。世界各地的组织都在使用 Kafka 作为主要的流处理平台来大规模收集、处理和分析数据。随着组织的发展和壮大,数据规模也在增长,随之而来的云成本同样日益上升。

 

所以我们能做些什么呢?为了削减成本,我们是否可以实施一些容易实现的策略?

 

本文就此主题列举了一些可能会有所帮助的提示和 KIP(Kafka 改进建议)!

免责声明

这篇文章不会涵盖那些旨在降本的托管服务方法。在某些用例中,像 Confluent Cloud 这样的托管服务可能会起到作用。要获取更多信息,你可以参考 Confluent 网站上的成本效益页面

在开始之前,我们先来了解一些基础知识。

我们的钱都花在了什么地方?

我可以试着列出我们在使用各种云服务时花钱购买的所有组件,但这样还不如来看 Gwen Shapira 在她的文章“Apache Kafka的成本:为DIY运维定价的工程师指南”中总结的内容。

我们从一些相当明显且易于量化的费用开始分析。如果你打算在 AWS 上运行 Kafka,你需要为 EC2 machines 支付费用来运行你的 broker。如果你使用像 EKS 这样的 Kubernetes 服务,你要为节点和服务本身(Kubernetes 主节点)付费。大多数相关的 EC2 类型都是 EBS 存储,Kubernetes 仅支持 EBS 作为一等磁盘选项,这意味着除了 EBS 数据卷之外,你还需要为 EBS 根卷付费。还要记得,在合并 KIP-500 之前 Kafka 不只有 broker——我们还需要运行 Apache ZooKeeper,给它算上三到五个节点及其存储的费用。我们的 Kafka 是在一个负载均衡器(部分充当一个 NAT 层)之后运行的,并且由于每个 broker 都需要单独寻址,因此你需要为“引导”路由和每个 broker 的路由付费

 

所有这些都是固定成本,你一个字节都不向 Kafka 发送也得花这些钱。

 

除此之外还有网络成本。将数据导入 EC2 需要花钱,并且根据你的网络设置(VPC、私有链接或公共互联网),你可能在发送和接收数据时都要付费。如果你在不同地区或区域之间复制数据,请一定要考虑到这些成本。如果你通过 ELB 路由流量,你将为此流量支付额外费用。不要忘了算上入口和出口,并且要记住,使用 Kafka 时,你读取的数据往往是写入量的 3-5 倍。

 

现在我们算上了运行软件、摄取数据、存储和读取数据的成本,我们就快完成了。你还需要监控 Kafka,对吧?一定要考虑到监控(Kafka 有许多重要的指标)——无论是使用服务还是自托管,你还需要一种收集日志并搜索它们的方法。最后这些可能成为系统中最昂贵的部分,特别是如果你有许多分区的时候,这会显著增加指标的数量。


我加粗了帖子中的要点,还有来自 Kafka 生态系统的其他一些组件在文中没有直接提到,如 Schema Registry、Connect workers,以及 CMAK 或 Cruise-Control 等工具,但这些都适用于同样的三个要素——机器、存储和网络

 

虽然有更多要素是难以衡量的,例如员工工资、停机时间,甚至处理中断(也就是将系统维持在可用状态所必须完成的工作),但上面这三点是我们在使用云提供商时花钱购买的主要要素。

我们可以做什么?

除了适用于几乎所有分布式系统的一些基本概念之外,随着时间的推移,Kafka 的提交者引入了一些直接或间接影响 Kafka TCO 的 KIP 和特性。

 

但我们还是会从显而易见的东西开始分析——

你是否使用了正确的实例类型?

AWS 上有很多实例类型可供选择(当然,这里提到的方法也可以用在其他云提供商上)。

 

Kafka 可以在廉价的货架硬件上轻松运行,并且不会出什么显眼的问题。如果你在谷歌上搜索生产级 Kafka 集群的推荐实例类型,你会发现人们建议用 r4、d2 甚至 c5 与 GP2/3 或 IO2 存储搭配用于一般用途。

 

每种组合都有自己的优点和缺点,你可能需要根据各种权衡来找到最适合自己的选项——这些权衡包括更长的恢复时间(HDD 磁盘)、存储性价比、网络吞吐量,甚至 EBS 在极端情况下的性能下降

 

但随着时间的推移,i3 和 i3en 机器得到了人们的青睐;根据我的经验,它们是迄今为止获推荐最多的高回报率大规模部署实例类型,就算你考虑到了使用非永久存储器带来的运维开销也是如此。

 

使用 Kafka 时,i3 和 i3en 在无数基准测试中都提供了更好的性能,并充分利用了非永久驱动器的优势(10gbps 磁盘带宽,对比 EBS 优化的 C 级实例的 875mbps)。

 

ScyllaDB 的这篇很棒的文章,研究了在主要瓶颈因素是存储容量的系统上使用 i3en 机器带来的显著成本优势(稍后会详细介绍):

作为降低成本的第一步,你需要重新评估你的实例类型决策:你的集群是否饱和?在什么情况下饱和?是否存在其他实例类型,可能比你第一次创建集群时选择的类型更合适?EBS 优化实例与 GP2/3 或 IO2 驱动器的混合是否真的比 i3 或 i3en 机器(及其带来的优势)有更好的性价比?


如果你不熟悉这款工具,你应该了解一下。

压缩

压缩在 Kafka 中并不新鲜,大多数用户已经知道了自己可以在 GZIP、Snappy 和 LZ4 之间做出选择。但自从KIP-110被合并进 Kafka,并添加了用于 Zstandard 压缩的压缩器后,它已实现了显著的性能改进,并且是降低网络成本的完美方式。

 

Zstandard是 Facebook 的压缩算法;与其他压缩算法相比,它旨在实现更小、更快的数据压缩。

例如,使用 zstd(Zstandard)后,Shopify获得了 4.28 倍的压缩率。关于 zstd 优势的另一个很好的例子是 Cloudflare 的“挤一挤firehose:从Kafka压缩中获得最大收益”这篇文章。


这和降低成本又有什么关系呢?以生产者端略高的 CPU 使用率为代价,你将获得更高的压缩率并在线上“挤进”更多信息。

 

Amplitude在他们的帖子中介绍,在切换到 Zstandard 后,他们的带宽使用量减少了三分之二,仅在处理管道上就可以节省每月数万美元的数据传输成本。

 

毕竟你还要支付数据传输费用,记得吗?

从最近的副本中获取数据

为了容错需求,在同一 AWS 区域内的几个可用区上分布集群是很常见的做法。

 

遗憾的是,我们无法通过协调让消费者的分布与他们需要消费的分区 leader 完美对齐,以避免跨区域流量和成本。参阅KIP-392

 

2015 年的KIP-36合并之后,机架感知就可以启用了,并且只需在配置文件中添加一行代码就可以轻松完成:

broker.rack=<rack ID as string> # For example, AWS AZ ID
复制代码

在实现KIP-392之前,此设置仅控制副本位置(将 AZ 视为机架)。而这个 KIP 正好解决了这个麻烦,并允许你利用局部性来减少昂贵的跨 dc 流量。

 

一些客户端已经实现了这一更改,如果你的客户端还不支持它,这里有一个开源项目适合你周末来研究!🙂

集群均衡

这一点可能看起来没那么明显,但如果你的集群不平衡,也可能会影响集群成本。

 

不平衡的集群可能会损害集群性能,导致某些 borker 比其他 broker 的负载更大,让响应延迟更高,并且在某些情况下会导致这些 broker 的资源饱和,从而导致不必要的扩容。

 

不平衡集群面临的另一个风险是在一个 broker 出故障后出现更高的 MTTR(例如当该 broker 不必要地持有更多分区时),以及更高的数据丢失风险(想象一个复制因子为 2 的主题,其中一个节点由于启动时要加载的 segment 过多,于是难以启动)。

 

不要让这个相对容易完成的任务去浪费金钱。你可以使用CMAKKafka-Kit等工具,更好的是Cruise-Control,它允许你根据多个目标(容量违规、副本计数违规、流量分布等)自动执行这些任务。

微调你的配置——生产者、broker、消费者

听起来很明显吧?其实在友好的 Kafka 集群幕后,你可以启用或更改大量设置。

 

这些设置会极大地影响集群的工作方式:资源利用率、集群可用性、保证、延迟等等。

 

例如,行为不端的客户端会影响你的 broker 资源利用率(CPU、磁盘等)。更改你的客户端 batch.size 和 linger.ms(与业务逻辑相适应)可以显著降低集群 LoadAvg 和 CPU 使用率。

 

消息转换会带来处理开销,因为 Kafka 客户端和 broker 之间的消息需要转换才能被双方理解,从而导致更高的 CPU 使用率。升级你的生产者和消费者可以解决这一问题,将本来不需要用在这上面的资源释放出来。

 

这样的例子数不胜数。

 

通过适当的微调,你可以让集群更好地运作、提供更多服务、增加吞吐量、释放资源,从而避免不必要的扩容,甚至可以将集群缩小到适合你需求的大小。

 

阅读和处理每一行文档是一项不可能完成的任务,因此你可以先阅读其中一篇关于调整客户端和 broker 的帖子。我会推荐Strimzi的系列相关文章——Broker生产者消费者

未来

压缩级别

如前所述,使用某种压缩算法(最好是 zstd)可以极大地提高性能并节省数据传输费用。

 

处理压缩时,你需要面对一种新的权衡决策——CPU vs IO(压缩后文件的大小)。大多数算法提供了一些压缩级别可供选择,这会影响所需的处理能力和压缩后的数据集大小。

压缩器支持的压缩级别


到目前为止,Kafka 仅支持每种压缩器的默认压缩级别。这个问题将在KIP-390上得到解决,KIP-390 将随 Kafka3.0.0 一起提供。

 

实现这个 KIP 后,我们将能在配置中添加一行,将压缩级别设置得更高(设置到合适的级别。记住更高的级别对应更多的资源开销)

compression.type=gzipcompression.level=4             # NEW: Compression level to be used.
复制代码

这个新特性针对真实世界的一个数据集(29218 个 JSON 文件,平均大小为 55.25kb)进行了测试,结果可能因编码、压缩级别的不同和由此产生的延迟而异,如下所示

分层存储


集群上所需的总存储量与主题和分区的数量、消息速率以及最重要的保留期限成正比。集群上的每个 Kafka broker 通常都有大量磁盘,于是单个集群上一般会有数十 TB 的磁盘存储。Kafka 已经成为组织中所有数据的主要入口点,让客户端不仅可以消费最近的事件,还可以根据主题保留来使用较旧的数据。

 

人们很可能会添加更多 broker 或磁盘,以便根据客户的需求在集群上保存更多数据。

 

另一种常见模式是将你的数据管道拆分为一些更小的集群,并在上游集群上设置更长的保留期限,以便在发生故障时进行数据恢复。使用这种方法时,你能完全“停止”管道,修复管道中的错误,然后流回所有“丢失”的事件,而不会丢失任何数据。

 

这两种情况都需要你为集群增加容量,而且通常还会向集群添加不必要的内存和 CPU,于是与将旧数据存储在外部存储的方案相比,它们的总体存储成本效率较低。具有更多节点的更大集群也增加了部署的复杂性并增加了运营成本。

 

为了解决这个问题,KIP-405分层存储应运而生。

 

使用分层存储时,Kafka 集群配置有两层存储:本地和远程。本地层和现在是一样的,也就是使用本地磁盘——而新的远程层会使用外部存储层(如 AWS S3 或 HDFS)来存储完整的日志 segment,这会比本地磁盘便宜得多。

 

你能为每一层设置多个保留期限,因此对延迟更敏感且使用实时数据的服务可以从本地磁盘提供,而需要旧数据进行回填,或在事故后恢复的服务可以经济地从外部层加载数周甚至数月时间。

 

除了明显的磁盘成本下降(gp3 每 GB 约 0.08 美元,S3 约 0.023 美元)之外,你还可以根据服务需求(主要基于计算能力而非存储)进行更准确的容量规划,独立于内存和 CPU 来扩展存储,并节省不必要的 broker 和磁盘的费用。

节省的成本是非常可观的。

你的 broker 恢复速度会更快,因为它们在启动时需要加载的本地数据要少得多。

 

分层存储已在 Confluent Platform 6.0.0 上可用,并将添加到 Kafka3.0 版本中。

KIP-500:Kafka 不需要 Keeper

可能你还没有听说过,在未来的版本中,Kafka 将移除其对 ZooKeeper 管理集群元数据的依赖,并移至基于 Raft 的治理模式。

 

这不仅将提供一种更具扩展性和健壮性的元数据管理方式,还能简化 Kafka 的部署和配置(去除外部组件),而且还消除了 Zookeeper 部署的成本。

 

如前所述,Kafka 不仅仅是一堆 broker,我们需要为 Zookeeper 运行三五个节点;除了实例之外,你还需要算上它们的存储和网络的成本,以及难以衡量的运营开销(例如监控、警报、升级、事件和关注)。

总结

要降低云成本可以有很多方法。其中一些是可以在几分钟内实现的唾手可得的成果,而另一些则需要更深入的理解、尝试和试错。

 

这篇文章仅涵盖了降低成本的一小部分方法,但更重要的是它试图强调一个事实,即了解在云上运行 Kafka 时我们需要支付哪些费用是很重要的。

 

我们需要意识到,有时云成本可能会超出人们的想象。

 

原文链接:

https://leevs.dev/kafka-cost-reduction/

2021 年 8 月 02 日 15:324281

评论

发布
暂无评论
发现更多内容

【干货篇】bilibili:基于 Flink 的机器学习工作流平台在 b 站的应用

Apache Flink

flink

拍乐云受邀QCon大会 | 详解音视频技术架构实践,首发美术教学音视频方案

拍乐云Pano

《原则》(三)

Changing Lin

23种设计模式,正确的解读方式原来是这样

Java架构师迁哥

华为 HarmonyOS 正式发布!你还认为鸿蒙只是安卓套壳吗?

北游学Java

鸿蒙

defi流动性挖矿系统开发案例分析,defi流动性挖矿现成源码

系统开发咨询1357O98O718

新大陆!阿里P9整理出:Java架构师“成长笔记”共计23版块

Java架构师迁哥

持续测试 | 测试流程提效:在 CODING 中实践迭代内的持续测试

CODING DevOps

DevOps 测试计划 持续测试 迭代式测试

阿里直通车?阿里Java面试“内幕”:十万字内部面试题总结

Java架构追梦

Java 阿里巴巴 架构 面试

defi流动性系统开发案例详情丨defi流动性源码功能

系统开发咨询1357O98O718

分享:在阿里做Java开发的这五年,收获与感悟

Java架构师迁哥

拍乐云推出业内首个「线上美术教学音视频方案」,打造极致互动体验

拍乐云Pano

从零开始学习3D可视化之控制对象(2)

森友小锘

可视化 数据化 3D 3D可视化

龙蜥专场精彩回放来了!10位技术大咖、242位开发者相聚

阿里云基础软件团队

百度搜索与推荐引擎的云原生改造

百度开发者中心

云原生

defi流动性挖矿系统开发(案例版)丨defi流动性挖矿源码现成版

系统开发咨询1357O98O718

iOS上的CSS样式协议 VKCssProtocol

iOSer

CSS ios 移动开发 ios开发 VKCssProtocol

蓝海战略 - 如何设计与众不同的价值曲线

石云升

战略思考 职场经验 6月日更

python使用命令行传入参数

卤蛋翔

6月日更

牛客网亲测有效!牛客下载量近百万的Java程序员复盘秘籍真滴强

小Q

Java 学习 编程 架构 面试

OGA 联盟正式成立!禅道作为理事单位助力共建开源生态!

禅道项目管理

项目管理 DevOps gitlab

联邦计算在百度观星盘的实践

百度Geek说

反洗钱监管再度升级,看这家金融集团如何应对

索信达控股

大数据 银行 金融监管 风险管理 数据管理

☕️【Java 技术之旅】知识盲点关于jar包的点点滴滴

浩宇天尚

Java jar Jar包扫描 6月日更

2021金三银四面试经历:腾讯三面落马+拒网易、CVTE后,字节四面成功拿下offer

Java 程序员 架构 面试

阿里P8熬了一个月肝出这份32W字Java面试手册,在Github标星68K+

Java 程序员 面试

官宣!禅道与极狐(GitLab)达成深度合作,携手推进开源开放DevOps生态发展

禅道项目管理

项目管理 DevOps gitlab

大数据好书推荐

五分钟学大数据

Flink 在有赞的实践和应用

Apache Flink

flink

你想进大厂吗?阿里Java面试“内幕”分享

Java架构师迁哥

系统性思维 系统之美1

张老蔫

28天写作

Kafka降本实用指南_开源_Elad Leev_InfoQ精选文章