🗒️字节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
字节跳动serverless目前已经超大规模落地,峰值qps达到1.5亿——2023-06-17 结果表达有误
如抖音、今日头条、西瓜视频和番茄小说等,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
你可以通过添加或删除节点来扩展集群。集群扩缩的方式取决于集群的部署方式。
技术实力强的可以扩大集群节点和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带宽
DNS划分集群,单机群后配置负载均衡,单集群网关承接带宽 21Gbps = 21,000Mbps 131wqps
负载均衡
硬件
硬件负载均衡: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会更加快)
单ALB实例性能(以默认2个可用区为例说明)
IP模式 | 最大每秒请求数(QPS) | 最大新建连接数(CPS) | 最大并发连接数 | 最大私网带宽 | 默认公网带宽 |
动态IP | 100万 | 100万 | 1000万 | 100 Gbps | |
固定IP | 10万 | 10万 | 100万 | 10 Gbps | ㅤ |
其他参考资料
边缘计算 serveless 大规模集群管理 数据库管理
字节跳动serverless目前已经超大规模落地,峰值qps达到1.5亿——介绍有问题,实际课程里面数据
字节跳动的云原生技术历程演进 2022-8
上一篇
spring Boot、nestjs、flask web服务框架对比
下一篇
通用软件架构设计参考
Loading...