KVM의 내부 동작 원리
KVM은 /dev/kvm 캐릭터 디바이스를 노출함으로써 리눅스 커널을 Type-1 하이퍼바이저로 변환합니다. 사용자 공간 프로세스(보통 QEMU)가 그 디바이스를 열고, 커널에 가상 CPU 생성을 요청한 뒤, 하드웨어 가상화 확장을 사용해 게스트 명령어를 물리 CPU에서 직접 실행합니다. 커널은 권한이 필요한 이벤트만 처리하고, 나머지는 모두 네이티브 속도로 실행됩니다.
세 가지 구성 요소가 KVM을 작동하게 합니다. 첫째, kvm.ko 커널 모듈은 CPU와 메모리 가상화를 관리하고 /dev/kvm 인터페이스를 노출합니다. 둘째, 아키텍처별 모듈 — Intel VT-x용 kvm-intel.ko 또는 AMD-V용 kvm-amd.ko — 이 일반 KVM API와 기반 CPU의 가상화 명령어 사이를 변환합니다. 셋째, QEMU, cloud-hypervisor, Firecracker 같은 사용자 공간 하이퍼바이저 프로세스가 디바이스 에뮬레이션을 제공합니다: 가상 디스크, NIC, USB 컨트롤러, BIOS 또는 UEFI 펌웨어. 리눅스 커널 자체가 하이퍼바이저이므로, 모든 리눅스 스케줄러, 메모리 관리자, 보안 기능이 네이티브 프로세스에 적용되는 방식 그대로 VM에도 적용됩니다. 커널 관점에서 KVM 게스트는 그저 무거운 프로세스이며, 그래서 top, perf, cgroups 같은 도구가 수정 없이 그대로 작동합니다.
KVM vs OpenVZ vs VMware ESXi vs Hyper-V
KVM은 모든 VM에 별도의 게스트 커널과 함께 완전 하드웨어 가상화를 제공합니다. OpenVZ는 모든 컨테이너가 호스트 커널을 공유하는 OS 수준 컨테이너화를 사용합니다. VMware ESXi는 자체 커널(VMkernel)을 갖춘 독점 베어메탈 Type-1 하이퍼바이저입니다. Hyper-V는 마이크로소프트의 Windows 기반 Type-1 하이퍼바이저입니다. 진정한 격리된 게스트 커널을 제공하는 것은 KVM, ESXi, Hyper-V뿐입니다.
OpenVZ(및 그 후속인 Virtuozzo)는 하이퍼바이저가 아니라 컨테이너 기술입니다. 모든 OpenVZ 컨테이너는 호스트의 리눅스 커널을 공유하며, 이는 다른 커널 버전을 실행할 수 없고, 사용자 정의 커널 모듈을 로드할 수 없으며, 비리눅스 운영체제를 실행할 수 없다는 뜻입니다. 트레이드오프는 밀도입니다 — VM별 커널 오버헤드가 없으므로 OpenVZ 호스트는 같은 하드웨어에 더 많은 컨테이너를 욱여넣을 수 있고, 그래서 저가형 공유 VPS 요금제가 자주 채택했습니다. VMware ESXi는 Type-1 가상화의 엔터프라이즈 표준이지만 소켓당 라이선스가 적용되는 클로즈드 소스 제품으로 출시되어, 역사적으로 범용 VPS 호스팅에는 가격이 맞지 않았습니다. Hyper-V는 Windows 서버 환경을 지배하며 Active Directory와 System Center에 긴밀히 통합되지만, 리눅스 중심 호스팅 플릿에는 덜 일반적인 선택입니다. KVM은 오픈소스이고, 커널 메인라인에 포함되며, x86_64나 aarch64에서 동작하는 모든 게스트 OS를 지원하고, 성숙한 관리 생태계(libvirt, oVirt, Proxmox, OpenStack Nova)를 갖추고 있어 현대 VPS 호스팅의 기본값이 됐습니다.
왜 KVM이 현대 VPS의 기본값인가
KVM은 VMware 식 라이선스 비용 없이도 모든 고객에게 진짜로 격리된 커널을 제공하기 때문에 VPS 기술의 지배적 위치를 차지하게 됐습니다. Linux, Windows, BSD, Solaris 게스트를 지원하고, 범용 x86_64 및 ARM 하드웨어에서 실행되며, 모든 주요 클라우드 오케스트레이션 스택에 통합되어 있습니다 — OpenStack, Proxmox VE, KubeVirt를 통한 Kubernetes, AWS Nitro 모두가 KVM 위에 만들어집니다.
세 가지 힘이 모여 KVM을 표준으로 만들었습니다. 첫째, 하드웨어 가상화 확장이 보편화됐습니다: Intel VT-x는 2006년 Core 2 칩에 탑재됐고 AMD-V는 초기 Athlon 64에 탑재됐으며, 2010년대 초까지 사실상 모든 서버 CPU가 KVM을 거의 네이티브 속도로 호스팅할 수 있게 됐습니다. 둘째, 리눅스 커뮤니티는 Xen 식 파라가상화를 메인라인에 채택하지 않았지만 2007년에 KVM을 메인라인에 포함시켰고, 모든 배포판에 즉시 내장 하이퍼바이저를 제공했습니다. 셋째, 퍼블릭 클라우드 생태계가 큰 투자를 했습니다: Google Cloud Engine은 KVM에서 출시했고, AWS는 Xen에서 KVM 기반 Nitro 아키텍처로 마이그레이션했으며, OpenStack은 KVM을 레퍼런스 하이퍼바이저로 표준화했습니다. 작은 VPS 사업자들도 이 인력의 혜택을 받습니다 — 하이퍼스케일러 플릿을 운영하는 동일한 도구(libvirt, virtio 드라이버, cloud-init)가 범용 서버 한 랙에서도 작동하기 때문입니다.
실제 성능 특성: CPU 스틸, IO, 오버헤드
적절히 프로비저닝된 KVM 호스트라면 베어메탈 대비 한 자릿수 % CPU 오버헤드, 로컬 네트워크 경로에 추가되는 1ms 미만의 네트워크 지연, 그리고 virtio-blk 또는 virtio-scsi가 파라가상화 드라이버와 함께 사용될 때 네이티브 디스크 IOPS의 80-95%를 기대할 수 있습니다. 5%를 지속적으로 넘는 CPU 스틸 시간은 호스트 오버커밋의 전형적 신호이며 강력한 업그레이드 시그널입니다.
프로덕션의 KVM 게스트에서는 세 가지 수치가 중요합니다. CPU 스틸 시간은 /proc/stat의 8번째 필드로 노출되며, 가상 CPU가 실행 준비됐지만 물리 CPU가 다른 게스트를 실행하느라 바빴던 시간 비율을 측정합니다. 1-2% 미만은 일반적인 배경 노이즈이며, 5%를 지속적으로 넘으면 호스트가 오버커밋되어 워크로드가 스로틀링되고 있다는 의미입니다. iostat이나 top 같은 도구로 노출되는 IO 대기는 CPU가 디스크나 네트워크에서 블록된 시간의 비율을 측정합니다. virtio 파라가상화 드라이버와 최신 NVMe 백킹 스토리지에서 CPU 바운드여야 할 워크로드의 IO 대기가 20%를 지속적으로 넘으면 디스크 서브시스템이 포화 상태라는 강력한 신호입니다. virtio-net의 네트워크 처리량은 물리 NIC 라인 레이트의 80-95%에 도달해야 하며, 그보다 의미 있게 낮다면 잘못 구성된 오프로드나 구식 에뮬레이션 e1000 드라이버가 원인일 가능성이 높습니다.
KVM을 사용하지 말아야 할 때
KVM은 세 가지 상황에서 잘못된 선택입니다: VM당 커널 오버헤드가 지배적인 초고밀도 컨테이너 워크로드, Hyper-V의 SPLA 가격이 의미 있게 저렴한 Windows 라이선스 민감 배포, 그리고 SR-IOV나 GPU 패스스루가 특정 NIC나 GPU 모델에서 잘 지원되지 않는 일부 저지연 하드웨어 패스스루 시나리오입니다.
커널 격리가 필요 없는 컨테이너화된 마이크로서비스라면, 베어메탈에서 직접 실행되는 리눅스 컨테이너(Docker, Podman, Kubernetes)가 KVM 기반 VPS보다 3-5배 더 많이 들어갑니다 — 각 컨테이너는 네임스페이스와 cgroups를 갖춘 프로세스 그룹일 뿐이기 때문입니다. 밀도에 민감한 저비용 VPS 사업자들이 역사적으로 OpenVZ를 선택한 이유도 같습니다. Windows 중심 배포 — 특히 SPLA로 구입한 Windows Server 라이선스를 운영하는 경우 — 는 마이크로소프트가 경쟁 하이퍼바이저의 게스트 라이선스 가격을 책정하는 방식 때문에 Hyper-V에서 KVM보다 의미 있게 적은 비용을 지불하기도 합니다. 마지막으로 일부 하드웨어 패스스루 시나리오는 KVM에서 여전히 까다롭습니다: GPU 패스스루는 IOMMU 그룹이 깔끔하게 격리되어야 하고, 일부 컨슈머 NIC은 SR-IOV를 지원하지 않으며, NVMe 드라이브의 PCIe 패스스루는 때때로 리셋 버그 우회 처리를 요구합니다. 범용 리눅스 VPS 워크로드의 95%에는 이 중 어떤 것도 해당되지 않으며, KVM이 올바른 기본값입니다.
VPS가 정말 KVM 기반인지 확인하는 법
리눅스 게스트 안에서 `systemd-detect-virt`를 실행하세요 — `kvm`이 출력되어야 합니다. `lscpu`(Hypervisor vendor 줄에 'KVM'이 표시되어야 함)와 `dmesg | grep -i kvm`으로 교차 확인하세요. 'OpenVZ', 'lxc', 'VMware'가 보인다면 마케팅 문구와 달리 사업자가 다른 기술을 사용하고 있는 것입니다.
계약을 체결하기 전 평가용 VPS에서 작은 진단 배터리를 실행하세요. `systemd-detect-virt`로 표준 감지 출력을 확인하세요. `cat /proc/cpuinfo | grep -E 'vmx|svm'`으로 하드웨어 가상화 확장이 패스스루되는지 확인하세요(일부 사업자는 이를 제거해 중첩 가상화를 깨뜨립니다). `uname -r`로 공유 호스트 커널이 아니라 게스트 전용 커널이 보이는지 확인하세요 — 진짜 KVM VPS에서는 `apt install linux-image-...`나 `dnf install kernel-...`로 다른 커널을 설치하고 그것으로 재부팅할 수 있습니다. OpenVZ에서는 불가능합니다. 마지막으로 `/proc/user_beancounters`를 확인하세요 — 이 파일이 존재하면 마케팅 문구와 무관하게 호스트가 OpenVZ를 운영하고 있는 것입니다.