QCon London 2026: Fixing the AI Infra Scale Problem by Stuffing 1M Sandboxes in a Single Server

Context

컨테이너는 Linux 커널 전체(수천만 줄)를 신뢰 컴퓨팅 베이스로 공유하며, VM은 강한 격리를 제공하지만 부팅 시간과 메모리 오버헤드가 크다. 기존 unikernel 접근은 각 애플리케이션마다 수작업으로 커스텀 OS를 빌드해야 했고, AWS 같은 클라우드에 배포하면 30초 부팅 시간으로 실제 이점을 잃었다.

Technical Solution

• Unikraft SDK로 unikernel 빌드 자동화: 애플리케이션이 실제로 필요한 OS 컴포넌트만 포함된 단일 목적 VM을 자동 생성
• VM 스냅샷 기반 부팅: 애플리케이션 초기화 완료 후 스냅샷 저장, 이후 모든 인스턴스는 사전 준비된 상태에서 밀리초 단위로 재개
• 전체 스택 효율화: Firecracker VMM 선택, 불필요한 로드밸런서/프록시 계층 제거, 공유 메모리 통신 기반으로 재구축
• Scale-to-zero 상태 관리: 유휴 VM을 CPU 소비 없이 메모리 최소화 상태로 수면, 요청 도착 시 정확한 이전 상태에서 즉시 재개
• 압축·차등 스냅샷 저장: Linux 커널 제한 극복(tap 디바이스, 브리지 포트, TCP 잠금 경합) 및 100만 개 VM 스냅샷을 약 12TB로 압축
• Kubernetes 통합: virtual kubelet으로 microVM을 Kubernetes pod으로 표현, 스케줄러에는 'running' 상태 보고하며 내부적으로 수면/복구

Impact

• 단일 서버당 100만 개 VM 구동
• 콜드 부팅 및 응답 시간 10ms 이하
• 2014년 ClickOS 30ms 부팅 대비 달성, 2017년 논문의 8,000 VM 밀도 대비 125배 증가
• 100만 개 sleeping VM 스냅샷 저장 12TB
• NGINX 인스턴스 응답 시간 밀리초 단위

Key Takeaway

VM 격리 강도, 부팅 속도, 서버 밀도는 전통적으로 트레이드오프였으나, 스냅샷 재개와 scale-to-zero 상태 관리, 전체 스택 재설계를 통해 세 가지를 동시에 확보할 수 있다. 실제 클라우드 배포 성능은 애플리케이션 자체뿐 아니라 부팅 환경, 제어 평면, 메모리 관리 전체에서의 누적 효율화에 달려 있다.