Compute Platforms - 05. VM 라이프사이클

실행 중인 서버를 중단 없이 옮기는 마술 — VM 라이프사이클과 자원 관리

2003년, VMware는 vMotion이라는 기능을 발표했다. 실행 중인 가상 머신을 중단하지 않고 다른 물리 서버로 옮기는 기술이었다. 데모에서 웹 서버가 트래픽을 처리하며 응답하는 동안, 그 서버가 통째로 다른 랙의 다른 물리 서버로 옮겨갔다 — 사용자는 아무런 중단도 느끼지 못했다. 당시 이건 마술처럼 보였다. 20년이 지난 2026년에도 라이브 마이그레이션은 인프라 엔지니어가 감탄하는 기술이지만, 원리를 이해하면 마술이 아니라 정교한 엔지니어링이라는 게 보인다.

이 글은 가상 머신(VM)의 일생을 다룬다 — 어떻게 만들어지고, 어떻게 CPU와 메모리를 나눠 쓰고, 어떻게 복사되고, 어떻게 다른 서버로 옮겨지고, 어떻게 삭제되는지. 이전 글에서 하이퍼바이저가 무엇인지, KVM과 QEMU가 어떻게 협력하는지를 봤다. 여기서는 그 하이퍼바이저 위에서 도는 VM 자체를 관리하는 방법을 본다. 특히 — 물리 코어 32개인 서버에 VM 50개를 돌리면 그 32개 코어를 어떻게 50개에 나눠주는가(vCPU 오버커밋), 메모리 256GB를 50개 VM에 어떻게 나눠주는가(메모리 오버커밋), 그리고 실행 중인 VM을 어떻게 멈추지 않고 옮기는가(라이브 마이그레이션)를 파헤친다.

VM의 일생 — 여섯 단계

VM은 만들어지고(provisioning), 실행되고(running), 때때로 스냅샷을 찍고(snapshotted), 다른 호스트로 옮겨지고(migrated), 그리고 삭제된다(decommissioned). 이 전체 흐름을 "VM 라이프사이클"이라 부른다.

flowchart LR
    CREATE["1. 생성<br/>(템플릿/이미지)"] --> RUN["2. 실행<br/>(CPU·메모리 할당)"]
    RUN --> SNAP["3. 스냅샷<br/>(시점 저장)"]
    RUN --> MIGRATE["4. 마이그레이션<br/>(다른 호스트로)"]
    SNAP --> CLONE["5. 클론<br/>(복사)"]
    RUN --> DELETE["6. 삭제<br/>(자원 회수)"]

각 단계는 하이퍼바이저가 관리한다. VMware vSphere의 vCenter, KVM의 libvirt, 클라우드의 관리 API(AWS EC2·GCP Compute Engine)가 이 단계들을 추상화해서 사용자에게 버튼으로 제공한다. 사용자는 "인스턴스 만들기" 버튼을 누르지만 — 그 뒤에서는 여섯 단계의 정교한 과정이 자동으로 일어난다.

vCPU와 CPU 스케줄링 — 물리 코어를 나눠 쓰는 법

VM에게 할당하는 가상 CPU를 vCPU(virtual CPU)라 부른다. 물리 코어 32개인 서버에 VM 50개를 돌린다고 할 때, 각 VM에 vCPU 2개씩 할당하면 — 총 vCPU 100개가 필요하다. 물리 코어는 32개뿐인데 어떻게 100개를 지원하나? 핵심은 — 물리 코어를 시간으로 나눠 쓰는 것(time-sharing)이다.

이 원리는 OS의 프로세스 스케줄링과 같다. OS가 한 코어에서 100개의 프로세스를 "동시에" 돌리듯(사실은 밀리초 단위로 빠르게 전환), 하이퍼바이저는 한 물리 코어에서 여러 vCPU를 번갈가며 실행한다. 각 vCPU는 밀리초 단위의 슬라이스를 받아 실행되고, 다음 vCPU에게 코어를 넘긴다. VM 입장에서는 "내가 CPU를 쓰고 있다"고 느끼지만, 실제로는 수십 개의 vCPU가 한 코어를 돌려 쓰는 것이다.

