김신건의 로그 - 위키 / virtualization

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

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

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

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

VM 은 hypervisor + 별도 커널, 컨테이너는 host 커널 공유. 시작 속도 수 ms vs 수 초.

컨테이너 생성 과정

sequenceDiagram
    participant CLI as docker run
    participant D as containerd
    participant Runc as runc
    participant OS as Linux Kernel

    CLI->>D: 컨테이너 생성 요청
    D->>Runc: OCI bundle (config.json + rootfs)
    Runc->>OS: clone(CLONE_NEWPID|CLONE_NEWNET|CLONE_NEWNS|...)
    OS-->>Runc: 새 namespace pid=1
    Runc->>OS: cgroup 설정 (memory.max, cpu.max)
    Runc->>OS: mount overlay filesystem
    Runc->>OS: exec (container entrypoint)
    OS-->>CLI: 컨테이너 실행 중

Namespaces (격리)

Linux 8가지 namespace 로 컨테이너 격리:

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

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

# 컨테이너 namespace 확인
ls -la /proc/$(docker inspect --format='{{.State.Pid}}' my-container)/ns/

# namespace 종류별 ID (같은 숫자 = 공유)
lsns -p $(docker inspect --format='{{.State.Pid}}' my-container)

PID Namespace 심화

Host                 Container
------               ----------
PID 1: systemd       PID 1: nginx (container init)
PID 2: kthread       PID 2: nginx worker
PID 100: dockerd     (host PIDs 불가시)
PID 234: nginx       (동일 프로세스, host 는 234로 봄)

컨테이너 안 PID 1 이 종료되면 컨테이너 전체 종료. SIGTERM 핸들러 필수.

# PID 1 문제 해결: init process 사용
FROM node:22-alpine
RUN apk add --no-cache tini
ENTRYPOINT ["/sbin/tini", "--"]
CMD ["node", "server.js"]

tini/dumb-init = zombie reaping + SIGTERM 전파. 직접 CMD ["node"] 하면 zombie process 누적.

Network Namespace 심화

Host network namespace:
  eth0: 192.168.1.10
  docker0 (bridge): 172.17.0.1

Container network namespace:
  eth0 (veth pair): 172.17.0.2
  lo: 127.0.0.1

# container 의 network namespace 진입
nsenter --target $(docker inspect --format='{{.State.Pid}}' c1) \
        --net -- ip addr show

# veth pair 확인 (host side)
ip link show type veth

cgroups (자원 제한)

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

Controller	제한 대상	파일
`cpu`	CPU 시간	`cpu.max`
`memory`	RAM + swap	`memory.max`, `memory.swap.max`
`io`	block I/O	`io.max`
`pid`	프로세스 수	`pids.max`
`cpuset`	CPU core 지정	`cpuset.cpus`
`hugetlb`	huge pages	`hugetlb.*.max`

# cgroup v2 확인
cat /sys/fs/cgroup/cgroup.controllers
# output: cpuset cpu io memory hugetlb pids rdma misc

# container cgroup 확인
cat /sys/fs/cgroup/system.slice/docker-<id>.scope/memory.current
cat /sys/fs/cgroup/system.slice/docker-<id>.scope/cpu.stat

cgroup v1 vs v2

	v1	v2
출시	2007	2016 (kernel 4.5)
계층	controller 별 다수 트리	단일 통합 계층
파일시스템	`/sys/fs/cgroup/{cpu,memory,...}/`	`/sys/fs/cgroup/` 하나
thread granularity	없음	thread-level 제어 가능
권장	legacy	모든 현대 distro 기본
K8s 지원	deprecated (1.25+)	기본 (1.25+)

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

cgroup v2 CPU 제한 예시

# CPU 50% 제한 (50ms / 100ms period)
echo "50000 100000" > /sys/fs/cgroup/mycontainer/cpu.max

# Docker 설정
docker run --cpus="0.5" --memory="512m" nginx

# K8s 설정 (내부적으로 cgroup 설정)
resources:
  limits:
    cpu: "500m"
    memory: "512Mi"

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
    participant App as Container App
    participant OS as Linux Kernel

    App->>OS: malloc() (RAM 부족)
    OS-->>OS: cgroup memory.max 초과 감지
    OS->>App: SIGKILL (즉시)
    Note over App,OS: OOM Killer 발동, graceful shutdown 없음

