클라우드 VM을 신청하면 몇 분 만에 서버 한 대가 뚝딱 생깁니다. 그런데 데이터센터에서 물리 서버를 새로 사서 꽂아준 건 당연히 아니죠. 이미 돌아가고 있는 서버 한 대를 쪼개서 그중 일부를 떼어준 겁니다. 이걸 가능하게 하는 게 가상화이고, 그 한가운데 하이퍼바이저라는 소프트웨어가 있어요.
하이퍼바이저가 하는 일
하이퍼바이저는 물리 서버의 CPU, 메모리, 디스크, 네트워크를 잘라서 여러 개의 가상 머신에 나눠주는 역할을 합니다. 각 가상 머신은 자기가 서버 한 대를 통째로 쓰고 있다고 믿어요. 옆방에 다른 가상 머신이 돌아가고 있다는 것도 모르고, 서로의 메모리를 들여다볼 수도 없습니다. 이 격리가 가상화의 핵심입니다.
하이퍼바이저는 크게 두 종류로 나뉩니다. 타입 1은 하드웨어 위에서 바로 돌아가는 방식이에요. 중간에 운영체제가 끼지 않으니 오버헤드가 적고 자원을 효율적으로 씁니다. 서버와 데이터센터에서 쓰는 게 이쪽입니다. 타입 2는 윈도우나 맥에 프로그램 하나 설치하듯 운영체제 위에서 돌아갑니다. 설치가 간편하고 게스트 OS 제약이 적지만, 호스트 OS를 한 번 거치니 성능 손해가 있어요. 개발이나 테스트, 학습용으로 적합합니다.
KVM은 어느 쪽일까
리눅스 기반 클라우드에서 가장 널리 쓰이는 KVM은 이 분류에 딱 들어맞지 않아서 종종 헷갈립니다. 이름부터 Kernel-based Virtual Machine, 즉 커널 기반 가상 머신이에요. 리눅스 커널에 모듈로 올라가서 커널 자체를 하이퍼바이저로 만들어버립니다.
리눅스라는 운영체제가 있어야 돌아가니 타입 2처럼 보이지만, 실제로는 커널이 CPU의 하드웨어 가상화 기능을 직접 쓰기 때문에 성능은 타입 1에 가깝습니다. 그래서 타입 1.5로 부르기도 해요. CPU와 메모리 작업에서 거의 물리 서버에 근접한 성능이 나오는 이유가 여기 있습니다.
KVM 옆에는 보통 QEMU가 따라옵니다. KVM이 CPU와 메모리 가상화를 맡고, QEMU가 디스크나 네트워크 카드 같은 주변 장치를 흉내 내는 역할을 나눠 맡아요. 둘이 한 몸처럼 움직이기 때문에 KVM 기반이라고 하면 사실상 KVM과 QEMU 조합을 뜻합니다.
가상 장치도 드라이버가 중요해요
QEMU가 주변 장치를 만들어준다고 해서 모든 VM이 같은 방식으로 디스크와 네트워크를 쓰는 건 아니에요. 실제 하드웨어처럼 보이는 장치를 흉내 내는 방식도 있고, 가상 환경에 맞춘 장치와 드라이버가 협력하는 방식도 있어요. KVM에서 자주 만나는 virtio는 후자에 해당합니다. 이런 방식을 반가상화라고 부르는데, 여기서는 운영체제 전체를 바꾸는 대신 입출력 장치에 맞는 드라이버를 쓰는 것으로 이해하면 돼요.
virtio 드라이버는 가상 환경이라는 점을 활용해 입출력 지연을 줄이고 처리량을 높여줍니다. CPU 계산 성능과 별개로, 디스크를 자주 읽고 쓰거나 네트워크 통신이 많은 작업에서 중요한 이유예요. 사양을 올렸는데도 기대만큼 빨라지지 않는다면 가상 장치와 게스트 안의 드라이버 구성을 함께 확인할 만해요. 저장 장치와 네트워크 장치에 각각 어떤 드라이버가 연결돼 있는지도 점검 항목에 넣어두세요.
특히 윈도우를 직접 설치할 때는 이 차이가 눈에 보입니다. virtio 저장 장치를 사용하는 VM에서는 설치 과정에 해당 드라이버를 별도로 제공해야 할 수 있어요. 설치 화면에서 디스크가 보이지 않는다면 드라이버가 준비됐는지 확인해보세요. 호스팅 업체가 제공한 윈도우 이미지라면 virtio 드라이버의 포함 여부와 업데이트 방법을 물어두는 게 좋습니다.
실행 중인 VM도 이사할 수 있어요
가상화의 장점은 한 서버를 나누는 데서 끝나지 않아요. 실행 중인 VM을 다른 물리 서버로 옮기는 라이브 마이그레이션도 가능합니다. 일반적인 사전 복사 방식은 VM을 돌려둔 채 메모리 내용을 목적지로 보내고, 복사 중 바뀐 부분을 다시 전달해요. 마지막에는 잠깐 실행을 멈춰 남은 상태를 넘긴 뒤 새 서버에서 이어서 실행합니다.
이 기능은 물리 서버를 점검할 때 유용해요. VM을 먼저 다른 호스트로 옮겨두면 원래 서버를 정비할 수 있죠. 다만 KVM을 쓴다는 사실만으로 어느 서버에나 바로 옮길 수 있는 건 아닙니다. 두 호스트의 CPU 기능과 가상 장치 구성이 호환돼야 하고, 목적지에서도 디스크 데이터에 접근할 수 있어야 해요. 공유 스토리지가 없다면 디스크를 함께 복사하는 구성도 필요합니다.
이용자라면 정기 점검 때 VM을 이전하는지, 재부팅이 필요한지, 전환 중 중단을 어느 정도 예상하는지 확인해두세요. 메모리를 빠르게 바꾸는 작업은 복사가 따라잡기 어려워 이전 시간이 길어질 수 있어요. 따라서 라이브 마이그레이션이라는 이름을 중단 시간이 항상 없다는 보장으로 받아들이기보다, 내 서비스의 작업 특성과 업체의 점검 정책을 함께 확인하는 게 좋습니다.
가상 머신과 컨테이너는 다릅니다
요즘은 도커 같은 컨테이너 얘기도 자주 나오죠. 둘 다 하나의 서버를 나눠 쓴다는 점은 같지만 나누는 층이 다릅니다. 가상 머신은 운영체제를 통째로 하나씩 더 띄우고, 컨테이너는 호스트의 커널을 공유하면서 프로세스 수준으로만 격리해요.
그래서 컨테이너는 가볍고 뜨는 속도가 빠른 대신 격리 수준이 낮습니다. 커널을 공유하니 커널에 문제가 생기면 전부 영향을 받아요. 반대로 가상 머신은 무겁지만 격리가 확실합니다. 다른 고객과 인프라를 공유하는 환경에서 보안이 중요하다면 여전히 가상 머신이 안전한 선택이에요. 운영체제를 자유롭게 고르고, 커널 파라미터까지 직접 손대야 하는 작업도 가상 머신이라야 가능합니다.
VM을 고를 때 볼 것
사양표의 vCPU 숫자만 보면 놓치는 게 있습니다. 같은 4 vCPU라도 물리 코어를 몇 개의 가상 머신이 나눠 쓰는지에 따라 체감 성능이 크게 갈려요. 한 물리 서버에 가상 머신을 빽빽하게 몰아넣으면 이웃이 CPU를 많이 쓸 때 내 서버가 느려지는 일이 생깁니다.
디스크도 마찬가지입니다. NVMe인지 일반 SSD인지에 따라 데이터베이스 응답 속도가 눈에 띄게 달라져요. 그리고 의외로 많이 놓치는 게 스냅샷과 백업의 차이입니다. 스냅샷은 같은 스토리지 안에 특정 시점을 표시해두는 것이라, 스토리지 자체에 문제가 생기면 스냅샷도 함께 사라집니다. 별도 저장소에 남기는 백업이 따로 있어야 해요.
TIDC는 국내 데이터센터에서 KVM 기반 클라우드 VM을 직접 운영하고 있습니다. 어떤 사양이 맞을지 판단이 어려우시면 현재 트래픽과 용도를 알려주세요. 과하지도 부족하지도 않은 구성으로 함께 잡아드리겠습니다.
