김신건의 로그 - 위키 / virtualization

Hypervisor: Type 1 (bare metal) vs Type 2 (hosted)

koa (김신건) — Mon, 29 Jun 2026 00:00:00 GMT

정의

Hypervisor (Virtual Machine Monitor, VMM) 는 여러 [[virtual-machine|VM]] 을 한 물리 머신 위에서 실행하도록 하드웨어를 가상화하는 소프트웨어입니다. CPU 시간, 메모리 페이지, I/O 디바이스를 게스트 OS 들에게 분배 및 격리합니다.

용어의 어원: hyper (넘어서는) + supervisor. 원래 IBM 의 CP-67 (1968) 에서 “supervisor 위에서 supervisor 를 감독한다” 는 의미로 명명되었습니다.

Popek & Goldberg 정리 (1974)

가상화 가능한 아키텍처의 조건을 처음 정형화한 논문. 세 가지 성질이 필요합니다.

동등성 (Equivalence): VM 에서 실행한 프로그램이 실물 하드웨어에서와 같은 결과를 낸다
자원 제어 (Resource Control): hypervisor 가 물리 자원을 완전히 통제한다
효율성 (Efficiency): 대다수 명령은 하드웨어에서 직접 실행되어야 한다 (인터프리트 X)

핵심 결과: 모든 sensitive instruction (자원 상태 변경) 이 privileged instruction (특권 실행 필요) 의 부분집합 이어야 가상화 가능. x86 은 원래 이 조건을 만족하지 않았고, 그래서 2005 년 이전 x86 가상화는 이진 재작성 (binary translation, VMware ESX 초기) 을 썼습니다. Intel VT-x / AMD-V 가 이 조건을 하드웨어로 만족시켰습니다.

Type 1 vs Type 2

{}

Type 1: Bare Metal Hypervisor

하드웨어 위에 직접 올라갑니다. 그 자체가 OS 역할.

오버헤드 작음 (host OS 층이 없음)
관리 도구는 별도 (관리 VM 또는 원격 접속)
대상: 데이터센터, 서버, 프로덕션 클라우드
대표: VMware ESXi, Xen, KVM (일부 시각), Microsoft Hyper-V, Nutanix AHV, Proxmox VE

[!NOTE] KVM 은 Type 1 인가 Type 2 인가? 두 시각이 공존합니다. KVM 은 Linux 커널 모듈로 동작하고 Linux 자체가 host OS 역할을 하지만, KVM 은 Linux 를 hypervisor 로 “승격” 시켜 게스트를 직접 관리합니다. VMware, Red Hat 등은 KVM 을 Type 1 으로 분류하는 경향이 있고, 학술 텍스트는 Type 2 로 보는 경향이 있습니다.

Type 2: Hosted Hypervisor

Host OS 위에 애플리케이션으로 올라갑니다.

Host OS 층이 있어 오버헤드 다소 큼
대신 설치가 간단, 데스크톱에서 편함
대상: 개발자 로컬 환경, 학습, 크로스-OS 테스트
대표: Oracle VirtualBox, VMware Workstation / Fusion, Parallels Desktop, QEMU (일반 모드)

주요 hypervisor 상세

KVM (Kernel-based Virtual Machine)

2007 년 Linux 커널에 병합 (Avi Kivity)
Linux 커널 모듈 형태, /dev/kvm 인터페이스
QEMU 와 조합 하는 것이 표준 (QEMU 가 device emulation, KVM 이 CPU/메모리)
오픈소스, 무료, 성능 좋음
libvirt 로 관리, virt-manager, virsh CLI
RHEL, Ubuntu 등 리눅스 클라우드/서버 기본
사용처: AWS Nitro (일부), Google Cloud, DigitalOcean, OpenStack

Xen

2003 년 케임브리지 대학 발원, paravirtualization 개척
Dom0 (관리 도메인) + DomU (게스트) 아키텍처
AWS EC2 초기 세대가 Xen 기반 (~2017)
현재는 KVM 에 밀려 점유율 감소, Citrix Hypervisor (XenServer) 로 상용
임베디드, 자동차 (Xen ARM) 등 특수 영역에서는 여전히 강함

VMware ESXi

VMware 상용 hypervisor, 데이터센터 최강자 (오랫동안)
vSphere 는 ESXi 를 관리하는 상위 스택 (vCenter, vMotion, HA)
Broadcom 인수 (2023) 후 라이선싱 변경으로 대안 검토가 늘어남
Type 1, 마이크로커널 기반
VMFS 클러스터 파일시스템, live migration (vMotion) 유명

Microsoft Hyper-V

Windows Server 및 Windows 10/11 Pro 에 내장
Type 1 (기술적으로), 다만 Windows 는 parent partition 이라 UI 상 Type 2 처럼 보임
Azure 의 기반 hypervisor
WSL2 도 내부적으로 Hyper-V 를 이용해 경량 Linux VM 실행

Oracle VirtualBox

무료, GPL, 크로스플랫폼 (Windows / macOS / Linux)
Type 2, 데스크톱 개발자 표준
Vagrant 와 조합해서 개발 환경 구성

QEMU

에뮬레이터 이자 hypervisor
순수 QEMU: 소프트웨어 에뮬레이션 (느림, 하지만 다른 아키텍처 실행 가능, 예: ARM → x86)
QEMU + KVM: 하드웨어 가속 (Linux 표준)
QEMU + HVF: macOS 하드웨어 가속
Firecracker, Cloud Hypervisor 등이 QEMU 의 subset 을 fork

Firecracker

AWS 가 2018 년 오픈소스로 공개
microVM: 극도로 slim 한 hypervisor (수백 KB)
Rust 로 작성, KVM 기반
부팅 125ms 이하
AWS Lambda, AWS Fargate 의 기반
컨테이너 편의 + VM 격리의 조합이 목표

기타

Cloud Hypervisor (Intel + Rust community): Firecracker 계열, 더 많은 기능
Bhyve (FreeBSD 기반)
z/VM (IBM 메인프레임)
PowerVM (IBM POWER)

하드웨어 지원

Hypervisor 성능은 CPU 의 가상화 지원에 크게 의존합니다.

VT-x / AMD-V: Ring -1 이라는 새로운 특권 레벨을 만들어 hypervisor 를 여기서 실행
EPT / RVI (Nested Paging): 게스트 물리 → 호스트 물리 변환을 하드웨어로
VT-d / AMD-Vi (IOMMU): PCI passthrough 안전화
SR-IOV: NIC 을 VF (Virtual Function) 로 나누어 게스트가 직접 접근
APICv: 인터럽트 가상화 오버헤드 감소

이 모두가 켜져 있으면 컴퓨트/메모리 오버헤드는 몇% 수준, I/O 는 virtio + SR-IOV 로 near-native.

Nested Virtualization

VM 안에서 다시 hypervisor 를 돌리는 것. 예:

클라우드에서 개발자가 로컬처럼 KVM 을 돌리고 싶을 때
WSL2 (Windows 안에서 Hyper-V, 그 안에서 Linux)
학습/랩 환경

문제점:

성능 오버헤드가 커짐 (트랩 두 번)
L1 hypervisor 가 nested 를 명시적으로 지원해야 함 (Intel VMCS shadowing 등)
AWS EC2 는 특정 metal 인스턴스만 nested 허용

주요 기능

Live Migration