[!CAUTION] Memory limit 초과 = SIGKILL (graceful 없음). K8s 는 OOMKilled 로 표시. limit 을 측정 후 여유 있게.

# OOM kill 확인
dmesg | grep -i "oom"
kubectl describe pod mypod | grep -A5 "OOMKilled"

User Namespace

Container:           Host:
root (uid 0)    =>  uid 100000
user1 (uid 1)   =>  uid 100001

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

# rootless Podman (host uid 1000 사용자로 실행)
podman run --rm ubuntu id
# uid=0(root) gid=0(root) ... (container 내부는 root 처럼 보임)

# 실제 host 에서 확인
cat /proc/$(pgrep -n bash)/status | grep Uid
# Uid: 100000  100000 ...  (실제 제한된 uid)

Docker 는 userns-remap 설정 필요. Podman 은 기본 지원.

OverlayFS

lowerdir (read-only): image layers (L1, L2, L3 ...)
upperdir (read-write): container 변경사항
merged:               통합 view (container 가 보는 FS)
workdir:              OverlayFS 내부 작업 디렉토리

# OverlayFS 마운트 확인
mount | grep overlay
# overlay on /var/lib/docker/overlay2/<id>/merged type overlay
#   (lowerdir=<L3>:<L2>:<L1>,upperdir=<upper>,workdir=<work>)

# container 에서 파일 수정 시
# → upperdir 에만 기록 (lowerdir 불변)
# → 삭제는 whiteout 파일로 표시

흔한 함정

[!WARNING]

--privileged = 모든 namespace 해제 + 모든 capability. 컨테이너 = host process. capabilities 만 추가 (--cap-add).

호스트 PID/IPC/Network 공유 = --pid=host 등. 격리 완전히 없어짐.

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

Memory limit 너무 작음 = OOM kill 반복. 실제 사용량 측정 후 설정.

PID 1 에 signal 핸들러 없음 = SIGTERM 무시, K8s graceful shutdown 실패. tini 사용.

[Container] Docker: image, layer, registry

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

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

컨테이너 런타임 생태계

flowchart TB
    Docker["Docker CLI / Compose"]
    Podman["Podman CLI"]
    K8s["Kubernetes kubelet"]

    Docker --> DockerD["dockerd (daemon)"]
    Podman --> PodmanLib["libpod (daemonless)"]
    K8s --> CRI["CRI (Container Runtime Interface)"]

    DockerD --> Containerd["containerd"]
    PodmanLib --> Containerd
    CRI --> Containerd

    Containerd --> Runc["runc (OCI Runtime)"]
    Containerd --> GVisor["gVisor (sandboxed)"]
    Containerd --> Kata["Kata Containers (VM)"]
    Runc --> Linux["Linux kernel (namespaces + cgroups)"]

런타임	특징
dockerd	전통 Docker daemon, 개발 환경 표준
containerd	CNCF graduated, K8s 표준 CRI
Podman	daemonless, rootless 지원, systemd 통합
gVisor	사용자 공간 커널, 보안 강화 (Google Cloud Run)
Kata Containers	VM 기반 격리, 강한 보안

2026 시점 프로덕션 K8s = containerd. 개발 편의는 Docker. 보안 우선 = Podman.

OCI 표준

Open Container Initiative = image + runtime 표준화.

스펙	내용
OCI Image Spec	image manifest, config, layer (tar.gz)
OCI Runtime Spec	container 생성/실행 (runc 구현)
OCI Distribution Spec	registry API (push/pull)

// OCI Image Manifest (요약)
{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "config": { "mediaType": "application/vnd.oci.image.config.v1+json", "size": 1234 },
  "layers": [
    { "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip", "size": 7023, "digest": "sha256:abc..." },
    { "mediaType": "application/vnd.oci.image.layer.v1.tar+gzip", "size": 1234, "digest": "sha256:def..." }
  ]
}

OCI 표준 덕분에 Docker build 로 만든 image 를 Podman run / K8s 가 그대로 실행.

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 (큰 dependency)"] -->|"결과물만 COPY --from"| Stage2["Stage 2: runtime (작은 base)"]

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

# Go: 정적 binary → distroless
FROM golang:1.23 AS builder
WORKDIR /src
COPY go.* ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /bin/server ./cmd/server

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

BuildKit (현대 빌드)

# BuildKit 활성화 (Docker 23+ 기본)
DOCKER_BUILDKIT=1 docker build .

# 멀티 아키텍처 빌드
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t myapp:latest \
  --push .