비유하자면 — 회사에 책상이 32개 있는데 직원이 100명이다. 모두에게 전용 책상을 줄 수는 없다. 대신 책상을 시간대별로 예약제로 돌려 쓴다 — A 직원이 오전 9시 ~ 9시 5분에 책상 1번을 쓰고, B 직원이 9시 5분 ~ 9시 10분에 같은 책상을 쓴다. 전환(책상 비우기·새 직원 앉기)이 충분히 빠르면, 100명의 직원 모두 "내 책상"이 있다고 느낀다.

오버커밋(overcommit) — 위험과 효율의 경계

오버커밋이란 vCPU 총합이 물리 코어 수를 초과하는 상태다. 물리 코어 32개에 vCPU 100개를 할당하면 오버커밋 비율은 100/32 ≈ 3.1:1이다. 이게 가능한 이유는 — 모든 VM이 항상 100% CPU를 쓰지는 않기 때문이다. 웹 서버 VM은 평소 5 ~ 20% CPU만 쓰고, DB VM도 트래픽이 없을 때는 거의 쉰다. 100개 vCPU가 동시에 100%를 쓰면 물리 코어 32개로는 감당이 안 되지만(성능 폭락), 실제로는 그런 일이 드물다.

오버커밋 비율	위험도	적용 환경	설명
1:1 (오버커밋 없음)	없음	실시간 시스템, 베어메탈급 성능 필요	vCPU = 물리 코어. 가장 안전하지만 비용 최대
2:1 ~ 3:1	낮음	일반 웹 서비스, 개발/테스트	대부분의 워크로드에서 안전
4:1 ~ 6:1	중간	일반 엔터프라이즈, VDI(Virtual Desktop)	주의 깊은 모니터링 필요
8:1 ~ 10:1	높음	개발 환경, 비프로덕션	일시적 성능 저하 감수
10:1 초과	매우 높음	데모/테스트 전용	"CPU 스틸"(다른 VM의 CPU 시간을 빼앗는 현상) 빈번

오버커밋이 위험한 순간은 — 여러 VM이 동시에 CPU를 100% 쓰기 시작할 때다. 예를 들어 아침 9시에 모든 직원이 동시에 로그인하면(모든 VDI VM이 동시에 부팅), vCPU 100개가 동시에 CPU를 요구하고 물리 코어 32개로는 감당이 안 된다. 이 현상을 CPU 경합(contention)이라 부르고, 결과는 — 모든 VM이 동시에 느려진다. 한 VM이 다른 VM의 CPU 시간을 "훔치는" 것을 CPU 스틸(CPU steal, st로 표시)이라 부른다. 클라우드 EC2에서 top 명령을 쳤을 때 %st가 높으면 — 다른 VM이 내 CPU 시간을 빼앗고 있다는 뜻이다.

CPU affinity — 특정 코어에 고정하기

때로는 vCPU가 어느 물리 코어에서든 돌게 두지 않고, 특정 물리 코어에 고정해야 할 때가 있다. 이걸 CPU affinity(또는 CPU pinning)라 부른다. 이유는 세 가지다.

첫째, 캐시 지역성. vCPU가 코어 0에서 실행되다 코어 5로 옮겨가면 — 코어 0의 L1/L2 캐시에 쌓인 데이터를 못 쓰고 코어 5의 캐시를 새로 채워야 한다. 캐시 미스가 폭발한다. 고정하면 캐시가 따라온다. foundations 01에서 본 NUMA(Non-Uniform Memory Access)와 연결 — CPU가 자기 소켓의 로컬 메모리에 접근하는 게 원격 메모리보다 빠르듯, vCPU가 같은 코어(또는 같은 NUMA 노드)에 고정되면 캐시와 메모리 지역성이 유지된다.

둘째, 실시간 성능 보장. 오버커밋된 환경에서는 vCPU가 다른 vCPU 때문에 밀릴 수 있다. 반도체 제조·고빈도 거래 같은 워크로드는 "절대 밀리면 안 되는" 요구사항이 있다. CPU affinity로 전용 코어를 주면, 다른 VM이 그 코어를 못 쓰게 돼 성능이 보장된다. 대신 오버커밋의 이점(자원 공유)은 포기해야 한다.

