cgroups v1/v2 (Control Groups)

Linux cgroups(v1/v2)를 리소스 제어와 멀티테넌트 안정성 보장 관점에서 심층 분석합니다. CPU/memory/io/pids/cpuset 컨트롤러의 동작 원리와 계층 정책, cgroup v2 통합 트리 모델과 delegation 규칙, OOM 제어와 memory.high/max 실전 설정, throttling과 latency tradeoff, PSI(Pressure Stall Information) 기반 과부하 탐지, systemd·container runtime 연동 경로, 운영 중 runaway workload 격리와 디버깅 절차까지 생산 환경에서 필요한 리소스 거버넌스 핵심을 다룹니다.

빠른 시작: cgroup v2 실습

cgroup v2를 처음 사용하는 독자를 위해, 기본적인 리소스 제한을 단계별로 실습합니다.

# Step 1: cgroup v2가 활성화되어 있는지 확인
mount | grep cgroup2
# cgroup2 on /sys/fs/cgroup type cgroup2 (...)
# ↑ 이 줄이 없으면 v2가 비활성화된 상태

# 활성화 방법: /etc/default/grub에 추가 후 update-grub && reboot
# GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=1"

# Step 2: cgroup 생성
sudo mkdir /sys/fs/cgroup/test-app

# Step 3: 컨트롤러 활성화 (부모에서)
# 루트 cgroup에서 사용 가능한 컨트롤러 확인
cat /sys/fs/cgroup/cgroup.controllers
# cpuset cpu io memory hugetlb pids rdma misc

# 자식에게 cpu와 memory 컨트롤러 위임
echo "+cpu +memory" | sudo tee /sys/fs/cgroup/cgroup.subtree_control

# Step 4: 리소스 제한 설정
# 메모리 256MB 제한
echo 268435456 | sudo tee /sys/fs/cgroup/test-app/memory.max

# CPU 50% 제한 (100ms period, 50ms quota)
echo "50000 100000" | sudo tee /sys/fs/cgroup/test-app/cpu.max

# Step 5: 현재 셸을 cgroup에 배치
echo $$ | sudo tee /sys/fs/cgroup/test-app/cgroup.procs

# Step 6: 리소스 사용 확인
cat /sys/fs/cgroup/test-app/memory.current
cat /sys/fs/cgroup/test-app/cpu.stat
cat /sys/fs/cgroup/test-app/memory.pressure

# Step 7: 정리 (셸을 먼저 루트로 이동)
echo $$ | sudo tee /sys/fs/cgroup/cgroup.procs
sudo rmdir /sys/fs/cgroup/test-app

스트레스 테스트로 cgroup 제한 확인

# stress 도구로 cgroup 제한 효과 확인

# 메모리 제한 테스트: 256MB cgroup에서 512MB 할당 시도
systemd-run --scope -p MemoryMax=256M -- stress --vm 1 --vm-bytes 512M --timeout 10s
# → OOM kill 발생

# CPU 제한 테스트: 50% CPU cgroup에서 CPU 풀로드
systemd-run --scope -p CPUQuota=50% -- stress --cpu 2 --timeout 10s
# → top에서 50% CPU만 사용하는 것을 확인

# PID 제한 테스트: 포크 폭탄 방어
systemd-run --scope -p TasksMax=50 -- bash -c ":(){ :|:& };:"
# → 50개 프로세스에서 멈춤, 시스템 영향 없음

# IO 제한 테스트: 10MB/s 쓰기 제한
DEVICE=$(lsblk -no MAJ:MIN /dev/sda | head -1 | tr -d ' ')
systemd-run --scope -p IOWriteBandwidthMax="/dev/sda 10M" \
  -- dd if=/dev/zero of=/tmp/test bs=1M count=100 oflag=direct
# → 약 10MB/s로 제한됨

프로그래밍 언어별 cgroup v2 API

/* Go: containerd cgroups v3 라이브러리 사용 예시 */
// import "github.com/containerd/cgroups/v3/cgroup2"

// cgroup 생성 및 리소스 제한
// res := cgroup2.Resources{
//     Memory: &cgroup2.Memory{
//         Max:  pointerInt64(2 * 1024 * 1024 * 1024), // 2GB
//         High: pointerInt64(1536 * 1024 * 1024),      // 1.5GB
//     },
//     CPU: &cgroup2.CPU{
//         Max:    cgroup2.NewCPUMax(pointerInt64(200000), pointerUint64(100000)),
//         Weight: pointerUint64(200),
//     },
//     Pids: &cgroup2.Pids{
//         Max: 1024,
//     },
// }
// m, _ := cgroup2.NewManager("/sys/fs/cgroup", "/myapp", &res)
// m.AddProc(uint64(os.Getpid()))

cgroups 개요

Control Groups(cgroups)는 프로세스 그룹의 시스템 리소스 사용을 제한(limit), 계량(accounting), 격리(isolation)하는 커널 메커니즘입니다. 컨테이너 런타임, systemd 등에서 리소스 관리의 기반으로 사용됩니다.

리소스 제어 원리

cgroups의 핵심 설계 원리는 "커널의 리소스 할당 경로에 cgroup 검사를 삽입한다"는 것입니다. 프로세스가 리소스(메모리, CPU 시간, I/O 대역폭)를 요청할 때마다 커널은 해당 프로세스가 속한 cgroup의 제한을 확인합니다:

CPU 제어 원리

CPU 컨트롤러는 CFS(Completely Fair Scheduler) 스케줄러에 통합되어 동작합니다. 두 가지 메커니즘이 있습니다:

• 가중치(weight): 경쟁 상황에서 CPU 시간의 비례 배분. cpu.weight=200인 그룹은 cpu.weight=100인 그룹보다 2배의 CPU 시간을 받습니다. CPU가 여유로우면 제한 없이 사용 가능합니다.
• 대역폭 제한(bandwidth throttling): cpu.max의 quota/period 방식. period(예: 100ms) 동안 quota(예: 50ms)만큼만 실행을 허용하고, 초과하면 해당 period가 끝날 때까지 스로틀링합니다. 내부적으로 hrtimer가 period 경계를 관리합니다.

메모리 제어 원리

메모리 컨트롤러는 charge/uncharge 메커니즘으로 동작합니다:

1. 프로세스가 페이지를 할당하면, 해당 페이지의 비용을 프로세스의 cgroup에 charge(부과)합니다.
2. 페이지가 해제되면 uncharge(환급)합니다.
3. cgroup의 누적 사용량이 memory.max에 도달하면, 커널은 해당 cgroup 내에서 페이지 회수를 시도합니다.
4. 회수로도 부족하면 OOM killer가 해당 cgroup 내의 프로세스를 종료합니다.

계층 구조와 리소스 누적 원리

cgroup v2의 계층 구조에서 리소스 제한은 부모가 자식을 포함합니다:

• 자식 cgroup의 리소스 사용량은 항상 부모에 누적됩니다. 부모의 memory.max가 1GB이면, 모든 자식의 합산 메모리가 1GB를 초과할 수 없습니다.
• 자식은 부모보다 더 높은 제한을 설정할 수 있지만, 실질적으로는 부모의 제한이 먼저 적용됩니다.
• memory.low는 리소스 보호를 위한 최소 보장으로, 글로벌 메모리 회수 시 이 값 이하의 메모리는 보호됩니다.

cgroup v1 vs v2

cgroup v1과 v2는 설계 철학, 보안 모델, 기능 범위에서 근본적으로 다릅니다. v2는 v1의 설계 결함을 해결하기 위해 완전히 새로 설계되었으며, 커널 4.5에서 정식 릴리스되었습니다.

cgroup v2 채택 현황

주요 컨트롤러

CPU 컨트롤러

# cgroup v2: CPU 제한 (quota/period)
echo "100000 1000000" > /sys/fs/cgroup/mygroup/cpu.max
# → 1초(1000000us) 중 100ms(100000us)만 사용 = 10% CPU

# CPU weight (상대적 가중치, 1-10000)
echo 150 > /sys/fs/cgroup/mygroup/cpu.weight

Memory 컨트롤러

# 메모리 제한 (256MB)
echo 268435456 > /sys/fs/cgroup/mygroup/memory.max

# 메모리 사용량 확인
cat /sys/fs/cgroup/mygroup/memory.current

# OOM kill 카운트
cat /sys/fs/cgroup/mygroup/memory.events

I/O 컨트롤러

# I/O 대역폭 제한 (장치 8:0에 대해 읽기 10MB/s)
echo "8:0 rbps=10485760" > /sys/fs/cgroup/mygroup/io.max

# I/O weight
echo "default 100" > /sys/fs/cgroup/mygroup/io.weight

PID 컨트롤러

cgroup v2의 PID 컨트롤러는 프로세스/스레드 생성 수를 제한하여 포크 폭탄을 방지합니다:

# PID 제한: 최대 500개 프로세스/스레드
echo 500 > /sys/fs/cgroup/mygroup/pids.max

# 현재 프로세스 수 확인
cat /sys/fs/cgroup/mygroup/pids.current

# 제한 초과 시도 횟수
cat /sys/fs/cgroup/mygroup/pids.events
# max 0  ← fork()가 EAGAIN으로 실패한 횟수

cpuset 컨트롤러 상세

cpuset은 프로세스 그룹을 특정 CPU와 NUMA 메모리 노드에 바인딩합니다. 파티션 모드를 사용하면 전용 CPU를 확보할 수 있습니다:

# cpuset 파티션 모드: CPU 전용 할당
# Step 1: 전용 CPU 범위 지정
echo "4-7" > /sys/fs/cgroup/realtime/cpuset.cpus
echo "0" > /sys/fs/cgroup/realtime/cpuset.mems

# Step 2: 파티션 루트로 설정 → 다른 cgroup에서 CPU 4-7 제외
echo "root" > /sys/fs/cgroup/realtime/cpuset.cpus.partition

# Step 3: isolated 모드 (커널 스레드도 제외, 커널 6.2+)
echo "isolated" > /sys/fs/cgroup/realtime/cpuset.cpus.partition
# → CPU 4-7에서 워크큐, 타이머 등 커널 활동 최소화

# NUMA 메모리 통계 확인
cat /sys/fs/cgroup/realtime/memory.numa_stat
# anon N0=134217728 N1=0
# file N0=67108864 N1=0

RDMA 컨트롤러

RDMA(Remote Direct Memory Access) 컨트롤러는 InfiniBand/RoCE 리소스를 cgroup별로 제한합니다:

# RDMA 리소스 제한
echo "mlx5_0 hca_handle=10 hca_object=1000" > /sys/fs/cgroup/hpc/rdma.max