# 캐시 마운트 (apt / npm 캐시 재사용)
RUN --mount=type=cache,target=/var/cache/apt \
    apt-get update && apt-get install -y build-essential

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

BuildKit 기능	효과
캐시 마운트	apt/npm 캐시 재사용, 빌드 수분 → 수초
Secret 마운트	평문 secret 이 layer 에 안 남음
멀티 아키	ARM + x86 동시 빌드
병렬 stage	독립 stage 병렬 실행

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

Image Registry

Registry	특징
Docker Hub	공식, rate limit (anonymous 100 pulls/6h)
GHCR (GitHub)	github 통합, free for public
ECR (AWS)	IAM 통합, 동일 region 무료
Artifact Registry (GCP)	GCP 통합
Harbor	self-host, RBAC + 취약점 스캔

Podman: daemonless 대안

# Docker 대체 명령 (거의 동일 CLI)
podman build -t myapp .
podman run -d -p 8080:80 myapp
podman compose up -d

# rootless: root 없이 컨테이너 실행
podman run --rm --userns=keep-id myapp

	Docker	Podman
Daemon	있음 (dockerd)	없음 (fork-exec)
Rootless	제한적	완전 지원
systemd 통합	수동	`podman generate systemd`
K8s 호환	containerd shim	동일
Windows/Mac	Docker Desktop	가상화 (Podman Machine)

Docker Networking

# 기본 bridge network
docker run -p 8080:80 nginx

# 사용자 정의 bridge (컨테이너간 DNS 이름 해석)
docker network create mynet
docker run --network mynet --name api myapi
docker run --network mynet --name db postgres

# host network (Linux only, 포트 매핑 없이 직접)
docker run --network host nginx

Network 모드	설명
`bridge`	기본, 격리된 가상 LAN
`host`	host 네트워크 공유 (Linux, 성능 최적)
`none`	네트워크 없음 (완전 격리)
`overlay`	Docker Swarm 멀티 호스트

Docker Compose

# compose.yml
services:
  api:
    build: .
    ports:
      - "8080:8080"
    environment:
      - DATABASE_URL=postgresql://db:5432/app
    depends_on:
      db:
        condition: service_healthy
    restart: unless-stopped

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_PASSWORD: secret
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  pgdata:

docker compose up -d
docker compose logs -f api
docker compose down -v   # volume 포함 삭제

Layer Cache 활용

# 의존성 파일만 먼저 복사 → cache hit
COPY package*.json ./
RUN npm ci              # package.json 변경 시에만 재실행

# 이후 소스 복사
COPY . .
RUN npm run build

# BuildKit cache 마운트로 npm cache 재사용
RUN --mount=type=cache,target=/root/.npm \
    npm ci

.dockerignore

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

.gitignore 같은. build context 작게 → 빠른 build + context 전송 감소.

흔한 함정

[!WARNING]

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

root 사용자 = 보안 위험. USER 1000 명시. K8s PodSecurityPolicy 도 차단.

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

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

COPY . . 를 의존성 이전에 = 코드 변경 시 의존성 재설치. 순서 중요.

RUN 여러 줄 분리 = 각각 layer. && \ 로 하나의 RUN 으로 합치기.

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

koa (김신건) — Wed, 15 Jul 2026 00:00:00 GMT

정의

컨테이너 image best practices = 작고 (small), 안전하고 (secure), 재현 가능하고 (reproducible), 서명된 (signed) image 를 만드는 원칙.

5가지 원칙

flowchart TB
    Q[Image Best Practices]
    Q --> Small["1. 작게 (distroless / alpine)"]
    Q --> Sec["2. 안전하게 (non-root, secret)"]
    Q --> Cache["3. Layer cache 활용"]
    Q --> Repro["4. Reproducible (pin version)"]
    Q --> Sign["5. Sign + Scan (Cosign, Trivy)"]

1. Base Image 선택

Base	크기	musl/glibc	적합
`ubuntu:24.04`	~70 MB	glibc	개발 / 디버깅 친화
`debian:12-slim`	~40 MB	glibc	일반 범용
`alpine:3.20`	~5 MB	musl	작음, glibc 의존성 주의
`distroless/static`	~2 MB	-	Go / Rust 정적 binary
`distroless/cc`	~20 MB	glibc	C 라이브러리 필요
`distroless/nodejs22`	~150 MB	glibc	Node.js, 안전
`distroless/java21`	~200 MB	glibc	Java (JRE 포함)
`distroless/python3`	~50 MB	glibc	Python
`scratch`	0	-	정적 binary 전용