셋째, 라이선스 제약. 일부 상용 소프트웨어(Oracle DB 같은)는 코어 수에 따라 라이선스 비용이 매겨진다. VM에 vCPU 4개를 할당하되 특정 물리 코어 4개에 고정하면 — 소프트웨어가 "이 서버는 4코어"로 인식해 라이선스 비용이 정확히 매겨진다.

KVM에서는 virsh vcpupin으로, Linux 프로세스 수준에서는 taskset으로 affinity를 설정한다.

메모리 오버커밋 — 호텔의 오버부킹

CPU 오버커밋과 같은 원리가 메모리에도 적용된다. 물리 메모리 256GB인 서버에 VM 50개를 돌린다. 각 VM에 8GB를 할당하면 — 총 400GB가 필요한데 물리 메모리는 256GB다. 어떻게 가능한가? 답은 — 모든 VM이 할당받은 메모리를 항상 100% 쓰지는 않기 때문이다. 비유하자면 호텔의 오버부킹(overbooking). 방이 256개인 호텔이 400개의 예약을 받을 수 있는 이유 — 모든 손님이 동시에 체크인하지 않기 때문이다. 대신 모든 손님이 동시에 오면(성수기) 방이 부족해진다.

메모리 오버커밋은 CPU보다 더 복잡하다 — CPU는 시간을 나눠 쓰면 되지만, 메모리는 공간을 나눠 쓰는 것이라 한 번 할당된 메모리를 빼앗기가 어렵다. 하이퍼바이저는 세 가지 기술로 이 문제를 푼다.

1. balloon driver(풍선 드라이버) — 하이퍼바이저가 게스트 OS 안에 "풍선"을 부풀려 메모리를 빼앗는 기술. 게스트 OS에는 특수 드라이버(virtio-balloon, VMware Tools의 vmmemctl)가 설치돼 있다. 다른 VM이 메모리가 부족해지면, 하이퍼바이저가 이 드라이버에게 "풍선을 부풀여라"라고 지시한다. 풍선이 부풀면(=드라이버가 게스트 OS에게 메모리를 요청하면) 게스트 OS는 자기 캐시·버퍼를 비워 그 메모리를 풍선에 준다. 하이퍼바이저는 그 확보된 메모리를 메모리가 부족한 다른 VM에게 준다. 비유하자면 — 호텔 매니저가 "잠시 안 쓰는 방 좀 비워달라"고 일부 손님에게 부탁하는 것이다.

2. KSM(Kernel Same-Page Merging) — Linux 커널의 기능(KVM에서 사용). 메모리 페이지(4KB 단위)의 내용이 똑같으면 하나로 합친다. 예를 들어 50개의 VM이 같은 OS(Ubuntu 24.04)를 돌리면 — 커널 이미지·공유 라이브러리·공통 설정 파일이 거의 똑같다. 이런 중복 페이지를 하나로 합치면 엄청난 메모리 절약이 된다. 비유하자면 — 100명의 학생이 같은 교과서를 각자 사는 대신, 한 권을 공유하는 것이다. KSM은 페이지 내용을 해시로 비교해 같은 것을 찾고, 하나를 지우고 나머지를 그쪽으로 향하게 한다(copy-on-write). 단, 페이지를 스캔하는 데 CPU 비용이 든다 — 메모리 절약과 CPU 소비의 트레이드오프.

3. swap(스왑) — 최후의 수단. 메모리가 정말 부족하면, 하이퍼바이저가 게스트의 메모리 페이지 일부를 디스크로 내보낸다(swap-out). 디스크는 메모리보다 수만 배 느리니, swap이 일어나면 VM이 극단적으로 느려진다. 클라우드에서 이걸 감지하려면 — vmstat의 si(swap-in)·so(swap-out) 컬럼을 본다. 이 값이 0이 아니면 메모리 부족 신호다.

기술	원리	장점	단점
balloon driver	게스트 안의 풍선으로 메모리 회수	게스트가 자발적으로 반환, 효율적	드라이버 설치 필요, 지연 발생
KSM	같은 내용의 페이지를 하나로 합침	대규모 동일 OS 환경에서 큰 절약	CPU 스캔 비용, 보안 우려(side-channel)
swap	메모리를 디스크로 내보냄	최후의 보루, 메모리 부족 시 즉시 적용	수만 배 느림, 사용자 경험 붕괴
오버커밋 안 함	1:1만 할당	가장 안전	비용 최대, 자원 낭비