실행 중인 VM 을 중단 없이 다른 물리 서버로 이동:

메모리 페이지를 백그라운드로 복사 (pre-copy 방식)
Dirty page 만 반복 복사
마지막에 잠깐 (수십 ms) freeze 후 CPU 상태 전송
VMware vMotion, KVM libvirt migration, Xen live migration

Snapshot

특정 시점 상태 (메모리 + 디스크) 저장. 롤백, 백업.

디스크: qcow2 의 CoW 스냅샷
메모리: RAM 을 파일로 dump
주의: 프로덕션에서 스냅샷 유지는 성능/공간 부담

Overcommit

물리 자원보다 더 많은 자원을 게스트에 할당:

Memory overcommit: KSM (Kernel Same-page Merging) 으로 동일 페이지 공유, ballooning 으로 회수
CPU overcommit: 물리 코어보다 많은 vCPU (스케줄링으로 시분할)
위험: 오버커밋 후 실제 사용량이 급증하면 성능 붕괴, 최악의 경우 OOM

PCI Passthrough

특정 PCI 디바이스 (GPU, NIC) 를 특정 게스트에게 독점 할당. VFIO (Linux) 로 구현. GPU 가상 데스크톱, HFT 등에 사용.

Hypervisor 비교

항목	KVM	Xen	ESXi	Hyper-V	VirtualBox
유형	Type 1 (일부 시각 Type 2)	Type 1	Type 1	Type 1	Type 2
라이선스	GPL (무료)	GPL / 상용	상용	상용 (Windows 포함)	GPL
주 사용처	클라우드, Linux 서버	임베디드, 특수 클라우드	엔터프라이즈 DC	Windows DC, Azure	데스크톱, 개발
관리 도구	libvirt, virt-manager	xm/xl, XenCenter	vSphere Client, vCenter	Hyper-V Manager, SCVMM	VirtualBox GUI
live migration	지원 (libvirt)	지원	지원 (vMotion)	지원	지원 안 함
성능	우수 (하드웨어 가속 잘 활용)	우수 (paravirt 특히)	최상	우수	중간
학습 곡선	중간	높음	낮음~중간 (UI 좋음)	낮음	매우 낮음

함정

QEMU-only vs KVM: qemu-system-x86_64 만 실행하면 순수 에뮬레이션으로 느립니다. -enable-kvm 이나 -accel kvm 을 명시해야 하드웨어 가속됩니다.
오버커밋: 넉넉해 보인다고 무한정 게스트를 얹으면 실제 부하 급증 시 붕괴합니다. 프로덕션은 물리 자원의 80% 정도까지만.
NUMA: 대규모 VM 이 NUMA 노드를 넘어가면 성능 저하. numa 옵션으로 게스트가 NUMA 를 인지하게 하거나 pinning 필요.
CPU 세대 mismatch: live migration 대상 서버가 CPU 명령어 셋이 다르면 게스트가 죽을 수 있음. cluster 내 CPU 마스킹 (EVC in VMware) 필요.
Timekeeping: 게스트 시계가 자주 어긋남. kvm-clock (Linux 게스트) 또는 NTP 필수.

참고

관련 [[virtualization|가상화 전체]]
관련 [[virtual-machine|Virtual Machine]]
관련 [[vm-vs-container|VM vs Container 비교]]
Popek & Goldberg 정리: Formal Requirements for Virtualizable Third Generation Architectures
Firecracker paper: Firecracker: Lightweight Virtualization for Serverless Applications

LXC / LXD: System Containers, Docker 이전의 컨테이너

koa (김신건) — Mon, 29 Jun 2026 00:00:00 GMT

정의

LXC (Linux Containers) 는 Linux 커널의 [[cgroups-namespaces|namespaces + cgroups]] 를 이용해 완전한 리눅스 시스템 (init, 서비스, 파일시스템) 을 컨테이너로 실행 하는 도구입니다. [[docker|Docker]] 가 등장하기 전 (2008 년) 부터 있었으며, “system container” 접근의 대표 주자입니다.

LXD 는 Canonical (Ubuntu) 이 만든 LXC 위 관리 레이어로, REST API + 이미지 관리 + 클러스터링을 추가합니다. 2023 년 Canonical 이 라이선스를 변경하자 커뮤니티가 Incus 로 fork 하여 현재 두 갈래로 발전 중입니다.

System Container vs Application Container

컨테이너를 사용하는 두 관점입니다.

System Container (LXC 계열)

미니 VM 처럼 사용: init 프로세스 + systemd + 여러 서비스 실행
안에 여러 프로세스 (nginx + rails + cron 등)
로그인 (ssh) 가능한 완전한 리눅스 환경
오래 살아있는 인스턴스, VM 을 대체하는 감각으로 배포
대표: LXC, LXD, Incus, systemd-nspawn, OpenVZ

Application Container (Docker 계열)

하나의 프로세스가 하나의 컨테이너
Immutable: 로그인해서 고치는 게 아니라 이미지를 새로 빌드
일회용, 짧은 수명 (crash 나면 restart)
Kubernetes 등 오케스트레이터가 대량 실행
대표: [[docker|Docker]], Podman, containerd, CRI-O

같은 커널 기술 (namespaces + cgroups) 위에 서 있지만, 사용 철학이 다릅니다.

LXC 의 특징

VM 을 대체할 수 있는 컨테이너

# 컨테이너 생성 (Ubuntu 24.04 시스템)
lxc-create -n myct -t download -- --dist ubuntu --release noble --arch amd64

# 시작
lxc-start -n myct

# 안에서 shell
lxc-attach -n myct

# 안에서 systemctl 사용 가능
systemctl status
systemctl start nginx

컨테이너 안에 systemd 가 PID 1 로 뜹니다. 여러 서비스, cron, syslog 등 완전한 리눅스 시스템이 그 안에서 돕니다.

Privileged vs Unprivileged

Unprivileged (기본): 컨테이너의 root 가 호스트의 일반 유저에 매핑됨 → 탈출해도 root 권한 없음
Privileged: 컨테이너의 root 가 호스트 root 와 같음 → 성능 우위, 보안 약함

user namespace 를 활용한 unprivileged 모드가 LXC 의 강점입니다. Docker 는 default 로 privileged 이라 (rootless docker 는 별도 설정) LXC 가 이 면에서 오랫동안 앞서 있었습니다.

LXD / Incus

LXC 위에 얹은 관리 레이어.

CLI: lxc launch ubuntu:24.04 web, lxc list, lxc exec web bash
REST API: 로컬 소켓 또는 HTTPS
이미지 서버: images:ubuntu/24.04 로 원격 이미지 자동 다운로드
스토리지 백엔드: dir / zfs / btrfs / lvm / ceph
네트워크: 브릿지, macvlan, ovn
클러스터: 여러 호스트 묶어서 배포
Live migration: CRIU 로 실행 중 컨테이너 이동
VM 지원: LXD 4.0+ 는 QEMU 백엔드로 VM 도 관리 (컨테이너와 통합 UI)

Ubuntu 서버에서 “미니 클라우드” 를 구축하는 표준 방식이었습니다. 2023 년 Canonical 이 CLA 요구 등 라이선스를 강화하자 원 개발자 Stéphane Graber 등이 Incus 로 fork. 현재 Incus 가 커뮤니티 주류입니다.

다른 시스템 컨테이너 도구

systemd-nspawn