Distroless = shell / package manager / OS 유틸 없음. 공격 면 감소. CVE 도 줄어듦. Google 권장.

# 크기 비교
docker pull ubuntu:24.04 && docker image ls ubuntu
docker pull gcr.io/distroless/static:nonroot && docker image ls gcr.io/distroless/static

2. Multi-stage build

Go + distroless

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

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

Node.js + distroless

FROM node:22-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM gcr.io/distroless/nodejs22:nonroot
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist
USER nonroot:nonroot
CMD ["dist/server.js"]

Java + distroless

FROM gradle:8.5-jdk21 AS builder
WORKDIR /src
COPY . .
RUN gradle bootJar --no-daemon

FROM gcr.io/distroless/java21:nonroot
COPY --from=builder /src/build/libs/app.jar /app.jar
USER nonroot:nonroot
ENTRYPOINT ["java", "-jar", "/app.jar"]

최종 image 에 빌드 도구 없음. JDK 대신 JRE / distroless 사용으로 수백 MB 절감.

3. Layer Cache 최적화

flowchart LR
    Bad["COPY . .\nRUN npm ci\n(코드 1줄 변경 = npm ci 재실행)"]
    Good["COPY package*.json ./\nRUN npm ci\nCOPY . .\n(package.json 변경 시에만 npm ci)"]
    Bad -->|"최적화"| Good

# ✅ 의존성 파일 먼저, 소스 나중
COPY package*.json ./
RUN npm ci
COPY . .

# ✅ BuildKit 캐시 마운트 (패키지 캐시 영속)
RUN --mount=type=cache,target=/root/.npm \
    npm ci

# ✅ apt 캐시 마운트
RUN --mount=type=cache,target=/var/cache/apt \
    apt-get update && apt-get install -y --no-install-recommends \
    build-essential \
    && rm -rf /var/lib/apt/lists/*

BuildKit 캐시 마운트 = npm / pip / apt 캐시를 build 간 재사용. CI 에서 수분 단축.

4. Non-root User

# Alpine 방식
RUN addgroup -g 1000 appuser && \
    adduser -D -u 1000 -G appuser appuser
USER appuser:appuser

# Debian/Ubuntu 방식
RUN groupadd -g 1000 appuser && \
    useradd -r -u 1000 -g appuser appuser
USER appuser:appuser

# distroless 내장
FROM gcr.io/distroless/static:nonroot
USER nonroot:nonroot   # uid 65532

# K8s PodSecurityContext
securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  runAsGroup: 1000
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false

K8s 1.23+ Restricted PodSecurityStandard = runAsNonRoot: true 강제. 미리 맞춰야 배포 됨.

5. Secret 처리

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

# pip private index
RUN --mount=type=secret,id=pip_conf \
    PIP_CONFIG_FILE=/run/secrets/pip_conf pip install -r requirements.txt

docker buildx build \
  --secret id=npmrc,src=$HOME/.npmrc \
  --secret id=pip_conf,src=$HOME/.pip/pip.conf \
  .

[!CAUTION] ARG / ENV / COPY 로 secret 전달 절대 금지. docker history 로 layer 평문 확인 가능. BuildKit --secret 만 사용.

6. .dockerignore

# 불필요 파일 제외 (build context 최소화)
node_modules
.git
.env
.env.*
**/*.log
.DS_Store
dist
coverage
.vscode
.idea
*.md
tests
docs

7. HEALTHCHECK

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

# wget 사용 (curl 없는 경우)
HEALTHCHECK --interval=30s --timeout=5s \
  CMD wget -qO- http://localhost:8080/health || exit 1

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

8. Image Scan + 서명

# CVE 스캔 (Trivy)
trivy image --severity HIGH,CRITICAL myapp:1.0

# Grype 스캔
grype myapp:1.0

# 서명 (Cosign + Sigstore)
cosign sign --key cosign.key myapp:1.0
cosign verify --key cosign.pub myapp:1.0

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

# SBOM 취약점 검사
grype sbom:sbom.json

도구	용도
Trivy	CVE / misconfig / secret scan (가장 많이 씀)
Grype	CVE scan (Anchore)
Cosign	image 서명 + verify (keyless 지원)
Syft	SBOM 생성 (SPDX, CycloneDX)
Notary v2	image trust, CNCF 표준