# 현재 사용량
cat /sys/fs/cgroup/hpc/rdma.current
# mlx5_0 hca_handle=3 hca_object=150

memory.events 상세 분석

memory.events는 메모리 컨트롤러의 핵심 관측 포인트입니다. 각 이벤트 카운터의 의미를 정확히 이해해야 효과적인 모니터링이 가능합니다:

# memory.events 모니터링 원라이너
while true; do
    echo "=== $(date) ==="
    cat /sys/fs/cgroup/myapp/memory.events
    echo "current: $(cat /sys/fs/cgroup/myapp/memory.current)"
    echo "pressure: $(cat /sys/fs/cgroup/myapp/memory.pressure | head -1)"
    sleep 5
done

# inotify 기반 이벤트 감지 (즉각 반응)
inotifywait -m -e modify /sys/fs/cgroup/myapp/memory.events

# memory.events.local: 해당 cgroup만의 이벤트 (자식 제외)
# memory.events: 자식 포함 전체 이벤트
cat /sys/fs/cgroup/myapp/memory.events.local

memory.stat 심층 분석

memory.stat은 메모리 사용의 세부 구성을 보여줍니다. 각 필드를 이해하면 메모리 문제의 원인을 정확히 파악할 수 있습니다:

# memory.stat 분석 실전
cat /sys/fs/cgroup/myapp/memory.stat
# anon 536870912          ← 512MB 익명 메모리
# file 268435456          ← 256MB 파일 캐시 (회수 가능)
# kernel 33554432         ← 32MB 커널 메모리
# slab 16777216           ← 16MB slab
# sock 8388608            ← 8MB 소켓 버퍼
# shmem 4194304           ← 4MB 공유 메모리
# pgfault 1000000         ← 100만 페이지 폴트
# pgmajfault 50           ← 50번 메이저 폴트 (낮음=좋음)
# workingset_refault_file 200  ← 파일 스래싱 있음

# 메모리 구성 비율 분석
# total ≈ 512 + 256 + 32 + 8 + 4 = 812MB
# anon/total = 63% → 대부분 프로세스 메모리
# file/total = 31% → 파일 캐시 (회수로 확보 가능)
# kernel/total = 4% → 커널 오버헤드 적정

cpu.stat 심층 분석

# CPU 스로틀링 비율 계산
# nr_throttled / nr_periods × 100 = 스로틀링 비율 (%)
# 예: 150/5000 × 100 = 3% → 양호
# 10% 이상이면 cpu.max 조정 필요

# system/user 비율 분석
# system_usec/usage_usec > 30% → 커널 오버헤드 높음
# → syscall 최적화, io_uring 도입 검토

# 스로틀링 실시간 모니터링
while true; do
    awk '/nr_throttled/ {print $2}' /sys/fs/cgroup/myapp/cpu.stat
    sleep 1
done

커널 cgroup API

#include <linux/cgroup.h>

/* 현재 태스크의 cgroup 접근 */
struct cgroup *cgrp;
rcu_read_lock();
cgrp = task_cgroup(current, memory_cgrp_id);
rcu_read_unlock();

/* cgroup 서브시스템 등록 (커널 컨트롤러 개발 시) */
struct cgroup_subsys my_cgrp_subsys = {
    .css_alloc  = my_css_alloc,
    .css_free   = my_css_free,
    .attach     = my_attach,
    .name       = "my_controller",
};

PSI (Pressure Stall Information)

cgroup v2에서는 PSI를 통해 CPU, 메모리, I/O의 리소스 압력을 실시간 모니터링할 수 있습니다. PSI의 핵심 원리는 "일할 수 있는데 리소스를 기다리느라 못 하는 시간의 비율"을 측정하는 것입니다:

• some: 최소 하나 이상의 태스크가 해당 리소스를 기다리는 시간 비율 (부분적 지연)
• full: 모든 태스크가 해당 리소스를 기다리는 시간 비율 (완전 정체). CPU에는 full이 없습니다.

커널은 각 CPU에서 태스크 상태 전환(running → waiting)을 추적하고, 지수 이동 평균(EMA)으로 10초/60초/300초 윈도우의 압력 비율을 계산합니다. 이 값은 0.00(압력 없음)~100.00(완전 정체) 사이입니다.

# CPU 압력 확인
cat /proc/pressure/cpu
# some avg10=0.50 avg60=0.30 avg300=0.20 total=12345678

# cgroup별 메모리 압력
cat /sys/fs/cgroup/mygroup/memory.pressure

PSI 압력 수준 해석

PSI 기반 자동 스케일링 구현

PSI 트리거를 활용하면 리소스 압력에 따라 자동으로 워크로드를 조절하는 시스템을 구축할 수 있습니다:

#!/bin/bash
# PSI 기반 자동 스케일링 스크립트 (메모리)
# memory.pressure의 some avg10이 25%를 초과하면 워크로드 축소

CGROUP_PATH="/sys/fs/cgroup/myapp"
THRESHOLD=25

while true; do
    # PSI 값 파싱
    avg10=$(awk '/some/ {gsub(/avg10=/,""); print $2}' "$CGROUP_PATH/memory.pressure")

    # 소수점 비교
    if (echo "$avg10 > $THRESHOLD" | bc -l) > /dev/null 2>&1; then
        echo "[WARN] 메모리 압력 $(avg10)% > ${THRESHOLD}%"
        # 대응 1: 능동적 메모리 회수
        echo 104857600 > "$CGROUP_PATH/memory.reclaim"  # 100MB 회수

        # 대응 2: 워커 수 축소 (애플리케이션별 구현)
        # curl -s http://localhost:8080/admin/scale-down

        # 대응 3: 낮은 우선순위 프로세스 중지
        # echo 1 > /sys/fs/cgroup/myapp/batch/cgroup.freeze
    fi
    sleep 5
done

/* PSI 기반 메모리 관리 데몬 (C 구현) */
/* 단계별 PSI 트리거로 점진적 대응 */

/* Level 1: 경고 (some 150ms/1s) → 로깅 + 능동 회수 */
write(psi_fd, "some 150000 1000000", 20);

/* Level 2: 심각 (some 500ms/1s) → 워크로드 축소 */
write(psi_fd2, "some 500000 1000000", 20);

/* Level 3: 위험 (full 200ms/1s) → 프로세스 종료 */
write(psi_fd3, "full 200000 1000000", 20);

/* poll()로 다중 트리거 감시 */
struct pollfd fds[3] = {
    { .fd = psi_fd,  .events = POLLPRI },
    { .fd = psi_fd2, .events = POLLPRI },
    { .fd = psi_fd3, .events = POLLPRI },
};

while (1) {
    int ret = poll(fds, 3, -1);
    if (fds[2].revents & POLLPRI) {
        /* Level 3: 위험 → 즉시 프로세스 종료 */
        handle_critical_pressure();
    } else if (fds[1].revents & POLLPRI) {
        /* Level 2: 심각 → 워크로드 축소 */
        handle_high_pressure();
    } else if (fds[0].revents & POLLPRI) {
        /* Level 1: 경고 → 능동 회수 */
        handle_warning_pressure();
    }
}

cgroup 트러블슈팅 가이드

프로덕션 환경에서 자주 발생하는 cgroup 관련 문제와 해결 방법을 체계적으로 정리합니다.

문제 1: 예상치 못한 CPU 스로틀링

# 증상: 애플리케이션 응답 시간 증가, cpu.stat에 throttled 증가

# 1단계: 스로틀링 현황 확인
cat /sys/fs/cgroup/myapp/cpu.stat
# nr_periods 10000
# nr_throttled 500      ← 5% 스로틀링
# throttled_usec 25000000 ← 25초 총 스로틀 시간

# 2단계: 현재 설정 확인
cat /sys/fs/cgroup/myapp/cpu.max
# 100000 100000         ← 100ms period, 100ms quota (1 CPU)

# 3단계: 해결 방법
# 방법 A: quota 증가
echo "200000 100000" > /sys/fs/cgroup/myapp/cpu.max  # 2 CPU

# 방법 B: burst 설정 (순간 스파이크 허용)
echo 50000 > /sys/fs/cgroup/myapp/cpu.max.burst  # 50ms burst

# 방법 C: weight만 사용 (하드 제한 제거)
echo "max 100000" > /sys/fs/cgroup/myapp/cpu.max  # 무제한
echo 200 > /sys/fs/cgroup/myapp/cpu.weight  # 상대적 가중치

문제 2: 반복적 OOM Kill

# 증상: 프로세스가 주기적으로 종료됨

# 1단계: OOM 이벤트 확인
cat /sys/fs/cgroup/myapp/memory.events
# oom_kill 5    ← OOM kill 5회
# high 1000    ← memory.high 초과 1000회

# 2단계: 메모리 사용 분석
cat /sys/fs/cgroup/myapp/memory.current
# 1073741824   ← 1GB 사용 중
cat /sys/fs/cgroup/myapp/memory.max
# 1073741824   ← 1GB 제한 → 꽉 참

# 3단계: 무엇이 메모리를 사용하는지 분석
cat /sys/fs/cgroup/myapp/memory.stat | grep -E "^(anon|file|kernel|slab|sock)"
# anon 805306368    ← 768MB (75%) ← 주요 사용처!
# file 214748364   ← 205MB (20%) ← 파일 캐시 (회수 가능)
# kernel 53687091  ← 51MB (5%)

# 4단계: 해결 방법
# 방법 A: 제한 확대
echo 2G > /sys/fs/cgroup/myapp/memory.max

# 방법 B: 스로틀링으로 점진적 관리 (OOM 방지)
echo 1536M > /sys/fs/cgroup/myapp/memory.high  # max 전에 스로틀

# 방법 C: 스왑 허용
echo 1G > /sys/fs/cgroup/myapp/memory.swap.max

# 방법 D: 능동적 회수 스케줄링
echo 209715200 > /sys/fs/cgroup/myapp/memory.reclaim  # 200MB 회수

문제 3: I/O 지연 증가

# 증상: 파일 읽기/쓰기가 느려짐

# 1단계: IO 압력 확인
cat /sys/fs/cgroup/myapp/io.pressure
# some avg10=45.00 avg60=30.00 avg300=20.00
# full avg10=15.00 avg60=10.00 avg300=5.00
# → some 45%: 심각한 I/O 대기

# 2단계: I/O 사용량 확인
cat /sys/fs/cgroup/myapp/io.stat
# 259:0 rbytes=10737418240 wbytes=5368709120 rios=1000000 wios=500000

