서버 운영자나 데브옵스 엔지니어라면 누구나 한 번쯤 겪어봤을 아찔한 상황이 있습니다. 바로 운영 중인 서버의 디스크 용량이 100%에 도달하여 서비스가 멈추거나 동작이 불안정해지는 경우입니다. 특히 도커(Docker) 환경에서 컨테이너를 장기간 운영하다 보면, 우리가 미처 신경 쓰지 못한 사이에 로그 파일이 기하급수적으로 커져 수십 기가바이트(GB)에서 심지어 테라바이트(TB) 단위까지 디스크를 점유하는 일이 빈번하게 발생합니다.
일반적인 상황이라면 컨테이너를 삭제하고 다시 실행하거나, 도커 데몬을 재시작하여 로그 설정을 적용하면 해결되겠지만, 실시간으로 트래픽을 처리하고 있는 '라이브 서비스'라면 이야기가 다릅니다. 서비스 중단(Downtime)은 곧 매출 하락과 신뢰도 저하로 이어지기 때문에, 우리는 서비스 중단 없이 즉시 디스크 공간을 확보해야 하는 절체절명의 과제를 안게 됩니다. 오늘은 도커 컨테이너가 실행 중인 상태에서 안전하게 로그 용량을 비우고, 향후 재발을 방지하기 위한 근본적인 설정 방법까지 상세하게 알아보겠습니다.
도커 로그가 디스크를 잠식하는 원인 분석
문제를 해결하기에 앞서, 도대체 왜 도커 로그가 이렇게 무자비하게 디스크를 채우는지 그 메커니즘을 이해할 필요가 있습니다. 원인을 정확히 알아야만 동일한 실수를 반복하지 않고 최적의 운영 환경을 구축할 수 있기 때문입니다.
기본 로깅 드라이버의 함정: JSON-file
도커를 설치하고 별도의 설정을 하지 않았다면, 기본 로깅 드라이버는 'json-file'로 설정되어 있습니다. 이는 컨테이너 내부에서 발생하는 표준 출력(STDOUT)과 표준 에러(STDERR)를 호스트 머신의 특정 경로에 JSON 형식의 파일로 저장하는 방식입니다. 문제는 이 방식이 기본적으로 '용량 제한'이나 '파일 개수 제한'이 설정되어 있지 않다는 점입니다. 즉, 컨테이너가 1년이고 2년이고 계속 실행된다면, 로그 파일은 디스크가 꽉 찰 때까지 무한정 커지게 됩니다.
잘못된 애플리케이션 로그 레벨 설정
개발 단계에서 디버깅을 위해 설정해 둔 'Debug' 모드나 'Verbose' 모드를 운영 환경(Production) 배포 시 끄지 않은 경우도 흔한 원인 중 하나입니다. 트래픽이 적을 때는 문제가 되지 않지만, 사용자가 몰리거나 특정 이벤트가 발생했을 때 불필요한 상세 로그가 초당 수백, 수천 줄씩 기록되면서 순식간에 기가바이트 단위의 로그가 쌓이게 됩니다. 특히 무한 루프에 빠진 애플리케이션이 에러 로그를 쉴 새 없이 뱉어내는 상황이라면 디스크 고갈은 시간문제입니다.
현재 디스크 상태 진단 및 로그 파일 찾기
디스크 용량 부족 알림을 받았다면, 가장 먼저 해야 할 일은 정확히 '어떤' 파일이 공간을 차지하고 있는지 범인을 색출하는 것입니다. 리눅스 환경을 기준으로 도커 로그가 어디에 숨어있는지 확인하는 절차를 살펴보겠습니다.
디스크 사용량 전체 점검
터미널에서 `df -h` 명령어를 입력하여 현재 마운트된 디스크의 사용량을 확인합니다. 보통 도커 데이터는 `/var/lib/docker` 경로에 저장되므로, 루트 파티션(`/`)이나 `/var` 파티션의 사용량이 90% 이상 혹은 100%인지 확인해야 합니다. 만약 `/var` 경로가 별도 파티션으로 분리되어 있지 않다면 루트 파티션 전체가 꽉 차서 시스템의 다른 기능까지 마비될 수 있습니다.
도커 시스템 용량 확인
도커는 자체적으로 디스크 사용량을 요약해서 보여주는 명령어를 제공합니다. `docker system df`를 입력하면 이미지, 컨테이너, 로컬 볼륨, 빌드 캐시가 각각 얼마나 공간을 차지하고 있는지 한눈에 볼 수 있습니다. 여기서 'Containers' 항목의 용량이 비정상적으로 크다면, 이는 컨테이너 내부의 쓰기 레이어(Writable Layer) 혹은 로그 파일이 비대해졌음을 의미합니다. 더 구체적으로 각 컨테이너별 용량을 보고 싶다면 `docker system df -v` 명령어를 활용할 수 있습니다.
거대 로그 파일의 실제 경로 찾기
도커 컨테이너의 로그 파일은 일반적으로 `/var/lib/docker/containers/<컨테이너ID>/` 디렉토리 내부에 `<컨테이너ID>-json.log`라는 이름으로 존재합니다. 하지만 컨테이너 ID는 복잡한 해시값이므로 눈으로 찾기는 어렵습니다. 이럴 때 리눅스의 `find` 명령어나 `du` 명령어를 조합하여 용량이 큰 순서대로 파일을 나열해 보는 것이 좋습니다. 예를 들어 `/var/lib/docker/containers` 경로에서 1GB 이상인 파일만 찾도록 명령을 내리면 범인이 되는 로그 파일을 즉시 특정할 수 있습니다.
서비스 중단 없이 로그 비우기 (긴급 조치)
이제 가장 중요한 해결 방법입니다. 컨테이너를 멈추지 않고(Stop), 재시작하지 않고(Restart), 삭제하지 않고(Rm), 오직 로그 파일의 내용만 비워서 디스크 공간을 즉시 확보하는 기술입니다. 여기서 많은 분들이 실수하는 부분이 바로 `rm` 명령어로 파일을 삭제해버리는 것입니다.
절대 rm 명령어를 사용하면 안 되는 이유
주의: 실행 중인 프로세스가 잡고 있는 파일을 `rm` 명령어로 삭제하면, 파일 이름은 지워지지만 파일 디스크립터(File Descriptor)는 프로세스에 의해 여전히 열려 있습니다. 이 경우 디스크 공간은 반환되지 않으며, 오히려 '삭제된 파일(deleted)' 상태로 계속해서 용량만 차지하는 좀비 파일이 됩니다. 이를 해결하려면 결국 프로세스(컨테이너)를 재시작해야 하므로, 무중단 목표 달성에 실패하게 됩니다.
따라서 파일을 '삭제'하는 것이 아니라, 파일의 내용을 '0'으로 만들어야 합니다. 이것을 Truncate(잘라내기)라고 합니다. 파일 자체는 그대로 두고 내용만 비우기 때문에 도
댓글
댓글 쓰기