Docker는 CPU를 어떻게 나눠 쓰는가: 컨텍스트 스위칭과 자원 관리 구조

컨테이너 기술이 대세가된 시대입니다. 하지만 많은 개발자가 Docker를 "가볍고 빠른 가상머신" 정도로만 이해하는것 같습니다.

이 글은 "추상적인 개념 설명"이 아니라
Docker에서 실제로 어떤 방식으로 컨텍스트 스위칭이 발생하고, 리소스가 어떻게 처리되는지 다룹니다.

Docker와 커널: 어디까지 분리되고 어디까지 공유되는가

Docker는 독립된 OS가 아닙니다. 모든 컨테이너는 호스트 리눅스 커널을 공유합니다. 따라서 컨테이너별 격리가 매우 중요하죠.

Docker의 격리 수단에는 Namespaces와 cgroups이 있습니다. 이 두가지가 docker에서 가장 중요하다고 생각됩니다.

• Namespaces: 프로세스/네트워크/파일시스템 격리
• cgroups: CPU/메모리/I/O 제한 및 관리

즉, 컨테이너 안에서 실행되는 프로세스도 결국 호스트의 스케줄러가 관리하는 리눅스 프로세스일 뿐입니다.

컨텍스트 스위칭이란

CPU는 매우 단순한 존재입니다. proram counter register를 보고 명령어를 인출하여 실행할뿐이죠.

결국 윗단에서 어떻게 명령어를 정하느냐가 핵심이 됩니다.

컨텍스트 스위칭(context switching)은 CPU가 실행 중인 작업을 다른 작업으로 바꾸는 과정으로 프로세스, 스레드 등을 매우 빠른 속도로 작업을 바꾸어 마치 동시에 실행되게끔 보이게 만듭니다.

발생 시점:

• 프로세스 전환
• 스레드 전환
• 사용자 모드 ↔ 커널 모드 전환

어떤 명령에서는 CPU가 하는일에 부담이 되는 명령어도 있습니다. 아래는 CPU 오버헤드를 부를수 있는 경우입니다.

• 레지스터 상태 저장/복원
• 캐시 미스 증가
• 메모리, I/O 큐 영향

Docker에서 컨텍스트 스위칭이 발생하는 순간

컨테이너도 OS 프로세스이므로 아래 이벤트에서 전환이 일어나게 됩니다.

• 컨테이너 간 CPU 경쟁
• cgroups CPU 제한 설정 (quota, share)
• I/O 기다림 (DB, network)
• 시스템 콜 호출
• 네트워킹 (컨테이너 → host bridge → kernel stack)

Container Process
  ↓ syscalls
Host Kernel
  ↓ scheduler decision
CPU Core

결국 컨테이너가 많아질수록 스위칭 비용 증가하게 되는 구조입니다.

리소스 처리 방식

실전 성능 영향

결국 컨테이너 개수가 늘어날수록 아래의 구조가 될수밖에 없습니다.

• 컨텍스트 스위칭 비용 ↑
• 캐시 효율 ↓
• I/O wait 증가

최적화 방법

아래는 docker container이용시 최적화 방법이 될수 있는 방법들 입니다.

# CPU core 바인딩
docker run --cpuset-cpus="0,1"

• 컨테이너가 특정 CPU 코어만 사용
• 캐시(local cache, NUMA) 일관성 유지 → CPU 캐시 미스 감소
• CPU 컨텍스트 스위칭 감소

# CPU 제한
docker run --cpu-quota=50000 --cpu-period=100000

• 컨테이너 CPU 사용량 제한
• 한 컨테이너가 CPU 독점 방지
• 노이즈/버스트 워크로드의 CPU 폭주 제어

# 메모리 제한 
docker run -m 2g --memory-swap=2g

• 메모리 오버커밋 방지
• 시스템 전체 OOM(Out Of Memory) 사고 예방

진단 도구

마무리

Docker가 가볍다고 해서 운영체제 레벨 오버헤드가 없는건 아닙니다. 성능이슈가 생긴다면 어떤 컨테이너(프로세스)가 문제가 있는지 확인해야하고, 그에따른 최적화가 필요할수 있습니다 🙂