Menjalankan browser dalam Firecracker VM di EC2 dalam waktu kurang dari 1 detik

 (browser-use.com)
2 poin oleh GN⁺ 3 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Browser Use Cloud menggunakan Firecracker VM terpisah untuk setiap sesi browser, sambil menurunkan waktu mulai sesi baru menjadi kurang dari 1 detik dan memangkas biaya dari $0.06 per jam browser menjadi $0.02
  • Arsitektur Unikraft sebelumnya menguntungkan untuk biaya saat idle, tetapi saat lonjakan trafik kapasitas harus disesuaikan secara manual, sehingga produksi sempat down selama 45 menit saat uji beban
  • Arsitektur baru memakai control plane buatan sendiri untuk memantau armada browser secara real-time dan memutuskan penempatan host EC2, scaling, serta draining dengan lebih rinci dibanding CloudWatch
  • Alih-alih memakai .metal, mereka memilih virtualisasi bertingkat dengan menjalankan Firecracker di atas EC2 biasa, lalu mengurangi bottleneck lewat halaman memori 2MB, userfaultfd, vCPU pinning, real-time priority, dan patch headless Chromium
  • Cold start VM kurang dari 400ms, dan dalam stress test 10.000 sesi, latensi pembuatan browser dari API publik tercatat p50 825ms dan p99 1,35 detik, dengan semua browser berhasil dimulai

Browser cloud yang cepat, terisolasi, dan murah

  • Tujuan Browser Use Cloud adalah memulai browser dengan cepat sambil mengisolasi state antar sesi dan menekan biaya
  • Satu sesi dapat mencakup Chromium, filesystem, cookie, cache, pengaturan proxy, unduhan, dan kadang bahkan sesi pelanggan yang sudah login
  • Jika satu browser bisa membaca state browser lain, itu menjadi masalah keamanan, jadi setiap sesi harus diisolasi dari host dan dari sesi lainnya
  • Solusi umum adalah VM dengan CPU, memori, disk, dan perangkat jaringan sendiri, tetapi itu terlalu berat dan mahal untuk lingkungan browser cloud yang terus dibuat lalu dibuang setelah sesi berakhir
  • Arsitektur baru menjalankan semua sesi Browser Use Cloud di dalam satu Firecracker VM kecil per sesi, dan VM ini berjalan di atas Amazon EC2

Alasan meninggalkan Unikraft

  • Arsitektur sebelumnya menjalankan browser cloud dengan Unikraft
  • Unikraft memuat unikernel, yaitu image kecil yang dibuat untuk tujuan tertentu tanpa harus mem-boot Linux penuh
  • Unikernel bisa start dengan cepat dan dapat dimatikan saat tidak ada pengguna, sehingga biaya idle rendah
  • Bottleneck-nya adalah menaikkan kapasitas browser dengan cepat saat trafik melonjak
    • Unikraft tidak memiliki autoscaling bawaan yang memadai
    • Engineer harus mengubah variabel dan menambah instance secara manual
    • Salah satu uji beban membuat produksi down selama 45 menit
  • Setelah dibangun ulang, mereka beralih ke Firecracker
    • Firecracker menyediakan lapisan untuk membuat, memantau, dan menjalankan VM
    • Setiap VM diberi CPU, memori, disk, dan perangkat jaringan, serta diisolasi dari host dan VM lain

Mengotomatiskan scaling browser dengan control plane sendiri

  • Firecracker bisa memberi satu VM untuk tiap browser, tetapi tidak otomatis menentukan jumlah VM, penempatan, atau kapan harus scale
  • Browser Use membuat control plane sendiri untuk memantau armada browser dan memutuskan scale up/down
  • Saat pengguna meminta browser, control plane memilih mesin yang masih punya kapasitas kosong
  • Saat trafik naik, lebih banyak mesin dinyalakan; saat turun, browser baru tidak lagi dikirim ke mesin yang akan dihapus
  • Control plane memeriksa armada secara real-time
    • CloudWatch, layanan monitoring AWS, biasanya bereaksi dalam jendela 1 menit
    • Control plane juga mengetahui informasi yang tidak ada di metrik biasa, seperti browser yang masih starting, mesin yang sedang dihapus, atau mesin yang tidak boleh menerima sesi baru
  • Permintaan pengguna diteruskan melalui edge router stateless ke control plane, lalu control plane memilih host EC2 yang masih longgar

