원인 불명의 NAS 스토리지 용량 고갈 현상
홈 서버 용도로 시놀로지(Synology) NAS를 운영하다 보면 어느 순간 시스템으로부터 ‘볼륨 용량이 부족합니다’라는 치명적인 경고 알림을 받게 됩니다. 당황한 마음에 File Station을 열어 동영상이나 대용량 백업 파일들을 지워보지만, 확보되는 용량은 미미하며 몇 주 뒤면 다시 스토리지가 100% 꽉 차버리는 악순환에 빠지곤 합니다.
NAS 내부에 저장된 파일들을 모두 더해봐도 하드디스크의 전체 용량에 한참 미치지 못한다면, 그 범인은 사용자의 눈에 보이지 않는 시스템 내부 파티션에 숨어 있을 확률이 매우 높습니다. 그리고 도커(Docker, Container Manager)를 통해 여러 개의 서버를 구동하는 환경에서 이 ‘용량 도둑’의 정체는 십중팔구 비정상적으로 비대해진 ‘컨테이너 백그라운드 로그(Log) 파일’입니다.
본 글에서는 도커 환경에서 로그 데이터가 기가바이트(GB) 단위로 무한히 증식하는 원인을 시스템 구조적으로 분석하고, 이를 원천적으로 차단하기 위한 로그 회전(Log Rotation) 및 제한(Limit) 설정 트러블슈팅 방법을 상세히 다룹니다.
도커(Docker) 기본 로깅 드라이버의 함정
개발 환경과 운영 환경 모두에서 도커가 사랑받는 이유는 애플리케이션의 모든 입출력을 컨테이너라는 단위로 완벽하게 격리하기 때문입니다. 하지만 이 완벽한 격리가 때로는 서버 인프라에 치명적인 독으로 작용합니다.
1. 무제한으로 쌓이는 JSON-File 로깅 아키텍처
도커 엔진은 기본적으로 ‘json-file’이라는 로깅 드라이버를 사용합니다. 컨테이너 내부에서 구동되는 파이썬 스크립트가 뱉어내는 print() 결과물이나, 웹 서버(Nginx, Apache)로 들어오는 전 세계의 수많은 접속 기록(Standard Output 및 Standard Error)은 모두 이 드라이버를 통해 컨테이너별 고유한 .json.log 파일로 차곡차곡 기록됩니다.
가장 큰 문제는 도커의 기본 설정에는 이 로그 파일의 ‘최대 크기’나 ‘보존 기간’에 대한 제한이 전혀 없다는 점입니다. 데이터베이스 쿼리에러가 반복적으로 발생하거나 외부 공격자의 무차별 대입 공격(Brute-force) 시도가 지속될 경우, 단 하나의 컨테이너가 하루에 수백 메가바이트의 로그를 생성하며 몇 달 후에는 50GB, 100GB 단위의 거대한 괴물 파일로 변모하게 됩니다.
2. 시스템 파티션의 구조적 은닉과 접근의 한계
이러한 거대 로그 파일은 사용자가 쉽게 접근할 수 있는 ‘/volume1/docker’ 공유 폴더에 존재하지 않습니다. 시놀로지의 내부 시스템 파티션인 ‘/volume1/@docker/containers/[컨테이너 해시 ID]/’ 라는 깊숙하고 은밀한 경로에 숨겨져 생성됩니다. File Station이나 윈도우 네트워크 드라이브로는 아예 접근조차 불가능하므로, 일반적인 NAS 사용자는 스토리지 용량이 어디서 증발했는지 그 원인조차 파악하지 못하고 하드디스크를 추가 구매하는 헛된 지출을 하게 됩니다.
시스템 용량 정상화를 위한 트러블슈팅 및 제한 설정
로그 파일로 인한 스토리지 고갈을 근본적으로 차단하기 위해서는 도커 데몬이나 컨테이너의 생성 규칙을 수정하여 ‘로그 파일의 최대 크기’와 ‘유지할 파일의 개수(Rotation)’를 명시적으로 통제해야 합니다.
1. Docker Compose (프로젝트) 내 개별 제한 설정
시놀로지 Container Manager의 ‘프로젝트’ 기능을 활용하여 docker-compose.yml 파일로 컨테이너를 배포하는 경우, 가장 안전하고 직관적으로 로그를 제한할 수 있습니다. 각 서비스 설정 하단에 ‘logging’ 섹션을 추가하여 통제권을 쥡니다.
예를 들어, ‘options: max-size: “10m”‘과 ‘max-file: “3”‘이라는 구문을 추가하면, 해당 컨테이너의 로그 파일이 10MB에 도달할 때마다 시스템이 자동으로 기존 파일을 압축하여 백업하고 새로운 로그 파일을 생성합니다. 또한 보존되는 파일의 개수를 최대 3개로 제한하므로, 하나의 컨테이너가 차지하는 총 로그 용량은 영구적으로 30MB를 절대 초과하지 않게 됩니다.
2. 전역 데몬(daemon.json) 수정을 통한 일괄 적용 (SSH 접근)
컨테이너가 수십 개에 달하여 일일이 설정하기 번거롭다면, 시놀로지 NAS에 SSH로 접속하여 도커 엔진의 뼈대 설정을 직접 변경하는 전역(Global) 튜닝 기법을 사용할 수 있습니다. 터미널 관리자(root) 권한으로 ‘/var/packages/ContainerManager/etc/dockerd.json’ (또는 구버전의 경우 /var/packages/Docker/etc/dockerd.json) 파일을 텍스트 에디터로 엽니다.
해당 파일의 JSON 구조 안에 ‘”log-driver”: “json-file”‘ 항목 아래에 ‘”log-opts”: {“max-size”: “50m”, “max-file”: “3”}’ 옵션을 삽입하고 저장합니다. 이후 시놀로지 패키지 센터에서 Container Manager를 ‘중지’했다가 다시 ‘실행’하여 도커 데몬을 재시작해 줍니다. 주의할 점은 이 전역 설정은 ‘새롭게 생성되는’ 컨테이너에만 적용되므로, 기존에 이미 돌아가고 있는 컨테이너들은 삭제 후 재생성해야만 새로운 제한 규칙이 올바르게 적용됩니다.
3. 이미 비대해진 기존 로그 파일의 안전한 초기화
당장 시스템 용량이 100%에 도달해 NAS가 먹통이 되기 직전이라면, 기존 로그 파일을 물리적으로 삭제하여 긴급하게 공간을 확보해야 합니다. 이때 SSH 터미널에서 대용량 ‘.json.log’ 파일을 찾아 ‘rm’ 명령어로 무작정 지워버리면, 컨테이너 프로세스는 파일이 사라진 것을 인지하지 못하고 I/O 에러를 일으키며 시스템 전체에 패닉을 유발할 수 있습니다. 파일 자체를 지우는 대신 ‘truncate -s 0 파일명.json.log’ 명령어를 사용하여 컨테이너가 실행 중인 상태에서도 파일의 껍데기는 남겨둔 채 내부 크기만 0 바이트로 강제 초기화하는 것이 훨씬 안전한 시스템 유지보수 방법입니다.
결론 및 안정적인 인프라 운영의 조건
도커 컨테이너를 띄우고 애플리케이션이 정상적으로 동작하는 것을 확인하는 것은 서버 구축의 시작 단계에 불과합니다. 진짜 서버 관리의 역량은 시간이 지남에 따라 필연적으로 누적되는 로그 데이터, 캐시, 메모리 누수와 같은 ‘시스템의 잔여물’들을 얼마나 체계적으로 통제하고 청소하느냐에서 판가름 납니다.
로그(Log)는 시스템의 장애를 추적하기 위한 가장 소중한 자산이지만, 통제되지 않는 로그는 결국 시스템 자체를 파괴하는 가장 무서운 적이 됩니다. 도커 로깅 드라이버의 특성을 이해하고 파일 회전(Rotation) 아키텍처를 도입함으로써, 더 이상 NAS 스토리지 부족 경고창에 시달리지 않는 완벽하고 무중단된 엔터프라이즈급 홈 서버 인프라를 완성하시기 바랍니다.
