EC2 안 Firecracker VM으로 브라우저를 1초 미만에 시작하기

 (browser-use.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Browser Use Cloud는 브라우저 세션마다 개별 Firecracker VM을 쓰면서 새 세션 시작 시간을 1초 미만으로 낮추고 비용을 브라우저 시간당 $0.06에서 $0.02로 줄임
  • 이전 Unikraft 구조는 유휴 비용에는 유리했지만, 트래픽 급증 때 사람이 용량을 조정해야 해 부하 테스트 중 프로덕션이 45분간 중단됨
  • 새 구조는 자체 control plane이 브라우저 플릿을 실시간으로 감시해 EC2 호스트 배치, 확장, 드레이닝을 CloudWatch보다 더 세밀하게 결정함
  • 정규 EC2 위에서 Firecracker를 실행하는 중첩 가상화를 택한 대신, 2MB 메모리 페이지, userfaultfd, vCPU 고정, real-time priority, headless Chromium 패치로 병목을 줄임
  • VM cold start는 400ms 미만이고, 10,000세션 스트레스 테스트에서 공개 API 기준 브라우저 생성 지연은 p50 825ms, p99 1.35초였으며 모든 브라우저가 성공적으로 시작됨

빠르고 격리되고 저렴한 클라우드 브라우저

  • Browser Use Cloud의 목표는 브라우저를 빠르게 시작하면서 세션 간 상태를 격리하고 비용을 낮추는 것임
  • 한 세션에는 Chromium, 파일시스템, 쿠키, 캐시, 프록시 설정, 다운로드, 때로는 로그인된 고객 세션까지 포함됨
  • 한 브라우저가 다른 브라우저의 상태를 읽을 수 있으면 보안 문제가 되므로, 각 세션을 호스트와 다른 세션에서 분리해야 함
  • 일반적인 해법은 자체 CPU, 메모리, 디스크, 네트워크 장치를 갖는 VM이지만, 계속 만들고 세션 종료 후 버리는 클라우드 브라우저 환경에는 너무 무겁고 비쌈
  • 새 구조는 모든 Browser Use Cloud 세션을 작은 Firecracker VM 하나에서 실행하고, 이 VM들을 Amazon EC2 위에서 구동함

Unikraft를 떠난 이유

  • 이전 구조는 Unikraft로 클라우드 브라우저를 실행했음
  • Unikraft는 전체 Linux를 부팅하지 않고 목적에 맞게 만든 작은 이미지인 unikernel을 로드함
  • unikernel은 빠르게 시작하고, 사용자가 없을 때 종료할 수 있어 유휴 비용이 낮음
  • 병목은 트래픽 급증 때 브라우저 용량을 빠르게 늘리는 일이었음
    • Unikraft에는 좋은 내장 autoscaling이 없었음
    • 엔지니어가 변수를 바꿔 인스턴스를 수동으로 추가해야 했음
    • 한 부하 테스트는 프로덕션을 45분간 중단시킴
  • 재구축 후에는 Firecracker를 사용함
    • Firecracker는 VM을 생성, 감시, 실행하는 계층을 제공함
    • 각 VM에 CPU, 메모리, 디스크, 네트워크 장치를 제공하고 호스트 및 다른 VM과 격리함

자체 control plane으로 브라우저 확장 자동화

  • Firecracker는 각 브라우저에 VM을 줄 수 있지만, VM 수와 배치, 확장 시점을 자동으로 결정하지는 않음
  • Browser Use는 자체 control plane을 만들어 브라우저 플릿을 감시하고 scale up/down을 결정함
  • 사용자가 브라우저를 요청하면 control plane이 여유 있는 머신을 선택함
  • 트래픽이 늘면 더 많은 머신을 시작하고, 줄어들면 제거할 머신에는 새 브라우저를 보내지 않음
  • control plane은 플릿을 실시간으로 확인함
    • AWS 모니터링 서비스인 CloudWatch는 보통 1분 단위 창으로 반응함
    • control plane은 아직 시작 중인 브라우저, 제거 중인 머신, 새 세션을 받으면 안 되는 머신처럼 일반 지표에 없는 정보를 알고 있음
  • 사용자 요청은 stateless edge router를 거쳐 control plane으로 전달되고, control plane은 여유 있는 EC2 호스트를 고름

정규 EC2 위에서 Firecracker를 실행한 이유

  • AWS에서 Firecracker를 실행하는 일반적인 방식은 .metal 인스턴스를 쓰는 것임
    • .metal은 물리 서버 전체를 빌려 Firecracker가 직접 실행되는 구조임
  • Browser Use는 정규 EC2를 선택함
    • 정규 EC2 머신은 더 빨리 확보할 수 있음
    • 유지 비용이 더 낮음
    • 호스트는 미리 만든 이미지에서 부팅하고 시작 후 약 30초 만에 브라우저를 제공함
  • 호스트를 더 빨리 추가할 수 있으면 비용을 내야 하는 유휴 용량이 줄고 고객에게 전가되는 비용도 낮아짐
  • 대가는 VM 안의 VM 구조임
    • 정규 EC2 자체가 이미 AWS의 격리 계층 안에서 실행됨
    • 그 안에서 다시 브라우저 VM을 실행함
    • 브라우저 VM이 호스트 도움을 요청할 때 두 VM 계층을 지나야 하므로 지연이 추가됨
  • Browser Use는 더 빠른 scale-up과 낮은 비용을 위해 이 절충을 선택하고, Firecracker 실행 경로를 빠르게 만드는 데 집중함

요청에서 사용 가능한 브라우저까지의 흐름

  • 사용자가 브라우저를 요청하면 control plane이 여유 있는 머신을 고름
  • 해당 머신은 저장된 브라우저 VM을 복원하고, 그 안에서 Chromium을 시작함
  • Chromium이 제어 가능한 상태가 되면 연결 URL을 반환함
  • 사용자의 에이전트는 이 URL로 접속함
  • Browser Use는 WebSocket을 통해 Chrome DevTools Protocol(CDP) 로 Chromium을 제어함
    • CDP는 버튼 클릭, 텍스트 입력, 페이지 읽기, 스크린샷 촬영 같은 Chrome 원격 제어 API임
  • 지연을 만든 주요 병목은 세 가지였음
    • VM 메모리 복원
    • Chromium 시작
    • anti-bot 보안에 탐지되지 않는 stealth 유지

첫 번째 병목: 메모리 복원

  • 프로덕션 브라우저는 처음부터 부팅하지 않고 snapshot에서 재개함
  • snapshot은 이미 부팅되어 있고 Chromium 시작 직전에 멈춰 있는 저장된 VM임
  • VM 재개는 새 부팅보다 빠르지만, 초기 cold start에서는 page fault가 전체 VM exit의 72% 를 차지함
  • VM 재개부터 CDP-ready 브라우저까지 걸린 시간은 처음에 9.8초였음
  • 느린 이유는 복원된 VM이 메모리를 처음 만질 때 호스트가 해당 메모리를 다시 매핑해야 하기 때문임
    • 이 이벤트가 page fault임
    • 중첩 VM에서는 page fault가 두 VM 계층을 지날 수 있어 비쌈
  • 해결책은 메모리를 더 큰 단위로 매핑하는 것이었음
    • 이전에는 4KB 페이지로 복원함
    • 지금은 2MB 페이지를 사용함
    • 각 페이지가 512배 더 많은 메모리를 덮어 브라우저가 깨어나는 동안 page fault가 크게 줄어듦
  • Linux의 누락 메모리 페이지 처리 API인 userfaultfd에 대한 custom handler도 추가함
    • VM 실행 전에 Chromium이 먼저 접근할 가능성이 큰 메모리를 로드함
    • Chromium 시작 시 page fault 폭주를 막음
  • 이 변경으로 VM 재개부터 명령 수락 가능한 브라우저까지 걸린 시간이 9.8초에서 3.1초로 줄어듦
  • 누락 메모리 처리를 위해 브라우저 VM이 멈추고 호스트에 요청한 횟수는 재개당 약 100,000회에서 약 1,100회로 줄어 약 91배 감소함
  • 작은 최적화도 누적됨
    • 존재하지 않는 오래된 PS/2 키보드를 찾느라 쓰던 500ms 검사를 비활성화함
    • 준비 상태 확인을 HTTP polling에서 vsock 로그 읽기로 바꿈
    • 브라우저 드라이버가 로그에 ready 메시지를 쓰면 호스트가 vsock으로 읽고, ready 메시지를 1ms 미만에 확인함

두 번째 병목: Chromium 시작과 CPU 배치

  • Chromium 시작 시에는 renderer, compositor, V8 isolate를 한꺼번에 만들기 때문에 CPU 사용량이 큼
  • 시작 이후의 브라우저 자동화는 상대적으로 조용함
    • 에이전트는 클릭하고 기다리고 읽고 다시 클릭함
    • 브라우저는 대부분 페이지, 네트워크 응답, 다음 에이전트 동작을 기다림
  • 이 특성 때문에 한 호스트에 많은 브라우저를 packing할 수 있음
  • 시작 순간의 CPU burst는 두 단계로 처리함
    • 브라우저가 재개되고 Chromium이 시작되는 동안에는 vCPU를 unpinned 상태로 둠
    • Linux가 브라우저 CPU 작업을 고정 코어에 묶지 않고 호스트 전반에 분산할 수 있음
    • 브라우저가 ready 상태를 보고하면 vCPU를 안정적인 코어에 pinning함
  • 시작부터 pinning하면 여러 브라우저가 동시에 시작될 때 같은 hot core에 몰려 일부 launch가 실패함
  • hyperthread 처리도 조정함
    • 물리 CPU 코어 하나는 종종 sibling thread라는 두 논리 CPU로 보임
    • 두 브라우저 VM이 각각 sibling 하나씩 받으면 같은 물리 코어를 놓고 경쟁함
    • 중첩 환경에서는 이 경쟁이 launch 실패로 나타남
    • 현재 각 브라우저는 사용하는 물리 코어의 sibling thread 둘 다 받음
  • pinning된 각 vCPU thread에는 real-time priority를 부여함
    • Linux가 덜 중요한 작업 뒤에 VM을 멈춰 두지 않고 즉시 실행하게 함
    • 변경 전 1,000브라우저 테스트에서는 생성 직후 세션의 17%가 손실됨
    • 변경 후 같은 테스트에서는 손실이 0이었음

화면 없는 stealth 브라우저

  • headless 브라우저는 보이는 창 없이 실행되고, headful 브라우저는 노트북의 브라우저처럼 창과 그래픽, 렌더링 프레임을 갖고 실행됨
  • plain headless Chromium은 anti-bot 조치를 쓰는 웹사이트에서 탐지되기 쉬움
  • Browser Use의 stealth benchmark에 따르면 plain headless Chromium은 차단을 피한 비율이 2% 였음
  • 같은 Chromium을 보이는 창이 있는 headful 상태로 실행하면 렌더링만으로 차단 회피율이 50% 가 됨
  • 많은 제공자가 headful 브라우저를 실행하는 이유는 이 때문이며, 화면을 보는 사람이 없어도 display server, GPU, compositor 비용을 냄
  • Browser Use는 브라우저 자체를 바꿔 완전한 headless 실행을 유지함
  • 첫 번째 구성요소는 Chromium fork임
    • 많은 stealth 도구는 브라우저 시작 후 모든 페이지에 JavaScript를 주입해 자동화를 숨김
    • 예를 들어 navigator.webdriver 값을 덮어써 웹사이트가 true 대신 false를 보게 함
    • 웹사이트는 이런 값이 덮어써졌는지 탐지할 수 있음
    • Browser Use는 Chromium의 낮은 수준을 패치해 이런 값이 처음부터 노출되지 않게 함
  • 두 번째 구성요소는 fingerprinting임
    • 브라우저 fingerprint는 웹사이트가 읽는 브라우저와 머신 정보의 조합임
    • 운영체제, 화면 크기, 폰트, 그래픽 출력, 오디오, 시간대, 언어 등 수백 가지 세부 정보가 포함됨
    • Browser Use는 macOS, Windows, Linux 전반의 실제 fingerprint 수만 개를 사용함
  • 이 브라우저들은 stealth benchmark에서 81%, Halluminate BrowserBench에서 84.8% 의 차단 회피율을 기록함
  • 화면이 없기 때문에 브라우저 실행 비용이 낮고 확장도 쉬움

올바른 브라우저에 연결하기

  • 브라우저가 준비되면 사용자는 CDP로 연결함
  • 공개 URL은 WebSocket URL임
  • 브라우저 플릿 앞에는 단순한 edge router들이 있음
  • router는 WebSocket 연결을 받고 control plane에 해당 브라우저 위치를 물은 뒤, raw CDP 바이트를 올바른 VM으로 전달함
  • router는 브라우저가 어디서 실행될지 결정하지 않음
  • router 하나가 죽어도 다른 router가 새 연결을 맡을 수 있음
  • 배치는 control plane이 담당하고, router는 바이트 전달만 수행함

결과와 다음 단계

  • 현재 각 브라우저 세션은 정규 EC2 안에서 실행되는 작은 VM snapshot에서 재개되고, 그 안에서 headless Chromium이 실행되는 구조임
  • VM cold start는 400ms 미만임
  • 공개 API 기준 브라우저 생성 지연은 p50 825ms, p99 1.35초임
  • 이 수치는 모든 브라우저가 성공적으로 시작된 10,000세션 스트레스 테스트에서 측정됨
  • BrowserArena의 독립 leaderboard는 Browser Use를 $0.02/hr와 100% reliability로 1위에 올림
  • 이 인프라에서 가장 큰 남은 비용은 Chromium 자체임
    • resume 이후 Chromium 시작은 여전히 p50 기준 약 545ms가 걸림
  • 현재 snapshot은 Chromium 시작 직전 시점에 만들어짐
    • 모든 브라우저가 동일하고 깨끗한 지점에서 깨어난 뒤 각자 Chromium을 시작함
  • 다음 단계는 Chromium이 이미 실행된 뒤에 snapshot을 만드는 것임
    • 새 세션이 브라우저를 시작하지 않고 이미 살아 있는 브라우저와 함께 깨어날 수 있음
  • 이 작업은 복잡함
    • 실행 중인 브라우저에는 열린 장치, 타이머, 그래픽 상태, 네트워크 상태, fingerprint 상태가 있음
    • freeze 전에 이 상태들을 안전하게 만들어야 함
    • restore 후 각 브라우저는 이전 브라우저의 복제본이 아니라 자기만의 브라우저처럼 보여야 함
  • Browser Use Cloud는 cloud.browser-use.com에서 현재 사용 가능함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 안티봇 우회를 벤치마크로 내세우는 건 꽤 비윤리적으로 보임. 안티봇의 목적은 원치 않는 봇을 막는 것인데, 이런 서비스는 결국 웹을 더 사람에게 불친절하고 비싸게 만듦
    사이트들은 자동화 접근을 계속 막으려 할 것이고, 콘텐츠 접근 장벽은 더 늘어날 것임. 웹에서 신원 확인 요구가 커지는 이유도 나이 제한이나 “아이들 보호”만이 아니라 봇 방어와 광고 수익 보호까지 포함된 상위 효과로 보임

    • 웹사이트 변경 감지에 이런 도구를 씀. 좋아하는 작가들 중 RSS가 없는 경우가 있고, 큰 가전 같은 고가 물건은 가격 변화를 보려고 항상 가격 모니터링을 설정함
      API가 없는 사이트에서는 스크레이퍼도 쓰고, 구매 내역 전체를 데이터베이스에 색인해 분석할 수 있게 해 둠. 멍청한 봇 탐지를 우회하는 데 더 많은 시간을 쓰고 싶진 않으며, 다른 방법으로 접근할 수 없는 데이터라면 기꺼이 비용을 낼 의향도 있음. 어차피 스크레이퍼가 이길 수밖에 없는 고양이와 쥐 게임에 자원을 태우는 셈임
    • 공개 웹사이트 스크레이핑이 비윤리적인지는 논쟁의 여지가 있음. 어떤 경우에는 사이트가 기술적 장벽을 세우거나 중지 요구서를 보내도 법원이 합법이라고 본 적도 있음
      다만 주거용 프록시를 제공하는 건 비윤리적일 가능성이 큼. 그런 프록시의 주거 회선 제공자들은 자신이 그런 서비스에 편입됐다는 사실을 모르는 경우가 많음
    • 남이 원하지 않는 일을 한다는 이유만으로 비윤리적이라고 보긴 어려움. 이유와 의도가 중요함
      어떤 공연 티켓을 얻으려고 24시간 컴퓨터 앞에 앉아 있을 수 없을 때, 좋아하는 밴드 티켓을 사기 위해 개인 봇을 쓰는 게 비윤리적이라고 보긴 어려움. 반대로 암표상 목적이라면 비윤리적이라는 데 동의함. 안티봇의 안티봇은 남들이 자동화되면 안 된다고 보는 일을 가능하게 하려는 것이고, Hacker News 독자 중 꽤 많은 사람이 한 번쯤은 이런 일을 해봤을 것 같음. 순전히 이익 목적이면 별로지만, 암표상과 맞설 기회를 얻기 위한 용도라면 괜찮아 보임
    • 웹으로만 접근 가능하고 API 지원이 부실하거나 없는 소프트웨어를 자동화하는 회사들을 알고 있음. 보통 꽤 큰돈을 내고 쓰는 소프트웨어인데, 로그인 보호용 캡차가 내장돼 있음
      여러 SaaS 테넌트 중 하나일 뿐이라 캡차 제거를 요구할 만큼 큰 고객도 아니어서, 그냥 그 제약을 우회함
    • 자기 헤드리스 브라우저가 차단되지 않기를 원하는 사람들이 씀

  • 여기서 빠진 부분은 일반 EC2 인스턴스의 중첩 가상화가 올해 2월부터 가능해졌다는 점임. 그 전에는 Firecracker VM을 실행하려면 metal EC2 인스턴스를 써야 했음

    1. https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-ec...
    • 꽤 새로운 기능이고, 공식적으로는 아직 권장되지 않지만 지금까지는 아주 잘 동작함. 드디어 베어메탈을 돌리지 않아도 됨
    • metal 인스턴스는 시작과 중지가 엄청 느림

  • 이 정도까지 해놓고도 여전히 Chromium을 고수한 게 조금 놀라움
    우리의 web-access MCP 서버[0]는 훨씬 단순한 구성으로 브라우저 인스턴스를 하위 프로세스로 띄우는데, 안정성·CPU·메모리 사용량에서 가장 큰 개선은 Chrome에서 Lightpanda[1]로 바꿨을 때였음. 글 끝의 말처럼 더 빨리 뜨는 브라우저는 애초에 메모리를 덜 할당하는 브라우저일 수도 있음
    [0]: https://github.com/EratoLab/web-access-mcp
    [1]: https://lightpanda.io

    • 스텔스 목적 때문에 Chromium을 엔진으로 유지하기로 했음
      LightPanda 같은 브라우저는 스텔스가 전혀 없고 탐지가 아주 쉬움. 필요 없는 것을 제거하면 Chromium도 더 빠르게 만들 방법이 있음. 처음부터 엔진 전체를 새로 만들지 않고도, 최우선순위인 스텔스를 잃지 않으면서 Chromium이 그 성능에 도달할 수 있다고 봄. 언어가 문제는 아니며 C++도 Zig만큼 성능이 좋지만, Chromium의 비대함은 크다는 데 동의함

  • ApiFlash라는 스크린샷 API를 운영하는데, EC2의 Firecracker 대신 AWS Lambda 컨테이너 이미지에 Chromium을 패키징해서 씀
    AWS Lambda는 격리와 자동 확장을 공짜로 제공하므로 스크린샷처럼 부하가 튀는 무상태 작업에 이상적임. browser-use 솔루션과 거의 같은 이점을 얻으면서 아키텍처는 훨씬 단순하다고 봄. 트레이드오프는 AWS Lambda 콜드 스타트지만, 실제로는 연속 호출에서 뜨거운 함수를 재사용함. 충분한 호출량이 있으면 피크가 완화되고 콜드 스타트도 그리 자주 일어나지 않음

    • 우리가 만든 기능이 모든 사용 사례에 필요한 건 아님
      Lambda에서 겪은 문제는 실행 시간 제한이 15분이라는 점, 가격, 스냅샷 메커니즘 부재, 실행 호스트에 대한 저수준 제어 부족이었음. 우리는 최대 4시간을 지원하고 필요하면 더 길게도 실행 가능함. 그래도 대부분의 일반적인 웹 자동화 사용 사례에는 Lambda면 충분하고도 남음
    • 그 솔루션은 꽤 비싸 보임

  • “다음: Chromium 시작 건너뛰기”라고 했는데, 이미 실행 중인 브라우저 묶음을 웜 풀로 유지해 들어오는 요청에 할당하면 안 되나 싶음
    사용자 입장에서는 지연 시간이 거의 0에 가까울 것임. 트래픽 패턴에 따라 웜 풀을 늘리거나 줄이는 예측 로직은 필요하겠지만, 가장 쉬운 해결책처럼 보임

    • 웜 풀은 동작하지만, 목표는 그것 자체를 대체하는 것임
      웜 풀은 좋지만 결국 리소스를 소비하고, 풀을 항상 따뜻하게 유지하며 균형을 맞추기 위해 브라우저를 계속 시작해야 함. 앞으로의 변경으로 Chromium 시작을 유지하면서 VM이 50ms 안에 준비되게 만들어 웜 풀을 완전히 이길 계획임. 일부 고객은 특수 파라미터와 기능을 필요로 해서 웜 풀 복잡도가 커짐. 일반 경로는 빠르겠지만 예외 경로는 매우 느려질 수 있는데, 요청한 브라우저에 어떤 기능이 필요하든 빠른 속도를 보장하고 싶음

  • Firecracker는 훌륭한 기술임. 코딩 인터뷰와 개인 작업공간용 격리 런타임을 실행하는 면접 스타트업에서 쓰고 있는데, 매우 안정적이고 놀라울 만큼 가벼움
    Go SDK로 연동하는 것도 아주 쉬웠음

  • userfaultfd가 더 많이 쓰이는 걸 보니 멋짐. 페이지 폴트가 발생할 때 메모리를 어떻게, 어디서 불러올지 완전히 제어할 수 있어서 정말 강력한 API임

  • 일반 EC2도 이미 VM이라는 점은 맞지만, 하이퍼바이저 접근을 제공해서 Firecracker도 가능한 특정 EC2가 있는 것으로 알고 있음. 틀렸다면 정정 바람

    • 맞음. c8i, m8i, r8i 인스턴스 유형만 지원하고, 중첩 가상화라고 부름[1]
      [1] https://aws.amazon.com/about-aws/whats-new/2026/02/amazon-ec...
    • 꽤 큰 머신, 즉 AWS metal 인스턴스가 필요했을 때 metal과 같은 크기의 VM 사이에서 CPU 중심 작업 성능 차이가 10~20% 정도였음

  • Firecracker가 왜 필요한지 궁금함. 그냥 컨테이너에서 직접 실행하면 안 되나? 격리 우려는 이해하지만, 브라우저와 컨테이너 탈출 조합이면 10억 달러짜리 CVE 아닌가?

    • 성숙하거나 보안 의식이 높은 제공자 대부분은 컨테이너를 안전한 격리 경계로 보지 않음. Microsoft는 예외로 보이지만, 내부 정책 실패인지 정책 집행 역량 부족인지는 불분명함
      컨테이너는 VM보다 훨씬 넓은 공격 표면을 제공하고, 업계 표준상 안전하다고 보지 않기 때문에 컨테이너 탈출 CVE 관리에 투입되는 자원도 VM 탈출보다 적을 가능성이 큼
    • 커널 메일링 리스트를 보면 컨테이너 탈출 익스플로잇은 요즘 거의 매주 나옴
    • 마이크로VM은 스냅샷을 찍고 롤백할 수 있음. 컨테이너에서 이렇게 한다는 건 들어본 적이 없음

  • 이걸 .metal이 아닌 인스턴스에서 하려면 커널 패치가 필요하지 않나? PVM 패치가 필요한 것 같음

답변달기