Browser Use: 在 EC2 上运行 Firecracker microVMs 以实现高性能云浏览器

Browser Use 重构了其云浏览器基础设施，实现了每浏览器每小时 0.02 美元的成本（从 0.06 美元降至 0.02 美元），并将 VM 冷启动时间缩短至 400ms 以下。该系统通过为每个浏览器会话分配独立的 Firecracker microVM 来提供高隔离性，并将这些 VM 嵌套运行在常规的 Amazon EC2 实例中，以优化成本和扩展速度。

从 Unikernels 转向 Firecracker

由于扩展性的限制，Browser Use 放弃了 Unikraft unikernels。虽然 unikernels 提供了快速的启动时间和较低的空闲成本，但它们缺乏强大的内置自动扩展功能，这在流量高峰期间需要人工干预，并且此前在一次负载测试中导致了长达 45 分钟的生产环境停机。

采用 Firecracker 是为了提供一个轻量级的虚拟化层，确保每个浏览器与宿主机和其他会话隔离，同时允许控制平面更有效地管理 VM 的创建和监控。

用于自动扩展的自定义控制平面

为了解决 unikernels 遇到的扩展问题，Browser Use 开发了一个自定义控制平面。该控制平面实时管理浏览器集群，执行以下功能：

  • Host Selection（宿主机选择）：将用户分配到具有可用容量的 EC2 宿主机上。
  • Dynamic Scaling（动态扩展）：在流量上升时自动启动新机器，并在标记为待移除的宿主机上停止发送新会话。
  • Real-time Monitoring（实时监控）：通过跟踪当前正在启动的浏览器并识别不应接收新会话的宿主机，其运行速度比标准的 AWS CloudWatch 指标更快。

在 EC2 上优化嵌套虚拟化

虽然 Firecracker 通常运行在裸金属（.metal）实例上，但 Browser Use 使用的是常规 EC2 实例。这种方法可以实现更快的宿主机启动时间（约 30 秒）并降低成本，尽管这引入了嵌套虚拟化（在 VM 内部运行 VM）的挑战。

为了减轻由于页面错误（page faults）跨越两个 hypervisor 层而导致的延迟，团队实施了多项内存和 CPU 优化：

内存优化与减少页面错误

初始冷启动需要 9.8 秒，其中页面错误占 VM exits 的 72%。团队通过以下方式将其降低至 3.1 秒：

  • 增加页面大小：从 4KB 页面切换到 2MB 页面，使每个页面的页面错误次数减少了 512 倍。
  • 实现 userfaultfd：使用自定义的 Linux userfaultfd API 处理程序来预加载 Chromium 最有可能首先访问的内存页。
  • 移除旧版检查：禁用了对不存在的 PS/2 键盘的 500ms 检查。
  • 优化 Ready-Signals（就绪信号）：使用 vsock 通信通道取代 HTTP 轮询，使宿主机能够在不到一毫秒的时间内检测到浏览器何时就绪。

CPU 调度与突发管理

Chromium 的启动是 CPU 密集型的，而其运行阶段相对安静。Browser Use 通过两阶段 CPU 策略来管理这一点：

  • Launch Phase（启动阶段）：虚拟 CPU (vCPUs) 保持未绑定（unpinned），允许 Linux 将启动时的突发流量分布到所有可用的宿主机核心上。
  • Operational Phase（运行阶段）：一旦浏览器就绪绪，vCPUs 会被绑定到稳定的核心上，以防止干扰并允许在每个宿主机上更密集地部署浏览器。
  • Hyperthread Management（超线程管理）：为了防止物理核心上的竞争，每个浏览器都被分配了物理核心的两个兄弟线程。
  • Real-time Priority（实时优先级）：vCPUs 被赋予实时优先级以确保立即执行，这在 1,000 个浏览器的压力测试中消除了会话丢失问题。

通过 Headless Chromium 分支实现隐身性

为了在没有 GPU 或显示服务器开销的情况下避免机器人检测，Browser Use 采用全 headless 模式，并结合了自定义的 Chromium fork。

  • Low-level Patching（底层补丁）：团队没有使用 JavaScript 注入来隐藏自动化标志（如 navigator.webdriver），而是通过在源码级别对 Chromium 进行补丁处理，以防止这些标志被暴露。
  • Lvl-level Fingerprinting（层级指纹识别）：系统利用了分布在 macOS、Windows 和 Linux 上的数万个真实指纹，以模拟真实用户环境。

根据其内部基准测试，这种方法在 81% 的情况下可以避免被拦截，成功率显著高于普通的 headless Chromium (2%)。

性能结果与未来路线图

在 10,000 个会话的压力测试中，系统实现了 p50 浏览器创建延迟为 825ms，p99 为 1.35s，且可靠性为 100%。VM 冷启动本身在 400ms 以下。

下一个瓶颈：Chromium 启动

目前最大的剩余延迟是 VM 在恢复后启动 Chromium 所需的 545ms (p50)。团队目前正在研究在 Chromium 已经 启动 之后 对 VM 进行快照处理。这将允许新会话在启动时就带有一个正在运行的浏览器，从而可能完全从关键路径中移除 Chromium 的启动时间。

Sources