AWS Firecracker란? 마이크로VM 기술 설명
TMT요약
AWS Firecracker는 마이크로VM(microVM)이라 불리는 가벼운 가상 머신을 만들고 관리하는 오픈소스 가상 머신 모니터(VMM)입니다. Amazon Web Services가 개발했고, 전통적인 VM의 보안 격리와 컨테이너의 속도·자원 효율을 함께 갖췄습니다.
Firecracker는 AWS Lambda와 AWS Fargate를 구동하면서 매달 수조 건의 함수 실행을 처리합니다. 마이크로VM을 빠르면 125밀리초 만에 부팅하고, VM 하나당 메모리 오버헤드는 5MiB 미만이며, 호스트 한 대에서 초당 최대 150개의 마이크로VM을 만들 수 있습니다.
이 기술은 Apache 2.0 라이선스로 공개되어 있고, Northflank를 비롯한 여러 플랫폼이 서버리스 함수부터 AI 코드 실행 샌드박스까지 다양한 워크로드에 채택했습니다.
Firecracker란?
Firecracker는 서버리스와 컨테이너 워크로드를 위해 특별히 만든 가상 머신 모니터(VMM)입니다. Rust로 작성했고, 리눅스의 커널 기반 가상 머신(KVM)을 이용해 마이크로VM을 만듭니다. 마이크로VM은 요즘 클라우드 워크로드를 돌리는 데 꼭 필요한 것만 남기고 덜어낸 가벼운 가상 머신입니다.
AWS는 Lambda와 Fargate를 구동하려고 내부에서 개발한 Firecracker를 2018년 11월에 오픈소스 소프트웨어로 공개했습니다. 이 프로젝트는 기존 가상화 기술이 이벤트 기반이고 대체로 수명이 짧은 서버리스 워크로드에는 최적화되어 있지 않다는 판단에서 출발했습니다.
QEMU 같은 전통적인 VMM은 데스크톱과 서버 용도를 포함한 범용 가상화를 겨냥해 설계되었습니다. 그래서 서버리스 함수에는 전혀 필요 없는 하드웨어 장치까지 폭넓게 에뮬레이션합니다. USB 컨트롤러, 디스플레이, 사운드 카드, PCI 버스, BIOS가 그런 예입니다. 이렇게 불필요하게 복잡해지면 공격 표면과 자원 오버헤드가 함께 늘어납니다.
Firecracker는 반대 방향, 즉 최소주의를 택했습니다. 에뮬레이션 장치는 다섯 개만 구현하고, 전통적인 하드웨어를 그대로 모방하는 대신 최적화된 virtio 인터페이스로 게스트 커널과 통신합니다. 구현한 장치는 virtio-net, virtio-block, virtio-vsock, 시리얼 콘솔, 최소 기능의 키보드 컨트롤러입니다.
Firecracker의 동작 방식
마이크로VM 아키텍처
Firecracker 마이크로VM은 오버헤드를 최소한으로 유지하면서 하드웨어 수준의 격리를 제공하는 가벼운 가상 머신입니다. 마이크로VM은 각자 자기 게스트 커널을 돌리며, 다른 마이크로VM이나 호스트 시스템과 완전히 분리됩니다.
Firecracker 마이크로VM을 시작하면 다음 순서로 진행됩니다.
- Firecracker VMM 프로세스가 시작되면서 RESTful API 엔드포인트를 노출합니다
- API를 호출해 마이크로VM을 설정하면서 vCPU, 메모리, 네트워크 인터페이스, 블록 디바이스를 지정합니다
- 리눅스 커널 이미지와 루트 파일시스템을 제공합니다
- Firecracker가 게스트 커널을 부팅하고 사용자 공간 코드를 실행합니다
전체 과정은 약 125밀리초 만에 끝납니다. 비교하자면 전통적인 VM은 부팅에 보통 몇 초에서 몇 분이 걸립니다.
주요 기술 명세
부팅 시간: 빠르면 125밀리초 만에 사용자 공간 코드를 시작하며, 이 시간을 더 줄이는 작업이 계속 진행되고 있습니다.
메모리 오버헤드: 마이크로VM 하나당 5MiB 미만이라 호스트 한 대에서 수천 개의 VM을 돌릴 수 있습니다.
생성 속도: 호스트 한 대당 초당 최대 150개의 마이크로VM을 만듭니다.
지원 아키텍처: 하드웨어 가상화를 지원하는 64비트 인텔, AMD, ARM 프로세서입니다.
호스트 요구사항: KVM이 활성화된 리눅스가 필요하고, 커널은 4.14 이상이어야 합니다.
Jailer 보안 모델
Firecracker에는 심층 방어(defense-in-depth) 보안을 담당하는 jailer라는 보조 프로그램이 들어 있습니다. jailer는 다음을 적용합니다.
- 자원 사용량을 제한하는 cgroup 격리
- 시스템 자원이 보이는 범위를 제한하는 네임스페이스 격리
- 사용할 수 있는 시스템 콜을 제한하는 seccomp 필터
- 파일시스템 접근을 제한하는 chroot
이렇게 하면 보안 경계가 여러 겹 생깁니다. 공격자가 어떻게든 가상화 장벽을 빠져나왔다 해도, 여전히 jailer가 쳐 둔 차단 장치를 만나게 됩니다.
Firecracker와 전통적인 VM, 컨테이너 비교
Firecracker를 이해하려면 기존 방식들이 무엇을 얻고 무엇을 내주는지부터 알아야 합니다.
전통적인 가상 머신
전통적인 VM은 격리가 강력합니다. VM마다 자기 커널이 있어서 다른 VM이나 호스트에 직접 접근할 수 없습니다. 하지만 오버헤드가 상당합니다. 메모리를 많이 차지하고, 부팅이 느리며, 작은 워크로드를 여러 개 돌릴 때 자원 효율이 떨어집니다.
컨테이너
컨테이너(Docker, containerd)는 호스트 커널을 공유하기 때문에 가볍고 빠르게 시작합니다. 다만 커널을 공유한다는 것은 커널에 취약점이 생기면 한 컨테이너가 다른 컨테이너에 영향을 줄 수 있다는 뜻입니다. 정말로 신뢰할 수 없는 워크로드라면 이 커널 공유 모델은 위험을 안고 있습니다.
Firecracker 마이크로VM
Firecracker는 그 중간에 자리합니다. 마이크로VM은 VM처럼 워크로드마다 전용 커널을 두어 보안을 격리하면서도, 시작 시간과 자원 효율은 컨테이너에 가깝습니다. 마이크로VM은 하나하나가 하드웨어 가상화 수준에서 완전히 격리되지만, 전통적인 가상화처럼 군더더기를 짊어지지 않습니다.
| 항목 | 전통적인 VM | 컨테이너 | Firecracker 마이크로VM |
|---|---|---|---|
| 격리 | 강함(전용 커널) | 약함(커널 공유) | 강함(전용 커널) |
| 부팅 시간 | 몇 초에서 몇 분 | 밀리초 | 약 125밀리초 |
| 메모리 오버헤드 | 수백 MiB | 미미함 | 5MiB 미만 |
| 집적도 | 낮음 | 높음 | 높음 |
| 공격 표면 | 큼 | 중간 | 최소 |
다른 마이크로VM 기술과의 비교
마이크로VM 기술이 Firecracker뿐인 것은 아닙니다. 대안들과 비교하면 다음과 같습니다.
Firecracker와 QEMU
QEMU는 아주 다양한 하드웨어와 용도를 지원하는 범용 에뮬레이터 겸 가상화 도구입니다. Firecracker는 서버리스를 겨냥해 만들었습니다. QEMU의 유연성을 내준 대신 공격 표면을 크게 줄이고 오버헤드를 낮췄습니다. USB 패스스루나 GPU 지원, 윈도우 게스트가 필요하다면 QEMU를 쓰세요. 격리된 리눅스 워크로드 수천 개를 효율적으로 돌려야 한다면 Firecracker가 더 나은 선택입니다.
Firecracker와 Cloud Hypervisor
Cloud Hypervisor도 클라우드 워크로드에 초점을 맞춘 Rust 기반 VMM입니다. Firecracker보다 기능이 많아서 GPU 패스스루와 라이브 마이그레이션까지 지원하지만, 그러면서도 크기는 상대적으로 작게 유지합니다. Cloud Hypervisor와 Firecracker는 설계 철학이 비슷하고 부팅 시간도 100밀리초에서 150밀리초 정도로 비슷합니다. Firecracker가 지원하지 않는 기능이 필요하다면 Cloud Hypervisor가 더 알맞을 수 있습니다.
Firecracker와 Kata Containers
Kata Containers는 OCI 호환 컨테이너를 가벼운 VM 안에서 돌리는 컨테이너 런타임입니다. QEMU, Cloud Hypervisor, 그리고 Firecracker까지 여러 하이퍼바이저를 백엔드로 쓸 수 있습니다. Kata Containers는 통합 계층이고, 실제 격리는 Firecracker나 다른 VMM이 담당합니다. 많은 플랫폼이 Kata Containers를 쓰면서 그 아래 VMM으로 Cloud Hypervisor나 Firecracker를 둡니다.
Firecracker와 gVisor
gVisor는 접근 방식이 근본적으로 다릅니다. 전용 커널을 갖춘 VM에서 워크로드를 돌리지 않고, Sentry라는 구성 요소로 사용자 공간에서 시스템 콜을 가로챕니다. 전체 가상화의 오버헤드 없이 격리를 제공하지만, Firecracker와 같은 하드웨어 수준의 격리 보장을 주지는 못합니다. gVisor는 일부 워크로드에서 오버헤드가 더 낮은 대신 격리 경계가 더 약합니다.
Firecracker의 활용 사례
서버리스 컴퓨팅(FaaS)
Firecracker의 대표적인 활용 사례입니다. AWS Lambda는 함수 호출 하나하나를 각자의 Firecracker 마이크로VM에서 실행해, 빠른 콜드 스타트와 높은 집적도를 유지하면서 고객 사이에 강한 격리를 제공합니다. Lambda 함수가 실행되면 자기 커널을 가진 마이크로VM 안에서 돌아가므로, 커널 공유에서 생기는 취약점이 함수 경계를 넘을 수 없습니다.
컨테이너 격리
멀티테넌트 환경에서 컨테이너를 돌리는 조직이라면, 주로 Kata Containers를 거쳐 쓰는 Firecracker가 일반 Docker 컨테이너보다 강한 격리를 제공합니다. 컨테이너마다 자기 마이크로VM에서 돌아가므로 커널 공유에서 오는 위험이 사라집니다. AWS Fargate가 고객 컨테이너를 안전하게 돌리는 데 이 방식을 씁니다.
AI 및 코드 실행 샌드박스
신뢰할 수 없는 코드나 AI가 생성한 코드를 돌리려면 강한 격리가 필요합니다. Northflank 같은 플랫폼은 Firecracker 마이크로VM으로 코드 실행을 샌드박스에 담습니다. 실행 세션마다 마이크로VM을 하나씩 받고 끝나면 그 마이크로VM을 폐기하므로, 세션 사이에 데이터가 새지 않고 코드가 악의적으로 동작해도 침해가 남지 않습니다.
엣지 컴퓨팅
Firecracker는 자원을 아주 적게 요구하기 때문에 컴퓨팅 자원이 넉넉하지 않은 엣지 배포에 잘 맞습니다. 부팅이 빨라서 엣지 위치에서도 즉각적으로 확장할 수 있습니다.
CI/CD와 빌드 시스템
신뢰할 수 없는 코드를 실행하는 빌드 시스템은 Firecracker의 격리에서 이득을 봅니다. 사용자가 제출한 빌드나 오픈소스 프로젝트의 CI가 그런 경우입니다. 빌드마다 새 마이크로VM에서 돌아가므로, 빌드 과정을 노린 공격이 다른 빌드나 호스트 시스템에 영향을 주지 못합니다.
Firecracker를 쓰는 곳
AWS 서비스
AWS Lambda: Firecracker로 고객을 격리하면서 매달 수조 건의 함수 실행을 처리합니다. 함수 호출마다 자기 마이크로VM에서 돌아갑니다.
AWS Fargate: 고객 컨테이너를 전용 EC2 인스턴스가 아니라 Firecracker 마이크로VM 안에서 돌려, 격리를 유지하면서 집적도를 높이고 비용을 낮춥니다.
클라우드 플랫폼과 인프라 제공업체
공식 Firecracker 문서에 따르면 다음과 같은 곳이 이 기술을 채택했습니다.
- Northflank — 애플리케이션과 AI 워크로드를 배포하는 클라우드 플랫폼
- Kata Containers — 지원하는 여러 VMM 백엔드 중 하나로 사용
- Koyeb — 서버리스 플랫폼
- Fly.io — 글로벌 애플리케이션 플랫폼
- OpenNebula — 클라우드 컴퓨팅 플랫폼
- Qovery — 배포 플랫폼
- webapp.io — 프리뷰 환경
오픈소스 프로젝트
- containerd — firecracker-containerd 통합을 통해 사용
- Weave Ignite(현재는 보관 처리) — Firecracker용 GitOps
- microvm.nix — Firecracker에서 돌리는 NixOS
Firecracker의 한계
Firecracker는 최소주의로 설계했기 때문에 다른 VMM이 제공하는 기능을 의도적으로 지원하지 않습니다.
- GPU 패스스루 없음: GPU 접근이 필요한 애플리케이션은 Firecracker를 쓸 수 없습니다. 대신 QEMU나 Cloud Hypervisor를 쓰세요.
- 라이브 마이그레이션 없음: 실행 중인 Firecracker 마이크로VM을 다른 호스트로 옮길 수 없습니다. 워크로드가 상태를 갖지 않게 만들거나, 애플리케이션 계층에서 마이그레이션을 처리해야 합니다.
- 리눅스 게스트만 지원: Firecracker는 리눅스와 OSv 게스트를 지원합니다. 윈도우는 지원하지 않습니다.
- USB나 임의 장치 패스스루 없음: 에뮬레이션되는 virtio 장치 다섯 개만 쓸 수 있습니다.
- 베어메탈이나 중첩 가상화 필요: Firecracker는 KVM에 직접 접근해야 합니다. AWS에서는 .metal 인스턴스나 중첩 가상화를 켠 인스턴스에서 돌려야 한다는 뜻입니다.
이 한계들은 의도한 절충입니다. 구현하지 않은 기능은 그만큼 존재하지 않는 공격 표면입니다.
Northflank에서 Firecracker 시작하기
Firecracker 인프라를 직접 구축하고 운영하려면 엔지니어링에 상당히 투자해야 합니다. KVM을 설정하고, 커널 이미지를 관리하고, 네트워킹을 구성하고, jailer 보안 모델을 구현하고, 규모에 맞게 오케스트레이션까지 해내야 합니다. 그래서 대부분의 팀은 이런 복잡함을 감춰 주는 플랫폼을 통해 Firecracker를 씁니다.
Northflank는 Kata Containers와 Cloud Hypervisor로 구동되는 프로덕션 수준의 마이크로VM 인프라를 제공해, 운영 부담 없이 Firecracker급 격리를 누릴 수 있게 해 줍니다. 이 플랫폼은 매달 200만 건이 넘는 격리된 워크로드를 처리하며, 엔지니어링 팀은 Kata Containers, QEMU, containerd, Cloud Hypervisor에 활발히 기여하고 있습니다.
Northflank에서 격리된 워크로드를 돌리는 방법은 다음과 같습니다.
- northflank.com에서 가입합니다
- 프로젝트를 만듭니다 — 리전을 고르거나, BYOC 배포를 위해 직접 쓰는 클라우드 계정(AWS, GCP, Azure)을 연결합니다
- 서비스를 배포합니다 — 어느 레지스트리에 있는 OCI 컨테이너 이미지든 쓸 수 있습니다
- 마이크로VM 격리로 실행합니다 — Northflank가 격리된 인프라를 자동으로 프로비저닝합니다
Northflank는 특히 다음 경우에 잘 맞습니다.
AI 코드 실행 샌드박스: AI 에이전트가 코드를 생성해 실행할 때, 그 코드는 마이크로VM이 뒷받침하는 격리된 환경에서 돌아갑니다. 실행마다 따로 담기므로 악의적이거나 결함이 있는 코드가 다른 워크로드에 영향을 주지 못합니다.
멀티테넌트 배포: 고객을 대신해 워크로드를 돌리는 SaaS 플랫폼과 개발자 도구는 테넌트 사이에 엄격한 격리 경계를 얻습니다.
신뢰할 수 없는 워크로드 실행: 직접 작성하지 않은 코드가 관여하는 모든 상황은 하드웨어 수준의 격리에서 이득을 봅니다.
특별한 요구사항이 있는 팀은 Northflank 엔지니어링 팀과 데모를 예약해 마이크로VM 구성, 컴플라이언스 요건, 엔터프라이즈 요금을 논의할 수 있습니다.
자주 묻는 질문
Firecracker 마이크로VM이란 무엇인가요?
Firecracker 마이크로VM은 Firecracker VMM이 만드는 가벼운 가상 머신입니다. 약 125밀리초 만에 부팅하고 메모리는 5MiB 미만을 쓰면서 하드웨어 수준의 격리를 제공합니다. 마이크로VM은 각자 자기 리눅스 커널을 돌리며 다른 마이크로VM이나 호스트와 완전히 격리됩니다.
AWS Firecracker는 무료인가요?
네. Firecracker는 Apache 2.0 라이선스로 공개된 오픈소스 소프트웨어입니다. 자유롭게 사용하고 수정하고 배포할 수 있습니다. AWS가 개발했지만 커뮤니티에 공개했습니다.
Firecracker와 Docker의 차이는 무엇인가요?
Docker 컨테이너는 호스트 커널을 공유하며 프로세스 수준의 격리를 제공합니다. Firecracker 마이크로VM은 각자 커널을 가지고 하드웨어 수준의 격리를 제공합니다. Docker는 시작이 더 빠르고 오버헤드가 낮지만 격리는 더 약합니다. Firecracker는 오버헤드를 약간 더 쓰는 대신 더 강한 보안 경계를 제공합니다.
Firecracker로 윈도우를 돌릴 수 있나요?
아니요. Firecracker는 리눅스 게스트와 OSv만 지원합니다. 최소주의 설계에 따라 윈도우에 필요한 장치 에뮬레이션을 의도적으로 뺐습니다. 윈도우 워크로드에는 QEMU나 Hyper-V를 쓰세요.
Firecracker와 Kata Containers의 차이는 무엇인가요?
Firecracker는 VMM이라서 가상 머신을 만들고 관리합니다. Kata Containers는 Firecracker, QEMU, Cloud Hypervisor 같은 여러 VMM을 백엔드로 쓸 수 있는 컨테이너 런타임입니다. Kata Containers는 OCI와 쿠버네티스 통합 계층을 제공하고, 실제 격리는 Firecracker나 다른 VMM이 담당합니다.
Firecracker는 GPU를 지원하나요?
아니요. Firecracker는 GPU 패스스루를 지원하지 않고, 에뮬레이션되는 virtio 장치 다섯 개를 넘어서는 어떤 장치 패스스루도 지원하지 않습니다. GPU 워크로드에는 QEMU나 Cloud Hypervisor를 쓰세요.