스냅샷과 클론 — 시점 저장과 복사

VM이 실행되는 동안, 특정 시점의 상태를 저장하고 싶을 때가 있다. 업데이트 전에 "만약을 대비해 저장해 두자"든, 테스트 환경에서 "이 상태로 여러 개 복사해서 돌려보자"든. 이걸 스냅샷(snapshot) 이라 한다.

스냅샷 — 게임의 세이브 포인트

스냅샷은 VM의 특정 시점 상태를 저장하는 것이다. 저장되는 것은 세 가지 — 디스크 상태, 메모리 내용, CPU 상태(실행 중인 스냅샷인 경우). 비유하자면 게임의 세이브 포인트다 — 언제든 그 시점으로 돌아갈 수 있다.

기술적으로, 스냅샷은 copy-on-write(COW) 로 구현된다. 스냅샷을 찍는 순간, 원본 디스크는 "읽기 전용"으로 고정되고 새 변경 사항은 새로운 파일(델타 파일)에 기록된다. 스냅샷을 복구(revert)하면 — 델타 파일을 버리고 원본으로 돌아간다. 스냅샷을 삭제하면 — 델타 파일의 변경 사항을 원본에 합친다(commit). 이 과정이 디스크 I/O를 발생시키니, 스냅샷을 너무 많이 쌓으면 성능이 떨어진다.

flowchart TD
    BASE["원본 디스크<br/>(읽기 전용)"] --> SNAP1["스냅샷 1<br/>(델타)"]
    SNAP1 --> SNAP2["스냅샷 2<br/>(델타의 델타)"]
    SNAP2 --> LIVE["현재 실행 중<br/>(최신 변경)"]

스냅샷의 용도는 다양하다. 업데이트 전 백업, 장애 복구 롤백, 개발 환경의 "이 상태로 되돌리기". 다만 — 스냅샷은 백업이 아니다. 스냅샷은 같은 디스크 위에 의존하기 때문에, 원본 디스크가 고장나면 스냅샷도 같이 날아간다. 진짜 백업은 스냅샷을 다른 저장소에 복사하는 것이다. foundations 04에서 본 GitLab 사건이 이걸 보여줬다 — 다섯 백업이 있었지만 모두 같은 시스템에 의존해서, 시스템이 고장나자 전부 쓸모없어졌다.

클론 — 복사해서 새 VM 만들기

클론(clone) 은 기존 VM을 복사해 새 VM을 만드는 것이다. 두 가지 방식이 있다.

풀 클론(full clone) — 원본 VM의 디스크를 완전히 복사해 새 디스크를 만든다. 원본과 완전히 독립적이다. 용량이 두 배로 든다(원본 100GB + 클론 100GB = 200GB). 복사하는 데 시간이 걸린다. 한 번 만들면 이후에는 원본에 영향을 받지 않으니 안정적이다.

링크드 클론(linked clone) — 원본 디스크는 공유하고, 변경 사항만 새 디스크(델타)에 기록한다. 용량이 적게 든다(원본 100GB + 델타 5GB = 105GB). 만들기가 빠르다. 단점은 — 원본 디스크에 의존한다. 원본이 삭제되거나 손상되면 링크드 클론도 못 쓴다. VMware Horizon(VDI)·Docker 컨테이너 이미지(레이어 구조)가 링크드 클론의 사례다.

특성	풀 클론	링크드 클론
용량	원본과 동일 (2배)	델타만 (적게 듦)
생성 속도	느림 (전체 복사)	빠름 (변경분만)
원본 의존성	없음 (독립적)	있음 (원본이 삭제되면 사용 불가)
성능	원본과 동일	약간 느림 (추가 I/O)
전형 사례	프로덕션 VM 복제, DR	VDI, 개발/테스트 환경

라이브 마이그레이션 — 중단 없이 VM 옮기기