systemd 에 내장된 최소 컨테이너 러너
완전한 리눅스 시스템 이미지를 빠르게 부팅
개발/테스트에 유용, 프로덕션 관리는 별도 도구 필요
machinectl 로 관리

sudo systemd-nspawn -bD /var/lib/machines/ubuntu-noble/

OpenVZ / Virtuozzo

러시아의 Parallels 가 개발한 시스템 컨테이너
LXC 이전부터 있었음 (2005~)
커널 패치 필요 (mainline 이 아님)
러시아/CIS 지역의 저가 VPS 호스팅에서 자주 사용

FreeBSD Jails

FreeBSD 4.0 (2000) 부터 지원
컨테이너의 원조에 가까움
chroot 확장 + 프로세스/네트워크/사용자 격리
Linux 컨테이너의 개념적 조상

Solaris Zones

Sun Solaris 10 (2005) 부터 지원
Solaris 서버 통합에서 강력
Oracle 인수 후 사용 감소

LXC 와 Docker 비교

항목	LXC (system container)	Docker (application container)
철학	미니 VM	프로세스 격리
PID 1	`systemd` 또는 `init`	애플리케이션 프로세스
수명	오래 (일/주/월)	짧게 (초/분/시간)
이미지	완전한 배포판 tarball	앱 중심 layered image
네트워킹	브릿지, VLAN, macvlan	bridge, host, overlay (Docker network)
로그인	ssh 로 접속 자연스러움	원칙적으로 지양 (`docker exec` 로만)
불변성	컨테이너 내부 변경 흔함	이미지 재빌드로만 변경
오케스트레이션	LXD 클러스터, 손수	Kubernetes (`[[k8s-pod]]` 참조) 등 발달
주 사용처	VPS, 개발 환경, 레거시 이관	마이크로서비스, CI/CD

언제 LXC 를 쓰는가

LXC 가 잘 맞는 케이스

VPS 대체: 기존에 VM 으로 돌리던 워크로드를 더 가볍게
레거시 앱 이관: Docker 로 옮기기 어려운 다중 프로세스 모놀리스
연구/실험: 여러 배포판을 로컬에서 병렬로
CI 러너: 완전한 시스템 환경이 필요한 테스트
저비용 격리: OpenVZ 시대의 저가 VPS 호스팅

Docker 가 나은 케이스

마이크로서비스: 하나의 프로세스 = 하나의 컨테이너
불변 인프라: 재빌드/재배포 파이프라인 잘 되어 있는 조직
오케스트레이션: Kubernetes 생태계 활용
표준 이미지: Docker Hub 의 방대한 이미지 재사용

성능

LXC 와 Docker 는 커널이 같기 때문에 런타임 성능은 거의 동일 합니다. 차이는 다음에서 옵니다.

부팅: LXC 는 init/systemd 를 시작 (수초), Docker 는 프로세스만 (수백 ms)
이미지: LXC 는 전체 배포판 tarball (수백 MB), Docker 는 layered slim image (수십 MB)
격리: LXC 는 unprivileged 로 user namespace 활용, Docker 는 rootless docker 나 podman 이 뒤늦게 따라잡음

실전 명령어 참고

# LXC (native)
lxc-create -n myct -t download
lxc-start -n myct
lxc-attach -n myct
lxc-stop -n myct

# LXD / Incus
lxc launch ubuntu:24.04 web        # incus 는 incus launch
lxc list
lxc exec web -- bash
lxc file push local.conf web/etc/nginx/
lxc snapshot web backup-2026
lxc restore web backup-2026
lxc stop web

# systemd-nspawn
machinectl list-images
machinectl start ubuntu-noble
machinectl shell ubuntu-noble

참고

관련 [[docker|Docker]] (application container)
관련 [[cgroups-namespaces|cgroups + namespaces]] (LXC 의 근간)
관련 [[virtualization|가상화 전체]]
관련 [[vm-vs-container|VM vs Container 비교]]
공식: linuxcontainers.org
Incus: https://linuxcontainers.org/incus/
Ubuntu 튜토리얼: https://ubuntu.com/tutorials/how-to-run-docker-inside-lxd-containers

Virtual Machine (VM): guest OS, 스냅샷, 마이그레이션

koa (김신건) — Mon, 29 Jun 2026 00:00:00 GMT

정의

Virtual Machine (VM) 은 [[hypervisor|hypervisor]] 위에 실행되는 완전한 가상 컴퓨터 입니다. 가상 CPU (vCPU), 가상 메모리 (vRAM), 가상 디스크, 가상 NIC 을 갖고, 그 위에 게스트 OS 를 부팅합니다. 게스트 OS 는 자기가 물리 컴퓨터 위에 있다고 착각합니다.

VM 은 [[docker|container]] 와 달리 자체 커널 을 실행합니다. 이것이 VM 의 강한 격리와 큰 오버헤드의 근본 이유입니다.

구성 요소

vCPU

Hypervisor 가 물리 코어를 시분할하여 여러 vCPU 를 제공
게스트에게는 완전한 CPU 처럼 보임
CPU pinning: 특정 vCPU 를 특정 물리 코어에 고정 (성능/일관성 향상)
NUMA topology: 게스트에도 NUMA 를 노출하여 큰 워크로드가 지역성 활용

vRAM

게스트 물리 메모리는 hypervisor 관점에서는 그냥 메모리 풀
EPT (Extended Page Tables) 로 게스트 물리 → 호스트 물리 이중 변환을 하드웨어가 함
Ballooning: hypervisor 가 게스트에게 “회수 요청” 을 보내 유휴 메모리를 다시 가져옴
KSM (Kernel Same-page Merging): 여러 게스트가 같은 페이지 (예: 같은 배포판 커널) 를 공유

가상 디스크

파일 또는 볼륨 형태:

포맷	특징	Hypervisor
qcow2	QEMU CoW, 스냅샷, thin provisioning	KVM/QEMU
VMDK	VMware 표준	ESXi, Workstation
VHD / VHDX	Microsoft 표준	Hyper-V
raw	헤더 없이 그대로, 성능 최고	모든 hypervisor
VDI	VirtualBox 자체 포맷	VirtualBox

가상 NIC (vNIC)

에뮬레이션: e1000, rtl8139 (게스트가 물리 카드처럼 인식, 느림)
virtio-net: 게스트가 virtio 를 알고 있어 직접 hypervisor 와 통신 (paravirtual, 훨씬 빠름)
SR-IOV: 물리 NIC 을 나누어 게스트가 하드웨어 레벨로 접근

virtio

Rusty Russell (Linux 커널) 이 2008 년 발표한 paravirtual I/O 프레임워크. 게스트와 hypervisor 가 공유하는 링 버퍼 (vring) 로 통신.

virtio-blk, virtio-scsi: 디스크
virtio-net: 네트워크
virtio-balloon: 메모리 회수
virtio-gpu: 그래픽
virtio-fs: 파일시스템 (호스트 디렉토리 공유)

virtio 는 오늘날 KVM/QEMU 뿐 아니라 대부분의 hypervisor 가 지원하는 사실상 표준입니다.

부팅 흐름

hypervisor 가 VM 프로세스를 시작 (QEMU 프로세스 등)
가상 펌웨어 실행 (SeaBIOS 또는 OVMF/UEFI)
부트로더 (GRUB 등) 가 커널 이미지 로드
게스트 커널 부팅 (수백 MB 메모리 초기화, 디바이스 검색)
init/systemd 시작, 서비스 부트
최종적으로 login 프롬프트 또는 앱 실행

