도커화가 데이터베이스 벤치마크 성능에 미치는 영향

초록

본 논문은 데이터베이스 벤치마크에서 도커 컨테이너를 사용했을 때 발생하는 간접적인 성능 변동을 조사한다. 실험 결과, 워크로드 유형, 자원 제한 설정, 스토리지 드라이버 등에 따라 컨테이너화가 측정값에 5 %에서 15 %까지 비정상적인 영향을 미칠 수 있음을 확인하였다. 따라서 벤치마크에 도커를 도입하기 전 사전 검증이 필요함을 강조한다.

상세 분석

이 연구는 기존 연구가 주로 애플리케이션 수준에서 도커가 직접 유발하는 오버헤드(예: CPU 스케줄링, 네트워크 네임스페이스)만을 다루었던 점을 보완한다. 저자들은 동일한 물리적 서버에서 MySQL 5.7과 PostgreSQL 13을 대상으로 TPC‑C, YCSB, Sysbench 등 세 가지 대표적인 워크로드를 실행하였다. 실험 환경은 네이티브(호스트 직접 실행)와 도커화된 두 가지 경우로 나뉘며, 도커에서는 CPU‑share, 메모리 제한, I/O 제한, 네트워크 모드(bridge vs host), 스토리지 드라이버(overlay2, devicemapper) 등 다섯 가지 변수 조합을 체계적으로 변형하였다.

측정 지표는 트랜잭션 처리량(TPS), 평균 응답시간, CPU 사용률, 메모리 페이지 폴트, 디스크 I/O 대기시간, 네트워크 지연 등을 포함한다. 결과는 크게 두 가지 패턴으로 나타났다. 첫째, CPU‑share를 0.5로 낮추거나 메모리 제한을 2 GB 이하로 설정하면 CPU와 메모리 경합이 심화되어 TPS가 평균 8 %~12 % 감소하고, 응답시간이 15 %~20 % 증가한다. 둘째, 스토리지 드라이버가 overlay2에서 devicemapper로 바뀔 경우, 특히 쓰기‑중심 워크로드에서 디스크 대기시간이 30 %까지 늘어나며, 이는 전체 처리량 감소로 직결된다. 네트워크 모드가 host일 때는 bridge 모드 대비 평균 4 % 정도의 성능 향상이 관찰되었지만, 이는 워크로드가 네트워크 바운드일 때만 의미가 있다.

특히 주목할 점은 동일한 설정이라도 실험을 반복할 경우 측정값의 변동 폭이 3 %~7 % 정도 존재한다는 것이다. 이는 도커 내부의 cgroup 스케줄링, 커널 버전, 그리고 백그라운드 컨테이너 수에 따라 동적으로 자원 할당이 달라지기 때문이다. 따라서 “도커화가 성능에 미치는 영향은 일정하지 않다”는 결론은 실험 재현성 측면에서도 중요한 시사점을 제공한다.

저자들은 이러한 비정상적인 변동을 최소화하기 위해 다음과 같은 실무적 권고사항을 제시한다. ① 벤치마크 전용 호스트를 마련하고, 도커와 네이티브 환경을 동일한 커널·cgroup 설정으로 맞춘다. ② 컨테이너 실행 시 CPU‑set과 메모리‑limit을 워크로드 요구에 맞게 정확히 지정하고, 가능한 한 host 네트워크와 overlay2 스토리지 드라이버를 사용한다. ③ 실험은 최소 5회 이상 반복하여 평균값과 표준편차를 보고하고, 결과에 대한 통계적 유의성을 검증한다. ④ 도커 버전·엔진 설정이 바뀔 경우 반드시 재검증한다. 이러한 절차를 따르지 않으면 벤치마크 결과가 실제 서비스 성능과 크게 차이날 위험이 있다.