9. Dive: Layer 분석

# 설치
brew install dive

# image layer 분석 (크기 + 파일 변화)
dive myapp:1.0

# CI 모드: efficiency < 90% 이면 실패
CI=true dive --ci-config .dive-ci.yml myapp:1.0

# .dive-ci.yml
rules:
  lowestEfficiency: 0.9
  highestWastedBytes: "20MB"
  highestUserWastedPercent: 0.1

Dive = 각 layer 에서 추가/삭제된 파일 시각화. 불필요 파일 찾기 최고 도구.

10. Reproducible Build + OCI Labels

ARG BUILD_DATE
ARG GIT_SHA
ARG VERSION

LABEL org.opencontainers.image.created=$BUILD_DATE
LABEL org.opencontainers.image.revision=$GIT_SHA
LABEL org.opencontainers.image.version=$VERSION
LABEL org.opencontainers.image.source="https://github.com/myorg/myapp"
LABEL org.opencontainers.image.licenses="Apache-2.0"

docker buildx build \
  --build-arg BUILD_DATE=$(date -u +"%Y-%m-%dT%H:%M:%SZ") \
  --build-arg GIT_SHA=$(git rev-parse HEAD) \
  --build-arg VERSION=1.2.3 \
  -t myapp:1.2.3 .

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

빌드 최적화 체크리스트

항목	확인
Multi-stage build 사용	빌드 도구 final image 에 없음
Base image pin (`:22-alpine@sha256:...`)	digest 고정
`.dockerignore` 작성	context < 10MB 목표
의존성 파일 먼저 COPY	layer cache 활용
Non-root USER	uid 1000 이상
Secret = `--mount=type=secret`	ARG/ENV 금지
`apt-get clean` 같은 RUN 줄	별도 layer 아님
Trivy scan CI 통합	HIGH/CRITICAL 0건 목표
Cosign 서명	supply chain

흔한 함정

[!WARNING]

apt install ... && apt clean 여러 RUN = clean 이 별도 layer. 하나의 RUN + && 으로 합치기.

COPY . /app = .dockerignore 없으면 .git, node_modules 까지 포함. context 폭발.

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

root 사용자 + privileged = K8s Restricted Policy 거부. 미리 non-root.

base image 를 자주 갱신 안 함 = CVE 누적. 자동 Renovate / Dependabot 으로 주기 갱신.

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

{}

flowchart TB
    subgraph T1["Type 1: Bare Metal"]
        HW1["물리 하드웨어"]
        HW1 --> HV1["Hypervisor"]
        HV1 --> G1["Guest VM 1"]
        HV1 --> G2["Guest VM 2"]
    end
    subgraph T2["Type 2: Hosted"]
        HW2["물리 하드웨어"]
        HW2 --> OS2["Host OS (macOS, Windows, Linux)"]
        OS2 --> HV2["Hypervisor App (VirtualBox, VMware Fusion)"]
        HV2 --> G3["Guest VM 1"]
        HV2 --> G4["Guest VM 2"]
    end

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)

Trap-and-Emulate (가상화 핵심 메커니즘)

게스트 OS 가 특권 명령 (privileged instruction) 을 실행하려 할 때:

CPU 가 trap 을 발생시켜 hypervisor 로 제어 이전
Hypervisor 가 해당 명령을 에뮬레이트 (실제 효과를 시뮬레이션)
결과를 게스트에게 돌려주고 게스트 실행 재개

비특권 명령은 하드웨어에서 직접 실행 (Popek & Goldberg “효율성” 조건).

flowchart LR
    Guest["Guest OS\n(Ring 3 or Ring 1)"]
    Guest -->|"일반 명령"| HW["하드웨어 직접 실행"]
    Guest -->|"특권 명령 시도"| Trap["CPU Trap (VM-Exit)"]
    Trap --> HV["Hypervisor (Ring -1)"]
    HV -->|"에뮬레이트 후"| VMEntry["VM-Entry (게스트 복귀)"]
    VMEntry --> Guest

VT-x/AMD-V 가 없던 시절 x86 은 일부 sensitive instruction 이 trap 을 발생시키지 않아 binary translation (실행 전 코드를 재작성) 이 필요했습니다.

하드웨어 지원

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 좋음)	낮음	매우 낮음

microVM 트렌드 (Firecracker / gVisor)