Full boot 은 30~60 초 걸리는 게 흔합니다. [[docker|Container]] 가 수초 안에 뜨는 것과 대조됩니다.

Cloud-init

퍼블릭 클라우드에서 같은 이미지에서 여러 VM 을 띄우려면 인스턴스별 커스터마이징 이 필요합니다.

호스트네임 설정
SSH 키 주입
사용자 계정 생성
패키지 설치
초기 스크립트 실행

cloud-init 이 이를 자동화합니다. 클라우드 provider 의 metadata service (예: AWS http://169.254.169.254/) 에서 정보를 읽어 부팅 시 적용. user-data 로 shell script 나 YAML (cloud-config) 를 지정할 수 있습니다.

#cloud-config
hostname: web01
users:
  - name: deploy
    sudo: ALL=(ALL) NOPASSWD:ALL
    ssh_authorized_keys:
      - ssh-ed25519 AAAA... deploy@laptop
packages:
  - nginx
  - postgresql-client
runcmd:
  - systemctl enable --now nginx

스냅샷 (Snapshot)

특정 시점의 VM 상태 (메모리 + 디스크) 를 저장하여 나중에 그 상태로 되돌릴 수 있습니다.

종류

디스크 스냅샷: 파일시스템 시점 저장 (qcow2, ZFS, LVM)
메모리 스냅샷: RAM 을 dump (VM 이 정지되어 있어야 하거나 live 지원 필요)
Full snapshot: 디스크 + 메모리 + 장치 상태 모두 (VMware, VirtualBox 지원)

사용처

업그레이드 전 백업, 실패 시 롤백
개발/테스트 환경 재현
짧은 기간 (몇 분~시간)

[!WARNING] 프로덕션에서 스냅샷을 오래 유지하면 안 됩니다. qcow2 는 스냅샷이 쌓일수록 CoW 체인이 길어져 I/O 성능이 크게 저하됩니다. VMware 도 스냅샷 delta 파일이 커지면 문제. 스냅샷은 짧게 쓰고 지우거나 백업 파일로 export 하세요.

Live Migration

실행 중인 VM 을 거의 무중단 으로 다른 물리 서버로 옮기는 기술.

Pre-copy 방식 (표준)

원본 서버에서 메모리 페이지를 백그라운드로 대상 서버에 복사 시작
VM 계속 실행 중이므로 dirty page 발생
dirty page 만 다시 복사, 반복
dirty rate 가 충분히 낮아지면 마지막 stop-and-copy
VM 을 원본에서 잠깐 (수십 ms) 멈추고 남은 페이지 + CPU 상태 전송
대상에서 VM 재개

Post-copy 방식

VM 을 대상으로 옮겨서 즉시 재개
메모리 접근 시 원본에서 page fault 로 가져옴

Post-copy 는 다운타임이 더 짧지만 원본 실패 시 VM 이 죽습니다. VMware vMotion, KVM libvirt migration, Xen 모두 지원합니다.

요구 조건

두 서버가 공유 스토리지 (NFS, iSCSI, Ceph) 를 봐야 함 (또는 storage migration 병행)
CPU 모델이 호환 가능해야 함 (EVC / CPU masking 으로 완화)
네트워크 대역폭 (특히 대용량 VM)

VM 관리 CLI 예시 (libvirt / KVM)

# 새 VM 생성 (cloud image 사용)
virt-install \
  --name web01 \
  --memory 4096 --vcpus 2 \
  --disk path=/var/lib/libvirt/images/web01.qcow2,size=20 \
  --cdrom /iso/ubuntu-24.04-server.iso \
  --network network=default \
  --graphics none --console pty,target_type=serial

# 실행/정지
virsh start web01
virsh shutdown web01     # 정중한 종료
virsh destroy web01      # 강제 종료

# 스냅샷
virsh snapshot-create-as web01 pre-upgrade
virsh snapshot-list web01
virsh snapshot-revert web01 pre-upgrade

# Live migration (공유 스토리지 전제)
virsh migrate --live web01 qemu+ssh://target-host/system

# 콘솔 접속
virsh console web01

VM 이 컨테이너보다 유리한 경우

다른 커널 필요: Linux 위에서 Windows 실행
커널 수준 튜닝: 실시간 커널, 커스텀 모듈 로드
강한 격리 필요: 규제 산업 (금융, 의료), 멀티테넌트
하드웨어 에뮬레이션: 다른 CPU 아키텍처, 특수 디바이스
레거시 앱: 오래된 OS 그대로 유지 (Windows Server 2003 등)

VM 이 잘 안 맞는 경우

마이크로서비스 (수백~수천 인스턴스): 부팅/이미지 부담이 큼
짧은 수명 워크로드 (배치 잡): 부팅에 몇 분 걸리면 잡보다 오래 걸릴 수 있음
개발자 로컬 반복 (edit-restart): container 대비 반복 사이클이 느림

이런 경우 [[docker|container]] 가 자연스러운 선택입니다.

참고

관련 [[virtualization|가상화 전체]]
관련 [[hypervisor|Hypervisor]]
관련 [[vm-vs-container|VM vs Container 심층 비교]]
관련 [[docker|Docker]]
Cloud-init: https://cloudinit.readthedocs.io/
libvirt: https://libvirt.org/
Rusty Russell, virtio

VM vs Container: 층 구조, 성능, 격리 완벽 비교

koa (김신건) — Mon, 29 Jun 2026 00:00:00 GMT

정의

VM 과 Container 는 같은 문제 (하나의 물리 서버에 여러 워크로드 격리) 를 다른 방식으로 푸는 두 접근 입니다. VM 은 하드웨어를 가상화하고, Container 는 OS 를 가상화합니다. 이 근본적 차이가 성능, 격리, 이미지 크기, 부팅 시간 모두를 결정합니다.

이 문서는 두 접근을 시각화 세 개로 완전 해부합니다.

층 구조

{}

VM 스택 (왼쪽)

Hardware → Host OS (Type 2) 또는 없음 (Type 1) → Hypervisor → Guest Kernel × N → libs / bins × N → App × N
각 VM 이 자체 커널 인스턴스 를 실행
게스트가 물리 하드웨어를 착각하도록 hypervisor 가 CPU/메모리/디바이스를 가상화

Container 스택 (오른쪽)

Hardware → Host Kernel (공유!) → Container Runtime → libs / bins × N → App × N
모든 컨테이너가 하나의 host 커널을 공유
커널의 [[cgroups-namespaces|namespaces]] 로 프로세스/파일시스템/네트워크 뷰를 격리
[[cgroups-namespaces|cgroups]] 로 CPU/메모리 사용량 상한 부여

핵심 요점

“어디까지 공유하는가” 가 모든 차이를 만듭니다.

VM: 하드웨어까지만 공유 → 각자 커널, 강한 격리, 큰 오버헤드
Container: 커널까지 공유 → 얇은 격리, 낮은 오버헤드

왜 Container 가 빠른가

1. 커널 부팅 없음

VM 부팅: BIOS/UEFI → 부트로더 → 커널 초기화 (수십 초) → init/systemd → 앱

Container 부팅: 프로세스 fork → namespace 설정 → chroot → 앱 실행 (수백 ms)

커널을 부팅하지 않는다는 것 자체가 최대 이득입니다.

2. 시스템콜 직접 실행

VM 의 앱이 시스템콜을 하면: 게스트 커널로 → hypervisor 트랩 (VT-x 도움) → 필요시 에뮬레이션 → 게스트 커널이 응답 → 앱

Container 의 앱이 시스템콜을 하면: host 커널로 직접. 트랩도 게스트 커널도 없음.

virtio, EPT 등 하드웨어 가속으로 VM 오버헤드는 많이 줄었지만, syscall 밀집형 워크로드 (파일 I/O, 네트워크) 에서는 여전히 container 가 유리합니다.

3. 메모리 오버헤드가 작다

VM 하나: 게스트 커널 자체가 100~500MB, glibc/systemd 등 기본 서비스 포함하면 GB 단위 시작

Container 하나: libs + app 만, MB~수십 MB

같은 하드웨어에 VM 수십 개 vs Container 수천 개가 물리적 한계입니다.

4. 이미지 크기가 작다

VM 이미지: 전체 배포판 (수 GB)

Container 이미지: 앱 + 필요한 libs 만 (수십 MB)

특히 [[docker|Docker]] 의 layered filesystem 은 여러 컨테이너가 read-only 레이어를 공유해 저장 공간을 크게 절약합니다.

{}

왜 VM 이 강한가

1. 완전한 격리

각자 커널이므로 한 게스트에서 커널을 아무리 만져도 다른 게스트는 무영향
Container 는 host 커널 취약점이 있으면 모든 컨테이너에 영향
규제/보안 감사 요구가 강한 도메인에서 VM 이 선호되는 이유

2. 다른 OS 실행

Linux 위에서 Windows 실행 가능 (또는 반대)
Container 는 host 커널과 같은 OS 계열만 가능 (Windows container 는 Windows host, Linux container 는 Linux host)

3. 커널 수준 조작

실시간 커널, 커스텀 커널 모듈, 특정 커널 버전 고정 등
Container 는 host 커널 그대로 씀

4. 하드웨어 에뮬레이션

다른 CPU 아키텍처 (예: x86 호스트에서 ARM 게스트, QEMU 로)
특수 디바이스, 레거시 하드웨어

5. Live Migration

실행 중 VM 을 다른 서버로 무중단 이동 (VMware vMotion 등)
Container 도 CRIU 기반 migration 있지만 성숙도 낮음

성능 벤치마크 (Felter et al., IBM 2015)

고전적 비교. Docker vs KVM.

워크로드	Native	Docker	KVM	차이
CPU (LINPACK)	100	100	100	하드웨어 가속 덕에 거의 동일
메모리 (STREAM)	100	100	100	동일
디스크 (fio random)	100	99	92	KVM 이 다소 손해, virtio 로 완화
네트워크 (TCP)	100	96	92	Docker bridge 오버헤드, KVM virtio-net
DB (MySQL)	100	98	82	통합 오버헤드, KVM 이 크게 뒤짐
부팅 시간	-	1s	45s	순서가 다름

요약: 순수 CPU/메모리는 거의 무료, 디스크/네트워크는 각 5~10% 손해, 부팅/이미지 는 container 압승.

이 벤치마크는 2015 년 것이고, 이후 하드웨어 가속과 virtio 개선으로 VM 이 상당히 따라잡았습니다. 오늘날 프로덕션 워크로드에서 순수 성능 차이는 미미하며, 주된 차이는 부팅 속도, 이미지 크기, 밀도 입니다.

격리 강도 스펙트럼

가장 약한 격리 → 가장 강한 격리:

프로세스 (chroot) < Container (namespaces+cgroups) < gVisor / Kata < VM (Type 2) < VM (Type 1) < 물리 분리

중간층 기술

gVisor (Google): 컨테이너와 host 사이에 사용자 공간 커널 을 넣어 syscall 을 격리. Container 편의 + VM 에 근접한 격리.
Kata Containers: 각 컨테이너를 microVM 안에서 실행. OCI 호환. Firecracker 등 hypervisor 활용.
Firecracker: AWS Lambda 의 기반. 125ms 부팅 microVM.
AWS Nitro Enclaves: 완전 격리된 microVM, 심지어 host 도 접근 불가.

이 기술들은 “container 처럼 쓰고 VM 처럼 격리” 를 목표로 합니다.

언제 무엇을 쓸까

VM 선호

규제 산업 (금융, 의료, 정부)
멀티테넌트 클라우드 (테넌트간 강한 격리 필수)
서로 다른 OS 필요
레거시 앱 (오래된 Windows 등)
커널 수준 튜닝 (실시간 시스템)

Container 선호

마이크로서비스 (수백~수천 개 서비스)
CI/CD 파이프라인 (빠른 빌드/테스트/배포)
자원 밀도 (더 많이 얹기)
개발/운영 환경 일치 (dev = staging = prod)
빠른 스케일링

하이브리드 (현대 클라우드 표준)

물리 서버 → EC2 VM 여러 대 → 각 VM 안에 Docker 컨테이너 수십 개.

또는 AWS Fargate / Google Cloud Run: 컨테이너를 사용하지만 내부적으로는 microVM 안에서 격리 (Firecracker + gVisor).

상세 비교표

항목	Virtual Machine	Container
가상화 대상	하드웨어	OS (namespaces + cgroups)
커널	게스트 각자	host 공유
하드웨어 지원	VT-x, EPT, IOMMU 활용	없음 (커널 기능만)
부팅 시간	30~60 초	100~500 ms
이미지 크기	GB (전체 OS)	수십 MB (앱 중심)
메모리 오버헤드	GB (게스트 커널 포함)	MB (프로세스만)
CPU 오버헤드	~5% (하드웨어 가속 후)	~1%
디스크 I/O	90~95% (virtio)	~99%
네트워크	90~95% (virtio-net, SR-IOV)	~99% (host mode 시)
격리 강도	강함 (커널 분리)	중간 (커널 공유)
밀도 (서버당)	수십 개	수백~수천 개
다른 OS 실행	가능	불가 (같은 커널 계열만)
관리 도구	libvirt, vSphere, Hyper-V Mgr	Docker, Podman, Kubernetes
오케스트레이션	OpenStack, VMware vRealize	Kubernetes, Nomad, Docker Swarm
live migration	성숙 (vMotion, KVM libvirt)	미성숙 (CRIU)
이미지 포맷	qcow2, VMDK, VHD, OVF	OCI (Docker/Docker Hub)
주요 hypervisor / runtime	KVM, Xen, ESXi, Hyper-V	containerd, runc, CRI-O

혼동하기 쉬운 지점

”Container 는 프로세스일 뿐?”

절반 맞습니다. 컨테이너 안의 프로세스는 host 커널 관점에서 그냥 다른 프로세스와 동등합니다. ps aux 를 host 에서 실행하면 컨테이너의 프로세스가 보입니다. 다만 컨테이너 안에서 ps 를 실행하면 자기 [[cgroups-namespaces|PID namespace]] 만 보이므로 다른 컨테이너의 프로세스는 안 보입니다.

”VM 도 container 도 부팅한다?”

용어 오해입니다.

VM 은 게스트 커널을 부팅합니다 (BIOS → 부트로더 → 커널 초기화)
Container 는 프로세스를 시작할 뿐, 부팅이 없습니다. docker run alpine echo hi 는 그냥 새 프로세스 fork 후 namespace 격리한 것.

”Docker 는 VM 이다?”

macOS 나 Windows 에서 Docker Desktop 을 쓰면 내부적으로는 Linux VM 을 하나 띄우고 그 안에 Docker 를 실행 합니다. Linux 커널이 없는 host 에서 Linux container 를 돌리려면 어쩔 수 없습니다.

macOS: HyperKit 또는 QEMU 기반
Windows: WSL2 (Hyper-V 기반)

Linux host 에서는 순수 컨테이너입니다.

”Container 는 안전한가?”

Container escape 은 실존하는 위협입니다.

CVE-2019-5736 (runc): 호스트 runc 바이너리를 컨테이너가 덮어써서 escape
CVE-2022-0492 (cgroups v1): rogue cgroup 으로 root 상승
Kernel 취약점 → 모든 컨테이너 영향

기본 방어층: seccomp (syscall 화이트리스트), AppArmor / SELinux, user namespace (rootless), capabilities drop, read-only filesystem. 이 방어층을 다 켜면 실용적 격리 강도는 상당히 올라갑니다. 그래도 VM 만큼은 아닙니다.

예제 성능 (실측 감각)

로컬 노트북 기준 (M1 Pro, macOS + Docker Desktop):

Alpine container docker run --rm alpine echo hi: ~250ms
Ubuntu container docker run --rm ubuntu:24.04 echo hi: ~400ms (첫 실행 이미지 pull 제외)
KVM Ubuntu 24.04 부팅 (virsh start): ~40s
VirtualBox Ubuntu 부팅: ~50s

이미지 크기:

alpine:latest: ~8 MB
ubuntu:24.04: ~80 MB
nginx:latest: ~190 MB
Ubuntu 24.04 cloud-image qcow2: ~600 MB

메모리 사용 (idle):

Alpine container: ~2 MB
nginx container: ~10 MB
KVM Ubuntu 최소 설치: ~500 MB
KVM Ubuntu desktop: ~2 GB

참고

관련 [[virtualization|가상화 전체]]
관련 [[hypervisor|Hypervisor]]
관련 [[virtual-machine|Virtual Machine]]
관련 [[docker|Docker]]
관련 [[lxc-system-containers|LXC]]
관련 [[cgroups-namespaces|cgroups + namespaces]]
관련 [[k8s-pod|Kubernetes Pod]]
벤치마크: Felter et al. 2015, IBM
gVisor: https://gvisor.dev/
Kata Containers: https://katacontainers.io/

가상화 (Virtualization): 하드웨어, OS, 컨테이너 계층 전체 정리

koa (김신건) — Mon, 29 Jun 2026 00:00:00 GMT

정의

가상화 (Virtualization) 는 물리 자원 (CPU, RAM, 디스크, NIC) 을 소프트웨어 계층으로 감싸 여러 논리 인스턴스로 분할 하거나 하나로 통합 하는 기술 전반입니다. “한 대의 머신을 여러 대처럼”, 또는 “여러 대를 한 대처럼” 보이게 만드는 것이 목적입니다.

가상화는 크게 다음 세 층에서 일어납니다.

하드웨어 가상화: hypervisor 가 CPU/메모리를 나눠 [[virtual-machine|VM]] 을 만듭니다
OS 수준 가상화: 커널이 프로세스 그룹을 격리해 [[docker|container]] 를 만듭니다
애플리케이션 가상화: JVM, WebAssembly 등 언어 런타임이 앱을 격리합니다

왜 가상화하는가

자원 활용률: 물리 서버 한 대의 CPU 가 5% 만 쓰이는 것이 흔합니다. 가상화로 여러 워크로드를 밀집시키면 30~70% 까지 올릴 수 있습니다.
격리: 워크로드 A 의 크래시가 B 에 영향 주지 않음
이식성: 이미지 형태로 다른 하드웨어에 옮길 수 있음
재현성: 개발 환경과 운영 환경을 동일하게 만들 수 있음
관리성: 스냅샷, 라이브 마이그레이션, 자동 스케일링이 가능해짐

가상화 분류 (taxonomy)

1. 하드웨어 가상화 (Full Virtualization)

Hypervisor 가 CPU/메모리/디바이스를 완전히 에뮬레이션하여, 게스트 OS 는 자기가 실물 하드웨어 위에 있다고 착각 하도록 만듭니다.

게스트 OS 커널을 수정 없이 그대로 실행
대신 CPU 의 특권 명령 (privileged instruction) 을 hypervisor 가 가로채 처리 → 오버헤드 발생
Intel VT-x, AMD AMD-V 같은 하드웨어 지원이 나오면서 오버헤드가 크게 감소했습니다 (2005~)
예: KVM, VMware ESXi, VirtualBox, Hyper-V

2. Paravirtualization

게스트 OS 를 수정 하여, 성능이 중요한 명령을 hypervisor 에 직접 hypercall 로 요청하게 합니다.

특권 명령 트랩이 없어 오버헤드가 작음
게스트 OS 소스에 접근할 수 있어야 하므로 폐쇄 OS (오래된 Windows) 에는 부적합
원조: Xen (2003 년 케임브리지)
오늘날 순수 paravirt 는 드물고, 하이브리드 (하드웨어 지원 + paravirt 드라이버) 형태가 표준

3. OS-Level Virtualization (Containers)

Hypervisor 가 아니라 커널 자체가 여러 격리된 실행 환경 을 제공합니다.

같은 커널을 공유하지만 [[cgroups-namespaces|namespaces]] 로 프로세스/파일시스템/네트워크 뷰를 분리
[[cgroups-namespaces|cgroups]] 로 CPU/메모리 사용량 제한
커널 부팅 없음 → 부팅이 순식간
예: [[docker|Docker]], [[lxc-system-containers|LXC/LXD]], Podman, systemd-nspawn, FreeBSD Jails, Solaris Zones

4. Application Virtualization

앱 자체를 언어 런타임이나 샌드박스로 격리합니다.

JVM (Java): 바이트코드를 어느 OS/CPU 에서도 실행
WebAssembly (Wasm): 브라우저 및 서버 (Wasmtime, Wasmer) 에서 안전한 실행
Firecracker: AWS 가 만든 초경량 hypervisor (Lambda 에서 사용), 애플리케이션 가상화라기보다 microVM 이지만 경계에 위치

계층 비교

{}

핵심은 “어디까지 공유하는가” 입니다.

VM: 하드웨어만 공유 (커널, libs, app 모두 게스트 각자)
Container: 커널까지 공유 (libs, app 만 각자)
Application VM: OS 까지 공유 (런타임과 앱만 격리)

공유 범위가 넓을수록 가볍고 빠르지만, 격리 강도는 약해집니다. 가벼움 vs 격리 트레이드오프.

종합 비교표

축	Full Virtualization (VM)	Paravirtualization	Container (OS-level)	App VM
격리 대상	하드웨어	하드웨어 (수정된 게스트)	프로세스 그룹	프로세스
커널	게스트 각자	게스트 각자 (hypercall)	host 공유	host 공유
부팅 시간	분 단위	수초 ~ 분	초 단위	밀리초
오버헤드	중간 (하드웨어 가속으로 완화)	낮음	매우 낮음	최저
격리 강도	강함	강함	중간 (커널 취약점 공유)	약함
밀도	서버당 수십 개	서버당 수십 개	서버당 수백~수천 개	프로세스만큼
이미지 크기	GB 단위	GB 단위	MB 단위	KB ~ MB
대표	KVM, ESXi, Hyper-V	Xen, KVM+virtio	Docker, LXC	JVM, Wasm

언제 무엇을 쓰는가

VM 이 유리한 경우

다른 커널이 필요할 때 (Linux 위에서 Windows 실행)
강한 격리가 필수 (멀티테넌트 클라우드, 규제 산업)
커널 수준 튜닝이 필요할 때 (실시간 커널, 커스텀 모듈)
이식 대상이 다른 CPU 아키텍처 (QEMU 로 x86 → ARM 에뮬레이션)

Container 가 유리한 경우

개발/운영 환경 일치 (dev = staging = prod)
마이크로서비스 (하나에 수십~수백 서비스 배포)
빠른 스케일링 (몇 초 안에 새 인스턴스)
자원 밀도가 중요 (같은 하드웨어에 더 많이)

하이브리드

현대 클라우드는 두 층 모두 씁니다.

물리 서버 → 여러 [[virtual-machine|VM]] (예: EC2 인스턴스)
각 VM 안에 여러 [[docker|Container]] (예: 쿠버네티스 파드)

AWS Fargate, Google Cloud Run 은 하나의 컨테이너를 microVM 안에 실행 하는 방식으로 컨테이너의 편의와 VM 의 격리를 결합합니다 (Firecracker, gVisor).

하드웨어 지원

CPU 가 가상화를 도와주는 기능들:

Intel VT-x / AMD-V: 특권 명령 트랩을 하드웨어 수준에서 지원
Intel EPT / AMD RVI: 게스트-호스트 페이지 테이블 이중 관리를 하드웨어로 (nested paging)
VT-d / AMD-Vi (IOMMU): 게스트가 특정 PCI 디바이스를 직접 접근하도록 안전하게 매핑
SR-IOV: NIC 하나를 여러 게스트가 하드웨어 레벨로 나누어 사용
APICv, GICv3: 인터럽트 가상화

이 지원들 덕에 오늘날 VM 오버헤드는 대부분의 워크로드에서 5% 미만입니다.

성능 오버헤드가 발생하는 지점

VM 이 왜 느린가:

CPU 특권 명령 트랩: 하드웨어 지원으로 크게 완화됨
메모리 접근: 게스트 물리 → 호스트 물리 이중 변환 (EPT 도움)
I/O: 디스크/네트워크가 hypervisor 를 경유 (virtio 로 완화)
부팅 시간: 게스트 커널을 매번 부팅해야 함

Container 가 왜 빠른가:

커널 공유: 게스트 커널 부팅 자체가 없음
직접 시스템콜: 게스트 커널 트랩이 없어 syscall 오버헤드 최소
이미지 크기: MB 단위, 다운로드/실행 빠름
CoW 파일시스템: 여러 컨테이너가 read-only 레이어를 공유

함정과 오해

”Container 는 항상 빠르다”

Startup 은 확실히 빠릅니다
하지만 런타임 CPU/메모리 성능 은 VM 과 큰 차이 없습니다 (하드웨어 가속으로 VM 도 빠름)
밀도 (같은 하드웨어에 몇 개 얹을 수 있는가) 관점에서 컨테이너가 유리

”VM 은 격리가 완벽하다”

이론적으로는 강한 격리
하지만 Spectre, Meltdown 같은 CPU-level 취약점은 VM 경계를 넘습니다
Row Hammer 같은 DRAM 공격도 이론적으로 가능
완벽한 격리는 없음, “충분히 강한 격리” 만 있습니다

”Container 는 격리가 약하다”

Docker default 로는 root capability, seccomp filter, AppArmor 등 여러 방어층이 이미 켜져 있습니다
gVisor (Google) 나 Kata Containers 는 컨테이너를 microVM 안에서 실행하여 격리를 강화합니다
Firecracker (AWS Lambda) 도 이 계열

”가상화는 오버헤드가 크다”

2005 년 이전에는 사실이었습니다
하드웨어 지원 이후 대부분의 워크로드에서 5% 미만
예외: CPU 밀집형 (HFT), GPU 가상화 (NVIDIA vGPU 는 여전히 특수한 기술)

참고

관련 [[hypervisor|Hypervisor Type 1 vs Type 2]]
관련 [[virtual-machine|Virtual Machine 개념]]
관련 [[docker|Docker]]
관련 [[lxc-system-containers|LXC / LXD]]
관련 [[cgroups-namespaces|cgroups + namespaces]]
관련 [[vm-vs-container|VM vs Container 심층 비교]]
Xen 논문: Xen and the Art of Virtualization
Wikipedia: Hardware virtualization

[Container] cgroups + namespaces: 컨테이너의 두 기둥

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

컨테이너 = namespaces + cgroups + 파일시스템 (overlay). VM 이 아니라 host 의 프로세스 + 격리.

flowchart LR
    Container[Container]
    Container --> NS["Namespaces<br/>(격리)"]
    Container --> CG["cgroups<br/>(자원 제한)"]
    Container --> FS["Overlay FS<br/>(layered FS)"]

Namespaces (격리)

Namespace	격리 대상
`pid`	프로세스 ID (안에서 PID=1)
`mnt`	파일시스템 마운트
`net`	네트워크 인터페이스, 라우팅, 방화벽
`uts`	hostname, domain
`ipc`	System V IPC, POSIX msg queue
`user`	UID/GID 매핑 (root in container ≠ root in host)
`cgroup`	cgroup root
`time`	clock

# 새 namespace 에서 명령 실행
unshare --pid --mount --net --fork bash

cgroups (자원 제한)

flowchart TB
    Root[/sys/fs/cgroup/]
    Root --> ContainerA[container-a/]
    Root --> ContainerB[container-b/]
    ContainerA --> CPU["cpu.max = 50000 100000<br/>(50% CPU)"]
    ContainerA --> Mem[memory.max = 512M]
    ContainerA --> IO[io.max = read 100MB/s]
    ContainerB --> CPU2[cpu.max = 200000 100000]
    ContainerB --> Mem2[memory.max = 2G]

Controller	제한
`cpu`	CPU 시간
`memory`	RAM + swap
`io`	block I/O
`pid`	프로세스 수
`network` (BPF)	NIC bandwidth
`hugetlb`	huge pages

cgroup v1 vs v2

	v1	v2
출시	2007	2016
계층	controller 별 다수	단일 통합 계층
권장	legacy	모든 현대 distro

Ubuntu 22.04+, Fedora 31+, K8s 1.25+ 가 cgroup v2 기본.

OCI Runtime spec 에서

{
  "linux": {
    "namespaces": [
      { "type": "pid" },
      { "type": "network" },
      { "type": "ipc" },
      { "type": "uts" },
      { "type": "mount" }
    ],
    "resources": {
      "memory": { "limit": 536870912 },
      "cpu": { "shares": 1024, "quota": 50000, "period": 100000 }
    }
  }
}

OOM kill (cgroup memory)

sequenceDiagram
    Container->>OS: allocate memory (RAM 부족)
    OS-->>Container: ENOMEM 또는 OOM kill
    Note over OS: cgroup memory.max 초과
    OS->>Container: SIGKILL (즉시)

[!CAUTION] Memory limit 초과 = SIGKILL (graceful 없음). 애플리케이션이 준비 안 됨. limit 보수적으로.

User Namespace

container 내부 root (uid 0)
host: uid 100000 (제한된 일반 사용자)

컨테이너 내부 root 가 host root 아님. 보안 강화. rootless container (podman) 의 토대.

OverlayFS

lowerdir (read-only): image layers
upperdir (read-write): container 변경
merged: 통합 view

{}

Layered FS 의 append-only 동작 직관 (Linked list 의 읽기 시 위에서 아래로 와 유사).

흔한 함정

[!WARNING]

--privileged = 모든 namespace 해제. 컨테이너 의미 없음. capabilities 만 추가.

호스트 PID/IPC/Network 공유 = 컨테이너 = host process. 격리 없음.

CPU limit 의 throttle = container 가 느려짐 (kill 아님). 메트릭으로 확인.

Memory limit 너무 작음 = OOM kill 반복. 측정.

[Container] Docker: image, layer, registry

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

정의

Docker = 컨테이너 빌드 + 실행 + 배포 의 표준 도구. 2013 출시 → 컨테이너 시대 의 시작. 현재는 OCI 표준 으로 진화 (containerd, runc, podman 등 호환).

Layered Filesystem

flowchart TB
    Base["base: ubuntu:24.04"]
    Base --> L1["L1: apt install nginx"]
    L1 --> L2["L2: COPY config /etc/nginx/"]
    L2 --> L3["L3: COPY app /var/www/"]
    L3 --> Image[Final Image]
    Image --> RW["R/W layer (container 실행 시)"]

각 Dockerfile instruction = 별도 layer. 불변 + 재사용 (cache).

Dockerfile

# 멀티 스테이지 빌드
FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:alpine AS runtime
COPY --from=builder /app/dist /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

instruction	의미
`FROM`	base image
`WORKDIR`	작업 디렉토리
`COPY` / `ADD`	파일 복사
`RUN`	빌드 시 실행
`CMD` / `ENTRYPOINT`	컨테이너 시작 명령
`EXPOSE`	포트 (문서화, 자동 노출 아님)
`ENV`	환경 변수
`ARG`	빌드 시 변수
`VOLUME`	mount point
`USER`	실행 사용자
`HEALTHCHECK`	health probe

멀티 스테이지 빌드

flowchart LR
    Stage1["Stage 1: builder<br/>(큰 dependency)"] -->|결과물만 복사| Stage2["Stage 2: runtime<br/>(작은 base)"]

빌드 도구는 final image 에 안 들어감. 최종 image 가 작고 안전.

Image Registry

Registry	특징
Docker Hub	공식, rate limit
GHCR (GitHub)	github 통합
ECR (AWS)	IAM 통합
Artifact Registry (GCP)	GCP 통합
Harbor	self-host

Build vs Buildx (BuildKit)

# 옛 docker build
docker build -t myapp .

# Buildx (멀티 아키 + 캐시 + 병렬)
docker buildx build --platform linux/amd64,linux/arm64 -t myapp --push .

BuildKit 가 2026 표준. ARM/x86 멀티 아키 동시 build + 효율적 cache.

.dockerignore

node_modules
.git
.env
**/*.log
dist

.gitignore 같은. build context 작게 → 빠른 build.

Layer Cache 활용

# ❌ 의존성과 코드 같이 복사 → 코드 변경 시 npm ci 재실행
COPY . .
RUN npm ci

# ✅ 의존성 먼저
COPY package*.json ./
RUN npm ci
COPY . .

흔한 함정

[!WARNING]

latest tag = build 마다 다른 결과. 명시 tag 또는 digest sha256.

root 사용자 = 보안 위험. USER 1000 명시.

secret 을 ENV / ARG = image layer 에 평문 남음. BuildKit --secret.

거대한 image = transfer 느림. distroless / scratch / alpine 활용.

[Container] Image Best Practices: 작게, 안전하게

koa (김신건) — Thu, 25 Jun 2026 00:00:00 GMT

5가지 원칙

flowchart TB
    Q[Image Best Practices]
    Q --> Small[1. 작게]
    Q --> Sec[2. 안전하게]
    Q --> Cache[3. Layer cache 활용]
    Q --> Repro[4. Reproducible]
    Q --> Sign[5. Sign + Scan]

1. Base Image 선택

Base	크기	적합
`ubuntu:24.04`	~70 MB	개발 / 디버깅 친화
`debian:12-slim`	~40 MB	일반
`alpine:3.20`	~5 MB	작음, musl libc (glibc 의존성 주의)
`distroless/static`	~2 MB	Go / Rust 정적 binary
`distroless/nodejs22`	~150 MB	Node, 안전
`distroless/java21`	~200 MB	Java
`scratch`	0	정적 binary 만

Distroless = shell / package manager 없음. 공격 면 감소. Google 권장.

2. Multi-stage build

FROM golang:1.23 AS builder
WORKDIR /src
COPY go.* ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /app ./cmd/server

FROM gcr.io/distroless/static:nonroot
COPY --from=builder /app /app
USER nonroot:nonroot
ENTRYPOINT ["/app"]

최종 image 에 빌드 도구 없음. 수십 MB → 수 MB.

3. Layer Cache

# ❌ 모든 코드 복사 후 install
COPY . .
RUN npm ci

# ✅ 의존성 파일만 먼저
COPY package*.json ./
RUN npm ci
COPY . .

코드 변경 시 npm ci layer 캐시 활용. 빌드 시간 수배 단축.

4. Non-root User

RUN addgroup -g 1000 app && adduser -D -u 1000 -G app app
USER 1000:1000

또는 distroless 의 :nonroot.

5. Secret 처리

# BuildKit secret (image layer 에 안 남음)
RUN --mount=type=secret,id=npmrc cp /run/secrets/npmrc ~/.npmrc \
    && npm ci

docker buildx build --secret id=npmrc,src=$HOME/.npmrc .

[!CAUTION] ARG / ENV 로 secret 전달 절대 금지. layer 에 영구 남음.

6. .dockerignore

node_modules
.git
.env
**/*.log
.DS_Store
dist
coverage

7. HEALTHCHECK

HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
  CMD curl -f http://localhost:8080/health || exit 1

K8s 에서는 Liveness/Readiness probe 가 우선이지만 docker run 환경에서는 HEALTHCHECK 가 유용.

8. Image Scan

trivy image myapp:1.0
# CVE 검사

cosign sign myapp:1.0
cosign verify myapp:1.0
# 서명 + 검증

syft myapp:1.0 -o spdx-json > sbom.json
# SBOM 생성

도구	용도
Trivy	CVE / misconfig scan
Grype	CVE scan
Cosign	서명 + verify
Syft	SBOM 생성
Notary	image trust

9. Reproducible Build

ARG BUILD_DATE
ARG GIT_SHA
LABEL org.opencontainers.image.created=$BUILD_DATE
LABEL org.opencontainers.image.revision=$GIT_SHA

같은 입력 → 같은 output. supply chain security 의 토대.

흔한 함정

[!WARNING]

apt install ... && apt clean 한 줄로 = layer 작아짐. 별도 RUN 이면 clean 효과 없음.

COPY . /app = .dockerignore 없으면 .git, node_modules 까지.

latest tag = build 마다 다른 결과.

root 사용자 + privileged = 컨테이너 의미 없음.