이 글의 도입에서 본 VMware vMotion의 기술. 실행 중인 VM을 멈추지 않고 다른 물리 서버로 옮기는 기술이다. 2003년 VMware가 상용화했고, KVM(libvirt)·Xen·Hyper-V도 같은 기능을 제공한다. 어떻게 가능한가?

라이브 마이그레이션의 핵심 원리는 사전 복사(pre-copy) 다. 비유하자면 — 이사하면서 살림을 조금씩 미리 옮기고, 마지막에 "열쇠"만 바꾸는 것이다. 구체적 단계는 이렇다.

flowchart TD
    SRC["원본 호스트<br/>(VM 실행 중)"] -->|"1단계: 메모리 페이지 복사"| DST["대상 호스트"]
    SRC -->|"2단계: 변경된 페이지 재복사<br/>(iterative pre-copy)"| DST
    SRC -->|"3단계: 마지막 순간<br/>잠시 멈춤(stop-and-copy)"| DST
    DST -->|"4단계: VM 재개"| DST2["대상 호스트에서<br/>VM 실행 재개"]
    SRC -. 5단계: 원본 정리 .-> CLEAN["원본 VM 정리"]

1. 1단계 — 메모리 전체 복사. VM의 메모리 전체(예: 8GB)를 대상 호스트로 복사하기 시작한다. 이 동안 VM은 계속 실행된다 — 사용자는 아무것도 모른다.
2. 2단계 — 변경분 재복사(iterative). 1단계에서 메모리를 복사하는 동안 VM이 계속 실행되니까, 일부 메모리 페이지가 변경된다. 변경된 페이지만 다시 복사한다. 이 과정을 반복한다 — 매번 변경분이 줄어들어서, 언젠가 변경분이 매우 작아진다.
3. 3단계 — 최종 중단(stop-and-copy). 변경분이 충분히 작아지면, VM을 아주 잠시(수 밀리초 ~ 수 초) 멈춘다. 그 사이 마지막 변경분을 복사하고, CPU 상태를 대상 호스트로 옮긴다. 이 "멈춤"이 사용자가 느끼는 유일한 중단이다 — 보통 수십 밀리초에서 수 초라, TCP 연결이 끊기지 않고 HTTP 요청이 타임아웃되지 않는다.
4. 4단계 — 대상 호스트에서 재개. VM이 대상 호스트에서 실행을 재개한다. 이제 원본 호스트의 VM은 더 이상 필요 없다.
5. 5단계 — 정리. 원본 호스트의 VM 자원(메모리·CPU)을 회수한다.

이 과정이 실패하는 경우도 있다. VM가 메모리를 너무 빠르게 변경하면(예: 메모리 집약적 워크로드) — 2단계에서 변경분이 줄어들지 않아 "무한 루프"에 빠진다. 하이퍼바이저는 이 경우를 감지해 마이그레이션을 포기하고 원본에서 계속 실행한다. 또한 — 디스크가 로컬 디스크(호스트에 직접 연결된 디스크)인 경우, 디스크도 같이 옮겨야 해서 시간이 훨씬 걸린다. 공유 저장소(SAN·NAS·분산 스토리지)를 쓰면 양쪽 호스트가 같은 디스크를 보기 때문에 디스크 이동은 필요 없고 메모리만 옮기면 된다. 클라우드 EC2 인스턴스 stop/start 시 인스턴스가 다른 물리 서버에서 뜨는 것도 이 원리의 응용 — 다만 라이브 마이그레이션이 아니라 stop 후 start(콜드 마이그레이션)다.

마이그레이션의 실제 사례

라이브 마이그레이션이 쓰이는 시나리오는 다양하다.

• 하드웨어 유지보수 — 물리 서버의 RAM을 교체하거나 펌웨어를 업데이트해야 할 때, 그 서버 위의 VM들을 다른 서버로 옮기고 유지보수 후 다시 옮긴다. 서비스 중단 없이.
• 로드 밸런싱 — 한 호스트에 VM이 몰려 CPU 사용률이 높으면, 일부 VM을 한가한 호스트로 옮겨 부하를 분산한다. VMware DRS(Distributed Resource Scheduler)가 자동으로 이 작업을 수행한다.
• 장애 예방 — 하드웨어 장애 징후(ECC 메모리 오류 증가·디스크 S.M.A.R.T. 경고)가 감지되면, VM들을 미리 다른 호스트로 옮겨 장애가 일어나기 전에 대비한다.