전통적인 VM 은 부팅에 수십 초가 걸려 서버리스/컨테이너 밀도에 적합하지 않았습니다. 이를 해결하기 위해 microVM 이 등장했습니다.

제품	기반	부팅	격리	사용처
Firecracker	KVM + Rust	~125ms	VM 수준	AWS Lambda, Fargate
Cloud Hypervisor	KVM + Rust	~150ms	VM 수준	Intel, MS Azure
gVisor	시스템콜 인터셉트	즉시	OS 수준 (일부)	Google Cloud Run
Kata Containers	KVM / QEMU	~1s	VM 수준	OCI 호환 컨테이너 런타임

Firecracker 의 핵심 설계:

디바이스 에뮬레이션 최소화 (virtio-net, virtio-blk 만)
네트워크, 스토리지, 직렬 포트 외 미지원 (대신 가볍고 빠름)
Rust 로 작성해 메모리 안전성 보장

Kata Containers 는 OCI/CRI 인터페이스를 그대로 사용하므로 Kubernetes 와 바로 통합됩니다.

Hypervisor 선택 가이드

상황	권장
Linux 서버 / 클라우드 기반 구성	KVM + libvirt
엔터프라이즈 데이터센터, vMotion 필요	VMware ESXi / vSphere
Windows 서버 / Azure 연동	Hyper-V
개발자 로컬 (데스크톱)	VirtualBox 또는 Parallels (macOS)
서버리스, 컨테이너 격리 강화	Firecracker 또는 Kata Containers
크로스 아키텍처 에뮬레이션 (ARM on x86)	QEMU

함정

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

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

flowchart TB
    K["Linux Kernel<br/>namespaces + cgroups"]
    K --> SC["System Container (LXC)"]
    K --> AC["Application Container (Docker)"]

    subgraph SC["System Container (LXC)"]
        Init["init / systemd (PID 1)"] --> Nginx["nginx"]
        Init --> Rails["rails app"]
        Init --> Cron["crond"]
        Init --> SSH["sshd"]
    end

    subgraph AC["Application Container (Docker)"]
        Proc["앱 프로세스 (PID 1)"]
    end

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

보안 모델 상세

Unprivileged vs Privileged 심층

LXC 의 unprivileged container 는 Linux user namespace 를 활용합니다.

호스트 관점          컨테이너 관점
UID 100000 (일반 유저) → UID 0 (root)
UID 100001           → UID 1
...

컨테이너 안에서 root 로 실행되더라도, 호스트에서는 UID 100000 (권한 없는 유저) 입니다. 컨테이너가 탈출해도 호스트 root 권한을 얻지 못합니다.

# /etc/subuid, /etc/subgid 설정 확인
cat /etc/subuid
# myuser:100000:65536

# unprivileged 컨테이너 생성 (기본값)
lxc-create -n myct -t download -- --dist ubuntu --release noble --arch amd64
# /etc/lxc/lxc-usernet 에 bridge 권한 필요

AppArmor / SELinux 프로파일

LXC 는 AppArmor (Ubuntu 기본) 또는 SELinux 프로파일로 컨테이너의 호스트 접근을 추가 제한합니다.

/etc/apparmor.d/usr.bin.lxc-start 에 기본 프로파일 포함
/proc, /sys 의 민감한 하위 경로 마운트 제한
SYS_ADMIN 같은 위험 capability 기본 박탈

Capability 관리

컨테이너 시작 시 불필요한 Linux capability 를 드롭합니다.

# config 에서 capability 제한
lxc.cap.drop = sys_admin
lxc.cap.drop = sys_rawio
lxc.cap.drop = net_admin

함정

[!WARNING] Privileged container 는 root 탈출 위험. lxc-create 기본값은 unprivileged 이지만, 구버전 문서나 튜토리얼이 privileged 를 전제하는 경우가 있습니다. 프로덕션에서는 항상 unprivileged 확인.

[!CAUTION] nested container 는 추가 설정 필요. LXD 컨테이너 안에서 Docker 를 쓰려면 security.nesting: true 설정 필요. 설정 없이는 docker 가 커널 기능을 사용하지 못합니다.

[!WARNING] 이미지 파일시스템 크기 기본값이 작을 수 있습니다. 기본 루트 파티션이 수 GB 인 경우 패키지 설치 중 공간 부족. 생성 시 크기를 명시하거나 ZFS/btrfs 백엔드로 동적 확장 구성.