Mengapa menjalankan Firecracker di atas EC2 biasa

  • Cara umum menjalankan Firecracker di AWS adalah menggunakan instance .metal
    • .metal berarti menyewa seluruh server fisik agar Firecracker bisa berjalan langsung di atasnya
  • Browser Use memilih EC2 biasa
    • Mesin EC2 biasa bisa diperoleh lebih cepat
    • Biaya pemeliharaannya lebih rendah
    • Host boot dari image yang sudah disiapkan dan mulai bisa menyediakan browser sekitar 30 detik setelah start
  • Jika host bisa ditambahkan lebih cepat, kapasitas idle berbayar bisa dikurangi, dan biaya yang diteruskan ke pelanggan juga turun
  • Konsekuensinya adalah struktur VM di dalam VM
    • EC2 biasa sendiri sudah berjalan di dalam lapisan isolasi AWS
    • Di dalamnya mereka kembali menjalankan browser VM
    • Saat browser VM meminta bantuan host, permintaan itu harus melewati dua lapisan VM sehingga menambah latensi
  • Browser Use memilih kompromi ini demi scale-up yang lebih cepat dan biaya yang lebih rendah, lalu fokus mempercepat jalur eksekusi Firecracker

Alur dari permintaan hingga browser siap dipakai

  • Saat pengguna meminta browser, control plane memilih mesin yang masih punya kapasitas
  • Mesin tersebut memulihkan browser VM yang telah disimpan, lalu menjalankan Chromium di dalamnya
  • Setelah Chromium berada dalam kondisi bisa dikendalikan, sistem mengembalikan URL koneksi
  • Agen pengguna terhubung ke URL ini
  • Browser Use mengendalikan Chromium melalui Chrome DevTools Protocol(CDP) lewat WebSocket
    • CDP adalah API kendali jarak jauh Chrome untuk klik tombol, mengetik teks, membaca halaman, mengambil screenshot, dan sebagainya
  • Ada tiga bottleneck utama yang menambah latensi
    • pemulihan memori VM
    • startup Chromium
    • menjaga stealth agar tidak terdeteksi sistem anti-bot

Bottleneck pertama: pemulihan memori

  • Browser produksi tidak boot dari awal, tetapi dilanjutkan dari snapshot
  • Snapshot adalah VM yang sudah boot dan dihentikan tepat sebelum Chromium mulai dijalankan
  • Melanjutkan VM lebih cepat daripada boot baru, tetapi pada cold start awal, page fault menyumbang 72% dari seluruh VM exit
  • Waktu dari resume VM sampai browser siap CDP awalnya mencapai 9,8 detik
  • Penyebab lambatnya adalah saat VM hasil restore pertama kali menyentuh memori, host harus memetakan ulang memori tersebut
    • Peristiwa ini disebut page fault
    • Dalam VM bertingkat, page fault mahal karena bisa melewati dua lapisan VM
  • Solusinya adalah memetakan memori dalam unit yang lebih besar
    • Sebelumnya restore dilakukan dengan halaman 4KB
    • Sekarang mereka memakai halaman 2MB
    • Setiap halaman mencakup memori 512 kali lebih banyak, sehingga page fault berkurang drastis saat browser bangun
  • Mereka juga menambahkan custom handler untuk userfaultfd, API Linux untuk menangani halaman memori yang hilang
    • Sebelum VM dijalankan, mereka memuat memori yang kemungkinan besar akan diakses Chromium lebih dulu
    • Ini mencegah lonjakan page fault saat Chromium mulai berjalan
  • Perubahan ini menurunkan waktu dari resume VM hingga browser siap menerima perintah dari 9,8 detik menjadi 3,1 detik
  • Jumlah kali browser VM berhenti dan meminta host menangani memori yang hilang turun dari sekitar 100.000 kali menjadi sekitar 1.100 kali per resume, atau sekitar 91 kali lebih sedikit
  • Optimalisasi kecil juga ikut menumpuk
    • Mereka menonaktifkan pemeriksaan 500ms yang sebelumnya dipakai untuk mencari keyboard PS/2 lama yang sebenarnya tidak ada
    • Pemeriksaan kesiapan diubah dari HTTP polling menjadi pembacaan log vsock
    • Saat driver browser menulis pesan ready ke log, host membacanya lewat vsock dan bisa mendeteksi status ready dalam waktu kurang dari 1ms