# 3단계: I/O 제한 확인
cat /sys/fs/cgroup/myapp/io.max
# 259:0 rbps=104857600 wbps=52428800   ← 100MB/s 읽기, 50MB/s 쓰기

# 4단계: 해결 방법
# 방법 A: 제한 확대
echo "259:0 rbps=524288000 wbps=209715200" > /sys/fs/cgroup/myapp/io.max

# 방법 B: 가중치 기반으로 전환 (유연한 배분)
echo "259:0 rbps=max wbps=max" > /sys/fs/cgroup/myapp/io.max
echo "default 500" > /sys/fs/cgroup/myapp/io.weight

# 방법 C: 지연 목표 설정
echo "259:0 target=5" > /sys/fs/cgroup/myapp/io.latency  # 5ms 목표

문제 4: 컨테이너 내부에서 리소스 정보 불일치

# 증상: 컨테이너 내부 free/top이 호스트 전체 리소스를 표시

# 원인: /proc/meminfo, /proc/stat은 cgroup을 인식하지 않음

# 해결 방법 1: 애플리케이션에서 cgroup 파일 직접 읽기
# 메모리 사용량
cat /sys/fs/cgroup/memory.current
# 메모리 제한
cat /sys/fs/cgroup/memory.max
# CPU 제한
cat /sys/fs/cgroup/cpu.max

# 해결 방법 2: LXCFS 사용 (컨테이너용 /proc 가상화)
# LXCFS는 /proc/meminfo, /proc/cpuinfo 등을
# cgroup 제한에 맞게 가상화하여 제공
# docker run -v /var/lib/lxcfs/proc/meminfo:/proc/meminfo:rw ...

# 해결 방법 3: 프로그래밍 언어별 cgroup 인식
# Java: -XX:+UseContainerSupport (JDK 10+, 기본 활성화)
# Go: runtime.GOMAXPROCS()는 cpu.max 자동 인식 (Go 1.19+)
# Node.js: --max-old-space-size는 수동 설정 필요
# Python: os.cpu_count()는 cgroup 미인식 (수동 계산 필요)

문제 5: cgroup 생성/삭제 실패

# 증상: mkdir이나 rmdir 실패

# 원인 1: 계층 깊이/자손 수 초과
cat /sys/fs/cgroup/cgroup.max.depth
cat /sys/fs/cgroup/cgroup.max.descendants

# 원인 2: No Internal Process Constraint 위반
# subtree_control에 컨트롤러를 활성화하려는데 프로세스가 있는 경우
# EBUSY 에러 발생 → 프로세스를 자식 cgroup으로 이동

# 원인 3: 삭제 시 프로세스가 남아있음
cat /sys/fs/cgroup/myapp/cgroup.procs
# 프로세스가 있으면 삭제 불가 → 먼저 프로세스 이동 또는 종료

# 원인 4: dying cgroup (삭제 후 해제 안 됨)
cat /sys/fs/cgroup/cgroup.stat
# nr_dying_descendants가 높으면 page cache 드롭 필요
echo 3 > /proc/sys/vm/drop_caches

Freezer 컨트롤러

Freezer 컨트롤러는 cgroup 내 모든 프로세스를 일시 중지(freeze)하고 재개(thaw)할 수 있습니다:

# cgroup v2 freezer
echo 1 > /sys/fs/cgroup/myapp/cgroup.freeze
# myapp 그룹의 모든 프로세스가 TASK_FROZEN 상태

echo 0 > /sys/fs/cgroup/myapp/cgroup.freeze
# 프로세스 재개

# 상태 확인
cat /sys/fs/cgroup/myapp/cgroup.events
# frozen 1

cpuset 컨트롤러

CPU와 메모리 노드를 프로세스 그룹에 할당합니다:

# cgroup v2 cpuset
echo "0-3" > /sys/fs/cgroup/myapp/cpuset.cpus      # CPU 0~3 할당
echo "0" > /sys/fs/cgroup/myapp/cpuset.mems         # NUMA 노드 0
echo "root" > /sys/fs/cgroup/myapp/cpuset.cpus.partition  # 전용 파티션

cgroup 위임 (Delegation)

# 비특권 사용자에게 cgroup 관리 위임
mkdir /sys/fs/cgroup/user_slice/user-1000
chown -R 1000:1000 /sys/fs/cgroup/user_slice/user-1000

# systemd에서 위임 설정
# /etc/systemd/system/myservice.service
# [Service]
# Delegate=cpu memory io

cgroup 커널 내부 구조

/* 커널 내부: cgroup 서브시스템 등록 */
struct cgroup_subsys memory_cgrp_subsys = {
    .css_alloc   = mem_cgroup_css_alloc,
    .css_online  = mem_cgroup_css_online,
    .css_offline = mem_cgroup_css_offline,
    .css_free    = mem_cgroup_css_free,
    .can_attach  = mem_cgroup_can_attach,
    .attach      = mem_cgroup_move_task,
    .name        = "memory",
};

/* task_struct에서 cgroup 접근 */
struct css_set *cset = task->cgroups;
/* css_set은 프로세스가 속한 모든 cgroup subsystem state를 참조 */

PSI 상세 분석

PSI(Pressure Stall Information)는 시스템 자원 압박 수준을 정량적으로 측정합니다:

# 시스템 전체 PSI 확인
cat /proc/pressure/cpu
# some avg10=0.25 avg60=0.10 avg300=0.05 total=123456
# full avg10=0.00 avg60=0.00 avg300=0.00 total=0

cat /proc/pressure/memory
cat /proc/pressure/io

# cgroup별 PSI
cat /sys/fs/cgroup/myapp/cpu.pressure
cat /sys/fs/cgroup/myapp/memory.pressure
cat /sys/fs/cgroup/myapp/io.pressure

# PSI 트리거 (임계값 기반 알림)
# /proc/pressure/memory에 트리거 설정:
# "some 150000 1000000" → 1초 window에서 150ms 이상 some 압력 시 이벤트

/* PSI 트리거를 커널에서 사용 */
int fd = open("/proc/pressure/memory", O_RDWR | O_NONBLOCK);
struct pollfd fds = { .fd = fd, .events = POLLPRI };

/* 트리거 설정: 1초 window에서 150ms 이상 stall */
write(fd, "some 150000 1000000", 20);

/* 이벤트 대기 */
poll(&fds, 1, -1);  /* 압력 임계값 초과 시 반환 */

커널 버전별 변경사항

cgroup 관련 주요 취약점

cgroup은 컨테이너 리소스 격리의 핵심 메커니즘이지만, 특히 v1의 설계에서 보안 취약점이 반복적으로 발견되었습니다. cgroup v2로의 전환이 이러한 문제의 근본적 해결을 위해 가속화되고 있습니다.

/* cgroup v1 release_agent 탈출 vs v2의 개선 */

/* cgroup v1: release_agent는 호스트의 init cgroup ns에서 실행 */
/* → 컨테이너 내부에서 호스트 명령 실행 가능 */
echo /host/path/exploit.sh > /sys/fs/cgroup/rdma/release_agent
echo 1 > /sys/fs/cgroup/rdma/child/notify_on_release

/* cgroup v2: release_agent 메커니즘 제거 */
/* 대신 cgroup.events 파일의 "populated 0" 이벤트를 */
/* 유저스페이스 데몬(systemd 등)이 처리 */
/* → 커널이 직접 사용자 프로그램을 실행하지 않음 */

/* 커널 5.17+ 수정: cgroup namespace 내에서 release_agent 쓰기 차단 */
/* cgroup_release_agent_write()에 ns_capable(init_ns, CAP_SYS_ADMIN) 검사 추가 */

/* cgroup v1 vs v2 보안 비교 */

/*
 * cgroup v1 보안 문제:
 * 1. release_agent: 커널이 사용자 프로그램 직접 실행 → 탈출 벡터
 * 2. 다중 계층(hierarchy): 컨트롤러별 독립 트리 → 정책 불일치 가능
 * 3. 위임 모델 미비: 하위 cgroup에 대한 세밀한 권한 제어 부재
 * 4. kmem accounting 분리: 커널 메모리 제한 우회 가능
 *
 * cgroup v2 보안 개선:
 * 1. release_agent 제거: 유저스페이스 데몬으로 대체
 * 2. 단일 통합 계층: 모든 컨트롤러가 하나의 트리 → 일관된 정책
 * 3. 안전한 위임: subtree_control로 하위 cgroup 권한 제어
 * 4. 통합 메모리 accounting: 커널 + 사용자 메모리 통합 제한
 * 5. nsdelegate 마운트 옵션: cgroup NS 경계에서 위임 강제
 */

# cgroup v2 보안 권장 설정
# /etc/default/grub에 추가
GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=1 cgroup_no_v1=all"

# nsdelegate로 안전한 위임 활성화
mount -t cgroup2 none /sys/fs/cgroup -o nsdelegate,memory_recursiveprot

Android cgroup 구성

Android는 cgroup을 활용하여 foreground/background 앱의 CPU, 메모리, I/O 자원을 정교하게 관리한다. Android 12부터 cgroup v2가 필수이며, task_profiles.json이 cgroup 설정을 추상화한다.

# Android cgroup 계층 구조
/dev/cpuset/foreground     → cpus: 0-7   # 빅+리틀 전체 코어
/dev/cpuset/background     → cpus: 0-3   # 리틀 코어만
/dev/cpuctl/foreground     → cpu.weight: 1024
/dev/cpuctl/background     → cpu.weight: 50

# UCLAMP: 스케줄러에 utilization 힌트 (EAS 연동)
/dev/cpuctl/foreground/cpu.uclamp.min: 20
/dev/cpuctl/foreground/cpu.uclamp.max: 1024

Android init의 task_profiles 지시어, UCLAMP 스케줄링, lmkd PSI 연동 등 심화 내용은 Android 커널 — cgroup 구성을 참고하라.

cgroup v2 통합 계층 상세

cgroup v2의 가장 중요한 설계 결정은 단일 통합 계층(Unified Hierarchy)입니다. v1에서는 CPU, 메모리, I/O 등 컨트롤러별로 독립된 계층 트리를 마운트할 수 있어, 같은 프로세스가 CPU cgroup에서는 A 그룹, 메모리 cgroup에서는 B 그룹에 속하는 불일치가 발생했습니다. v2는 이를 하나의 트리로 통합하여 정책 일관성을 보장합니다.

No Internal Process Constraint

cgroup v2의 중요한 구조적 규칙은 내부 프로세스 제약(No Internal Process Constraint)입니다. 자식 cgroup이 존재하는 cgroup에는 프로세스를 직접 배치할 수 없습니다. 이 규칙은 리소스 분배의 모호성을 제거합니다:

