중첩 가상화를 이용한 멀티클라우드 배포 원리 이해
Vantisso가 MicroVM을 기동하기 위한 전제 조건은 하나이다. 호스트에서 /dev/kvm을 사용할 수 있어야 한다는 것. 물리 서버라면 당연히 충족되지만 클라우드 인스턴스는 그 자체가 이미 가상 머신이다. 가상 머신 안에서 또 가상 머신을 띄울 수 있을까? 이 질문에 답하는 기술이 중첩 가상화(Nested Virtualization) 이다.
L0, L1, L2 — 3계층으로 된 가상화 스택
중첩 가상화는 이름 그대로 가상화를 한 겹 더 쌓는 기술, 즉 가상 머신 안에서 또 다른 가상 머신을 실행하는 것이다. 이해를 돕기 위해 가상화 스택을 세 개 계층으로 나누어 본다.
일반적인 가상화는 L0과 L1의 두 계층으로 구성된다. 클라우드 사업자의 컴퓨트 인스턴스는 물리 서버(L0) 위에 가상화 인스턴스(L1)를 만들어 제공하는 것이다. 중첩 가상화는 여기서 한 단계 더 나아가 그 인스턴스(L1) 안에서 다시 가상 머신(L2)을 실행한다. Vantisso의 관점에서 보면 배포 대상 호스트가 L1 계층인 클라우드 인스턴스가 되고 Vantisso가 그 안에서 만드는 MicroVM이 L2 계층에 놓인다.
문제는 가상 머신을 실행하려면 CPU의 하드웨어 가상화 기능에 접근할 수 있어야 하는데 전통적으로 클라우드 인스턴스(L1)는 이 기능을 게스트 OS에게 노출하지 않았다는 점이다. 인스턴스 안에서 CPU 정보를 확인해도 vmx나 svm 플래그를 찾을 수 없었고, 따라서 그 안에서는 KVM을 쓸 수 없었다.
다행히 주요 클라우드 사업자들이 중첩 가상화를 지원하기 시작했다. 기술적으로는 L0 계층의 하이퍼바이저가 하드웨어 가상화 기능(VT-x/AMD-V)을 L1 인스턴스에 패스스루(Pass-through)한다는 뜻이다. 그러면 L1 안에서도 vmx 또는 svm 플래그가 보이고 /dev/kvm을 사용할 수 있게 되어 마치 물리 서버처럼 그 안에서 다시 가상 머신을 만들 수 있다. 이것이 고가의 베어메탈 인스턴스를 빌리지 않고도 일반 VM 인스턴스에 Vantisso를 배포할 수 있게 하는 열쇠이다.
중첩 가상화의 하드웨어 메커니즘
L2가 없는 일반적인 가상화에서는 L1의 게스트 OS가 특권 작업을 시도하면 VM Exit이 발생하고 L0의 하이퍼바이저가 대신 처리했다. 중첩 가상화는 이 구조가 한 겹 더 쌓인 형태이다. L2 MicroVM의 게스트 OS가 특권 작업을 시도하면 L1의 하이퍼바이저(KVM)가 처리해야 하는데 L1 자신도 가상 머신이므로 L1이 하이퍼바이저 역할을 하려는 시도 또한 결국 L0의 통제를 받는다.
이 중첩 처리에서 특히 중요한 것이 메모리 주소 변환의 다중화이다. 현대 CPU는 게스트의 가상 주소를 실제 물리 주소로 변환하는 과정을 하드웨어로 가속하는데 인텔은 이를 EPT(Extended Page Tables), AMD는 NPT(Nested Page Tables)라고 부른다. 중첩 가상화에서는 이 변환이 두 단계로 일어난다. L2의 주소를 L1의 주소로, 다시 L1의 주소를 L0의 물리 주소로 옮겨야 하기 때문이다. 이 다중 변환이 중첩 가상화가 베어메탈 대비 낮은 성능을 보이는 주된 요인이다.
성능: 어디서 얼마나 손해를 보는가
성능에 영향을 주는 요소는 다중 주소 변환만이 아니다. 중첩된 VM Exit 처리도 있다. L2에서 발생한 이벤트가 여러 계층을 거쳐 처리되므로 단일 계층 가상화보다 오버헤드가 클 수밖에 없다.
구글 클라우드는 공식 문서에서 이 영향을 명시하고 있다. 구글 클라우드가 공개한 정보를 요약해 보자면 하드웨어 지원 중첩 가상화를 사용하더라도 CPU 집약적 워크로드에서 10% 이상의 성능 저하가 있을 수 있고 입출력 집약적 워크로드에서는 그보다 클 수 있다는 것이다. AWS 역시 성능에 민감하거나 엄격한 지연 시간이 요구되는 워크로드라면 베어메탈 인스턴스를 검토하라고 안내한다.
여기서 중요한 것은 이 성능 감소 요인이 에이전트 워크로드의 어느 실행 지점에 영향을 미치는가이다. 에이전트 실행은 크게 두 구간으로 나뉜다.
- 기동 구간 — 디스크 프로비저닝, 게스트 커널 부팅, 네트워크 할당이 이루어 지는 구간. 입출력 집약적이라 중첩 가상화의 손해가 가장 직접적으로 나타나는 구간이다.
- 실행 구간 — 에이전트가 모델 API를 호출하고 응답을 기다리며 작업을 수행하는 구간. 태스크 전체 소요 시간의 대부분을 이 응답 대기가 차지하므로 CPU 오버헤드에 상대적으로 둔감하다.
즉 클라우드 위에서 체감 성능을 좌우하는 것은 기동 구간이고 여기에는 두 가지 대응이 유효하다. 첫째, 스냅샷 복원과 웜 풀의 비중을 높이는 것이다. 두 경로 모두 게스트 부팅과 디스크 프로비저닝을 건너뛰므로 중첩 가상화의 영향을 가장 적게 받는다. 둘째, 골든 이미지와 스냅샷 저장소를 로컬 NVMe나 SSD 계열 디스크에 두는 것이다. 입출력이 두 단계의 가상화를 통과하는 환경에서는 디스크 선택의 영향이 베어메탈에서보다 훨씬 크게 나타나기 때문이다.
그래서 최고 성능이나 엄격한 지연 시간이 필요한 워크로드에는 여전히 베어메탈이 정답이다. 그러나 그 외의 많은 경우 중첩 가상화로 인한 성능 감소는 베어메탈의 높은 비용을 고려하면 충분히 받아들일 만한 트레이드오프이다. 특히 개발·테스트 환경이나 중소 규모의 운영 환경이라면 일반 인스턴스에서 Vantisso를 운영하는 편이 경제적으로 훨씬 합리적이다.
주요 클라우드 지원 현황 (2026년 7월 기준)
| 사업자 | 지원 현황 | L1 하이퍼바이저 | 유의할 점 |
|---|---|---|---|
| Google Cloud | 2017년부터 지원, 성숙도·문서화 양호 | Linux KVM만 지원 | Intel Haswell 이상 필요(AMD 미지원), E2·메모리 최적화 등 일부 계열 제외 |
| Azure | Dv3·Ev3 이후 다수 계열에서 지원 | Hyper-V 중심 | Trusted Launch 보안 유형에서는 비활성 — Standard로 생성해야 함 |
| AWS | 2026년 2월부터 C8i·M8i·R8i 지원 | KVM, Hyper-V | 인스턴스 시작 시 CPU 옵션으로 활성화, 전 상용 리전 제공 |
구글 클라우드는 일찍부터 중첩 가상화를 지원해 왔고 L1 하이퍼바이저로 리눅스 KVM만을 지원한다. 리눅스와 KVM을 사용하는 Vantisso에는 가장 자연스러운 환경이다. 다만 인텔 Haswell 이상의 프로세서가 필요하고 AMD 기반 머신 타입에서는 사용할 수 없다는 제약이 있다.
애저도 오래전부터 특정 VM 계열에서 중첩 가상화를 지원한다. 다만 Hyper-V를 네이티브로 지원하는 데 초점이 맞춰져 있어 윈도우 서버 중심 스택에 더 자연스럽게 맞는다. 리눅스 KVM으로 쓸 때 자주 걸리는 지점은 보안 유형이다. Trusted Launch로 생성하면 중첩 가상화가 비활성화되므로 인스턴스를 만들 때부터 Standard를 선택해야 한다.
AWS는 오랫동안 베어메탈에서만 중첩 가상화가 가능했지만 2026년 2월부터 C8i·M8i·R8i 인스턴스에서 공식 지원을 시작했다. Nitro 시스템이 VT-x 같은 프로세서 확장을 인스턴스에 전달하는 방식이며 L1 하이퍼바이저로 KVM과 Hyper-V를 지원한다. 비싼 베어메탈 없이도 일반 인스턴스에서 Firecracker 기반 워크로드를 실행할 수 있는 길이 열린 셈이다.
한 가지 유의할 점은 클라우드의 인스턴스 계열과 지원 정책이 빠르게 변한다는 것이다. 위 내용은 작성 시점 기준이므로 실제 배포 시에는 각 사업자의 최신 문서에서 어떤 계열이 KVM 기반 중첩 가상화를 지원하는지 먼저 확인하기 바란다.
배포 전 1분 점검
인스턴스를 띄웠다면 다음 세 줄로 Vantisso가 동작할 수 있는 환경인지 바로 확인할 수 있다.
# 1. CPU 가상화 확장이 인스턴스 안에서 보이는가 (인텔: vmx, AMD: svm)
grep -Eo 'vmx|svm' /proc/cpuinfo | sort -u
# 2. KVM 모듈이 적재되어 있는가
lsmod | grep kvm
# 3. KVM 장치 파일이 존재하고 접근 가능한가
ls -l /dev/kvm1번 실행 결과가 비어 있다면 중첩 가상화가 켜지지 않은 것이다. 인스턴스 계열이 지원 대상인지, 생성 시 중첩 가상화 옵션(또는 보안 유형)을 올바로 지정했는지 확인해야 한다. 세 명령 실행의 결과 모두 정상적으로 답을 내놓는다면 그 인스턴스는 베어메탈과 동일하게 Vantisso를 실행할 수 있는 환경이다.
어디서나 실행되는 인프라
배포 환경별로 요약 정리하면 다음과 같다.
- 베어메탈 환경 — 하드웨어 가상화가 직접 제공되므로 중첩 가상화 지원 없이 Vantisso를 바로 실행할 수 있다. 자체 데이터센터의 물리 서버, 사무실 워크스테이션, 개인 랩탑까지 물리 CPU에 직접 접근하는 환경이면 어디든 가능하다. 개발자가 자기 랩탑에서 Vantisso를 띄워 멀티 에이전트 시스템을 실험하는 데 아무 문제가 없다.
- 클라우드 환경(IaaS) — 중첩 가상화를 지원하는 인스턴스를 선택하면 된다. Google Cloud, Azure, AWS를 비롯한 주요 사업자가 모두 지원하므로 특정 사업자에 종속되지 않고 여러 클라우드에 배포할 수 있다.
이 유연성은 Vantisso의 설계가 특정 환경에 의존하지 않는다는 데서 나온다. 요구 조건은 "하드웨어 가상화 기능에 접근할 수 있는 리눅스"라는 표준적인 것 하나뿐이다. Vantisso를 실행하는데 관리형 쿠버네티스도, 특정 사업자의 매니지드 서비스도, 전용 하드웨어도 필요하지 않다.
전제 조건이 하나뿐이라는 사실은 운영 관점에서 생각보다 큰 차이를 만든다. 배포 위치를 기술적 제약이 아니라 비용·성능·리전 요구사항을 기준으로 고를 수 있다는 뜻이기 때문이다. 데이터 주권 규제 때문에 특정 국가 리전에 두어야 한다면 그 리전에서 중첩 가상화를 지원하는 인스턴스를 고르면 되고 인스턴스 비용이 상대적으로 낮은 사업자를 선택하면 된다. 개인이 랩탑에서 가볍게 쓰는 것부터 기업이 여러 클라우드에 걸쳐 대규모로 운영하는 것까지 동일한 Vantisso를 이용해 동일한 방식으로 운영이 가능하다.