Bottleneck kedua: startup Chromium dan penempatan CPU

  • Saat Chromium start, penggunaan CPU tinggi karena renderer, compositor, dan V8 isolate dibuat sekaligus
  • Setelah start, otomatisasi browser relatif lebih tenang
    • Agen akan klik, menunggu, membaca, lalu klik lagi
    • Browser sebagian besar menunggu halaman, respons jaringan, atau aksi agen berikutnya
  • Karakteristik ini memungkinkan banyak browser dipacking dalam satu host
  • Burst CPU saat startup ditangani dalam dua tahap
    • Saat browser di-resume dan Chromium mulai jalan, vCPU dibiarkan unpinned
    • Linux bisa menyebarkan pekerjaan CPU browser ke seluruh host tanpa mengikatnya ke core tertentu
    • Setelah browser melaporkan status ready, vCPU dipin ke core yang stabil
  • Jika pinning dilakukan sejak awal, banyak browser yang start bersamaan akan menumpuk di hot core yang sama dan sebagian launch gagal
  • Penanganan hyperthread juga disesuaikan
    • Satu core CPU fisik sering terlihat sebagai dua CPU logis yang disebut sibling thread
    • Jika dua browser VM masing-masing mendapat satu sibling, keduanya berebut core fisik yang sama
    • Dalam lingkungan bertingkat, persaingan ini muncul sebagai kegagalan launch
    • Sekarang setiap browser mendapat kedua sibling thread dari core fisik yang digunakannya
  • Setiap thread vCPU yang sudah dipin diberi real-time priority
    • Dengan begitu Linux langsung menjalankan VM tanpa menundanya di belakang pekerjaan yang kurang penting
    • Sebelum perubahan ini, dalam uji 1.000 browser, 17% sesi hilang tepat setelah dibuat
    • Setelah perubahan, kehilangan dalam uji yang sama menjadi 0

Browser stealth tanpa layar

  • Browser headless berjalan tanpa jendela yang terlihat, sedangkan browser headful berjalan seperti browser di laptop dengan jendela, grafik, dan frame rendering
  • Chromium headless biasa mudah terdeteksi oleh situs yang memakai perlindungan anti-bot
  • Menurut stealth benchmark dari Browser Use, Chromium headless biasa hanya berhasil menghindari pemblokiran sebesar 2%
  • Jika Chromium yang sama dijalankan dalam mode headful dengan jendela terlihat, hanya lewat rendering saja tingkat lolos blokir naik menjadi 50%
  • Karena itu banyak penyedia menjalankan browser headful dan tetap membayar biaya display server, GPU, serta compositor meskipun tidak ada manusia yang melihat layarnya
  • Browser Use justru mengubah browser itu sendiri agar tetap bisa berjalan sepenuhnya headless
  • Komponen pertama adalah fork Chromium
    • Banyak alat stealth menyuntikkan JavaScript ke semua halaman setelah browser start untuk menyembunyikan otomatisasi
    • Misalnya dengan menimpa nilai navigator.webdriver agar situs melihat false alih-alih true
    • Situs bisa mendeteksi bahwa nilai seperti itu telah ditimpa
    • Browser Use menambal lapisan rendah Chromium agar nilai-nilai itu tidak terekspos sejak awal
  • Komponen kedua adalah fingerprinting
    • Fingerprint browser adalah kombinasi informasi browser dan mesin yang dibaca situs web
    • Ini mencakup ratusan detail seperti sistem operasi, ukuran layar, font, output grafis, audio, zona waktu, bahasa, dan lain-lain
    • Browser Use memakai puluhan ribu fingerprint nyata dari macOS, Windows, dan Linux
  • Browser ini mencatat tingkat lolos blokir 81% pada stealth benchmark dan 84,8% pada Halluminate BrowserBench
  • Karena tanpa layar, biaya menjalankan browser lebih rendah dan scaling juga lebih mudah