# No Internal Process Constraint 예시
# /sys/fs/cgroup/workloads/ 에 자식이 있으면
# workloads/cgroup.procs에 직접 PID를 쓸 수 없음

# 올바른 구조:
/sys/fs/cgroup/workloads/
├── web/           # 프로세스는 여기에 (leaf)
│   └── cgroup.procs
├── db/            # 프로세스는 여기에 (leaf)
│   └── cgroup.procs
├── cgroup.subtree_control   # 자식 컨트롤러 활성화
└── cgroup.procs             # ← 비어있어야 함 (자식이 있으므로)

# 컨트롤러 활성화: 부모에서 subtree_control에 작성
echo "+cpu +memory +io" > /sys/fs/cgroup/workloads/cgroup.subtree_control

주요 인터페이스 파일

Memory 컨트롤러 심화

cgroup v2 메모리 컨트롤러는 사용자 메모리(anon, file cache, tmpfs), 커널 메모리(slab, page tables, sock buffers), 스왑을 통합 관리합니다. v1과 달리 커널 메모리가 별도가 아닌 통합 계정으로 처리되어 제한 우회가 불가능합니다.

Memory 인터페이스 파일 상세

능동적 메모리 회수 (memory.reclaim)

커널 5.19에서 도입된 memory.reclaim은 OOM을 기다리지 않고 능동적으로 메모리를 회수하는 인터페이스입니다. 프로액티브 메모리 관리에 핵심적인 역할을 합니다:

# 500MB 회수 시도
echo 524288000 > /sys/fs/cgroup/myapp/memory.reclaim

# swappiness 조정과 함께 회수 (커널 6.1+)
echo "524288000 swappiness=0" > /sys/fs/cgroup/myapp/memory.reclaim
# swappiness=0: anon 페이지를 swap하지 않고 file 캐시만 회수

# memory.stat으로 상세 사용량 확인
cat /sys/fs/cgroup/myapp/memory.stat
# anon 134217728        ← 익명 메모리 (malloc 등)
# file 67108864         ← 파일 캐시
# kernel 16777216       ← 커널 메모리 (slab 등)
# shmem 8388608         ← 공유 메모리 / tmpfs
# sock 4194304          ← TCP/UDP 소켓 버퍼
# slab 12582912         ← slab 할당자
# pgfault 50000         ← 페이지 폴트 횟수
# pgmajfault 100        ← 메이저 페이지 폴트

메모리 과금 메커니즘 (Charge Accounting)

메모리 컨트롤러의 핵심은 charge/uncharge 과금 메커니즘입니다. 모든 메모리 할당 경로에서 cgroup 검사가 수행됩니다:

/* mm/memcontrol.c — 메모리 과금 핵심 경로 */

/* 1. 페이지 할당 시 charge */
int charge_memcg(struct folio *folio, struct mem_cgroup *memcg, gfp_t gfp) {
    unsigned long nr_pages = folio_nr_pages(folio);

    /* memory.max 검사 */
    if (!try_charge(memcg, gfp, nr_pages)) {
        /* 제한 초과 → direct reclaim 시도 */
        if (mem_cgroup_oom(memcg, gfp, get_order(nr_pages)))
            return -ENOMEM;  /* OOM 발생 */
    }

    /* memory.high 검사 — 스로틀링 */
    if (page_counter_read(&memcg->memory) > READ_ONCE(memcg->memory.high))
        schedule_work(&memcg->high_work);  /* 비동기 회수 */

    /* folio에 cgroup 연결 */
    folio->memcg_data = (unsigned long)memcg;
    return 0;
}

/* 2. 페이지 해제 시 uncharge */
void uncharge_folio(struct folio *folio) {
    struct mem_cgroup *memcg = folio_memcg(folio);
    if (memcg) {
        page_counter_uncharge(&memcg->memory, folio_nr_pages(folio));
        folio->memcg_data = 0;
    }
}

/* 3. page_counter 구조체 — 계층적 카운터 */
struct page_counter {
    atomic_long_t       usage;     /* 현재 사용량 */
    unsigned long       min;       /* memory.min */
    unsigned long       low;       /* memory.low */
    unsigned long       high;      /* memory.high */
    unsigned long       max;       /* memory.max */
    struct page_counter *parent;   /* 부모 카운터 (계층 누적) */
};

CPU 컨트롤러 심화

cgroup v2 CPU 컨트롤러는 CFS 스케줄러와 긴밀히 통합되어 가중치 기반 비례 배분과 대역폭 제한을 동시에 제공합니다. 여기서는 내부 메커니즘을 깊이 분석합니다.

대역폭 스로틀링 내부 구조

CPU 대역폭 스로틀링(cpu.max)은 커널 내부에서 CFS bandwidth control로 구현됩니다. 핵심 구조체는 struct cfs_bandwidth이며, period 타이머와 quota 관리를 담당합니다:

/* kernel/sched/fair.c — CFS 대역폭 제어 핵심 */

struct cfs_bandwidth {
    raw_spinlock_t  lock;
    ktime_t         period;        /* 100ms 기본 */
    u64             quota;         /* period 당 허용 ns */
    u64             runtime;       /* 남은 런타임 */
    u64             burst;         /* 미사용 quota 누적 한도 */
    s64             hierarchical_quota;
    u8              idle;
    u8              period_active;
    struct hrtimer  period_timer;  /* period 경계 타이머 */
    struct hrtimer  slack_timer;   /* 미사용 런타임 반환 */
    struct list_head throttled_cfs_rq;
    int             nr_periods;
    int             nr_throttled;
    u64             throttled_time;
};

/* 스로틀링 결정: runtime이 0 이하이면 스로틀 */
static bool cfs_rq_throttled(struct cfs_rq *cfs_rq) {
    return cfs_rq->throttled;
}

/* period 타이머 콜백: quota 리필 */
static enum hrtimer_restart sched_cfs_period_timer(...) {
    /* runtime을 quota로 리필 (burst 누적 고려) */
    cfs_b->runtime = min(cfs_b->quota + cfs_b->runtime,
                         cfs_b->quota + cfs_b->burst);
    /* 스로틀된 cfs_rq들 해제 */
    distribute_cfs_runtime(cfs_b);
    return HRTIMER_RESTART;
}

UCLAMP (Utilization Clamping)

UCLAMP은 스케줄러에게 CPU 활용도의 상한/하한 힌트를 제공하여 EAS(Energy Aware Scheduling)와 연동합니다:

# 웹 서버: CPU 성능 보장 (최소 30% 활용도)
echo "30.00" > /sys/fs/cgroup/webserver/cpu.uclamp.min
echo "100.00" > /sys/fs/cgroup/webserver/cpu.uclamp.max

# 배치 작업: 전력 절약 (최대 60% 활용도)
echo "0.00" > /sys/fs/cgroup/batch/cpu.uclamp.min
echo "60.00" > /sys/fs/cgroup/batch/cpu.uclamp.max

# 극저 우선순위 배경 작업
echo 1 > /sys/fs/cgroup/background/cpu.idle

# CPU 통계 확인
cat /sys/fs/cgroup/webserver/cpu.stat
# usage_usec 1234567        ← 총 CPU 사용 시간
# user_usec 1000000         ← 사용자 모드 시간
# system_usec 234567        ← 커널 모드 시간
# nr_periods 5000           ← 경과 period 수
# nr_throttled 150          ← 스로틀된 횟수
# throttled_usec 7500000    ← 스로틀된 총 시간
# nr_bursts 30              ← 버스트 사용 횟수
# burst_usec 600000         ← 버스트 사용 총 시간

IO 컨트롤러 심화

cgroup v2 IO 컨트롤러는 세 가지 제어 메커니즘을 제공합니다: 가중치 기반 비례 배분, 절대적 BPS/IOPS 제한, 지연 시간 목표 제어. v1의 blkio와 달리 buffered I/O(writeback)까지 포함하여 제한합니다.

io.latency 지연 목표 모델

io.latency는 Facebook이 개발한 I/O 지연 보장 메커니즘으로, 목표 지연을 초과하면 해당 cgroup의 I/O 큐 깊이(queue depth)를 동적으로 줄여 다른 cgroup에 I/O 대역폭을 양보합니다:

# 디바이스 8:0에 10ms 지연 목표 설정
echo "8:0 target=10" > /sys/fs/cgroup/latency-sensitive/io.latency

# 배치 작업에는 느슨한 지연 목표
echo "8:0 target=100" > /sys/fs/cgroup/batch-io/io.latency

# I/O 통계 확인
cat /sys/fs/cgroup/latency-sensitive/io.stat
# 8:0 rbytes=1234567 wbytes=7654321 rios=100 wios=200 dbytes=0 dios=0

io.cost QoS 모델

io.cost는 장치의 실제 성능 특성(순차/랜덤, 읽기/쓰기)을 모델링하여 정밀한 가중치 기반 I/O 분배를 제공합니다:

# io.cost 모델 파라미터 확인
cat /sys/fs/cgroup/io.cost.model
# 8:0 ctrl=auto model=linear rbps=2000000000 rseqiops=300000
#   rrandiops=70000 wbps=1500000000 wseqiops=200000 wrandiops=50000

# QoS 파라미터 조정
echo "8:0 enable=1 ctrl=auto" > /sys/fs/cgroup/io.cost.qos
# rpct: 읽기 완료 지연 백분위 목표
# rlat: 읽기 지연 목표 (us)
# wpct: 쓰기 완료 지연 백분위 목표
# wlat: 쓰기 지연 목표 (us)
# min: 최소 가중치 비율 (%)
# max: 최대 가중치 비율 (%)

PID 컨트롤러

PID 컨트롤러는 cgroup 내에서 생성 가능한 프로세스/스레드 수를 제한하여 포크 폭탄(fork bomb)을 방지합니다. 시스템 전체의 PID 소진을 막는 중요한 안전장치입니다.

# PID 제한 설정 (최대 500개 프로세스/스레드)
echo 500 > /sys/fs/cgroup/myapp/pids.max

# 현재 프로세스 수 확인
cat /sys/fs/cgroup/myapp/pids.current
# 42

# 최고 기록 확인
cat /sys/fs/cgroup/myapp/pids.peak
# 128

# 이벤트 확인 (제한 초과 시도 횟수)
cat /sys/fs/cgroup/myapp/pids.events
# max 3    ← fork()가 3번 EAGAIN으로 실패

디바이스 컨트롤러