[!IMPORTANT] Live migration (CRIU) 은 실험적 기능입니다. 특정 syscall / device 를 쓰는 프로세스는 checkpoint 실패. 중요 서비스 migration 전 충분한 테스트.

참고

관련 [[docker|Docker]] (application container)
관련 [[cgroups-namespaces|cgroups + namespaces]] (LXC 의 근간)
관련 [[virtualization|가상화 전체]]
관련 [[vm-vs-container|VM vs Container 비교]]
관련 [[k8s-pod|Kubernetes Pod]] (쿠버네티스에서의 컨테이너 단위)
공식: 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 의 강한 격리와 큰 오버헤드의 근본 이유입니다.

계층 구조

flowchart TB
    HW["물리 하드웨어\n(CPU, RAM, NIC, Disk)"]
    HW --> HV["Hypervisor (KVM, ESXi, Hyper-V)"]
    HV --> VM1["VM 1\nGuest OS: Ubuntu 24.04"]
    HV --> VM2["VM 2\nGuest OS: Windows Server 2022"]
    HV --> VM3["VM 3\nGuest OS: RHEL 9"]
    VM1 --> App1["App: nginx"]
    VM2 --> App2["App: IIS"]
    VM3 --> App3["App: Oracle DB"]

각 VM 은 독립 커널을 갖고, hypervisor 가 물리 자원을 시분할/격리합니다.

구성 요소

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 하세요.

성능 오버헤드

현대 VM (KVM + virtio) 의 실제 오버헤드는 생각보다 낮습니다.

자원	오버헤드	원인 및 완화
CPU	1-5%	VT-x 로 대부분 직접 실행. 잦은 VM-exit 는 tune 가능
메모리	2-8%	EPT 로 하드웨어 변환. 대규모 페이지 (hugepage) 로 TLB miss 감소
네트워크 (virtio)	~5%	virtio-net. SR-IOV 쓰면 near-native
디스크 (qcow2)	10-20%	CoW 오버헤드. raw 포맷 또는 직접 블록 디바이스 사용 시 개선

고성능이 필요한 DB 워크로드에는 raw 디스크 + 대용량 페이지 (2MB hugepage) 조합이 효과적.

Live Migration

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

Pre-copy 방식 (표준)

sequenceDiagram
    participant Src as 원본 서버
    participant VM as VM (실행 중)
    participant Dst as 대상 서버

    Src->>Dst: 메모리 페이지 bulk copy 시작
    loop dirty page 반복 복사
        VM->>Src: 페이지 write (dirty)
        Src->>Dst: dirty page 재전송
    end
    Note over Src,Dst: dirty rate 낮아지면
    Src->>VM: VM 일시 중지 (수십 ms)
    Src->>Dst: 남은 메모리 + CPU 상태
    Dst->>VM: VM 재개
    Src->>VM: 원본 VM 종료

원본 서버에서 메모리 페이지를 백그라운드로 대상 서버에 복사 시작
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

이미지 관리 (qcow2 체인 주의)

qcow2 는 스냅샷을 CoW (Copy-on-Write) 체인으로 구현합니다. 스냅샷이 쌓이면 읽기 시 체인을 순회해 성능이 저하됩니다.

# 체인 병합 (단일 파일로 평탄화)
qemu-img convert -f qcow2 -O qcow2 vm-with-snapshots.qcow2 vm-flat.qcow2

# 디스크 정보 확인 (backing file 체인 확인)
qemu-img info --backing-chain vm.qcow2

# 사용 실제 크기 vs 가상 크기
qemu-img info vm.qcow2 | grep -E 'virtual|disk'

[!IMPORTANT] 프로덕션에서 스냅샷을 주기적으로 flatten 하거나, 백업은 qemu-img convert 로 별도 파일로 내보내세요. 스냅샷은 임시 수단입니다.

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 는 여전히 특수한 기술)

가상화 레이어 스택

현대 클라우드의 2단 계층 구조를 시각화합니다.

flowchart TB
    HW["물리 하드웨어<br/>CPU / RAM / NIC / Disk"]
    HW --> HV["Type 1 Hypervisor<br/>KVM, ESXi, Hyper-V"]
    HV --> VM1["VM 1<br/>게스트 커널 + OS"]
    HV --> VM2["VM 2<br/>게스트 커널 + OS"]
    VM1 --> CRT["Container Runtime<br/>Docker, containerd"]
    CRT --> C1["Container A"]
    CRT --> C2["Container B"]
    VM2 --> App["직접 실행 앱"]