Terhubung ke browser yang benar

  • Setelah browser siap, pengguna terhubung lewat CDP
  • URL publiknya adalah WebSocket URL
  • Di depan armada browser ada edge router sederhana
  • Router menerima koneksi WebSocket, bertanya ke control plane tentang lokasi browser terkait, lalu meneruskan byte CDP mentah ke VM yang benar
  • Router tidak menentukan di mana browser akan dijalankan
  • Jika satu router mati, router lain bisa menangani koneksi baru
  • Penempatan ditangani oleh control plane, sedangkan router hanya meneruskan byte

Hasil dan langkah berikutnya

  • Saat ini setiap sesi browser dijalankan dengan melanjutkan snapshot VM kecil di dalam EC2 biasa, lalu menjalankan Chromium headless di dalamnya
  • Cold start VM kurang dari 400ms
  • Latensi pembuatan browser dari API publik adalah p50 825ms dan p99 1,35 detik
  • Angka ini diukur dalam stress test 10.000 sesi di mana semua browser berhasil start
  • Leaderboard independen dari BrowserArena menempatkan Browser Use di peringkat 1 dengan $0.02/jam dan reliabilitas 100%
  • Biaya terbesar yang masih tersisa dalam infrastruktur ini adalah Chromium itu sendiri
    • Setelah resume, startup Chromium masih memakan sekitar 545ms pada p50
  • Saat ini snapshot dibuat tepat sebelum Chromium mulai dijalankan
    • Semua browser bangun dari titik yang sama dan bersih, lalu masing-masing memulai Chromium sendiri
  • Langkah berikutnya adalah membuat snapshot setelah Chromium sudah berjalan
    • Dengan begitu sesi baru bisa bangun bersama browser yang sudah hidup tanpa harus menyalakan browser dari awal
  • Pekerjaan ini rumit
    • Browser yang sedang berjalan memiliki device terbuka, timer, state grafis, state jaringan, dan state fingerprint
    • Semua state itu harus dibuat aman sebelum freeze
    • Setelah restore, tiap browser harus terlihat seperti browsernya sendiri, bukan salinan browser sebelumnya
  • Browser Use Cloud kini tersedia di cloud.browser-use.com

Bacaan terkait

