🗒️字节5000WQPS 从DNS到Kubernetes集群负载均衡分析

type
status
slug
date
summary
tags
category
password
icon
QPS都是东拼西凑的来了,逻辑上都说不过去,基本不可靠
唯一有点价值的就是5000w DNS+ALB(单集群群可直接处理100wQps和5Gbps流量)用户能直接通过阿里云或者火山云买到的
又或者是SDN定义网络,构建200Gbps的入口流量
 
可靠的:serveless 单服务qps140、5000wQPS 200+集群处理
 

资料

截至目前,字节跳动业务流式作业数量已经达到 4 万个,其中 SQL 作业占 30%,随着 Flink SQL 在字节内部的推行,这一占比还将会继续扩大。而在这 4 万个作业中,已有 1.8 万个作业开启了 Checkpoint,高峰流量吞吐达到 600GB/s。在资源层面,全球目前业务平均使用的 Flink 资源已经超过 400 万核。——非在线业务,不具备参考价值
可以想象一下,每当今日头条、抖音等软件在夜晚迎来使用高峰时,字节跳动内部的实时计算引擎也随之进入高速运转。据统计,每晚 Flink 作业处理消息的 QPS 可达到 90 亿。——2023-12-25
如抖音、今日头条、西瓜视频和番茄小说等,QPS 峰值达千万级,解析请求量日达万亿次,日常流量极大,为保障业务稳定运行,应用了火山引擎移动解析 HTTPDNS(以下简称 HTTPDNS)为域名提供递归 DNS 服务,支撑起超大解析请求量。——2024-07-30
2021 年春晚,数据库团队支持了某中台的推送业务,目标用户量(设备)高达 10 亿级。最终我们的峰值吞吐量超过了 600 万 QPS,整体数据量也超过了 20TB。
 
能找到的出处很多,出处是在太多,估计5000w说法算是靠谱的

K8s大规模集群

大规模集群的注意事项
集群是运行 Kubernetes 代理的、 由控制平面管理的一组 节点(物理机或虚拟机)。 Kubernetes v1.31 单个集群支持的最大节点数为 5,000。 更具体地说,Kubernetes 旨在适应满足以下所有标准的配置: 每个节点的 Pod 数量不超过 110 节点数不超过 5,000 Pod 总数不超过 150,000 容器总数不超过 300,000 你可以通过添加或删除节点来扩展集群。集群扩缩的方式取决于集群的部署方式。 云供应商资源配额 为避免遇到云供应商配额问题,在创建具有大规模节点的集群时,请考虑以下事项: 请求增加云资源的配额,例如: 计算实例 CPU 存储卷 使用中的 IP 地址 数据包过滤规则集 负载均衡数量 网络子网 日志流 由于某些云供应商限制了创建新实例的速度,因此通过分批启动新节点来控制集群扩展操作,并在各批之间有一个暂停。 控制面组件 对于大型集群,你需要一个具有足够计算能力和其他资源的控制平面。 通常,你将在每个故障区域运行一个或两个控制平面实例, 先垂直缩放这些实例,然后在到达下降点(垂直)后再水平缩放。 你应该在每个故障区域至少应运行一个实例,以提供容错能力。 Kubernetes 节点不会自动将流量引向相同故障区域中的控制平面端点。 但是,你的云供应商可能有自己的机制来执行此操作。 例如,使用托管的负载均衡器时,你可以配置负载均衡器发送源自故障区域 A 中的 kubelet 和 Pod 的流量, 并将该流量仅定向到也位于区域 A 中的控制平面主机。 如果单个控制平面主机或端点故障区域 A 脱机,则意味着区域 A 中的节点的所有控制平面流量现在都在区域之间发送。 在每个区域中运行多个控制平面主机能降低出现这种结果的可能性。 etcd 存储 为了提高大规模集群的性能,你可以将事件对象存储在单独的专用 etcd 实例中。 在创建集群时,你可以(使用自定义工具): 启动并配置额外的 etcd 实例 配置 API 服务器,将它用于存储事件 有关为大型集群配置和管理 etcd 的详细信息, 请参阅为 Kubernetes 运行 etcd 集群 和使用 kubeadm 创建一个高可用 etcd 集群。
大规模集群的注意事项
集群是运行 Kubernetes 代理的、 由控制平面管理的一组 节点(物理机或虚拟机)。 Kubernetes v1.31 单个集群支持的最大节点数为 5,000。 更具体地说,Kubernetes 旨在适应满足以下所有标准的配置:
  • 每个节点的 Pod 数量不超过 110
  • 节点数不超过 5,000
  • Pod 总数不超过 150,000
  • 容器总数不超过 300,000
你可以通过添加或删除节点来扩展集群。集群扩缩的方式取决于集群的部署方式。
技术实力强的可以扩大集群节点和pod范围,互联网公开的字节就有很多文章

字节Hertz服务框架

Hertz 于 2022 年 6 月正式开源,目前已广泛应用于字节内部逾 1.4 万个服务,支撑日峰值 QPS 超 5000 万,显著降低资源使用和服务延时,接替大量基于 Gin 的存量服务,助力公司降本增效。

流量计算

假设1qps 2kb(get请求通常不建议超过2KB,一般post限制是2M,感觉99.9都不会到这个量)按照读多写少算
qps * (2kb)/ 1000/ 1000
50000000*2/1000/1000= 100GB(GB流量)一般流量是按照1G=1000M来算的(来自于云厂商的文档)
100GB/s相当于800Gbps = 800Gbps
 

带宽速率计算

100GB/s实际上相当于800Gbps 按照火山云自己价格来算
1Gbps = 1000Mbps
BGP(多线) 1000Mbps = ¥1,020,000/年 * 800 = 8亿/年
电信带宽 1Gbps一个月17w
如果是火山云1000(1000MBPS = 1GBP) = 10w一月,包年100w一年
带宽成本参考|电信
 

