网络容量计算正确性验证及基础设施最大支持用户数评估

给定条件 #

• 1台运行负载测试的笔记本电脑，互联网速度为10 MB/sec
• 存在一个代理服务：仅负责将流量重定向至AWS S3
• 该服务部署在AWS EKS集群中，且仅运行1个POD
• EKS集群配备10台EC2（m5.8xlarge）实例，单台实例支持10 Gigabit网络（约1 GB/sec带宽）
• 使用Gatling工具开展负载测试

测试场景 #

• 1000个并行用户通过代理服务向AWS S3上传1MB大小的文件

监控数据 #

• EC2监控显示测试期间累计入站网络流量（network in）为400MB
• 容器指标container_network_receive_bytes_total显示瞬时入站流量约为10 MB/sec

问题与估算分析 #

用户的粗略估算逻辑 #

1. 1000个上传1MB文件的用户，对应容器入站流量为10 MB/sec
2. 按比例推算，100000个用户将产生1000 MB/sec（1GB/sec）的容器入站流量
3. 单台m5.8xlarge EC2实例的最大网络带宽为1GB/sec
4. 结论：该基础设施最多可支持100000个上传1MB文件的并行用户

估算的偏差与修正 #

这个粗略估算存在明显局限性，需从以下维度修正：

1. 闲置资源未利用
   EKS集群虽有10台EC2实例，但服务仅运行1个POD，意味着只有1台EC2在承载流量，其余9台完全闲置。实际可用带宽仅为单台EC2的1GB/sec，而非10台实例的总带宽。

2. 双向流量被忽略
   代理服务的模式是接收用户上传的文件（入站流量），再转发至S3（出站流量）。每个1MB文件的上传操作，会产生1MB的入站流量和1MB的出站流量，这两部分都会占用EC2的网络带宽。若按同步转发逻辑，双向流量会同时消耗实例带宽，实际可承载的流量上限会低于单方向的1GB/sec。

3. 测试端瓶颈的误导
   当前测试受限于笔记本电脑的10MB/sec网速，1000个并行用户的流量被强制限制在10MB/sec，这个数据无法真实反映代理服务和EC2的实际承载能力。若要测试真实的最大用户数，必须消除测试端的带宽瓶颈，比如采用分布式负载测试集群。

4. 额外开销未计入
   实际场景中还要考虑TCP协议开销、容器网络转发损耗、S3的响应延迟等因素，这些都会进一步降低基础设施可承载的用户数。

更合理的估算方向 #

假设仅使用单台EC2实例的带宽，且忽略双向流量的叠加（极端理想状态），按用户的流量比例推算，理论上可支持100000个并行用户。但结合实际的双向流量和各类开销，实际可承载的用户数会大幅降低，约为该数值的40%-60%。若要充分利用EKS集群的10台EC2实例，需要将代理服务水平扩展为多个POD，通过Kubernetes调度分散到不同EC2节点上，此时总承载能力才能接近10倍单实例的水平。

内容的提问来源于stack exchange，提问作者Lesha Pipiev