Firecracker로 0.8ms 만에 시작하는 VM 샌드박스!

본 기술은 Firecracker를 사용하여 초기 VM을 부팅하고, 메모리 및 CPU 상태를 스냅샷한다. 이후 각 샌드박스는 스냅샷 메모리의 `MAP_PRIVATE` 매핑을 기반으로 하는 새로운 KVM VM을 생성하여, CoW(Copy-on-Write)를 통해 페이지를 공유한다. 이로 인해 각 샌드박스는 이미 실행 중인 Python 프로세스에서 시작되며, 0.8ms의 매우 짧은 시작 시간을 달성한다. 이는 기존 VM 부팅 방식 대비 획기적인 성능 향상(Performance Improvement)을 가져온다.

제공된 샌드박스는 컨테이너가 아닌 실제 KVM VM을 사용하므로, 게스트 커널, 메모리, 페이지 테이블이 완전히 분리되어 하드웨어 수준의 격리(Hardware-enforced Isolation)를 보장한다. 이는 보안 측면에서 매우 중요한 요소로, 한 샌드박스에서 발생한 문제가 다른 샌드박스에 영향을 미치는 것을 방지한다. 하지만, cperciva는 엔트로피(Entropy) 문제와 관련된 보안 취약점을 지적하며, Firecracker 팀의 관련 연구를 참고할 것을 권고한다.

벤치마크 결과에 따르면, Zeroboot E2B microsandbox는 p50 기준 0.79ms, p99 기준 1.74ms의 시작 시간을 기록했다. 이는 Daytona, E2B, 그리고 Fork + exec(Python) 방식에 비해 월등히 빠른 속도이다. 특히, 265KB의 메모리 사용량은 다른 솔루션에 비해 매우 적은 자원을 사용하며, AI 에이전트(AI Agent)와 같은 메모리 집약적인 작업에 적합하다는 것을 시사한다.

crawshaw는 초기 실험에서 네트워킹 설정에 어려움을 겪었다고 언급하며, 1초의 시작 시간을 허용하는 경우 시스템d(systemd)를 사용하는 것이 더 간단할 수 있다고 지적했다. diptanu는 여러 노드 간의 샌드박스 복제(Cloning) 시, 데이터 격리 아키텍처(Data Isolation Architecture), 파일 시스템 또는 CoW 레이어, 그리고 데이터 이동과 관련된 복잡성을 언급하며, 프로덕션 환경에서의 배포(Deployment)에 대한 추가적인 고려 사항을 제시했다.