MicroVM 스토리지 해부 — 복사 없이 골든 이미지를 공유하는 Copy-on-Write

Vantisso가 수십 개의 에이전트를 밀리초 단위로 기동할 수 있는 비결 중 하나는 스토리지 계층의 근본적인 재설계에 있다. 골든 이미지를 에이전트가 기동할 때마다 통째로 복제한다면 디스크 I/O가 곧바로 병목이 된다. Vantisso는 이 문제를 리눅스 커널의 블록 디바이스 가상화 프레임워크인 Device Mapper의 스냅샷 기능(dm-snapshot) 으로 구조적으로 해결한다.

Device Mapper는 리눅스 커널이 물리 블록 디바이스 위에 논리적인 가상 블록 디바이스를 만들어내는 계층이고, dm-snapshot은 그중 하나의 기능이다. 하나의 읽기 전용 베이스 이미지를 여러 논리 디바이스가 공유하면서 각자의 변경 사항만 별도의 저장 공간에 기록하는 Copy-on-Write 메커니즘을 제공한다. 즉 골든 이미지를 단 한 번도 복사하지 않고, 수십 개의 MicroVM이 각자 독립된 디스크를 가진 것처럼 동작하게 만드는 것이 dm-snapshot의 핵심 역할이다.

모든 MicroVM은 하나의 골든 이미지에서 출발한다

모든 MicroVM은 단 하나의 불변 마스터 이미지인 골든 이미지에서 출발한다. 골든 이미지는 Alpine Linux minirootfs, micro-init, 에이전트 실행 관리자, 그리고 에이전트 실행에 필요한 모든 의존성이 사전 설치된 RAW ext4 디스크 이미지이다. Vantisso는 COW를 기본 프로비저닝 전략으로 채택하며 dm-snapshot 도구가 없는 호스트에서는 자동으로 일반적인 파일 복사 방식으로 폴백한다.

COW(Copy-on-Write) 프로비저닝의 핵심 아이디어는 단순하다. 디스크의 내용을 실제로 복사하는 대신 변경이 발생했을 때만 그 부분을 새로 기록한다는 것이다. 일반적인 파일 복사 방식에서는 VM을 기동하기 전에 골든 이미지 전체를 새 파일로 복사하고 fsync로 디스크에 확정해야 한다. 에이전트를 여러 개 동시에 기동하면 이미지 크기의 배수에 달하는 쓰기가 한꺼번에 몰리고, 모든 VM이 경쟁적으로 디스크에 쓰기를 수행하므로 I/O 대역폭이 포화되며 VM마다 기동 시간 편차가 커진다. 에이전트 수가 늘어날수록 문제는 더 심각해진다. COW 방식에서는 이 전체 복사 과정 자체가 사라진다. 그 배경에 리눅스의 루프 디바이스(loop device) 와 dm-snapshot이 있다.

COW를 떠받치는 두 축: 루프 디바이스와 dm-snapshot

루프 디바이스는 일반 파일을 블록 디바이스처럼 다룰 수 있게 해 주는 리눅스 커널 기능이다. rootfs.ext4라는 파일을 losetup으로 루프 디바이스에 연결하면 커널은 이 파일을 마치 실제 디스크처럼 마운트하고 읽고 쓸 수 있다. Vantisso는 이 메커니즘을 활용해 골든 이미지 파일과 변경 블록 저장소 파일을 각각 별도의 루프 디바이스로 노출한다. 이때 골든 이미지 쪽은 losetup -r로 읽기 전용 연결한다는 점이 중요하다. 베이스는 절대 변하지 않아야 하기 때문이다.

dm-snapshot은 이 두 루프 디바이스를 결합하여 하나의 가상 블록 디바이스를 만들어낸다. dmsetup으로 생성한 /dev/mapper/cow-<vm_id> 가상 블록 디바이스는 실제로 호스트 OS 커널 공간에 존재한다. MicroVM이 이 디바이스를 자신의 디스크처럼 쓰게 만들기 위해 Firecracker는 이 가상 블록 디바이스를 virtio-blk 가상 하드웨어 장치로 에뮬레이션하여 게스트에 노출한다. 그러면 게스트 OS 커널은 virtio-blk 드라이버를 통해 이 가상 디스크를 /dev/vda로 인식한다. Firecracker의 Direct Kernel Boot 방식에서는 커널 파라미터로 root=/dev/vda rw가 전달되므로 커널 부팅 시점에 /dev/vda가 ext4 루트 파일 시스템으로 즉시 마운트된다. micro-init은 이후 /proc, /sys, /dev 같은 가상 파일 시스템만 추가로 마운트하면 된다.

이 구조의 핵심은 추상화 계층의 투명성이다. 게스트 OS는 자신이 dm-snapshot 위에서 실행되고 있다는 사실을 전혀 알지 못한다. 게스트 입장에서는 그냥 일반적인 ext4 디스크에 읽고 쓰는 것이며 그 I/O가 골든 이미지에서 읽어오는 것인지 변경 블록 저장소에 기록되는 것인지는 전적으로 호스트 커널의 Device Mapper가 투명하게 처리한다. 이 투명성 덕분에 골든 이미지는 COW를 전혀 모르는 표준 ext4 이미지 그대로 쓸 수 있고 게스트 OS와 에이전트 실행 관리자 역시 아무런 수정 없이 동작한다. 빠른 프로비저닝과 낮은 디스크 사용량이라는 COW의 이점은 전적으로 호스트 커널 레벨에서 달성되며 게스트 내부 소프트웨어 스택과 스토리지 최적화가 완전히 분리된다.

