10万并发沙箱测试：我们从中学到了什么

背景

在 AI 应用开发中，按需启动大量沙箱（Sandbox）已成为一种常见需求，尤其是在处理高并发推理或批量任务时。为了回答“当应用需要同时启动数万个沙箱时，各云服务商的表现如何”这一简单问题，Scale 团队发起了 Scale Invitational 项目。

虽然他们现有的日常基准测试已经能够衡量冷启动时间、阶梯式扩容以及小规模突发行为，但这些测试通常仅涉及几百个沙箱，且来自单一运行器。这种“小规模”测试无法真实反映大规模场景下的系统表现。因此，团队决定进行一次极限压力测试：同时创建 100,000 个沙箱。

然而，在正式运行测试之前，团队在测试架构的设计上遇到了意想不到的复杂性。这篇文章坦诚地分享了他们在测试过程中遇到的挑战、进行的修正，以及为何在发布任何最终数据之前，他们选择刻意放慢脚步，以确保测试结果的真实性和准确性。

核心内容

第一阶段：单一 VM 的局限性（v1 版本）

最初的测试方案（v1）看似直观：利用现有的基准测试工具，将迭代次数提升至 10,000 次，并指向一台高性能虚拟机（VM）。

虽然测试成功运行，但结果毫无价值。原因在于，单台 VM 拥有单一的协议栈、单一的事件循环和单一的出口 IP。在触及服务商底层基础设施的真实瓶颈之前，测试首先触达的是测试机自身的硬件极限。得到的数据更多反映的是测试 rig（测试设备）的性能，而非云服务商的表现。

教训一：在大规模测试中，测试框架本身成为实验的一部分。如果无法排除自身瓶颈，就无法发布有效数据。

第二阶段：负载分散（Sharding）

针对 v1 版本负载过于集中的问题，团队收到了反馈：真实的高并发工作负载是分布式的。因此，团队对架构进行了重构，引入了**分片（Sharding）**机制。

不再由一台 VM 执行 10,000 次任务，而是将一个逻辑上的突发任务拆分为多个部分，由多台 VM 共同承担。每台 VM 上的协调器携带分片元数据，使得独立启动的机器知道它们属于同一个更大的运行任务，并在事后将结果拼接起来。

这种架构消除了单台机器的上限，并使测试更贴近实际测量目标。

第三阶段：寻找最佳平衡点

引入分片后，新的问题随之而来：每台 VM 应该承担多少工作量？

• 负载过重：回到 v1 的问题，每台 VM 成为瓶颈，再次测量的是测试设备而非服务商。
• 负载过轻：需要配置、启动和协调海量的 VM 集群，造成资源浪费并引入编排噪音。

经过多次迭代，团队确定了每个分片/VM 约 100 次迭代 的最佳平衡点。这使得每台机器 comfortably 低于其资源限制，同时保持了集群规模的 manageable。10 万个沙箱被转化为约 1,000 个运行良好的分片，而非一台“着火”的机器。

第四阶段：核心认知的转变——从“吞吐量”到“真并发”

这是重塑整个项目的关键认知。

早期的突发测试虽然声称是“同时”创建 N 个沙箱，但实际上存在细微缺陷：如果一个沙箱创建后立即被销毁，它并不与其他沙箱并发。快速创建并销毁 #1，再创建并销毁 #2，这测量的是突发吞吐量（即创建速度），而非服务商能否同时维持 100,000 个活跃沙箱。

• 隐含并发（Implied Concurrency）：测量创建速度。
• 真并发（True Concurrency）：测量持续容量、内存压力和回收能力。

这两者对服务商基础设施的压力点完全不同。团队意识到之前报告的是“隐含并发”，而他们需要的是“真并发”。

第五阶段：实现真并发与结果模型重构

为了测量真并发，测试逻辑发生根本性变化：沙箱必须保持存活，直到整个运行达到峰值，然后统一销毁。每个分片必须保持沙箱开放并协调，以确保在某一时刻，所有 100,000 个沙箱同时处于活跃状态。

这改变了“结果”的定义，引入了更丰富的生命周期模型：

1. Success（成功）：创建成功，变为可交互状态，并在测试结束时的协调销毁阶段仍然存活。
2. Partial（部分成功）：创建成功并变为可交互，但在创建和协调销毁之间死亡。这是只有真并发测试才能检测到的类别，揭示了哪些服务商擅长创建但难以维持。
3. Readiness Failed（就绪失败）：创建成功，但从未变为可用状态。
4. Failed（失败）：创建调用本身报错。

为了确保证据链完整，团队还记录了每个分片随时间变化的存活状态，以重构真实的并发曲线，而不是盲目相信“已创建”即“仍在运行”。

第六阶段：全链路日志聚合

调试单台 VM 很容易（SSH 登录并查看日志），但调试分布在集群中的 1,000 个分片则完全不同。当第 734 号分片出现问题时，无法通过 SSH 逐一排查。

团队在协调器中内置了日志聚合功能。每个分片捕获其协调器输出，并将其持久化发送到对象存储（Tigris），与结果数据一起存储。这确保了即使 VM 宕机或编排层出现故障，日志依然幸存。没有分片级别的日志，只能看到成功率低，却无法得知原因；有了日志，才能进行全集群的事后复盘。

第七阶段：数据管道设计

10 万个沙箱，每个都有完整的生命周期记录，乘以多次运行和多个服务商，产生了海量数据，且这些数据大致同时从 1,000 个分片涌入。

团队采用了双存储架构：

• Tigris：用于冷存储原始数据。
• Clickhouse：用于数据分析。

设计原则是：永不丢失原始数据，永不将完整结果集保留在内存中，并确保任何环节（VM、协调器、编排层）的故障最多只导致几秒的数据丢失，而非整个运行失败。如果结构化存储需要重塑，可以从 Tigris 中的原始记录重建。

关键要点

• 测试框架本身也是变量：在大规模测试中，测试机的硬件和网络限制可能先于云服务商的瓶颈被触发，必须通过分片（Sharding）消除单点瓶颈。
• 吞吐量不等于并发：快速创建并销毁沙箱测量的是吞吐量，而非服务商维持大量活跃实例的能力。真并发测试要求沙箱在峰值时刻同时存活。
• “部分成功”是关键指标：只有真并发测试能捕捉到“创建成功但中途死亡”的沙箱，这直接反映了服务商在内存管理和资源回收上的短板。
• 分布式日志至关重要：在千级分片规模下，必须将日志持久化到外部对象存储（如 Tigris），以应对 VM 宕机和编排层故障，确保可追溯性。
• 数据架构需具备容错性：采用原始数据冷存（Tigris）与分析存储（Clickhouse）分离的架构，确保数据不丢失且可重建，以应对大规模数据洪峰。
• 迭代式优化：从 v1 的单点瓶颈到分片架构，再到真并发逻辑，每一步修正都揭示了新的问题。团队推迟发布结果（至 6 月 17 日），是为了确保测试的诚实性和准确性。

意义与影响

这次测试不仅是一次技术基准测试，更是对云服务商底层架构能力的一次深度体检。它揭示了在 AI 应用爆发式增长背景下，简单的“冷启动速度”已不足以衡量服务商的可靠性。

对于开发者而言，理解“真并发”与“吞吐量”的区别至关重要。许多服务商可能在基准测试中表现出色（快速创建），但在实际高并发场景下，可能因内存压力或调度瓶颈导致沙箱中途崩溃（Partial Success）。

Scale 团队推迟发布结果的决定，体现了对数据严谨性的坚持。在 10 万级并发规模下，任何测试设计的瑕疵都可能导致误导性结论。通过引入分片、真