Docker가 에너지 소비에 미치는 영향

초록

본 연구는 Docker 컨테이너와 베어메탈 Linux 환경에서 동일한 워크로드를 실행했을 때의 전력 소비 차이를 실험적으로 측정한다. 세 가지 오픈소스 애플리케이션(WordPress‑MySQL, Redis, PostgreSQL)을 대상으로 40회 반복 실험을 수행하고, RMS 기반 전력 측정 장치를 이용해 순간 전력을 수집한 뒤 에너지(와트·시)로 적분한다. 통계적 검증(t‑test, Wilcoxon) 결과 Docker 환경이 모든 경우에서 베어메탈 대비 유의미하게 높은 에너지를 소모함을 확인했으며, 특히 I/O 시스템 호출 오버헤드가 주요 원인으로 지목된다.

상세 분석

이 논문은 컨테이너 기반 가상화가 “무공해”라는 가정에 도전한다. 실험 설계는 두 대의 동일 사양 Dell PowerEdge R710 서버를 사용해 SUT(System‑Under‑Test)와 테스트 러너를 물리적으로 분리함으로써 전력 측정에 외부 간섭을 최소화하였다. 전력 측정은 Watts Up? Pro의 RMS 샘플을 1 초 간격으로 수집하고, 이를 사각형 적분법으로 에너지로 변환하였다. 각 워크로드는 40번 반복했으며, 테스트 전 2분간 아이들 상태를 유지해 초기 전력 상태를 동일하게 맞추었다.

세 가지 워크로드는 서로 다른 자원 특성을 갖는다. WordPress‑MySQL은 CPU와 디스크 I/O가 혼합된 웹‑DB 시나리오이며, Redis는 메모리‑집중형 키‑값 저장소, PostgreSQL은 디스크‑집중형 관계형 DB이다. 결과는 Docker가 베어메탈 대비 평균 3 %~7 % 정도 높은 에너지를 소비했으며, 특히 디스크 I/O가 많은 PostgreSQL 테스트에서 차이가 가장 크게 나타났다. 통계적 검증은 두 방법 모두 p < 0.05를 기록해 차이가 우연이 아님을 입증한다.

원인 분석에서는 Docker 데몬 자체와 UnionFS와 같은 파일시스템 레이어, 그리고 네트워크 네임스페이스와 cgroup 제어 그룹이 추가적인 시스템 콜을 유발해 전력 소모를 증가시킨다고 주장한다. 특히 컨테이너 내부에서 파일시스템이 겹쳐질 때 발생하는 복합적인 메타데이터 관리와 복사‑온‑쓰기(Copy‑On‑Write) 메커니즘이 디스크 접근 지연을 초래하고, 이는 CPU 대기 시간 증가와 전력 소모 상승으로 이어진다.

한계점으로는 전력 측정 장치가 전체 시스템 전력을 측정하므로 CPU 전용 RAPL과 같은 미세 측정과는 차이가 있을 수 있다. 또한 Docker 버전(1.12.1)과 커널(4.4) 등 특정 환경에 국한돼 최신 컨테이너 런타임 최적화가 반영되지 않았을 가능성이 있다. 실험에 사용된 워크로드는 대표적이지만, 대규모 분산 서비스나 GPU 가속 작업 등 다른 시나리오에 대한 일반화는 조심해야 한다.

이 연구는 컨테이너 도입 시 에너지 효율성을 단순히 “낮다”고 가정하기보다, 실제 워크로드 특성과 시스템 콜 오버헤드를 정량적으로 평가해야 함을 강조한다.