읽기와 쓰기: 골든 이미지는 건드리지 않는다

MicroVM은 읽기 요청이 오면 변경 블록 저장소를 먼저 확인하고 해당 블록이 없으면 골든 이미지에서 읽는다. 반대로 쓰기 요청이 오면 골든 이미지를 건드리지 않고 변경된 블록만 변경 블록 저장소에 기록한다. MicroVM 입장에서는 자신만의 독립된 디스크처럼 보이지만 실제로는 골든 이미지를 공유하면서 변경분만 별도로 관리하는 구조이다. 이 전 과정을 하나의 도식으로 나타내면 다음과 같다.

도식을 아래에서 위로 따라가면 구조가 한눈에 들어온다. 왼쪽의 골든 이미지 파일(rootfs.ext4)은 읽기 전용 베이스로 불변이며 losetup -r을 통해 루프 디바이스 A로 노출된다. 오른쪽의 변경 블록 저장소 파일(vm-<id>.cow)은 미리 생성된 희소 파일로 초기 크기가 사실상 0이며 losetup으로 루프 디바이스 B가 된다. dmsetup이 이 두 루프 디바이스를 결합해 가상 블록 디바이스 /dev/mapper/cow-<id>를 만들고 MicroVM은 이를 마운트한다. 그림의 두 화살표로 표시되어 있는 READ, WRITE가 앞서 설명한 읽기·쓰기 경로이다. ① 읽기는 변경 블록 저장소에 없는 블록을 골든 이미지(루프 A)에서 가져오고 ② 쓰기는 변경 블록 저장소(루프 B)만 대상으로 한다. 골든 이미지로 향하는 화살표에 쓰기가 없다는 점이 이 구조의 핵심 특징이다.

가상 블록 디바이스를 준비하는 디스크 프로비저닝 단계의 오퍼레이션(losetup 2번, dmsetup 1번)은 통상 수십 밀리초 안에 완료된다. 이후에는 일반적인 파일 복사 방식과 동일하게 게스트 커널 부팅과 에이전트 실행 관리자 기동이 이어진다. 그리고 프로비저닝을 위해 생성된 가상 블록 디바이스·루프 디바이스·변경 블록 저장소 파일은 VM 삭제 시 모두 자동으로 정리된다(가상 블록 디바이스 제거 → 루프 디바이스 해제 → 변경 블록 저장소 파일 삭제).

왜 빨라지는가: 이미지 크기와 무관한 프로비저닝 비용

COW의 성능 이점은 단순히 "조금 더 빠르다"가 아니라 시간 비용 구조 자체가 다르다는 데 있다. 두 방식의 기동을 단계로 분해하면 차이가 어디에서 오는지 분명해진다.

일반적인 파일 복사 방식:
  [골든 이미지 전체 복사 + fsync]   — 이미지 크기에 비례
  [게스트 커널 부팅 + 에이전트 기동]  — 두 방식 공통

COW 방식:
  [losetup 2번 + dmsetup 1번]    — 수십 밀리초, 이미지 크기와 무관
  [게스트 커널 부팅 + 에이전트 기동]  — 두 방식 공통

게스트 커널 부팅 구간은 두 방식이 동일하다. 따라서 두 방식의 기동 시간 차이는 정확히 디스크 프로비저닝 단계 하나에서 발생한다. 여기서 결정적인 차이는 각 단계의 시간 비용이 무엇에 비례하는가이다. 파일 복사의 비용은 골든 이미지 크기에 비례해 커지지만 COW의 프로비저닝은 losetup과 dmsetup이라는 커널 오퍼레이션 몇 번 실행일 뿐이라 이미지가 아무리 커져도 수십 밀리초로 일정하다. 이는 데이터를 실제로 복사하지 않기 때문이다. 그 결과 COW 기동은 게스트 부팅 시간이 지배하는 수준까지 내려가는데 이것은 스냅샷 복원을 제외하면 현재 구조에서 도달할 수 있는 사실상의 최소 수준이다.

디스크 사용량에서도 같은 원리가 작동한다. 변경 블록 저장소는 초기 크기가 0에 가깝고 실제로 변경된 블록만큼만 더 커지므로 VM을 하나 더 띄워도 늘어나는 디스크 사용량은 사실상 0에 수렴한다. 수십 개의 MicroVM이 하나의 골든 이미지를 물리적으로 공유하기 때문이다.

이 효과는 멀티 에이전트 환경에서 가장 두드러진다. 에이전트를 동시에 여러 개 기동할 때 파일 복사 방식은 이미지 크기의 배수에 달하는 쓰기가 동시에 경합하며 I/O 대역폭을 포화시킨다. 반면 COW 방식은 루프 디바이스와 가상 블록 디바이스 구성만 수행하므로 대규모 쓰기 자체가 없다. 디스크 I/O 경합이 원천적으로 방지되기 때문에 동시에 기동하는 에이전트 수가 늘어나도 기동 시간이 거의 증가하지 않는다. 프로비저닝 비용을 이미지 크기와 에이전트 수 양쪽에서 줄인 것이 이 구조의 본질이며 핵심이다.

정리 요약

정리하면 COW 스토리지는 세 가지를 동시에 달성한다. 골든 이미지를 복사하지 않아 프로비저닝이 수십 밀리초로 일정하고, 변경분만 기록해 VM당 디스크 증가가 사실상 0이며, 대규모 쓰기가 없어 에이전트 수가 늘어도 I/O 경합이 발생하지 않는다. 참고로 2026년 7월 현재 Vantisso 구현의 기동 성능 기준으로 요약하면 다음과 같다.