EC2 중첩 가상화로 1초 만에 브라우저 세션 시작!

일반 EC2 인스턴스 내부에 Firecracker VM을 중첩 실행하는 것은 AWS의 최신 지원(2024년 2월)으로 가능해졌으나, 이는 두 단계의 가상화 계층을 통과해야 하므로 성능 저하가 예상됨. 이를 극복하기 위해 2MB 대형 페이지(Huge Pages) 단위 메모리 매핑과 userfaultfd API를 활용하여 페이지 폴트(Page Fault) 발생 빈도를 91배 감소시키고, PS/2 키보드 비활성화 등 불필요한 초기화 로직을 제거하여 VM 복구 시간을 9.8초에서 3.1초로 단축함.

Chromium의 초기 CPU 부하를 분산시키기 위해, 브라우저 준비 완료 전까지는 가상 CPU(vCPU)를 고정하지 않고(Unpinned) 호스트 전체에 분산시킴. 준비 완료 후에는 안정적인 코어에 고정(Pinned)하여 예측 가능한 성능을 확보하고, 하이퍼스레드(Hyperthread) 공유 방지 및 실시간 우선순위(Real-time Priority) 부여로 세션 실패율을 0%로 개선함. 이로써 1,000개 브라우저 테스트에서 세션 손실이 발생하지 않음.

일반적인 헤드리스 Chromium은 웹사이트에서 2%만 탐지를 회피하지만, 이 서비스는 Chromium 자체를 패치하고 수만 개의 실제 사용자 지문(Fingerprint) 데이터를 활용하여 81%의 탐지 회피율을 달성함. 이는 별도의 디스플레이 서버나 GPU 없이 완전한 헤드리스 방식으로 운영 가능하게 하여 비용 절감과 확장성을 높임. 다만, 이 방식이 웹사이트의 봇 차단 정책에 반한다는 윤리적 비판도 존재함.

커뮤니티에서는 AWS Lambda를 이용한 스크린샷 API 구현(timojeajea), Kubernetes + Kata 활용(nunez), 또는 컨테이너 직접 사용(gozzoo) 등 대안 아키텍처가 제시됨. 특히 Lambda는 무료 자동 확장성과 간결한 아키텍처를 장점으로 언급되나, 콜드 스타트(Cold Start) 문제가 지적됨. 또한, Lightpanda와 같은 경량 브라우저 사용(hobofan)이나 컨테이너 기반 브라우저(SomaticPirate)에 대한 질문도 있었으나, 본문에서는 Firecracker의 강력한 격리 성능과 EC2의 비용 효율성을 중심으로 기술적 우위를 주장함.

현재 가장 큰 병목인 Chromium 시작 시간(약 545ms)을 단축하기 위해, 다음 단계로 실행 중인 브라우저 VM을 스냅샷하는 방안을 연구 중임. 이는 VM 복구 후 Chromium을 다시 시작하는 대신, 이미 실행된 브라우저 상태를 그대로 복원하여 콜드 스타트 시간을 거의 0에 가깝게 만들 수 있음. 다만, 실행 중인 브라우저의 다양한 상태(디바이스, 타이머, 그래픽, 네트워크 등)를 안전하게 저장하고 복원하는 복잡성이 과제로 남아있음.