Browser Use: 在 EC2 上運行 Firecracker microVMs 以實現高性能雲端瀏覽器

Browser Use 重建了其雲端瀏覽器基礎設施，將每小時瀏覽器成本從 $0.06 降低至 $0.02，並將 VM 冷啟動時間縮短至 400ms 以下。該系統透過為每個瀏覽器工作階段提供專屬的 Firecracker microVM 來提供高隔離性，並將這些 VM 嵌套運行在一般的 Amazon EC2 實例中，以優化成本與擴展速度。

從 Unikernels 轉向 Firecracker

由於擴展限制，Browser Use 捨棄了 Unikraft unikernels。雖然 unikernels 提供了快速的啟動時間與低閒置成本，但它們缺乏強大的內建自動擴展功能，這在流量高峰期間需要人工介入，且先前在一次負載測試中曾導致了 45 分鐘的生產環境停機。

採用 Firecracker 是為了提供一個輕量級的虛擬化層，確保每個瀏覽器與主機及其他工作階段隔離，同時讓控制平面（control plane）能更有效地管理 VM 的建立與監控。

用於自動擴展的自定義控制平面

為了解决 Unikraft unikernels 的擴展問題，Browser Use 開發了一個自定義控制平面。該控制平面即時管理瀏覽器群集，並執行以下功能：

  • Host Selection：將使用者分配至具有可用容量的 EC2 hosts。
  • Dynamic Scaling：當流量上升時自動啟動新機器，並停止向標記為移除的 hosts 發送新工作階段。
  • Real-time Monitoring：透過追蹤目前正在啟動的瀏覽器並識別不應接收新工作階段的 hosts，其運作速度比標準的 AWS CloudWatch 指標更快速。

在 EC2 上優化嵌套虛擬化

雖然 Firecracker 通常運行在裸機（.metal）實例上，但 Browser Use 使用一般的 EC2 實例。這種方法可以實現更快的 host 啟動時間（約 30 秒）並降低成本，儘管這也帶來了嵌套虛擬化（在 VM 內運行 VM）的挑戰。

為了減輕因頁面錯誤（page faults）跨越兩個 hypervisor 層而產生的延遲，團隊實施了幾項記憶體與 CPU 優化措施：

記憶體優化與減少頁面錯誤

最初的冷啟動需要 9.8 秒，其中頁面錯誤佔了 VM exits 的 72%。團隊透過以下方式將其降低至 3.1 秒：

  • 增加頁面大小：從 4KB 頁面切換到 2MB 頁面，將每個頁面的頁面錯誤次數減少了 512 倍。
  • 實施 userfaultfd：使用自定義的 Linux userfaultfd API 處理程序來預載 Chromium 最有可能首先存取的記憶體頁面。
  • 移除舊版檢查：停用對不存在的 PS/2 keyboard 的 500ms 檢查。
  • 優化 Ready-Signals：將 HTTP 輪詢替換為 vsock 通訊通道，讓主機能在不到一毫秒內偵測到瀏覽器何時就緒緒。

CPU 調度與突發管理

Chromium 的啟動過程是 CPU 密集型的，而其運行階段則相對平靜。Browser Use 透過兩階段 CPU 策略來管理此點：

  • Launch Phase：虛擬 CPU (vCPUs) 保持未綁定狀態，允許 Linux 將啟動突發流量分散到所有可用的 host cores。
  • Operational Phase：一旦瀏覽器就緒，vCPUs 會被綁定到穩定的 cores，以防止干擾並允許在每個 host 上進行更密集的瀏覽器打包。
  • Hyperthread Management：為了防止物理核心的爭用，每個瀏覽器都會被分配物理核心的兩個孿生執行緒（sibling threads）。
  • Real-time Priority：vCPUs 被賦予即時優先權，以確保立即執行，這在 1,000 個瀏覽器的壓力測試中消除了工作階段遺失的問題。

透過 Headless Chromium Fork 實現隱身性

為了在不增加 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 個工作階段的壓力測試中，系統實現了 825ms 的 p50 瀏覽器建立延遲，以及 1.35s 的 p99，且可靠性達 100%。VM 冷啟動本身則在 400ms 以下。

下一個瓶頸：Chromium 啟動

目前最大的延遲來源是 VM 恢復後啟動 Chromium 所需的 545ms (p50)。團隊目前正在研究在 Chromium 啟動 之後 對 VM 進行快照（snapshotting），這將允許新工作階段在喚醒時即帶有運行中的瀏覽器，從而可能將 Chromium 的啟動時間完全從關鍵路徑中移除。

Sources