cgroup v2에서는 eBPF를 통해 디바이스 접근을 제어합니다. v1의 devices 컨트롤러(화이트리스트/블랙리스트 방식)와 달리, v2는 BPF_PROG_TYPE_CGROUP_DEVICE 타입의 BPF 프로그램을 cgroup에 부착하여 mknod()와 장치 파일 open()을 필터링합니다.

/* BPF 디바이스 필터 프로그램 예시 */
SEC("cgroup/dev")
int device_filter(struct bpf_cgroup_dev_ctx *ctx) {
    /* ctx->major, ctx->minor: 장치 번호 */
    /* ctx->access_type: BPF_DEVCG_ACC_MKNOD/READ/WRITE */
    /* ctx->major == 0 이면 허용 (null 장치) */

    if (ctx->major == 1 && ctx->minor == 3)
        return 1;  /* /dev/null 허용 */
    if (ctx->major == 1 && ctx->minor == 5)
        return 1;  /* /dev/zero 허용 */
    if (ctx->major == 1 && ctx->minor == 8)
        return 1;  /* /dev/random 허용 */
    if (ctx->major == 1 && ctx->minor == 9)
        return 1;  /* /dev/urandom 허용 */
    if (ctx->major == 5 && ctx->minor == 0)
        return 1;  /* /dev/tty 허용 */
    if (ctx->major == 136)
        return 1;  /* /dev/pts/* 허용 */

    return 0;  /* 나머지 모두 거부 */
}

PSI 내부 연산 심화

PSI(Pressure Stall Information)는 "자원을 기다리느라 일하지 못하는 시간의 비율"을 정량화합니다. 여기서는 커널 내부에서 PSI가 어떻게 계산되는지 상세히 분석합니다.

/* kernel/sched/psi.c — PSI 핵심 구현 */

/* 태스크 상태 플래그 */
#define TSK_IOWAIT    (1 << 0)  /* I/O 대기 */
#define TSK_MEMSTALL  (1 << 1)  /* 메모리 회수 대기 */
#define TSK_RUNNING   (1 << 2)  /* 실행 가능 */
#define TSK_ONCPU     (1 << 3)  /* 실제 CPU에서 실행 */

/* PSI 그룹: 시스템 전체 + cgroup별 */
struct psi_group {
    struct psi_group_cpu __percpu *pcpu;
    u64  total[NR_PSI_STATES];      /* 누적 stall 시간 */
    u64  avg[NR_PSI_STATES][3];    /* EMA: avg10/60/300 */
    struct delayed_work avgs_work;  /* 2초 주기 갱신 */
};

/* 상태 전환 시 호출 */
void psi_task_change(struct task_struct *task,
                     int clear, int set) {
    /* clear: 해제할 상태 비트 */
    /* set: 설정할 상태 비트 */
    /* → per-CPU 카운터 갱신 → 글로벌 집계 */
}

/* some/full 판정 로직 */
/* some: nr_running < nr_online_cpus 이면 some 상태 */
/* full: nr_running == 0 이면 full 상태 */

PSI 트리거 프로그래밍

PSI 트리거는 userspace에서 리소스 압력 이벤트를 효율적으로 감지하는 메커니즘입니다. poll() 시스템 콜과 결합하여 이벤트 기반 리소스 관리를 구현할 수 있습니다:

/* PSI 트리거 기반 메모리 관리 데몬 예시 */
#include <fcntl.h>
#include <poll.h>
#include <stdio.h>
#include <unistd.h>

int main(void) {
    int fd;
    struct pollfd fds[1];
    char trigger[] = "some 150000 1000000";
    /* "some 150000 1000000" 의미:
     * 1초(1000000us) 윈도우에서 150ms(150000us) 이상
     * some 메모리 압력이 발생하면 이벤트 발생 */

    fd = open("/proc/pressure/memory", O_RDWR | O_NONBLOCK);
    if (fd < 0) {
        perror("open");
        return 1;
    }

    /* 트리거 등록 */
    if (write(fd, trigger, sizeof(trigger) - 1) < 0) {
        perror("write trigger");
        return 1;
    }

    fds[0].fd = fd;
    fds[0].events = POLLPRI;

    /* 이벤트 루프 */
    while (1) {
        int ret = poll(fds, 1, -1);
        if (ret > 0 && (fds[0].revents & POLLPRI)) {
            printf("메모리 압력 감지! 회수 작업 시작...\n");
            /* memory.reclaim 트리거 또는 프로세스 종료 등 */
        }
    }
    close(fd);
    return 0;
}

cgroup-aware OOM Killer

cgroup v2에서 OOM killer는 cgroup 경계를 인식하여 동작합니다. memory.max를 초과한 cgroup 내에서만 프로세스를 선택하여 종료하므로, 다른 cgroup의 워크로드에 영향을 주지 않습니다.

# memory.oom.group 설정: 그룹 전체 종료 모드
# 데이터베이스처럼 프로세스 간 강한 의존성이 있을 때 유용
echo 1 > /sys/fs/cgroup/database/memory.oom.group

# OOM 이벤트 모니터링
cat /sys/fs/cgroup/database/memory.events
# low 0
# high 15          ← memory.high 초과 횟수
# max 3            ← memory.max 도달 횟수
# oom 2            ← OOM 발생 횟수
# oom_kill 1       ← OOM kill 발생 횟수
# oom_group_kill 0 ← 그룹 OOM kill 횟수

# cgroup.kill로 긴급 전체 종료 (커널 5.14+)
echo 1 > /sys/fs/cgroup/runaway-workload/cgroup.kill
# cgroup 내 모든 프로세스에 SIGKILL 전송

systemd cgroup 연동

systemd는 cgroup v2의 주요 소비자로, 모든 서비스, 사용자 세션, 시스템 리소스를 cgroup 계층으로 체계적으로 관리합니다.

systemd 리소스 제어 지시어

# systemd 서비스 유닛 파일 예시: 웹 서버 리소스 제한
# /etc/systemd/system/webapp.service
[Unit]
Description=Web Application Server
After=network.target

[Service]
ExecStart=/usr/bin/webapp --port 8080
Restart=always

# CPU 제한: 2코어 분량 (200%), 가중치 200
CPUQuota=200%
CPUWeight=200

# 메모리 제한: 스로틀링 1.5G, 하드 2G, 보호 512M
MemoryHigh=1536M
MemoryMax=2G
MemoryLow=512M

# I/O 제한
IOWeight=500
IOReadBandwidthMax=/dev/nvme0n1 500M
IOWriteBandwidthMax=/dev/nvme0n1 200M

# PID 제한
TasksMax=1024

# 위임 (컨테이너 런타임 등이 하위 cgroup 관리)
Delegate=cpu memory io pids

# OOM 설정
OOMPolicy=stop
OOMScoreAdjust=-100

[Install]
WantedBy=multi-user.target

# systemd-run으로 임시 리소스 제한 적용
systemd-run --scope -p MemoryMax=1G -p CPUQuota=50% -- ./heavy-computation

# 실행 중인 서비스의 리소스 제한 동적 변경
systemctl set-property webapp.service MemoryMax=3G CPUQuota=300%

# cgroup 계층 확인
systemd-cgls
# Control group /:
# ├─init.scope
# │ └─1 /usr/lib/systemd/systemd
# ├─system.slice
# │ ├─webapp.service
# │ │ └─1234 /usr/bin/webapp
# │ └─sshd.service
# └─user.slice
#   └─user-1000.slice

# 실시간 리소스 사용량 모니터링
systemd-cgtop

cgroup BPF 프로그램

eBPF(extended Berkeley Packet Filter)는 cgroup과 결합하여 강력한 네트워크, 디바이스, 소켓 제어를 제공합니다. cgroup에 BPF 프로그램을 부착하면 해당 cgroup의 모든 프로세스에 자동으로 적용됩니다.

# bpftool로 cgroup BPF 프로그램 확인
bpftool cgroup list /sys/fs/cgroup/myapp/
# ID       AttachType      AttachFlags     Name
# 42       ingress         multi           filter_ingress
# 43       egress          multi           filter_egress
# 44       device          multi           device_filter

# BPF 프로그램 부착 (bpftool 사용)
bpftool cgroup attach /sys/fs/cgroup/myapp/ egress pinned /sys/fs/bpf/my_egress_filter multi

# ip 명령으로 네트워크 cgroup BPF 확인
ip link show dev eth0 | grep -i bpf

cgroup v1 → v2 마이그레이션

기존 cgroup v1 환경에서 v2로 전환하는 것은 단계적으로 진행해야 합니다. 하이브리드 모드를 거쳐 완전 v2로 전환하는 것이 권장됩니다.

v1 → v2 인터페이스 매핑

# v1→v2 변환 예시: cpu.shares → cpu.weight
# v1: cpu.shares 범위 2-262144, 기본 1024
# v2: cpu.weight 범위 1-10000, 기본 100
# 변환 공식: weight = 1 + ((shares - 2) * 9999) / 262142

# v1: 2048 (기본의 2배) → v2: weight ≈ 200
echo 200 > /sys/fs/cgroup/myapp/cpu.weight

# v1: cpu.cfs_quota_us=50000, cpu.cfs_period_us=100000
# v2: cpu.max "50000 100000" (quota period 형식)
echo "50000 100000" > /sys/fs/cgroup/myapp/cpu.max

# 하이브리드 모드 확인: v1과 v2가 공존하는지 체크
mount | grep cgroup
# cgroup2 on /sys/fs/cgroup type cgroup2 (rw,...) ← v2
# cgroup on /sys/fs/cgroup/memory type cgroup (rw,...) ← v1 잔여

# v1 완전 비활성화 확인
cat /proc/cmdline | grep cgroup
# ... systemd.unified_cgroup_hierarchy=1 cgroup_no_v1=all

스레드 모드 (Threaded cgroups)

cgroup v2의 스레드 모드는 프로세스 내 개별 스레드를 다른 cgroup에 배치할 수 있는 기능입니다. 일반 cgroup(domain)은 프로세스 단위로만 이동 가능하지만, threaded cgroup에서는 스레드(TID) 단위로 이동할 수 있습니다.

# 스레드 모드 활성화
echo "threaded" > /sys/fs/cgroup/myapp/worker-pool/cgroup.type

# cgroup 유형 확인
cat /sys/fs/cgroup/myapp/cgroup.type
# domain threaded    ← 스레드 도메인 (자식이 threaded)

cat /sys/fs/cgroup/myapp/worker-pool/cgroup.type
# threaded           ← 스레드 모드 cgroup

# 스레드 단위 이동 (TID 기반)
echo 1234 > /sys/fs/cgroup/myapp/worker-pool/cgroup.threads