业务资源

以字节跳动已经建设了完善的云原生基础设施:拥有 200 多个生产集群,共计 50 万节点,容器数超过 1000 万;拥有 10 万多在线微服务,平均每日变更数达 2 万次,离线任务数超过 1.4 亿。——资源分配不完全一样,大事平均一下也差不多,虽然单机群能做大很高像分享的一样,生产实践估计还是偏保守策略——2021 年底
 
举个例子,字节跳动目前有超过 10 万个在线服务,在线集群中有超过一千万的 Pod,这些服务每天都有超过 2 万次的变更。平均来看,字节的业务系统每五天就会更新一遍。为了处理数据报表和机器学习训练,每天有超过 1.5 亿的离线任务数量处理数十 EB 的存储资源。——22年9月
2024年了,历经2年,服务数量拍脑袋决定 * 1.5 15w在线服务 1500wPod——实际上1000w对10亿人,单qps过5个服务来算,每个服务qps就只有(5000wqps 除以 300服务每个服务只有17Qps,常规来说每个服务起码1000qps吧)
如果拆分一下1000pod,三分之一算作业务200w服务,单qps过5个服务,其他算作监控、实时分析、机器学习,每个服务(5000wqps / 60w服务 ≈ 84qps 我姑且按照22年九月1000wpod来算,这靠谱么?)如果按照单服务1000qps,三分之算真在线,一次请求5个服务,真qps要5亿,这个也不太靠谱
 
分享实践——大规模集群在减少集群管理成本、降低资源碎片率等方面具有明显优势。经过持续优化,我们在线上环境实现了单集群 2w 节点,100w Pod 的超大规模突破,有效地提高了集群的资源利用效率。——22年底
 
推测以以15w在线服务 1500wpod 75w节点来计算
最大单机群2w节点,75w/2w ≈ 38个生产集群(实际上应该比较分散,按照最晚22年底生产实践2w节点1集群
承接131wQps 28Gbps流量(算出来38个生产集群,如果是分开部署,并没有采用这么紧凑的做法,火山云上直接就能买到;单ALB 100w+Qps,5Gbps流量) 200多个生产集群,用于在线业务不会只给分38个吧;而且单ABL内网流量可达100Gbps,限制就在入网带宽(要不就是自己搭建集群,要不就是联系SA,业务真的做到这个水平,估计都要自建了)——单集群100wqps、28Gbps是属于合理范围,但是5000wqps对1500w服务(一个链路5个服务)也就是单服务处理≈17个请求?

设计

38个生产集群 单机群2w节点 40wpod(按照在线业务的说话,近些年发展迅速*1.5,一般都讲pod,讲容器应该不太可靠,而且大规模集群日志收集都有优化,以单机为单位)按照之前在线业务说法(算下来是单集群2500节点,5wpod),跟滴滴原地升级爆炸,我估计不会这么激进,如果在这个基础上除以2,或者除以3,qps和流量就少很多,用火山云直接就能搭建出来;我更相信后面的说法
 
CDN前端页面资源、文件生产、图片存储 算作OSS——另算
 
云厂商差不多也是10W QPS需要1Gbps带宽

负载均衡

硬件

硬件负载均衡:F5 生产的售价百万的硬件负载均衡设备,仅凭一颗 4 核 8 线程的至强 x86 CPU,就实现了 40Gbps 的四层负载均衡能力和 18Gbps 的七层负载均衡(应用网关)能力。

软件

软件负载均衡:今天,一台总价 3 万元的通用 x86 服务器搭配 100G 以太网卡,使用基于 DPDK 开发的用户态应用程序在 Linux 上发送小包,轻松就能达到 100Gbps 的网卡带宽。爱奇艺开源的 DPVS 就是 DPDK 技术在负载均衡领域的成功应用。在 10G 网络下进行小包测试,DPVS 的性能是标准 LVS 的五倍。在这里我们保守一点,将其折半为 2.5 倍,那么 DPVS 的单网卡性能极限就是 50G。

云厂商ABL

一般用云厂商的,实践过程中ALB、CLb居多,与DNS配合:在您创建了 ALB 实例后,系统将自动为您的实例分配一个实例域名。您可以在 DNS 处将 ALB 实例域名配置为业务域名的 CNAME ,从而接入ALB。当 ALB 实例多AZ 部署时,实例域名将轮询解析到各个AZ 的实例 IP 上。然后通过ABL负载到POD上(有些可以支持直连POD会更加快)
notion image
 
单ALB实例性能(以默认2个可用区为例说明)
IP模式
最大每秒请求数(QPS)
最大新建连接数(CPS)
最大并发连接数
最大私网带宽
默认公网带宽
动态IP
100万
100万
1000万
100 Gbps
400 Mbps,实际公网带宽以单ALB实例下EIP的带宽总和为准。 • 单个地域下,单个阿里云账号下所有按使用流量计费EIP的实际业务带宽峰值总和不能大于5 Gbps。更多信息,请参见按量付费中的带宽峰值限制。 • 如需更大带宽请购买共享带宽。关于如何购买共享带宽,请参见创建共享带宽实例
固定IP
10万
10万
100万
10 Gbps
 
 

其他参考资料

边缘计算 serveless 大规模集群管理 数据库管理
 
上一篇
spring Boot、nestjs、flask web服务框架对比
下一篇
通用软件架构设计参考
Loading...
文章列表
王小扬博客
产品
Think
Git
软件开发
计算机网络
CI
DB
设计
缓存
Docker
Node
操作系统
Java
大前端
Nestjs
其他
PHP