마이그레이션 유형	중단 시간	디스크 요구	전형 사례
라이브 마이그레이션 (공유 저장소)	수십 ms ~ 수 초	공유 저장소	vMotion, KVM live migration
라이브 마이그레이션 (로컬 디스크)	수 초 ~ 수 분	디스크도 복사	Storage vMotion, KVM + 로컬 디스크
콜드 마이그레이션 (stop → start)	VM 전체 재부팅 시간	재부팅 후 새 위치	EC2 stop/start, 유지보수
장애 복구 (HA)	VM 재시작 시간	공유 저장소 필요	vSphere HA, KVM + Pacemaker

VM 템플릿 — golden image에서 양산

VM을 한 대씩 처음부터 만들면 시간이 오래 걸린다. OS 설치, 패키지 설치, 설정, 보안 패치 — 한 대당 30분 이상. 이걸 100대에 하면 며칠이 걸린다. 해결책은 템플릿(template) 이다. 미리 OS·패키지·설정이 다 된 VM 이미지(golden image)를 만들어 두고, 그것에서 새 VM을 복제(clone)하는 것이다.

템플릿에서 VM을 만드는 과정은 — 주로 링크드 클론 또는 풀 클론이다. VMware의 "템플릿에서 배포(Deploy from Template)"는 풀 클론이 기본이고, VDI 환경에서는 링크드 클론으로 용량을 절약한다. 클라우드의 AMI(Amazon Machine Image)·GCE Image도 같은 개념 — 미리 만들어진 이미지에서 인스턴스를 만드는 것. foundations 06의 IaC 철학에서 본 "immutable infrastructure"가 여기서 실천된다. 템플릿 자체를 코드(Packer)로 정의하고, 그 템플릿에서 VM을 만드는 것. 다음 글인 이미지 빌드에서 이 과정을 깊이 다룬다.

클라우드의 VM 수명 주기 — EC2 인스턴스

AWS EC2·GCP Compute Engine·Azure VM에서 VM은 인스턴스(instance) 라는 이름으로 불린다. 인스턴스의 수명 주기는 이렇다.

flowchart LR
    PENDING["pending<br/>(시작 중)"] --> RUNNING["running<br/>(실행 중)"]
    RUNNING --> STOPPING["stopping<br/>(정지 중)"]
    STOPPING --> STOPPED["stopped<br/>(정지됨)"]
    STOPPED --> PENDING
    RUNNING --> TERMINATED["terminated<br/>(삭제됨)"]
    STOPPED --> TERMINATED

• pending → running — 인스턴스 생성 요청 → AMI에서 볼륨 생성 → 하이퍼바이저가 VM 할당 → 부팅 → 실행. 약 30 ~ 60초.
• running → stopping → stopped — 인스턴스 정지. 디스크는 유지되고 CPU·메모리는 회수됨. stopped 상태에서는 컴퓨트 비용만 무료(디스크 비용은 계속 청구).
• stopped → pending → running — 정지된 인스턴스 재시작. 이때 다른 물리 서버에서 뜰 수 있다 — 하이퍼바이저가 새 호스트를 할당하기 때문. 이게 EC2 인스턴스 stop/start가 IP가 바뀔 수 있는 이유다(탄력적 IP를 안 쓰면).
• terminated — 인스턴스 완전 삭제. 디스크(루트 볼륨)도 삭제됨(기본 설정 시). 복구 불가.

클라우드의 인스턴스는 — 자원 한계(vCPU·메모리)가 "인스턴스 타입"(m6i.large·c7g.2xlarge 등)으로 고정돼 있다. 이는 오버커밋을 벤더가 관리한다는 뜻이다. 고객은 "2 vCPU, 8GB"를 빌리지만, 그 물리 서버에서 몇 개의 다른 인스턴스가 같이 돌고 있는지(오버커밋 비율)는 알 수 없다. EC2의 "Dedicated Instance" 또는 "Dedicated Host"는 — 전용 물리 서버를 빌리는 옵션으로, 오버커밋이 없다(다른 고객의 인스턴스가 같은 서버에 안 뜸). 라이선스·보안·성능 예측성이 필요한 워크로드에 쓴다.