# 스레드 모드에서 사용 가능한 컨트롤러
# cpu, cpuset, perf_event, pids
# memory, io는 스레드 모드 미지원 (프로세스 단위)

cgroup 네임스페이스

cgroup 네임스페이스는 프로세스가 자신의 cgroup을 루트(/)로 인식하도록 가상화합니다. 컨테이너 내부에서 /proc/self/cgroup을 읽으면 호스트의 실제 cgroup 경로 대신 가상화된 경로를 보게 됩니다.

# 호스트에서 확인
cat /proc/self/cgroup
# 0::/system.slice/docker-abc123.scope

# 컨테이너 내부에서 확인 (cgroup namespace 적용)
cat /proc/self/cgroup
# 0::/
# → 자신의 cgroup이 루트로 보임

# unshare로 cgroup 네임스페이스 생성
unshare --cgroup bash
cat /proc/self/cgroup
# 0::/    ← 현재 cgroup이 루트로 가상화

# nsdelegate 마운트 옵션: cgroup NS 경계에서 위임 자동 적용
mount -t cgroup2 none /sys/fs/cgroup -o nsdelegate

cgroup 모니터링 및 디버깅

cgroup 관련 문제를 진단하고 리소스 사용을 모니터링하기 위한 도구와 기법을 정리합니다.

# === cgroup 디버깅 실전 가이드 ===

# 1. 스로틀링 확인: CPU 제한에 걸리고 있는지?
cat /sys/fs/cgroup/myapp/cpu.stat
# nr_throttled 가 증가하고 있으면 cpu.max 제한에 걸리는 중
# throttled_usec 가 크면 성능 영향이 큰 상태

# 2. 메모리 압력 확인: 메모리가 부족한지?
cat /sys/fs/cgroup/myapp/memory.pressure
# some avg10=25.00 → 10% 이상이면 메모리 압력 있음

cat /sys/fs/cgroup/myapp/memory.events
# high 값이 증가하면 memory.high 초과 (스로틀링)
# oom 값이 증가하면 OOM 발생

# 3. 메모리 사용 내역 분석
cat /sys/fs/cgroup/myapp/memory.stat | head -20
# anon: 프로세스 메모리 (heap, stack)
# file: 파일 캐시
# kernel: 커널 메모리 (slab, page tables)
# sock: 소켓 버퍼

# 4. I/O 통계 확인
cat /sys/fs/cgroup/myapp/io.stat
# 8:0 rbytes=... wbytes=... rios=... wios=...

# 5. dying cgroup 확인 (좀비 cgroup)
cat /sys/fs/cgroup/cgroup.stat
# nr_descendants 42
# nr_dying_descendants 5  ← 좀비 cgroup 수
# dying cgroup은 메모리를 점유하고 있지만 사라지지 않는 상태
# → 주로 page cache 참조로 인해 발생

# 6. perf로 cgroup별 성능 카운터
perf stat -a --cgroup=system.slice/nginx.service -- sleep 5

# 7. bpftrace로 cgroup 이벤트 추적
bpftrace -e 'tracepoint:cgroup:cgroup_attach_task {
    printf("PID %d → cgroup %s\n", args->pid, args->dst_path);
}'

cgroup 성능 최적화

cgroup은 리소스 격리를 위해 추가 커널 경로를 삽입하므로 약간의 오버헤드가 있습니다. 여기서는 성능 영향을 최소화하는 방법을 정리합니다.

# === 성능 최적화 실전 ===

# 1. CPU burst 설정으로 마이크로 스파이크 허용
echo "200000 100000" > /sys/fs/cgroup/webserver/cpu.max
# 100ms period, 200ms quota (2 CPU)
echo 50000 > /sys/fs/cgroup/webserver/cpu.max.burst
# 50ms burst: 유휴 시 미사용 quota를 최대 50ms 축적
# → 스파이크 시 250ms까지 사용 가능

# 2. 메모리 보호 계층 설정 (효율적인 3단계)
# root → system.slice → nginx.service
echo "+memory +cpu +io" > /sys/fs/cgroup/system.slice/cgroup.subtree_control
echo 2G > /sys/fs/cgroup/system.slice/nginx.service/memory.max
echo 1536M > /sys/fs/cgroup/system.slice/nginx.service/memory.high
echo 512M > /sys/fs/cgroup/system.slice/nginx.service/memory.low

# 3. 불필요한 PSI 비활성화 (오버헤드 감소)
echo 0 > /sys/fs/cgroup/batch-jobs/cgroup.pressure

# 4. dying cgroup 정리
echo 3 > /proc/sys/vm/drop_caches  # page cache 해제

# 5. cgroup 계층 깊이 제한
echo 3 > /sys/fs/cgroup/cgroup.max.depth
echo 256 > /sys/fs/cgroup/cgroup.max.descendants

Delegation 심화

cgroup v2의 위임(Delegation)은 비특권 사용자나 컨테이너 런타임이 자신에게 할당된 cgroup 하위 트리를 안전하게 관리할 수 있도록 하는 메커니즘입니다. v1에서 불가능했던 안전한 다중 사용자 cgroup 관리를 가능하게 합니다.

# === Delegation 설정 방법 ===

# 방법 1: 파일 시스템 권한 기반
mkdir -p /sys/fs/cgroup/user.slice/user-1000.slice
# 위임할 파일들의 소유자를 변경
chown 1000:1000 /sys/fs/cgroup/user.slice/user-1000.slice/
chown 1000:1000 /sys/fs/cgroup/user.slice/user-1000.slice/cgroup.procs
chown 1000:1000 /sys/fs/cgroup/user.slice/user-1000.slice/cgroup.threads
chown 1000:1000 /sys/fs/cgroup/user.slice/user-1000.slice/cgroup.subtree_control

# 방법 2: systemd Delegate 지시어
# [Service] 섹션에 추가
Delegate=cpu memory io pids
# → systemd가 자동으로 하위 트리 권한을 서비스에 위임

# 방법 3: nsdelegate 마운트 옵션 (컨테이너)
mount -t cgroup2 none /sys/fs/cgroup -o nsdelegate
# cgroup 네임스페이스 진입 시 자동으로 delegation 경계 생성

# Delegation 검증
# 위임받은 사용자(uid 1000)로 실행:
su - user1000
mkdir /sys/fs/cgroup/user.slice/user-1000.slice/my-app
echo $$ > /sys/fs/cgroup/user.slice/user-1000.slice/my-app/cgroup.procs
echo "+cpu +memory" > /sys/fs/cgroup/user.slice/user-1000.slice/cgroup.subtree_control

컨테이너 런타임 cgroup 연동

Docker, containerd, CRI-O 등 컨테이너 런타임은 cgroup v2를 사용하여 컨테이너별 리소스를 격리합니다. 런타임별 cgroup 계층 구조와 설정 방법을 정리합니다.

# Docker: cgroup v2 + systemd 드라이버 설정
# /etc/docker/daemon.json
{
    "exec-opts": ["native.cgroupdriver=systemd"],
    "default-ulimits": {
        "nofile": {
            "Name": "nofile",
            "Hard": 65536,
            "Soft": 65536
        }
    }
}

# 컨테이너 리소스 제한 설정
docker run --memory=2g --memory-swap=3g \
           --cpus=2.0 --cpu-shares=512 \
           --pids-limit=1024 \
           --blkio-weight=500 \
           nginx

# 컨테이너의 cgroup 확인
docker inspect --format '{{.HostConfig.CgroupParent}}' 

# Kubernetes: cgroup v2 설정 (kubelet)
# /var/lib/kubelet/config.yaml
# cgroupDriver: systemd
# cgroupsPerQOS: true
# enforceNodeAllocatable: ["pods"]

Kubernetes cgroup v2 계층 상세

Kubernetes는 cgroup v2에서 Pod 수준 QoS 클래스를 cgroup 계층으로 매핑합니다. kubelet의 cgroupDriver: systemd 설정이 권장되며, QoS 클래스별 cgroup 경로가 자동 생성됩니다.

# Kubernetes Pod cgroup 경로 (systemd 드라이버)
# /sys/fs/cgroup/kubepods.slice/
# ├── kubepods-guaranteed.slice/
# │   └── kubepods-guaranteed-pod{uid}.slice/
# │       ├── cri-containerd-{container-id}.scope
# │       └── cri-containerd-{pause-id}.scope
# ├── kubepods-burstable.slice/
# │   └── kubepods-burstable-pod{uid}.slice/
# │       └── ...
# └── kubepods-besteffort.slice/
#     └── kubepods-besteffort-pod{uid}.slice/
#         └── ...

# Pod의 실제 cgroup 설정 확인
POD_CGROUP=kubepods.slice/kubepods-burstable.slice/kubepods-burstable-podABC.slice
cat /sys/fs/cgroup/$POD_CGROUP/memory.max
cat /sys/fs/cgroup/$POD_CGROUP/cpu.max
cat /sys/fs/cgroup/$POD_CGROUP/memory.pressure

# kubelet MemoryQoS (alpha → beta, cgroup v2 전용)
# Burstable Pod: memory.high = requests × 1.5 (자동 설정)
# → memory.high 초과 시 스로틀링 (OOM 방지)
# kubelet feature gate: MemoryQoS=true

실전 운영 레시피

프로덕션 환경에서 자주 사용되는 cgroup 설정 패턴과 문제 해결 레시피를 정리합니다.

레시피 1: 웹 서버 최적 cgroup 설정

# 웹 서버: 응답 시간 보장 + 메모리 보호
# systemd unit: /etc/systemd/system/nginx.service.d/cgroup.conf
[Service]
# CPU: 4코어 분량, 버스트 허용
CPUQuota=400%
CPUWeight=300

# 메모리: 하드 4G, 스로틀 3G, 보호 1G
MemoryMax=4G
MemoryHigh=3G
MemoryLow=1G

# I/O: 높은 가중치 (DB보다 낮지만 배치보다 높게)
IOWeight=500

# PID: 웹 서버 워커 + 커넥션 핸들러
TasksMax=4096

# UCLAMP: 최소 성능 보장 (모바일/ARM)
# cpu.uclamp.min=20.00 (systemd 252+)

레시피 2: 데이터베이스 cgroup 설정

# 데이터베이스: 메모리 보호 최우선 + OOM 그룹 kill
[Service]
# CPU: 전용 코어 할당
AllowedCPUs=4-15
CPUWeight=500

# 메모리: 최대한 보호
MemoryMax=32G
MemoryHigh=28G
MemoryLow=16G
MemoryMin=8G
MemorySwapMax=0

# OOM 시 전체 종료 (일부만 죽으면 데이터 손상)
OOMPolicy=stop
# memory.oom.group=1 (수동 설정 필요)