물리 하드웨어 → Type 1 하이퍼바이저 → VM → 컨테이너 런타임 → 컨테이너 순서로 쌓이는 것이 AWS EC2 + ECS/EKS 구성의 실제 모습입니다.

최신 동향: microVM

일반 VM 보다 훨씬 가벼운 microVM 이 서버리스 / FaaS 의 테넌트 격리 계층이 되었습니다.

Firecracker (AWS Lambda, Fargate)

AWS 가 Rust 로 작성한 초경량 KVM hypervisor.

부팅 시간 125 ms 이하 (일반 VM 수십 초 대비)
메모리 오버헤드 약 5 MB (일반 hypervisor 수백 MB)
Lambda 는 각 함수 호출을 별도 microVM 에서 실행해 테넌트 격리
KVM 위에서 동작, x86-64 / aarch64 지원

gVisor (Google GKE Sandbox)

컨테이너의 syscall 을 사용자 공간 커널이 처리하는 샌드박스.

컨테이너가 host 커널을 직접 호출하지 않음 → 커널 취약점 공격면 축소
Go 로 작성, runsc OCI 런타임으로 containerd / CRI-O 와 통합
GKE Sandbox 옵션으로 활성화 가능

Kata Containers

OCI 컨테이너 이미지를 경량 VM 안에서 실행하는 CNCF 프로젝트.

“컨테이너 API + VM 격리”를 함께 제공
QEMU / Firecracker / Cloud Hypervisor 백엔드 선택 가능
containerd + kata-containers shim 으로 기존 쿠버네티스 클러스터에 통합

[!TIP] microVM 은 “컨테이너의 편의 + VM 의 격리”를 결합합니다. 멀티테넌트 FaaS 와 공개 클라우드에서 점점 표준이 되고 있습니다.

NUMA 와 가상화

대용량 서버에서 VM 을 배치할 때 NUMA (Non-Uniform Memory Access) 를 무시하면 성능 저하가 큽니다.

NUMA 노드: CPU 와 해당 CPU 가 빠르게 접근하는 RAM 의 묶음
VM 이 여러 NUMA 노드에 걸치면 원격 메모리 접근 지연 발생
KVM / ESXi 는 NUMA topology 를 VM 에 반영하는 pinning 기능 제공
컨테이너 수준: numactl 또는 쿠버네티스 Topology Manager 로 제어

참고

관련 [[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

김신건의 로그 - 위키 / virtualization

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

정의

컨테이너 생성 과정

Namespaces (격리)

PID Namespace 심화

Network Namespace 심화

cgroups (자원 제한)

cgroup v1 vs v2

cgroup v2 CPU 제한 예시

OCI Runtime spec 에서

OOM kill (cgroup memory)

User Namespace

OverlayFS

흔한 함정

관련 위키

[Container] Docker: image, layer, registry

정의

컨테이너 런타임 생태계

OCI 표준

Layered Filesystem

Dockerfile

멀티 스테이지 빌드

BuildKit (현대 빌드)

Image Registry

Podman: daemonless 대안

Docker Networking

Docker Compose

Layer Cache 활용

.dockerignore

흔한 함정

관련 위키

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

정의

5가지 원칙

1. Base Image 선택

2. Multi-stage build

Go + distroless

Node.js + distroless

Java + distroless

3. Layer Cache 최적화

4. Non-root User

5. Secret 처리

6. .dockerignore

7. HEALTHCHECK

8. Image Scan + 서명

9. Dive: Layer 분석

10. Reproducible Build + OCI Labels

빌드 최적화 체크리스트

흔한 함정

관련 위키

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

정의

Popek & Goldberg 정리 (1974)

Type 1 vs Type 2

Type 1: Bare Metal Hypervisor

Type 2: Hosted Hypervisor

주요 hypervisor 상세

KVM (Kernel-based Virtual Machine)

Xen

VMware ESXi

Microsoft Hyper-V

Oracle VirtualBox

QEMU

Firecracker

기타

Trap-and-Emulate (가상화 핵심 메커니즘)

하드웨어 지원

Nested Virtualization

주요 기능

Live Migration

Snapshot

Overcommit

PCI Passthrough

Hypervisor 비교

microVM 트렌드 (Firecracker / gVisor)

Hypervisor 선택 가이드

함정

참고

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