.svg)
%201.svg)
%201.svg){kind=icon}
담당자가 프로모션 코드를 발송해 드립니다.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
와탭을 경험해 보세요.
WhaTap AI를 경험해 보세요.
하이퍼바이저란? 뜻과 종류, Type 1과 Type 2 차이
물리 서버 한 대를 여러 대의 컴퓨터처럼 사용할 수 있습니다. 예를 들어 서버 한 대 안에 리눅스를 쓰는 컴퓨터와 윈도우를 쓰는 컴퓨터를 각각 만들 수 있습니다. 물리 서버 안에 소프트웨어로 구현한 컴퓨터를 가상 머신이라고 합니다.
하이퍼바이저(hypervisor)는 물리 서버의 CPU와 메모리, 스토리지를 여러 가상 머신에 나눠 주는 소프트웨어입니다. 각 가상 머신은 할당받은 자원으로 운영체제와 프로그램을 실행합니다.
여러 가상 머신이 동시에 많은 작업을 처리하면 물리 서버의 자원이 부족해질 수 있습니다. 이때 가상 머신은 CPU를 사용할 차례를 기다리느라 느려지기도 합니다. 가상 머신의 성능 문제를 파악하려면 가상 머신 내부 상태와 함께 하이퍼바이저와 물리 서버의 상태도 확인합니다.
이 글에서는 하이퍼바이저의 두 가지 종류와 가상 머신과 컨테이너의 차이를 정리하고, 하이퍼바이저가 자원을 나눌 때 생기는 경합을 보여 주는 지표를 소개합니다.
하이퍼바이저란? 호스트, 게스트, 가상 머신 뜻
가상화 문서를 읽으면 가상 머신, 호스트, 게스트, 가상 CPU라는 말이 계속 나옵니다. 네 용어의 뜻은 다음과 같습니다.
- 가상 머신(virtual machine, VM): 하이퍼바이저가 나눠 준 CPU와 메모리, 디스크로 만든 가상의 컴퓨터입니다. 쿠버네티스 공식 문서는 가상 머신을 가상화한 하드웨어 위에서 자기 운영체제까지 모든 구성 요소를 실행하는 완전한 컴퓨터라고 설명합니다.
- 호스트(host): 가상 머신을 실제로 실행하는 물리 컴퓨터입니다. 호스트 머신, 호스트 서버라고도 부릅니다. 이 글에서 "호스트에서 확인한다"는 말은 물리 서버와 그 위의 하이퍼바이저 쪽에서 확인한다는 뜻입니다. Type 2 하이퍼바이저에서는 하이퍼바이저를 설치한 운영체제를 호스트 운영체제라고 부릅니다.
- 게스트(guest): 가상 머신 안에서 실행되는 운영체제입니다. 게스트 운영체제라고도 부릅니다.
- 가상 CPU(vCPU): 하이퍼바이저가 가상 머신에 나눠 준 CPU입니다. 게스트 운영체제에는 가상 CPU가 실제 CPU와 똑같이 보이지만, 실제 연산은 호스트의 물리 CPU 코어에서 이뤄집니다.
하이퍼바이저가 하는 일
게스트 운영체제는 물리 서버 한 대를 혼자 쓸 때와 같은 방식으로 동작합니다. 하이퍼바이저는 게스트가 그렇게 동작할 수 있도록 가운데에서 다음 일을 맡습니다.
- CPU 스케줄링: 가상 CPU를 물리 CPU 코어에 번갈아 올려 실행합니다. 운영체제가 여러 프로그램에 CPU 시간을 나눠 주듯, 하이퍼바이저는 여러 가상 머신의 가상 CPU에 물리 코어의 시간을 나눠 줍니다.
- 메모리 관리: 게스트 운영체제에는 자기 메모리가 0번지부터 이어진 하나의 공간으로 보입니다. 하이퍼바이저는 게스트 메모리를 호스트의 실제 메모리 어딘가에 연결해 두고, 가상 머신끼리 서로의 메모리에 접근하지 못하게 막습니다.
- 입출력(I/O) 처리: 하이퍼바이저는 가상 머신에 가상 디스크와 가상 네트워크 카드 같은 장치를 만들어 줍니다. 가상 디스크는 보통 호스트 스토리지에 있는 파일로, VMware는 VMDK, KVM은 qcow2, Hyper-V는 VHDX 형식을 씁니다. 게스트가 디스크에 쓰는 데이터는 하이퍼바이저를 거쳐 이 파일에 기록됩니다.
- 격리: 가상 머신은 서로 분리돼 있어서, 한 가상 머신의 운영체제가 멈추거나 재부팅돼도 같은 호스트의 다른 가상 머신은 계속 동작합니다.
하이퍼바이저 종류, Type 1과 Type 2 차이
하이퍼바이저는 하드웨어를 직접 다루느냐, 운영체제를 거쳐 하드웨어를 쓰느냐에 따라 두 가지 타입으로 나뉩니다. 설치 위치로 보면 물리 하드웨어 위에 바로 설치하는 쪽이 Type 1, 이미 설치된 운영체제 위에 프로그램처럼 설치하는 쪽이 Type 2입니다. IBM은 Type 1을 물리 하드웨어에서 곧바로 실행되며 CPU와 메모리, 스토리지를 직접 다루는 하이퍼바이저로, Type 2를 운영체제 안에서 애플리케이션으로 실행되는 하이퍼바이저로 설명합니다.
Red Hat에 따르면 Type 1은 베어메탈(bare-metal) 또는 네이티브 하이퍼바이저라고도 부르고, Type 2는 호스트형(hosted) 하이퍼바이저라고도 부릅니다. 두 종류의 차이를 표로 정리하면 다음과 같습니다.
VirtualBox 설명서는 VirtualBox를 호스트형 하이퍼바이저, 곧 Type 2 하이퍼바이저로 소개합니다. 같은 설명서에 따르면 VirtualBox는 하드웨어에서 직접 실행되는 Type 1과 달리 먼저 설치된 운영체제가 있어야 합니다. 노트북에 리눅스 가상 머신을 띄워 실습하는 경우가 Type 2의 대표적인 쓰임새입니다.
Type 1 제품의 공식 문서는 각 제품을 다음과 같이 소개합니다.
- VMware ESXi: Broadcom 설치 가이드는 ESXi를 물리 하드웨어에 설치해 가상 머신을 실행하는 플랫폼으로 쓴다고 안내합니다. 여러 ESXi 호스트는 vCenter라는 관리 서버로 모아서 관리합니다.
- Microsoft Hyper-V: 마이크로소프트 문서는 Hyper-V를 컴퓨팅 하드웨어에서 직접 실행되는 Type 1 하이퍼바이저로 소개합니다. Windows Server와 Windows 11 Pro 이상 에디션에 들어 있고, 게스트로 윈도우와 리눅스, FreeBSD를 지원합니다. 윈도우에서 기능을 켜는 방식이라 Type 2처럼 보이지만, Hyper-V 아키텍처 문서에 따르면 Hyper-V를 켜면 하이퍼바이저가 하드웨어 위에서 직접 실행되고 윈도우는 그 위의 관리용 파티션(root partition)에서 동작합니다.
- Xen: Xen Project는 Xen을 오픈소스 Type 1 하이퍼바이저로 설명합니다. 대부분의 설치 환경에서는 다른 가상 머신을 관리하는 권한을 가진 가상 머신(domain 0)으로 리눅스를 함께 실행한다고 합니다.
KVM은 Type 1인가 Type 2인가
KVM(Kernel-based Virtual Machine)은 자료마다 분류가 달라 헷갈리기 쉬운 하이퍼바이저입니다. 이 글은 위 표처럼 Red Hat과 IBM의 분류를 따라 KVM을 Type 1로 봅니다.
KVM을 Type 2로 분류하는 자료가 있는 이유는 KVM이 리눅스 커널의 일부로 동작하기 때문입니다. 커널은 운영체제의 핵심으로, CPU와 메모리 같은 하드웨어를 관리하고 프로그램에 나눠 주는 부분입니다. KVM 프로젝트 설명에 따르면 KVM은 리눅스 커널에 올리는 모듈(kvm.ko)로 동작하고, 리눅스 커널 2.6.20부터 커널 본체에 포함돼 있습니다. 그래서 KVM이 리눅스라는 운영체제 위에서 돌아가는 프로그램처럼 보이기도 합니다.
반면 Red Hat은 KVM을 Hyper-V, vSphere와 함께 Type 1 하이퍼바이저의 예로 들고, IBM도 KVM을 리눅스 기반 Type 1 하이퍼바이저로 분류합니다. KVM 서버에서는 호스트 리눅스 커널이 하이퍼바이저 역할을 맡으므로, 호스트 리눅스의 CPU와 메모리 상태를 보면 그 위 가상 머신들이 나눠 쓰는 물리 자원의 상태를 파악할 수 있습니다.
가상 머신과 컨테이너 차이
쿠버네티스나 도커를 쓰기 시작하면 컨테이너도 격리된 작은 서버처럼 보여서, 가상 머신과 무엇이 다른지 헷갈릴 수 있습니다. 가장 큰 차이는 운영체제를 따로 두느냐입니다.
가상 머신은 하이퍼바이저가 나눠 준 가상 하드웨어 위에서 운영체제 전체를 실행합니다. 컨테이너는 운영체제를 따로 띄우지 않고, 호스트 운영체제의 핵심인 커널을 다른 컨테이너와 함께 씁니다. 대신 호스트 운영체제가 컨테이너마다 파일 시스템과 프로세스 공간을 분리해, 다른 컨테이너의 파일이나 실행 중인 프로그램이 보이지 않게 합니다. CPU와 메모리는 컨테이너마다 쓸 수 있는 양을 설정해 따로 나눠 받습니다. 쿠버네티스 공식 문서는 컨테이너를 가상 머신과 비슷하지만 격리 수준을 낮춰 운영체제를 공유하기 때문에 가볍다고 설명합니다.
가상 머신과 컨테이너는 함께 쓰기도 합니다. AWS에서 EC2 인스턴스를 쿠버네티스 노드로 쓰면, 컨테이너는 가상 머신 안에서 실행되고 그 가상 머신은 다시 하이퍼바이저 위에서 실행됩니다. 물리 서버, 하이퍼바이저, 가상 머신(EC2), 컨테이너 순으로 여러 층이 겹치는 구성입니다.
가상 머신 위에서 컨테이너를 실행하는 구성에서 컨테이너가 느려지면 적어도 세 층을 나눠 확인합니다. 확인할 곳은 컨테이너에 건 CPU 제한, 노드 가상 머신의 CPU와 메모리, 그 아래 하이퍼바이저에서 생긴 대기입니다. 컨테이너 CPU 제한 때문에 생기는 지연은 리눅스 CPU 사용률이 높은 이유와 확인 방법에서 다뤘습니다.
하이퍼바이저 모니터링, 자원 경합과 오버커밋을 보여 주는 지표
가상 머신은 물리 자원을 혼자 쓰지 않습니다. 다른 가상 머신과 CPU, 메모리, 스토리지를 나눠 쓰기 때문에, 가상 머신 안의 CPU와 메모리 사용률에는 잘 드러나지 않는 대기가 생길 수 있습니다.
하이퍼바이저는 실제 자원보다 많이 나눠 주기도 합니다. 물리 CPU 코어 수보다 가상 CPU를 더 많이 나눠 주면, 가상 CPU들은 물리 코어를 번갈아 씁니다. 메모리도 실제보다 많이 나눠 줄 수 있습니다. 가상 머신은 설정받은 메모리를 항상 전부 쓰지는 않으므로, 여러 가상 머신에 설정한 메모리의 합이 호스트의 물리 메모리보다 크도록 구성할 수 있습니다. 다만 VMware vSphere 문서는 설정한 메모리의 합이 물리 메모리를 넘는 것만으로는 메모리 오버커밋(memory overcommitment)이 아니라고 설명합니다. 가상 머신들이 실제로 쓰는 메모리의 합이 호스트 메모리를 넘을 때 메모리 오버커밋입니다.
실제 자원보다 많이 나눠 주는 운영은 장비를 알뜰하게 쓰는 방법입니다. 대신 여러 가상 머신의 부하가 한꺼번에 몰리면 서로 기다리는 시간이 생깁니다.
가상 머신이 느려졌는데 게스트 안의 CPU와 메모리 사용률에 여유가 있다면, 원인이 하이퍼바이저 쪽에 있는지 확인합니다. 게스트의 CPU 사용률만 보면 가상 CPU가 물리 CPU 차례를 기다린 시간을 놓칠 수 있습니다. 리눅스 게스트에서는 가상 CPU가 기다린 시간을 steal time으로 따로 확인할 수 있고, 하이퍼바이저에서는 CPU Ready 같은 지표로 확인합니다.
CPU Ready와 steal time은 모두 가상 CPU가 물리 CPU를 바로 쓰지 못한 상황을 파악하는 데 도움이 되는 지표입니다. 가상 CPU들은 물리 코어를 번갈아 쓰므로, 가상 CPU가 실행 준비를 마쳐도 물리 코어가 다른 가상 머신의 가상 CPU를 처리하고 있으면 차례를 기다려야 합니다. 가상 CPU가 차례를 기다린 시간을 하이퍼바이저는 CPU Ready로, 게스트 리눅스는 steal time으로 집계합니다. 두 지표는 집계하는 계층과 계산 방식이 달라 숫자가 일대일로 대응하지는 않습니다.
CPU Ready 숫자는 집계 방식을 알고 읽어야 합니다. Broadcom 문서에 따르면 vSphere Client 성능 차트의 CPU Ready는 수집 간격 동안 쌓인 밀리초 값이고, 가상 머신의 모든 가상 CPU를 합한 값입니다. 가상 CPU 수로 나누면 대략적인 가상 CPU당 값이 되고, 정확히는 가상 CPU별 값을 봅니다. 응답 시간이 늘어난 시각에 CPU Ready도 함께 늘었다면 물리 CPU 경합을 의심합니다.
게스트 리눅스에서는 top 출력의 st 항목이나 /proc/stat의 steal 값으로 비슷한 대기를 봅니다. 리눅스 man 페이지는 steal을 가상화 환경에서 다른 운영체제가 사용한 시간으로 정의하고, KVM 문서는 가상 CPU가 실행되지 못한 시간이며 가상 CPU가 쉬고 있던 시간은 포함하지 않는다고 설명합니다. steal 값은 하이퍼바이저가 대기 시간을 게스트에 알려 주는 기능을 지원할 때만 채워지므로, 환경에 따라서는 0으로만 나오기도 합니다. steal time을 읽는 방법은 CPU Steal Time이란? 클라우드 서버 지연 원인과 해결 방법에서 자세히 정리했습니다.
메모리 벌루닝(memory ballooning)은 호스트에 메모리 압박이 생겼을 때 하이퍼바이저가 게스트에서 메모리를 돌려받는 방법입니다. ESXi에서는 게스트 안의 벌룬 드라이버(vmmemctl)가 메모리를 차지하면, 게스트 운영체제가 덜 중요한 페이지를 스스로 골라 내놓고 필요하면 자기 가상 디스크로 스왑합니다. 페이지는 운영체제가 메모리를 나눠 관리하는 단위이고, 스왑은 메모리에 있던 데이터를 디스크로 옮겨 두는 동작입니다. 디스크는 메모리보다 느리므로 스왑이 늘면 그 데이터를 쓰는 프로그램도 느려집니다.
VMware 문서에 따르면 ESXi는 벌루닝 외에도 메모리 공유와 압축, 스와핑을 함께 씁니다. KVM 쪽에도 virtio balloon이라는 벌룬 드라이버가 있고, Hyper-V는 동적 메모리(Dynamic Memory)로 가상 머신 메모리를 실제 부하에 맞춰 늘리고 줄입니다.
벌루닝이 일어나면 게스트 운영체제의 일반 지표에서는 주로 프로그램이 쓸 수 있는 메모리가 줄거나 스왑이 늘어난 모습으로 나타납니다. 게스트 안에서 메모리 부족이 반복되면 같은 시각 호스트의 메모리 사용률과 벌루닝 값을 함께 확인합니다.
데이터스토어 지연은 가상 머신의 입출력 요청이 데이터스토어(datastore)에서 응답받기까지 걸린 시간입니다. 데이터스토어는 VMware 환경에서 가상 디스크 파일을 저장하는 스토리지입니다. 게스트 안에서는 디스크가 느려진 모습만 보이므로, 스토리지 쪽 대기는 호스트에서 확인합니다.
CPU Ready나 데이터스토어 지연처럼 하이퍼바이저가 집계하는 값은 가상 머신 안의 일반적인 운영체제 모니터링만으로 확인하기 어렵습니다. 반면 리눅스의 steal time은 게스트 안에서 확인할 수 있고, 벌루닝 양처럼 가상화 도구를 설치하면 게스트에서 조회할 수 있는 값도 있습니다. 여러 가상 머신이 함께 쓰는 호스트 전체의 상태는 vSphere 환경이라면 vSphere API 같은 관리 인터페이스로 따로 수집합니다. VMware 환경에서 증상별로 어떤 호스트 지표를 먼저 볼지, 디스크 지연을 어느 스토리지 경로에서 좁혀 볼지는 VMware 모니터링이란? VM이 느릴 때 확인해야 할 호스트 지표에서 정리했습니다.
마치며
하이퍼바이저는 물리 서버의 CPU와 메모리, 스토리지를 가상 머신에 나눠 주는 소프트웨어입니다. 하드웨어 위에 바로 설치하는 Type 1과 운영체제 위에 설치하는 Type 2로 나뉩니다. KVM처럼 자료마다 분류가 다른 제품도 있지만, 어느 쪽으로 분류하든 운영할 때 호스트와 게스트를 나눠 본다는 점은 같습니다. 가상 머신이 느릴 때는 게스트 사용률과 steal time, 하이퍼바이저가 집계하는 CPU Ready와 메모리 벌루닝, 데이터스토어 지연을 같은 시각끼리 비교합니다.
와탭 서버 모니터링은 VMware vCenter나 ESXi 호스트를 연동해 호스트 지표와 호스트에서 본 가상 머신 지표를 수집합니다. 어떤 값을 모으는지는 VMware 수집 항목 문서에서 확인해 보세요.
자주 묻는 질문
가상화와 하이퍼바이저는 같은 말인가요
가상화는 물리 자원 하나를 여러 개처럼 나눠 쓰는 기술 전반을 가리키고, 하이퍼바이저는 그중 서버 가상화를 실제로 수행하는 소프트웨어입니다. 쿠버네티스 문서도 가상화를 물리 서버 한 대의 CPU에서 여러 가상 머신을 실행하게 해 주는 기술로 소개합니다. 가상화라는 말은 스토리지나 네트워크를 나눠 쓰는 기술에도 쓰이므로, 서버를 두고 가상화라고 할 때는 하이퍼바이저 위에서 가상 머신을 실행하는 방식을 가리키는지 문맥으로 확인합니다.
클라우드 서버에도 하이퍼바이저가 있나요
있습니다. AWS 문서에 따르면 EC2의 Nitro 시스템에는 메모리와 CPU 할당을 관리하는 가벼운 하이퍼바이저가 들어 있습니다. 반대로 베어메탈 인스턴스는 가상화 없이 호스트 하드웨어 전체를 쓰는 유형입니다. 클라우드 사용자는 하이퍼바이저의 CPU Ready 같은 값을 직접 볼 수 없으므로, 일반 인스턴스에서는 게스트 안의 steal time이 CPU 경합을 짐작하는 단서가 됩니다. steal time이 늘 0이라면 경합이 없는 것인지, 인스턴스가 steal 값을 제공하지 않는 것인지 먼저 구분합니다.
가상 머신 안에서 하이퍼바이저를 또 실행할 수 있나요
하이퍼바이저가 지원하면 가능하고, 이 방식을 중첩 가상화(nested virtualization)라고 부릅니다. 마이크로소프트 문서는 Hyper-V의 중첩 가상화를 개발 환경이나 여러 고객을 한 인프라에 수용하는 클라우드 환경에서 쓴다고 소개합니다. AWS 문서에 따르면 AWS는 일부 Intel 기반 인스턴스 유형에서 KVM과 Hyper-V를 인스턴스 안의 하이퍼바이저로 쓰는 중첩 가상화를 지원하고, 성능에 민감한 작업에는 베어메탈 인스턴스를 검토하라고 권합니다. 쓰려는 하이퍼바이저와 인스턴스 유형의 문서에서 지원 여부를 먼저 확인합니다.
더 읽을거리