# I/O: 최고 가중치
IOWeight=900
IODeviceWeight=/dev/nvme0n1 1000

# 위임: 내부 워커 관리
Delegate=cpu memory io pids

레시피 3: 배치 작업 격리

# 배치 작업: 낮은 우선순위, 남은 자원 활용
systemd-run --scope --slice=batch.slice \
  -p CPUWeight=10 \
  -p MemoryMax=8G \
  -p MemoryHigh=6G \
  -p IOWeight=10 \
  -p TasksMax=256 \
  # cpu.idle=1 효과 (systemd 252+)
  -- /usr/bin/batch-job

# 배치 슬라이스 전체 설정
# /etc/systemd/system/batch.slice
[Slice]
CPUWeight=10
MemoryMax=16G
IOWeight=10

레시피 4: 포크 폭탄 방어

# 시스템 전체 PID 제한
echo 32768 > /sys/fs/cgroup/pids.max

# 사용자별 PID 제한 (systemd)
# /etc/systemd/system/user-.slice.d/pids.conf
[Slice]
TasksMax=4096

# 컨테이너별 PID 제한
docker run --pids-limit=512 nginx

# 포크 폭탄 감지 스크립트
while true; do
    for cg in /sys/fs/cgroup/user.slice/user-*/; do
        current=$(cat "$cg/pids.current" 2>/dev/null)
        max=$(cat "$cg/pids.max" 2>/dev/null)
        if [ "$current" -gt $((max * 90 / 100)) ]; then
            echo "경고: $cg PID 90% 초과 ($current/$max)"
        fi
    done
    sleep 5
done

레시피 5: 폭주 워크로드 긴급 격리

# 긴급 상황: 특정 cgroup이 시스템 자원을 독점

# 1단계: 즉시 CPU 제한 (10% CPU만 허용)
echo "10000 100000" > /sys/fs/cgroup/runaway/cpu.max

# 2단계: 메모리 제한 강화
echo 1G > /sys/fs/cgroup/runaway/memory.max

# 3단계: I/O 제한
echo "8:0 rbps=1048576 wbps=1048576" > /sys/fs/cgroup/runaway/io.max

# 4단계: 프로세스 동결 (분석을 위해)
echo 1 > /sys/fs/cgroup/runaway/cgroup.freeze

# 5단계: 상태 분석
cat /sys/fs/cgroup/runaway/memory.stat
cat /sys/fs/cgroup/runaway/cpu.stat
cat /sys/fs/cgroup/runaway/pids.current

# 6단계: 필요 시 전체 종료
echo 1 > /sys/fs/cgroup/runaway/cgroup.kill

# 대안: 동결 해제 후 정상 제한으로 복구
echo 0 > /sys/fs/cgroup/runaway/cgroup.freeze
echo "200000 100000" > /sys/fs/cgroup/runaway/cpu.max

mem_cgroup 커널 내부 구조

메모리 컨트롤러의 핵심 자료구조인 struct mem_cgroup을 분석합니다. 이 구조체는 cgroup당 메모리 회계, 제한, 통계를 관리합니다.

/* include/linux/memcontrol.h — mem_cgroup 핵심 필드 */
struct mem_cgroup {
    struct cgroup_subsys_state css;  /* cgroup 서브시스템 상태 (공통) */

    /* 페이지 카운터 (계층적 누적) */
    struct page_counter memory;     /* 전체 메모리 카운터 */
    struct page_counter swap;       /* 스왑 카운터 */
    struct page_counter kmem;       /* 커널 메모리 (v2에서는 memory에 통합) */
    struct page_counter tcpmem;     /* TCP 소켓 메모리 */

    /* 워터마크 */
    unsigned long high;             /* memory.high (스로틀링 임계값) */

    /* VMPRESSURE: 메모리 압력 모니터 */
    struct vmpressure vmpressure;

    /* OOM 관련 */
    bool oom_group;                 /* memory.oom.group */
    int under_oom;                  /* OOM 진행 중 */
    int oom_kill_disable;           /* OOM kill 비활성화 */

    /* 통계: memory.stat에 표시 */
    struct memcg_vmstats *vmstats;
    struct memcg_vmstats_percpu __percpu *vmstats_percpu;

    /* LRU: cgroup-aware 페이지 회수 */
    struct mem_cgroup_per_node *nodeinfo[];
    /* → 노드별 LRU 리스트 (anon_active, anon_inactive, */
    /*    file_active, file_inactive) */

    /* 이벤트 카운터: memory.events */
    struct cgroup_file events_file;
    struct cgroup_file events_local_file;

    /* 워크큐: memory.high 초과 시 비동기 회수 */
    struct work_struct high_work;

    /* 소프트 제한 (v1 호환) */
    unsigned long soft_limit;

    /* Swap: 스왑 관련 설정 */
    int swappiness;                 /* cgroup별 swappiness */

    /* 차징 관련 */
    struct task_struct *move_charge_at_immigrate;
};

/* mem_cgroup_per_node: NUMA 노드별 LRU */
struct mem_cgroup_per_node {
    struct lruvec lruvec;          /* cgroup-aware LRU 벡터 */
    unsigned long lru_zone_size[MAX_NR_ZONES][NR_LRU_LISTS];
    struct mem_cgroup_reclaim_iter iter;
    struct rb_node tree_node;     /* soft limit 트리 */
    unsigned long usage_in_excess; /* soft limit 초과량 */
};

cgroup 커널 구현 아키텍처

cgroup 코어의 핵심 자료구조와 관계를 분석합니다.

/* cgroup 프로세스 이동 핵심 경로 */
/* cgroup.procs에 PID를 쓰면 호출되는 경로 */

/* 1. 유효성 검사 */
cgroup_procs_write(...)
  → cgroup_attach_task(dst_cgrp, task, threadgroup)
    → cgroup_migrate_add_src(...)   /* 이동 대상 수집 */
    → cgroup_migrate_prepare_dst(...) /* 목적지 css_set 할당 */

/* 2. 각 컨트롤러의 can_attach() 호출 */
for_each_subsys(ss, i) {
    if (ss->can_attach)
        ret = ss->can_attach(css, &mgctx->tset);
    /* 메모리 컨트롤러: charge 이동 가능 여부 확인 */
    /* CPU 컨트롤러: 대역폭 재계산 */
}

/* 3. 실제 이동 실행 */
cgroup_migrate_execute(...)
  → css_set_move_task(task, from_cset, to_cset)
  → for_each_subsys(ss, i)
        ss->attach(css, &mgctx->tset);

/* 4. RCU 기반 안전한 교체 */
rcu_assign_pointer(task->cgroups, new_cset);
/* → 다음 RCU grace period 이후 old_cset 해제 */

cgroup 파일시스템 구조

cgroup v2는 cgroup2 가상 파일시스템을 통해 사용자 공간과 통신합니다. 이 파일시스템은 kernfs 기반으로 구현되어 있으며, 각 cgroup 디렉토리가 하나의 cgroup 노드에 대응합니다.

# cgroup2 파일시스템 정보
mount | grep cgroup2
# cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)

# 마운트 옵션 상세
# nsdelegate: cgroup NS 경계에서 자동 delegation
# memory_recursiveprot: memory.low/min 재귀적 보호 활성화
# memory_hugetlb_accounting: HugeTLB 페이지 통합 회계

# 전체 cgroup 트리 구조 출력
find /sys/fs/cgroup -maxdepth 3 -type d | head -30
# /sys/fs/cgroup
# /sys/fs/cgroup/init.scope
# /sys/fs/cgroup/system.slice
# /sys/fs/cgroup/system.slice/nginx.service
# /sys/fs/cgroup/user.slice
# /sys/fs/cgroup/user.slice/user-1000.slice
# ...

# 각 cgroup 디렉토리의 파일 목록
ls /sys/fs/cgroup/system.slice/nginx.service/
# cgroup.controllers    cgroup.events        cgroup.freeze
# cgroup.kill           cgroup.max.depth     cgroup.max.descendants
# cgroup.pressure       cgroup.procs         cgroup.stat
# cgroup.subtree_control cgroup.threads       cgroup.type
# cpu.max               cpu.max.burst        cpu.pressure
# cpu.stat              cpu.uclamp.max       cpu.uclamp.min
# cpu.weight            cpu.weight.nice      io.max
# io.pressure           io.stat              io.weight
# memory.current        memory.events        memory.events.local
# memory.high           memory.low           memory.max
# memory.min            memory.numa_stat     memory.oom.group
# memory.peak           memory.pressure      memory.reclaim
# memory.stat           memory.swap.current  memory.swap.events
# memory.swap.high      memory.swap.max      memory.swap.peak
# memory.zswap.current  memory.zswap.max     pids.current
# pids.events           pids.max             pids.peak

cgroup.events를 이용한 이벤트 모니터링

cgroup.events 파일은 inotify와 poll()로 모니터링할 수 있어, cgroup 상태 변화를 효율적으로 감지할 수 있습니다:

/* cgroup.events 이벤트 모니터링 예시 */
#include <sys/inotify.h>
#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>

int main(void) {
    int ifd = inotify_init1(IN_NONBLOCK);
    int wd = inotify_add_watch(ifd,
        "/sys/fs/cgroup/myapp/cgroup.events",
        IN_MODIFY);

    struct pollfd fds = { .fd = ifd, .events = POLLIN };

    while (1) {
        int ret = poll(&fds, 1, -1);
        if (ret > 0) {
            /* cgroup 상태 변경 감지 */
            char buf[256];
            read(ifd, buf, sizeof(buf));
            /* cgroup.events 다시 읽기 */
            int fd = open("/sys/fs/cgroup/myapp/cgroup.events", O_RDONLY);
            ssize_t n = read(fd, buf, sizeof(buf) - 1);
            buf[n] = '\0';
            printf("Events: %s\n", buf);
            /* "populated 0" → cgroup 내 프로세스 없음 */
            /* "frozen 1"    → 프로세스 동결됨 */
            close(fd);
        }
    }
    return 0;
}

HugeTLB 컨트롤러

HugeTLB 컨트롤러는 cgroup별 대형 페이지(HugeTLB) 사용량을 제한합니다. 데이터베이스나 과학 연산 등 대형 메모리를 사용하는 워크로드에서 공정한 HugeTLB 분배를 보장합니다.

# HugeTLB 컨트롤러 파일 (페이지 크기별)
cat /sys/fs/cgroup/myapp/hugetlb.2MB.current
cat /sys/fs/cgroup/myapp/hugetlb.2MB.max
cat /sys/fs/cgroup/myapp/hugetlb.2MB.events
cat /sys/fs/cgroup/myapp/hugetlb.1GB.current
cat /sys/fs/cgroup/myapp/hugetlb.1GB.max

