[etc] Firecracker (microVM) 소개
https://aws.amazon.com/ko/blogs/korea/firecracker-lightweight-virtual… (536)
Firecracker 한줄 정의
AWS가 서버리스·컨테이너 워크로드를 “초고속 + 초경량 + 강격리”로 돌리려고 만든 KVM 기반 VMM(가상머신 모니터). 리눅스 커널만 최소 장치로 올리는 microVM을 띄워서 컨테이너급 속도와 VM급 격리를 동시에 노리는 구조야. 공식 수치로 부팅 < 125ms, 오버헤드 < 5MiB, 호스트당 초당 최대 150개 생성을 목표로 설계되었고, Lambda/Fargate에 실제 적용돼 있어. firecracker-microvm.github.ioUSENIXAmazon Science
왜 만들었나 / 어디에 쓰이나
문제의식: 컨테이너는 커널을 공유해서 속도/유연성은 좋지만 격리면에서 VM보다 약함. 서버리스 다중 테넌트에서 보안/밀도/속도를 모두 만족하려고 Firecracker를 별도로 설계. USENIX
적용: AWS Lambda, Fargate가 대규모로 사용. 한 서버에서 수천 microVM을 동시에 실행해 요청을 처리. USENIXAmazon Science
성능/밀도 목표(공개 수치): microVM 당 <5MiB 메모리 오버헤드, <125ms에서 유저 공간/앱 코드 진입, 초당 150개 microVM 생성. USENIXfirecracker-microvm.github.io
핵심 아키텍처 (구성요소)
VMM (Rust): 유저 공간에서 KVM을 사용해 microVM 생성·관리. 장치 모델 최소화(virtio-net, virtio-blk, virtio-vsock, 시리얼 콘솔, 최소 키보드 컨트롤러만)로 공격면을 극소화. firecracker-microvm.github.io
REST API: 유닉스 소켓을 통해 vCPU/메모리/디스크/네트워크/레이트리미터/메타데이터 서비스 등을 구성 후 부팅. GitHub
Jailer: chroot, PID/네임스페이스 분리, 권한 드롭, seccomp-BPF(화이트리스트 24개 syscalls)로 2중 격리. 운영 배포에서 권장. USENIX
스냅샷/복원: 실행 중 VM 상태를 저장/복원해 콜드스타트 지연을 더 줄이는 운영 패턴(예: Lambda SnapStart와 철학 유사). GitHubAWS 문서
컨테이너 / 전통 VM / Firecracker 비교
| 항목 | 컨테이너 | 전통 VM(QEMU 등) | Firecracker microVM |
|---|---|---|---|
| 커널 | 호스트 커널 공유 | 게스트 커널 | 게스트 커널 |
| 부팅 시간 | ms~수초 | 수초 | < 125ms 목표 설계 |
| 메모리 오버헤드 | 매우 낮음 | 상대적으로 큼 | < 5MiB 수준 목표 |
| 격리 강도 | 중(강화 가능) | 높음 | 높음(하드웨어 가상화 + 최소 장치 + jailer) |
| 장치/기능 풍부함 | 낮음 | 매우 높음 | 필수 장치만(virtio…)/BIOS·PCI·라이브 마이그레이션 없음 |
| 사용처 | CI, 앱 배포 등 | 복합 OS/드라이버 | 다중 테넌트 서버리스, 보안 중시 컨테이너 |
수치/제약의 근거: 공식 사이트와 NSDI 논문(“BIOS/PCI/라이브 마이그” 미지원), 장치 5종, 부팅/오버헤드/생성률. firecracker-microvm.github.ioUSENIX
장점과 트레이드오프
장점
보안/격리: 하드웨어 가상화 + 최소 장치 모델 + jailer(seccomp, chroot, 네임스페이스). USENIX
속도/밀도: 컨테이너에 근접한 스타트업 + 낮은 메모리 풋프린트로 고밀도 배치. firecracker-microvm.github.io
운영 제어: 네트워크/스토리지 레이트 리미터 내장, 메타데이터 서비스 제공. firecracker-microvm.github.io
트레이드오프
기능 최소화: BIOS/PCI/라이브 마이그레이션 미지원, Windows 게스트 부팅 불가(의미 있는 변경 없이는). USENIX
네트워킹 셋업 필요: TAP/브리지 구성 등 호스트 네트워킹 지식 요구. Actuated
오케스트레이션은 별도: Firecracker는 QEMU 대체 포지션이지 Docker/K8s 대체가 아님. 컨테이너 생태계와 연동(firecracker-containerd 등)로 해결. USENIXGitHub
빠르게 맛보기: “Hello microVM” 로컬 실행 흐름
전제: 리눅스 호스트, 하드웨어 가상화( /dev/kvm ), 커널 4.14+, x86_64/ARM64. firecracker-microvm.github.io
바이너리 설치(또는 빌드)
최신 릴리스 다운로드(현재 v1.12.1이 최신 릴리스로 표기). 또는 소스 빌드:
git clone https://github.com/firecracker-microvm/firecracker cd firecracker tools/devtool build빌드 산출물 경로는 README의 안내 참고. GitHub
커널 & 루트FS 준비
게스트 커널 이미지(
vmlinux)와 최소 루트FS(ext4)를 준비. (공식 가이드/배포판 도구/직접 빌드 활용 가능) GitHub
Firecracker 프로세스 시작(REST 소켓 노출)
./firecracker --api-sock /tmp/fc.sock
다른 터미널에서 REST 호출로 설정을 밀어넣어 부팅. 짓보 - 개발자의 오타크
머신/부팅/디스크 설정 + 부팅
# vCPU/메모리
curl --unix-socket /tmp/fc.sock -i \ -X PUT 'http://localhost/machine-config' \ -H 'Content-Type: application/json' \ -d '{"vcpu_count":1,"mem_size_mib":256,"ht_enabled":false}'
# 커널 경로/부팅 인자
curl --unix-socket /tmp/fc.sock -i \ -X PUT 'http://localhost/boot-source' \ -H 'Content-Type: application/json' \ -d '{"kernel_image_path":"./vmlinux", "boot_args":"console=ttyS0 reboot=k panic=1 pci=off"}'
# 루트 디스크
curl --unix-socket /tmp/fc.sock -i \ -X PUT 'http://localhost/drives/rootfs' \ -H 'Content-Type: application/json' \ -d '{"drive_id":"rootfs","path_on_host":"./rootfs.ext4", "is_root_device":true,"is_read_only":false}'
# (선택) TAP 네트워크 연결은 별도 준비 후 /network-interfaces 자원 추가
# 부팅
curl --unix-socket /tmp/fc.sock -i \ -X PUT 'http://localhost/actions' \ -H 'Content-Type: application/json' \ -d '{"action_type":"InstanceStart"}'
REST API로 구성/부팅하는 흐름은 공식 README/가이드가 기준. GitHub
운영 모드
운영에 투입하려면 (옵션)
컨테이너 생태계 연동:
firecracker-containerd사용 시 컨테이너당 microVM을 자동 관리(컨테이너드와 vsock 에이전트 연계). CI/CD, 멀티테넌트 SaaS 격리에 유용. GitHub스냅샷/복원: 장시간 초기화 있는 워크로드(예: 자바 런타임)에서 cold start를 크게 낮추는 패턴. Lambda SnapStart 문서의 아이디어와 맞닿음. GitHubAWS 문서
호스트 하드닝: Firecracker 팀이 권장하는 프로덕션 호스트 설정 문서 참고(커널 완화, SMT 비활성 등). NSDI 논문에 사이드채널 대응 권고가 정리되어 있음. GitHubUSENIX
언제 Firecracker를 택할까?
다중 테넌트 환경에서 컨테이너보다 더 강한 격리가 필요하지만 속도/밀도도 포기 못할 때.
서버리스/잡성(短命) 워크로드(요청 단위 인스턴스)나 불신 코드 실행 샌드박스(온라인 저지/코드 실행 서비스/멀티테넌트 CI) 등에 특히 적합. USENIXStan's blog
반대로 Windows 게스트, 풍부한 가상 장치/라이브 마이그레이션 등 전통적 VM 기능이 필수라면 QEMU/KVM 계열이 더 적합. USENIX
추가로 볼만한 1차 자료
공식 사이트(개요, 사양, 장치 5종, <125ms/<5MiB, 메타데이터/레이트리미터/Jailer): firecracker-microvm.github.io
NSDI’20 논문(설계 철학, 수치, 보안·성능 평가, “무엇을 빼었는가”): USENIX
Amazon Science 블로그(운영 스케일, “초당 150개·수천 동시”): Amazon Science
GitHub README(API/기능 목록, 빌드·릴리스, v1.12.1): GitHub
firecracker-containerd(컨테이너드 연동): GitHub
스냅샷/복원 문서: GitHub
Q&A :
Firecracker는 어떤 워크로드에 가장 적합하며, 왜 이를 선택하는지 궁금합니다
Firecracker는 특히 보안, 속도, 밀도가 중요한 워크로드에 가장 적합합니다. 기존 가상 머신(VM)의 강력한 격리 기능과 컨테이너의 가벼움을 모두 필요로 하는 현대적인 클라우드 환경에 최적화되어 있습니다.
Firecracker가 가장 효과적으로 사용되는 워크로드와 그 이유는 다음과 같습니다.
1. 서버리스 컴퓨팅 (예: AWS Lambda)
서버리스 함수는 이벤트가 발생할 때만 일시적으로 실행되는 짧은 생애주기를 가집니다.
선택 이유:
빠른 시작 속도: 사용자의 요청에 즉각적으로 응답하기 위해 수십 밀리초(ms) 내에 컴퓨팅 환경이 준비되어야 합니다. Firecracker의 microVM은 125ms 이내에 부팅이 가능하여 이러한 요구사항을 완벽히 충족합니다.
강력한 보안 및 격리: 서버리스 환경에서는 수많은 고객의 코드가 동일한 물리 서버에서 실행됩니다. Firecracker는 하드웨어 가상화 기반의 microVM을 사용하여 각 함수를 완벽하게 격리함으로써, 한 고객의 코드가 다른 고객에게 영향을 미치는 것을 원천적으로 차단합니다.
높은 자원 효율성: 각 microVM은 5MB 미만의 매우 적은 메모리만 추가로 사용하므로, 단일 서버에 수천 개의 함수를 동시에 실행할 수 있습니다. 이는 서비스 제공자 입장에서 비용 효율성을 극대화합니다.
2. 컨테이너 워크로드 (예: AWS Fargate)
컨테이너는 배포가 빠르고 가볍지만, 호스트 운영체제의 커널을 공유하기 때문에 다중 테넌트(multi-tenant) 환경에서는 보안에 대한 우려가 있을 수 있습니다.
선택 이유:
보안 강화: Firecracker는 각 컨테이너 또는 컨테이너 그룹(Pod)을 자체 microVM 내에서 실행하여, 컨테이너에 VM 수준의 강력한 격리 계층을 추가해 줍니다. 이를 통해 커널 취약점을 이용한 공격으로부터 호스트와 다른 컨테이너를 보호할 수 있습니다.
성능 유지: 무거운 전체 VM을 사용하는 대신 경량 microVM을 사용하므로, 보안을 강화하면서도 컨테iner의 장점인 빠른 시작과 낮은 오버헤드를 상당 부분 유지할 수 있습니다.
3. CI/CD 파이프라인 및 테스트 자동화
CI/CD(지속적 통합/지속적 배포) 파이프라인에서는 빌드, 테스트, 배포 등 짧고 반복적인 작업들이 실행됩니다.
선택 이유:
신속하고 깨끗한 환경: 각 작업(job)을 위해 수초 내에 완전히 격리된 깨끗한 환경을 생성하고, 작업이 끝나면 즉시 폐기할 수 있습니다. 이는 작업 간의 의존성을 없애고 테스트 결과의 일관성을 보장합니다.
효율적인 리소스 사용: 무거운 VM을 매번 생성하고 삭제하는 것에 비해 훨씬 적은 리소스를 사용하므로, 더 많은 작업을 동시에 효율적으로 처리할 수 있습니다.
4. 안전한 코드 실행 샌드박스
신뢰할 수 없는 외부 코드(예: 사용자가 제출한 코드, 플러그인, AI 에이전트가 생성한 코드)를 안전하게 실행해야 하는 모든 시나리오에 적합합니다.
선택 이유:
최소한의 공격 표면: Firecracker는 꼭 필요한 기능(네트워크, 스토리지 등)만 최소한으로 제공하여 잠재적인 보안 공격 경로를 크게 줄였습니다.
완벽한 격리: 악성 코드가 실행되더라도 그 영향은 해당 microVM 내부에 완벽히 격리되어 호스트 시스템이나 다른 워크로드에 전혀 영향을 미치지 못합니다.
결론적으로 Firecracker는 **'빠르고, 가벼우면서도, 매우 안전한 격리 환경'**이 필요한 모든 워크로드에 이상적인 솔루션이라고 할 수 있습니다.
Firecracker는 AWS 기술이다 보니 Linux 재단 및 CNCF 진영에서 밀고 있는 microVM 규격인 Kata Container도 관심을 많은 관심 부탁드립니다. ㅎㅎ
최근에는 Confidential Containers 라는 이름으로 CNCF 재단에서 microVM(Kata Container)을 Kubernetes와 결합하여 좀 더 격리된 환경의 Pod을 제공하자는 드라이브도 적극적으로 걸고 있습니당~
https://www.cncf.io/projects/confidential-containers/
kata 도 hypervisor 을 qemu/firecracker/cloud-hypervisor 중에 선택해서 사용합니다.
서로 상반되는 기술이 아닌거죠.
Kata Container가 Firecracker를 Hypervisor로도 지원 하는군요!
엔트그룹에서 발표한 이런 자료도 있는데 이해를 못 했습니다