1 komentar

 
GN⁺ 3 jam lalu
Komentar Hacker News

  • Menjadikan melewati anti-bot sebagai tolok ukur terasa cukup tidak etis. Tujuan anti-bot adalah memblokir bot yang tidak diinginkan, dan layanan seperti ini pada akhirnya membuat web semakin tidak ramah bagi manusia dan makin mahal
    Situs akan terus berusaha memblokir akses otomatis, dan hambatan untuk mengakses konten akan makin bertambah. Meningkatnya tuntutan verifikasi identitas di web tampaknya bukan hanya soal batasan usia atau “melindungi anak-anak”, tetapi juga efek turunan dari pertahanan terhadap bot dan perlindungan pendapatan iklan

    • Saya memakai alat seperti ini untuk mendeteksi perubahan situs web. Beberapa penulis favorit saya tidak punya RSS, dan untuk barang mahal seperti peralatan rumah tangga besar, saya selalu menyiapkan pemantauan harga untuk melihat perubahan harga
      Di situs yang tidak punya API, saya juga memakai scraper, dan saya mengindeks seluruh riwayat pembelian ke basis data agar bisa dianalisis. Saya tidak ingin menghabiskan lebih banyak waktu untuk melewati deteksi bot yang bodoh, dan jika datanya memang tidak bisa diakses dengan cara lain, saya bersedia membayar. Pada akhirnya ini cuma membakar sumber daya dalam permainan kucing-dan-tikus yang pada akhirnya akan dimenangkan scraper
    • Apakah scraping situs web publik itu tidak etis masih bisa diperdebatkan. Dalam beberapa kasus, pengadilan bahkan pernah menganggapnya legal meski situs memasang hambatan teknis atau mengirim surat penghentian
      Namun, menyediakan proxy residensial kemungkinan besar tidak etis. Banyak penyedia koneksi rumah dalam proxy semacam itu sering kali tidak tahu bahwa mereka telah dimasukkan ke layanan seperti itu
    • Sulit mengatakan sesuatu itu tidak etis hanya karena melakukan hal yang tidak diinginkan orang lain. Alasan dan niatnya lebih penting
      Jika saya tidak bisa duduk 24 jam di depan komputer demi mendapatkan tiket pertunjukan tertentu, sulit rasanya menyebut penggunaan bot pribadi untuk membeli tiket band favorit sebagai tidak etis. Sebaliknya, kalau tujuannya untuk calo, saya setuju itu tidak etis. Anti-bot untuk anti-bot pada dasarnya memungkinkan hal-hal yang menurut orang lain tidak boleh diotomatisasi, dan saya rasa cukup banyak pembaca Hacker News pernah melakukan hal seperti ini setidaknya sekali. Kalau murni demi keuntungan memang kurang bagus, tetapi jika dipakai untuk mendapat kesempatan melawan calo, itu terasa masuk akal
    • Saya tahu ada perusahaan yang mengotomatisasi perangkat lunak yang hanya bisa diakses lewat web, dengan dukungan API yang buruk atau tidak ada sama sekali. Biasanya itu perangkat lunak yang mereka pakai dengan biaya cukup besar, tetapi ada CAPTCHA bawaan untuk melindungi login
      Karena mereka hanya salah satu dari banyak tenant SaaS dan bukan pelanggan cukup besar untuk menuntut CAPTCHA dihapus, mereka akhirnya hanya melewati batasan itu
    • Dipakai oleh orang-orang yang ingin browser headless mereka tidak diblokir

  • Bagian yang terlewat di sini adalah bahwa virtualisasi bersarang pada instans EC2 biasa sudah dimungkinkan sejak Februari tahun ini. Sebelumnya, untuk menjalankan Firecracker VM, Anda harus memakai instans EC2 metal

    1. https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-ec...
    • Ini fitur yang cukup baru, dan secara resmi masih belum direkomendasikan, tetapi sejauh ini bekerja sangat baik. Akhirnya tidak perlu lagi menjalankan bare metal
    • Instans metal sangat lambat saat start dan stop

  • Agak mengejutkan mereka masih tetap bertahan dengan Chromium sampai sejauh ini
    Server MCP web-access kami[0] menjalankan instans browser sebagai subprocess dengan konfigurasi yang jauh lebih sederhana, dan peningkatan terbesar dalam stabilitas, CPU, dan penggunaan memori datang saat kami beralih dari Chrome ke Lightpanda[1]. Seperti dikatakan di akhir tulisan, browser yang lebih cepat mulai bisa jadi sejak awal hanyalah browser yang mengalokasikan memori lebih sedikit
    [0]: https://github.com/EratoLab/web-access-mcp
    [1]: https://lightpanda.io

    • Kami memutuskan tetap memakai Chromium sebagai mesin demi tujuan stealth
      Browser seperti LightPanda sama sekali tidak punya stealth dan sangat mudah dideteksi. Jika hal-hal yang tidak perlu dibuang, ada cara untuk membuat Chromium lebih cepat juga. Tanpa harus membangun ulang seluruh mesin dari nol, saya rasa Chromium bisa mencapai performa itu tanpa kehilangan stealth, yang merupakan prioritas utama. Bahasanya bukan masalah; C++ juga secepat Zig, tetapi saya setuju kebesaran Chromium memang nyata

  • Saya menjalankan API screenshot bernama ApiFlash, dan alih-alih memakai Firecracker di EC2, saya mengemas Chromium dalam image kontainer AWS Lambda
    AWS Lambda memberi isolasi dan auto-scaling secara gratis, jadi sangat ideal untuk pekerjaan stateless yang bebannya bisa melonjak seperti screenshot. Menurut saya, ini memberi hampir semua keuntungan yang sama dengan solusi browser-use, tetapi dengan arsitektur yang jauh lebih sederhana. Trade-off-nya adalah cold start AWS Lambda, tetapi dalam praktiknya fungsi yang panas dipakai ulang pada pemanggilan beruntun. Jika volume panggilannya cukup, puncak beban jadi lebih landai dan cold start juga tidak terlalu sering terjadi

    • Fitur yang kami buat tidak dibutuhkan untuk semua use case
      Masalah yang kami alami di Lambda adalah batas waktu eksekusi 15 menit, harga, tidak adanya mekanisme snapshot, dan kurangnya kontrol tingkat rendah atas host eksekusi. Kami mendukung hingga 4 jam dan bisa berjalan lebih lama jika perlu. Meski begitu, untuk sebagian besar use case otomasi web yang umum, Lambda sudah lebih dari cukup
    • Solusi itu kelihatannya cukup mahal

  • Mereka bilang “Berikutnya: lewati startup Chromium”, tetapi saya jadi bertanya kenapa tidak mempertahankan sekumpulan browser yang sudah berjalan sebagai warm pool lalu menugaskannya ke permintaan yang masuk
    Dari sudut pandang pengguna, latensinya akan hampir nol. Tentu perlu logika prediksi untuk menambah atau mengurangi warm pool sesuai pola trafik, tetapi ini tampak seperti solusi termudah

    • Warm pool memang bekerja, tetapi tujuannya justru menggantikan itu
      Warm pool itu bagus, tetapi tetap mengonsumsi sumber daya, dan Anda harus terus menyalakan browser untuk menjaga pool tetap hangat dan seimbang. Dengan perubahan berikutnya, kami berencana tetap mempertahankan startup Chromium sambil membuat VM siap dalam 50ms, sehingga sepenuhnya mengungguli warm pool. Beberapa pelanggan memerlukan parameter dan fitur khusus sehingga kompleksitas warm pool meningkat. Jalur umum mungkin cepat, tetapi jalur pengecualian bisa sangat lambat; kami ingin menjamin kecepatan cepat apa pun fitur yang dibutuhkan browser yang diminta

  • Firecracker adalah teknologi yang luar biasa. Kami memakainya di startup wawancara yang menjalankan runtime terisolasi untuk coding interview dan workspace pribadi, dan ini sangat stabil serta mengejutkan ringannya
    Integrasi dengan Go SDK juga sangat mudah

  • Keren melihat userfaultfd makin banyak dipakai. Ini API yang sangat kuat karena memberi kendali penuh atas bagaimana dan dari mana memori diambil saat page fault terjadi

  • Memang benar EC2 biasa juga sudah merupakan VM, tetapi setahu saya ada EC2 tertentu yang menyediakan akses hypervisor sehingga Firecracker juga bisa dijalankan. Mohon koreksi jika saya salah

    • Betul. Hanya tipe instans c8i, m8i, r8i yang didukung, dan ini disebut virtualisasi bersarang[1]
      [1] https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-ec...
    • Saat kami membutuhkan mesin yang cukup besar, yaitu instans AWS metal, perbedaan performa untuk pekerjaan yang berfokus pada CPU antara metal dan VM berukuran setara sekitar 10~20%

  • Saya penasaran kenapa Firecracker diperlukan. Kenapa tidak langsung dijalankan di kontainer saja? Kekhawatiran soal isolasi bisa saya pahami, tetapi kombinasi browser dan container escape bukankah seperti CVE bernilai satu miliar dolar?

    • Sebagian besar penyedia yang matang atau sadar keamanan tidak menganggap kontainer sebagai batas isolasi yang aman. Microsoft tampak seperti pengecualian, tetapi tidak jelas apakah itu kegagalan kebijakan internal atau kurangnya kemampuan menegakkan kebijakan
      Kontainer memberi permukaan serangan yang jauh lebih luas dibanding VM, dan karena tidak dianggap aman menurut standar industri, kemungkinan sumber daya yang dialokasikan untuk menangani CVE container escape juga lebih sedikit dibanding pelarian dari VM
    • Jika melihat kernel mailing list, eksploit container escape belakangan ini muncul hampir setiap minggu
    • MicroVM bisa di-snapshot dan di-rollback. Saya belum pernah dengar itu dilakukan di kontainer

  • Bukankah untuk melakukan ini di instans non-.metal perlu patch kernel? Sepertinya butuh patch PVM