# 2MB HugeTLB 제한: 최대 512MB (256개 × 2MB)
echo 536870912 > /sys/fs/cgroup/myapp/hugetlb.2MB.max

# 1GB HugeTLB 제한: 최대 4GB
echo 4294967296 > /sys/fs/cgroup/myapp/hugetlb.1GB.max

# HugeTLB 통합 회계 (커널 6.1+, memory_hugetlb_accounting 마운트 옵션)
# HugeTLB 사용량이 memory.current에도 반영됨

Misc 컨트롤러

Misc 컨트롤러는 다른 컨트롤러에 속하지 않는 스칼라 리소스를 제한합니다. 대표적으로 SEV(AMD Secure Encrypted Virtualization) ASIDs와 Intel SGX EPC 페이지가 있습니다.

# Misc 컨트롤러 가용 리소스 확인
cat /sys/fs/cgroup/misc.capacity
# sev 509
# sev_es 509
# sgx_epc 65536

# cgroup별 Misc 제한
echo "sev 100" > /sys/fs/cgroup/vm-pool/misc.max
echo "sgx_epc 8192" > /sys/fs/cgroup/sgx-app/misc.max

# 현재 사용량
cat /sys/fs/cgroup/vm-pool/misc.current
# sev 42

cgroup 보안 강화

컨테이너 환경에서 cgroup 보안을 강화하기 위한 모범 사례를 정리합니다.

# 컨테이너 보안 강화: 권장 부트 옵션
GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=1 \
  cgroup_no_v1=all \
  systemd.legacy_systemd_cgroup_controller=0"

# cgroup 파일시스템 보안 마운트
mount -t cgroup2 none /sys/fs/cgroup \
  -o rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot

# 커널 설정 확인
grep CGROUP /boot/config-$(uname -r)
# CONFIG_CGROUPS=y
# CONFIG_CGROUP_V1=n          ← v1 비활성화 (최신 커널)
# CONFIG_BLK_CGROUP=y
# CONFIG_CGROUP_WRITEBACK=y   ← buffered I/O 제어
# CONFIG_CGROUP_SCHED=y
# CONFIG_CGROUP_PIDS=y
# CONFIG_CGROUP_BPF=y
# CONFIG_MEMCG=y
# CONFIG_PSI=y

프로덕션 설정 모범 사례

대규모 프로덕션 환경에서 cgroup을 효과적으로 운용하기 위한 모범 사례를 정리합니다.

계층 설계 원칙

# 권장 cgroup 계층 설계 (3단계)
/sys/fs/cgroup/
├── system.slice/              # 시스템 서비스
│   ├── nginx.service/         # 웹 서버
│   ├── postgresql.service/    # 데이터베이스
│   └── redis.service/         # 캐시
├── user.slice/                # 사용자 세션
│   ├── user-1000.slice/       # 사용자별 격리
│   └── user-1001.slice/
├── machine.slice/             # VM/컨테이너
│   ├── docker-abc.scope/      # 컨테이너별 격리
│   └── docker-def.scope/
└── batch.slice/               # 배치 작업 (낮은 우선순위)
    ├── etl.service/
    └── backup.service/

# 슬라이스별 리소스 배분 (systemd)
# /etc/systemd/system/system.slice
[Slice]
CPUWeight=500       # 시스템 서비스: 높은 가중치
MemoryHigh=60%      # 전체 메모리의 60% (비율 지원, systemd 254+)

# /etc/systemd/system/batch.slice
[Slice]
CPUWeight=10        # 배치: 낮은 가중치
MemoryHigh=20%
IOWeight=10

모니터링 구성

# Prometheus node_exporter cgroup 메트릭 활성화
# --collector.cgroup (기본 활성화)
# 수집 메트릭:
# node_cgroup_memory_usage_bytes
# node_cgroup_cpu_usage_seconds_total
# node_cgroup_memory_pressure_some
# node_cgroup_memory_pressure_full

# Grafana 대시보드 PromQL 예시
# CPU 스로틀링 비율:
# rate(container_cpu_cfs_throttled_periods_total[5m])
#   / rate(container_cpu_cfs_periods_total[5m]) * 100

# 메모리 사용률:
# container_memory_usage_bytes / container_spec_memory_limit_bytes * 100

# PSI 메모리 압력 (cAdvisor):
# container_memory_pressure_some_total

# 알림 규칙 예시 (Prometheus AlertManager)
# - alert: HighMemoryPressure
#   expr: container_memory_pressure_some > 25
#   for: 5m
#   labels: { severity: warning }
#
# - alert: CpuThrottlingHigh
#   expr: rate(container_cpu_cfs_throttled_periods_total[5m])
#         / rate(container_cpu_cfs_periods_total[5m]) > 0.25
#   for: 5m
#   labels: { severity: warning }

용량 계획 지침

오버커밋과 QoS 전략

물리 리소스보다 더 많은 리소스를 할당(오버커밋)하되, 우선순위를 통해 경쟁 상황을 관리하는 전략입니다:

# 예: 8 CPU 코어, 32GB RAM 서버

# Tier 1: 보장 (Guaranteed) — 리소스 합: 6 CPU, 24GB
# → memory.min으로 하드 보호
echo 8G > /sys/fs/cgroup/tier1-db/memory.min
echo 16G > /sys/fs/cgroup/tier1-db/memory.max
echo 500 > /sys/fs/cgroup/tier1-db/cpu.weight

echo 4G > /sys/fs/cgroup/tier1-web/memory.min
echo 8G > /sys/fs/cgroup/tier1-web/memory.max
echo 300 > /sys/fs/cgroup/tier1-web/cpu.weight

# Tier 2: 탄력적 (Burstable) — 리소스 합: 4 CPU, 16GB
# → memory.low로 소프트 보호, 여유 시 burst
echo 4G > /sys/fs/cgroup/tier2-api/memory.low
echo 12G > /sys/fs/cgroup/tier2-api/memory.max
echo 200 > /sys/fs/cgroup/tier2-api/cpu.weight

# Tier 3: 최선 (BestEffort) — 보호 없음
# → 남는 리소스만 사용
echo 8G > /sys/fs/cgroup/tier3-batch/memory.max
echo 10 > /sys/fs/cgroup/tier3-batch/cpu.weight
echo 1 > /sys/fs/cgroup/tier3-batch/cpu.idle

# 전체 합: CPU weight 총합 = 1010, Memory min 총합 = 12GB < 32GB ✓
# 오버커밋 비율: Memory max 총합 = 44GB / 32GB = 1.375x
# → memory.min/low 보호로 tier1이 먼저 보장됨

cgroup 관련 커널 파라미터

참고 자료 및 출처

cgroup 발전 로드맵

cgroup 서브시스템은 리눅스 커널에서 가장 활발하게 발전하는 영역 중 하나입니다. 최신 커널에서 추가되었거나 진행 중인 주요 변화를 정리합니다.

cgroup v1 폐기 일정

cgroup v1은 점진적으로 폐기(deprecation) 경로에 있습니다:

cgroup 용어 사전

cgroup 테스트 프레임워크

커널 cgroup 기능을 테스트하기 위한 도구와 프레임워크를 정리합니다.

# 1. 커널 셀프 테스트: tools/testing/selftests/cgroup/
cd /usr/src/linux/tools/testing/selftests/cgroup
make
sudo ./test_memcontrol     # 메모리 컨트롤러 테스트
sudo ./test_cpu            # CPU 컨트롤러 테스트
sudo ./test_pids           # PID 컨트롤러 테스트
sudo ./test_freezer        # Freezer 테스트
sudo ./test_kill           # cgroup.kill 테스트

# 2. LTP (Linux Test Project) cgroup 테스트
# https://github.com/linux-test-project/ltp
cd ltp
./configure && make
sudo ./runltp -f controllers

# 3. stress-ng로 cgroup 제한 검증
# CPU 제한 검증
systemd-run --scope -p CPUQuota=100% -- \
  stress-ng --cpu 4 --timeout 30s --metrics-brief
# → cpu-used 합계가 ~100%인지 확인

# 메모리 제한 검증
systemd-run --scope -p MemoryMax=512M -- \
  stress-ng --vm 2 --vm-bytes 256M --timeout 30s
# → memory.current가 512M 이하인지 확인

# 4. cgroup-v2-test (커뮤니티 도구)
# PSI 트리거 정확도 테스트
# 메모리 회수 경로 테스트
# OOM 동작 테스트
# delegation 권한 테스트

# 5. bpftrace 기반 cgroup 이벤트 검증
sudo bpftrace -e '
tracepoint:cgroup:cgroup_mkdir { printf("mkdir: %s\n", args->path); }
tracepoint:cgroup:cgroup_rmdir { printf("rmdir: %s\n", args->path); }
tracepoint:cgroup:cgroup_attach_task { printf("attach PID %d → %s\n", args->pid, args->dst_path); }
tracepoint:oom:oom_score_adj_update { printf("oom_adj PID %d → %d\n", args->pid, args->oom_score_adj); }
'

자주 묻는 질문 (FAQ)

관련 문서

cgroups와 관련된 다른 주제를 더 깊이 이해하고 싶다면 다음 문서를 참고하세요.

• Linux Containers — 컨테이너와 cgroups 연동
• 네임스페이스 — 격리와 cgroup 네임스페이스
• 프로세스 스케줄러 — CPU cgroup과 CFS 대역폭 제어
• 메모리 관리 (기초) — 메모리 cgroup의 기반 개념
• cpusets & CPU Isolation — CPU/NUMA 격리 실전
• 버디 할당자 — 메모리 할당과 cgroup charge 경로
• BPF/XDP — cgroup BPF 프로그램
• 블록 I/O 계층 — IO 컨트롤러 내부 구현
• PSI (Pressure Stall Information) — 리소스 압력 모니터링 심화
• OOM Killer — cgroup-aware OOM 메커니즘
• Android 커널 — Android의 cgroup 활용
• Seccomp — cgroup과 함께 사용하는 시스템 콜 필터링
• 슬랩 할당자 — memcg-aware slab 계정 (kmem accounting)
• HugePages — HugeTLB cgroup 컨트롤러의 기반
• Swap 관리 — cgroup v2 memory.swap 컨트롤러
• NUMA 아키텍처 — NUMA-aware 메모리 분배와 cpuset
• eBPF 심화 — cgroup BPF 프로그램 작성 및 디버깅
• systemd 내부 구조 — systemd의 cgroup 관리 메커니즘