실습 — VM 상태 직접 확인하기

1. CPU 스틸(CPU steal) 확인

# top 명령에서 %st (steal) 확인
top -bn1 | head -5
# 더 정확하게 — vmstat의 steal 컬럼
vmstat 1 3

확인할 것: top의 %Cpu(s) 행에서 st(steal) 값. 0이면 정상 — 하이퍼바이저가 CPU를 충분히 준다. 5% 이상이면 — 같은 물리 서버의 다른 VM이 내 CPU 시간을 빼앗고 있다는 뜻. 클라우드에서 이게 지속되면 더 큰 인스턴스 타입으로 옮기거나 Dedicated Instance를 고려해야 한다.

# 예상 출력 (vmstat, 정상)
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 1234567 524288 890123    0    0    12    18  234  567 15  3 82  0  0
                                                                              ^^
                                                                          st = 0 (정상)

2. KSM 상태 확인 (KVM 호스트)

# KSM이 켜져 있는지, 얼마나 페이지를 합쳤는지
cat /sys/kernel/mm/ksm/run 2>/dev/null
# 1 = 켜짐, 0 = 꺼짐
grep -E 'pages_shared|pages_sharing|full_scans' /sys/kernel/mm/ksm/* 2>/dev/null | head -5

확인할 것: pages_sharing가 높으면 KSM이 같은 페이지를 합쳐 메모리를 절약하고 있다는 뜻. pages_shared는 공유되는 고유 페이지 수. 이 둘의 비율로 절약 효율을 알 수 있다.

# 예상 출력 (KSM 활성화, 메모리 절약 중)
pages_shared: 4523     # 공유된 고유 페이지 수
pages_sharing: 89234   # 공유에 참여한 총 페이지 수
# 절약: (89234 - 4523) × 4KB ≈ 339MB

3. VM 스냅샷 관리 (libvirt/KVM 호스트)

# VM의 스냅샷 목록
virsh snapshot-list --domain my-vm
# 스냅샷 생성
virsh snapshot-create-as --domain my-vm --name "pre-update"
# 스냅샷으로 복구
virsh snapshot-revert --domain my-vm --snapshotname "pre-update"
# 스냅샷 삭제
virsh snapshot-delete --domain my-vm --snapshotname "pre-update"

확인할 것: 스냅샷이 너무 많거나 오래된 스냅샷이 있으면 디스크 성능에 영향을 준다. 정기적으로 커밋(삭제)하는 게 좋다.

4. qcow2 디스크의 스냅샷 구조 확인

# qcow2 파일의 스냅샷 정보
qemu-img info /var/lib/libvirt/images/my-vm.qcow2
# 스냅샷 목록
qemu-img snapshot -l /var/lib/libvirt/images/my-vm.qcow2

확인할 것: backing file이 있으면 링크드 클론이거나 스냅샷이 있다는 뜻. disk size가 virtual size보다 작은 게 정상(씬 프로비저닝).

# 예상 출력 (qemu-img info)
image: my-vm.qcow2
file format: qcow2
virtual size: 20 GiB
disk size: 3.2 GiB
backing file: base-ubuntu-24.04.qcow2   # ← 링크드 클론의 원본
Snapshot list:
ID        TAG                 VM SIZE                DATE
1         pre-update             512 MiB   2026-07-21 10:00:00

미검증: 위 명령은 KVM/libvirt가 설치된 호스트에서만 동작. 클라우드 EC2 인스턴스 내부에서는 virsh·qemu-img가 없다 — 클라우드는 벤더가 관리하는 환경이므로. vmstat·top의 %st는 클라우드 VM에서도 동작. KSM 상태는 KVM 호스트에서만 의미 있음.

판단 표 — 오버커밋과 리소스 관리 결정

오버커밋 비율과 리소스 관리 전략은 워크로드에 따라 다르다.

워크로드 유형	CPU 오버커밋	메모리 오버커밋	KSM	balloon	권장 마이그레이션
실시간 (HFT·미디어 스트리밍)	1:1 (오버커밋 없음)	1:1	끔	끔	콜드 (계획적)
관계형 DB (OLTP)	2:1 ~ 3:1	1.5:1	끔	켬	라이브 (주의)
웹 서버 (stateless)	4:1 ~ 6:1	1.5:1	켬	켬	라이브 (자유)
VDI (가상 데스크탑)	6:1 ~ 10:1	1.5:1	켬 (큰 효과)	켬	라이브 (자유)
개발/테스트	8:1 ~ 12:1	2:1	켬	켬	불필요 (재생성)
AI 학습 (GPU)	1:1	1:1	끔	끔	콜드 (GPU 이동 어려움)

이 표의 원칙은 — 오버커밋은 "모든 VM이 동시에 최대치를 쓰지 않는다"는 가정에 의존한다는 것이다. DB처럼 항상 바쁜 워크로드는 오버커밋이 위험하고, 웹 서버·VDI처럼 사용 패턴이 불규칙한 워크로드는 오버커밋이 효율적이다. "얼마까지 오버커밋해야 안전한가"는 — 모니터링 데이터(%st·메모리 사용률·swap 발생)를 보면서 결정한다. 정답이 하나가 아니라 관찰하며 조정하는 것.

VM은 "코드가 된 하드웨어"다

도입의 vMotion 사건으로 돌아가자. 2003년에 마술처럼 보였던 라이브 마이그레이션은 — 메모리를 조금씩 미리 복사하고, 마지막에 잠시 멈추는 정교한 엔지니어링이었다. 원리를 이해하면 더 이상 마술이 아니다 — 하지만 그 우아함은 여전히 감탄할 만하다.

VM 라이프사이클을 이해하면 다른 질문에도 답이 보인다. "왜 클라우드 EC2가 stop/start 시 다른 서버에 뜨나" → 라이브 마이그레이션이 아니라 콜드 마이그레이션이라서. "왜 인스턴스 타입을 키우면 성능이 좋아지나" → 오버커밋 비율이 낮아지니까. "왜 같은 인스턴스 타입인데 어떤 때는 느리나" → 다른 인스턴스의 CPU 스틸 때문. VM은 단순한 "가상 서버"가 아니라 — 물리 하드웨어를 시간과 공간으로 나눠 쓰는 정교한 시스템이다.

다음 글에서는 이 VM 여러 대와 스토리지·네트워크를 하나의 유닛으로 통합한 형태를 다룬다 — HCI(Hyper-Converged Infrastructure). vSAN·Nutanix·Proxmox가 "컴퓨트+스토리지+네트워크를 한 상자에" 통합하는 방식. VM이 한 서버 위의 추상이라면, HCI는 한 랙(또는 클러스터) 위의 추상이다.

---

참고

• VMware, "VMware vMotion Architecture" white paper, 2010 — 라이브 마이그레이션 기술 원전. 접근 2026-07-21
• Waldspurger, C. A. "Memory Resource Management in VMware ESX Server", OSDI 2002 — balloon driver·메모리 오버커밋 원논문. 접근 2026-07-21
• Arcangeli, A., Eidus, T., Wright, C. "Increasing Memory Density by Using KSM", Linux Symposium 2009 — KSM 원논문. 접근 2026-07-21
• Clark, C. et al. "Live Migration of Virtual Machines", NSDI 2005 — 라이브 마이그레이션 학술 분석. 접근 2026-07-21
• VMware, "VMware Distributed Resource Scheduler (DRS)" documentation — 자동 로드 밸런싱. 접근 2026-07-21
• libvirt, "Live Migration" documentation — KVM 라이브 마이그레이션. 접근 2026-07-21. URL: https://libvirt.org/migration.html
• AWS, "Amazon EC2 Instance Lifecycle" — 인스턴스 수명 주기(pending/running/stopped/terminated). 접근 2026-07-21
• Gregg, B. 2nd ed, Addison-Wesley, 2020, Ch.7·Ch.8 — 가상화 성능 분석, CPU steal. 접근 2026-07-21
• Nemeth, E., Snyder, G., Hein, T. 5th ed, 2017, Ch.24 — 가상화 관리 실무. 접근 2026-07-21