시놀로지 Docker 로그 파일이 계속 커지는 이유와 저장 공간 부족 해결 방법

시놀로지 NAS에서 Docker 컨테이너를 여러 개 운영하다 보면 어느 순간 저장 공간이 예상보다 빠르게 줄어드는 경우가 있습니다.

처음에는 컨테이너와 이미지가 차지하는 용량이 크지 않았는데 시간이 지나면서 Docker 관련 데이터가 계속 증가하는 것입니다.

특히 NAS에 저장한 사진이나 동영상 파일은 크게 늘지 않았는데 저장 공간 사용량만 계속 증가한다면 Docker 로그 파일을 확인해 볼 필요가 있습니다.

Docker 컨테이너는 실행되는 동안 다양한 상태 정보와 오류 메시지를 로그로 기록합니다. 컨테이너가 장시간 실행되면 이러한 로그가 계속 누적될 수 있습니다.

문제는 로그가 정상적인 상태에서도 발생할 수 있다는 점입니다. 애플리케이션의 접속 기록이나 상태 메시지가 계속 기록되거나, 특정 오류가 반복되면 로그 파일이 예상보다 빠르게 커질 수 있습니다.

따라서 시놀로지 NAS에서 Docker를 장기간 운영한다면 단순히 컨테이너가 정상적으로 실행되고 있는지만 확인할 것이 아니라 로그가 얼마나 쌓이고 있는지도 함께 확인하는 것이 중요합니다.

Docker 로그 파일은 왜 계속 커질까?

Docker 컨테이너에서 실행되는 프로그램은 표준 출력과 오류 출력을 통해 다양한 메시지를 남길 수 있습니다.

예를 들어 웹 서버를 실행하고 있다면 사용자 접속 기록이 계속 발생할 수 있습니다.

또한 프로그램 내부에서 특정 작업을 반복하면서 상태 정보를 기록할 수도 있습니다.

문제가 되는 것은 오류가 반복되는 경우입니다.

예를 들어 데이터베이스 연결에 실패한 프로그램이 계속해서 재접속을 시도한다면 다음과 같은 상황이 반복될 수 있습니다.

데이터베이스 연결 시도

연결 실패

오류 메시지 기록

다시 연결 시도

연결 실패

오류 메시지 기록

이 과정이 계속 반복되면 로그 파일도 계속 증가합니다.

따라서 Docker 로그 용량이 비정상적으로 커졌다면 단순히 로그를 삭제하기보다 왜 로그가 계속 생성되고 있는지 먼저 확인하는 것이 중요합니다.

컨테이너가 정상 실행 중이어도 로그는 커질 수 있다

Container Manager에서 컨테이너 상태가 정상적으로 표시된다고 해서 로그 문제까지 없는 것은 아닙니다.

컨테이너는 정상적으로 실행되고 있으면서도 계속해서 로그를 기록할 수 있습니다.

예를 들어 미디어 서버, 웹 서버, 데이터베이스, 자동화 프로그램 등은 사용자가 특별히 오류를 인식하지 못하는 상황에서도 다양한 로그를 생성합니다.

따라서 저장 공간이 줄어들고 있다면 컨테이너의 실행 상태와 로그 크기를 별도로 확인해야 합니다.

오류가 반복되면 로그 증가 속도가 빨라진다

Docker 로그가 빠르게 증가하는 대표적인 원인은 반복적인 오류입니다.

예를 들어 다음과 같은 오류가 계속 반복될 수 있습니다.

Connection refused

Timeout

Permission denied

Database connection failed

Authentication failed

이러한 메시지가 몇 초 또는 몇 분 간격으로 계속 기록되면 로그 용량도 빠르게 증가할 수 있습니다.

특히 컨테이너가 오류가 발생한 상태에서 자동으로 재시도하도록 구성되어 있다면 사용자가 문제를 발견하기 전에 상당한 양의 로그가 쌓일 수 있습니다.

따라서 로그 용량이 갑자기 증가했다면 최근 로그에 동일한 오류가 반복되고 있는지 확인하는 것이 좋습니다.

Docker 로그 때문에 저장 공간이 부족한지 확인하는 방법

먼저 DSM에서 전체 저장 공간 사용량을 확인합니다.

그 다음 Container Manager에서 현재 실행 중인 컨테이너와 이미지, 볼륨 등을 확인합니다.

여기서 중요한 것은 Docker와 관련된 모든 용량을 하나의 원인으로 생각하지 않는 것입니다.

Docker 저장 공간은 크게 다음과 같이 나누어 생각할 수 있습니다.

컨테이너

이미지

볼륨

로그

빌드 관련 데이터

예를 들어 Docker가 50GB를 사용하고 있다고 해서 그 50GB가 모두 로그 파일이라는 의미는 아닙니다.

특정 이미지가 대용량일 수도 있고 데이터베이스 볼륨이 커졌을 수도 있습니다.

따라서 먼저 실제로 어떤 항목이 저장 공간을 많이 차지하는지 확인해야 합니다.

특정 컨테이너의 로그가 큰지 확인한다

여러 개의 컨테이너를 운영하고 있다면 모든 컨테이너의 로그를 한꺼번에 의심할 필요는 없습니다.

특정 컨테이너 하나가 비정상적으로 많은 로그를 생성하는 경우가 있기 때문입니다.

예를 들어 다음과 같은 상황이라면 해당 컨테이너를 우선 확인하는 것이 좋습니다.

컨테이너 A

로그 용량 300MB

컨테이너 B

로그 용량 500MB

컨테이너 C

로그 용량 20GB

이 경우 저장 공간 문제의 원인은 컨테이너 C일 가능성이 높습니다.

해당 컨테이너의 로그를 확인해 보면 특정 오류가 반복되고 있을 수도 있습니다.

로그를 삭제했는데 다시 커지는 이유

Docker 로그를 삭제해서 일시적으로 저장 공간을 확보했는데 며칠 후 다시 용량이 부족해지는 경우가 있습니다.

이것은 로그를 생성하는 원인이 그대로 남아 있기 때문입니다.

예를 들어 데이터베이스 연결 오류가 계속 발생하고 있다면 로그를 삭제해도 프로그램은 다시 오류 메시지를 기록합니다.

결국

로그 삭제

↓

컨테이너 실행

↓

오류 발생

↓

로그 생성

↓

저장 공간 감소

라는 과정이 반복됩니다.

따라서 로그 삭제는 임시적인 공간 확보 방법일 뿐이고, 로그가 계속 증가하는 원인을 해결해야 장기적으로 문제가 재발하지 않습니다.

로그 로테이션을 설정하는 것이 중요하다

Docker를 장기간 운영한다면 로그 로테이션을 고려하는 것이 좋습니다.

로그 로테이션은 로그가 무한정 증가하지 않도록 파일의 크기나 보관 개수를 제한하는 방식입니다.

예를 들어 Docker Compose에서는 다음과 같은 형태로 설정할 수 있습니다.

services:
  app:
    image: example/app
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

여기서 max-size는 하나의 로그 파일이 커질 수 있는 최대 크기를 지정하고, max-file은 유지할 로그 파일의 개수를 지정합니다.

이런 방식으로 구성하면 로그가 계속 발생하더라도 설정한 범위 안에서 관리할 수 있습니다.

다만 실제 적용 방법은 사용하는 Docker 이미지와 로그 드라이버, Container Manager 환경에 따라 달라질 수 있으므로 현재 구성에 맞는지 확인해야 합니다.

로그 크기를 너무 작게 설정하면 안 되는 이유

저장 공간을 절약하기 위해 로그 크기를 무조건 작게 설정하는 것도 좋은 방법은 아닙니다.

로그는 오류가 발생했을 때 원인을 찾는 중요한 자료이기 때문입니다.

예를 들어 로그를 지나치게 짧게 보관하면 장애가 발생했을 때 필요한 기록이 이미 삭제되어 원인을 분석하기 어려울 수 있습니다.

따라서 로그 관리는 저장 공간 절약과 장애 분석에 필요한 로그 보존 사이에서 적절한 균형을 잡는 것이 중요합니다.

Docker 이미지 때문에 저장 공간이 부족할 수도 있다

Docker 저장 공간이 커졌다고 해서 무조건 로그가 원인이라고 볼 수는 없습니다.

컨테이너를 업데이트하면서 새로운 이미지가 계속 다운로드되면 이전 이미지가 남아 있을 수 있습니다.

사용하지 않는 이미지가 여러 개 쌓이면 저장 공간을 상당히 차지할 수 있습니다.

따라서 로그가 원인인지 확인한 후에도 용량이 계속 부족하다면 Docker 이미지도 함께 확인해야 합니다.

다만 현재 실행 중인 컨테이너에서 사용하는 이미지를 확인하지 않고 무작정 삭제해서는 안 됩니다.

Docker 볼륨도 함께 확인해야 한다

Docker에서 데이터베이스나 미디어 서버 등을 운영한다면 로그보다 볼륨 데이터가 훨씬 많은 공간을 차지할 수도 있습니다.

예를 들어 데이터베이스를 컨테이너로 운영하면서 데이터가 계속 쌓이면 Docker 볼륨의 용량도 증가합니다.

Jellyfin과 같은 미디어 관련 서비스를 사용하는 경우에도 데이터베이스, 메타데이터, 캐시 등이 증가할 수 있습니다.

따라서 저장 공간이 부족할 때는

로그

이미지

볼륨

컨테이너

를 각각 구분해서 확인하는 것이 좋습니다.

Docker 로그를 직접 삭제할 때 주의해야 한다

인터넷을 검색하면 Docker 로그 파일을 직접 찾아 삭제하는 방법을 쉽게 찾을 수 있습니다.

하지만 시놀로지 NAS에서 Docker의 내부 파일을 직접 삭제하는 방법은 주의해야 합니다.

Docker가 사용하고 있는 파일을 잘못 삭제하면 컨테이너 관리에 문제가 발생하거나 예상하지 못한 오류가 생길 수 있기 때문입니다.

특히 저장 공간을 확보하기 위해 시스템 영역의 파일을 무작정 삭제하는 방식은 권장하지 않습니다.

가능하면 Container Manager와 Docker에서 제공하는 관리 방법을 우선 사용하고, 직접 파일을 삭제해야 하는 경우에는 해당 파일의 역할과 영향을 확인한 후 진행하는 것이 좋습니다.

로그가 계속 발생하는 원인을 먼저 해결해야 한다

로그 관리에서 가장 중요한 부분입니다.

로그가 너무 커졌다는 이유로 로그만 삭제하면 같은 문제가 반복될 가능성이 높습니다.

예를 들어 로그에 다음과 같은 메시지가 계속 나타난다고 가정해 보겠습니다.

database connection failed
database connection failed
database connection failed

이 경우 로그 파일을 삭제하는 것보다 데이터베이스 연결 설정을 확인하는 것이 먼저입니다.

또 다른 예로 다음과 같은 메시지가 반복될 수도 있습니다.

permission denied
permission denied
permission denied

이 경우에는 컨테이너의 볼륨 권한이나 실행 사용자 설정 등을 확인해야 할 수 있습니다.

즉, 로그는 저장 공간을 차지하는 데이터인 동시에 시스템의 문제를 알려주는 진단 정보이기도 합니다.

로그와 Docker 볼륨을 혼동하지 않아야 한다

저장 공간 부족 문제를 해결하다 보면 로그와 볼륨을 혼동하는 경우가 있습니다.

하지만 두 가지는 완전히 다른 데이터입니다.

로그는 컨테이너에서 발생하는 상태와 오류 등의 기록이고, 볼륨은 애플리케이션에서 실제로 사용하는 데이터를 저장하는 공간입니다.

예를 들어 데이터베이스 컨테이너의 경우 데이터베이스 자체가 수십 GB를 사용할 수 있습니다.

이때 로그를 아무리 삭제해도 전체 저장 공간이 크게 줄어들지 않을 수 있습니다.

따라서 실제 용량을 확인한 후 어떤 데이터가 공간을 차지하고 있는지 구분해야 합니다.

NAS 저장 공간이 가득 차면 Docker 외의 서비스에도 영향을 준다

Docker 로그가 계속 증가해서 NAS의 저장 공간이 거의 가득 차면 Docker만 문제가 생기는 것은 아닙니다.

NAS 전체 저장 공간이 부족해지면서 다른 서비스에도 영향을 줄 수 있습니다.

새로운 파일을 저장하지 못하거나 데이터베이스가 정상적으로 동작하지 않을 수도 있고, 컨테이너 업데이트나 재시작 과정에서 문제가 발생할 수도 있습니다.

따라서 저장 공간이 거의 가득 찬 상태까지 기다렸다가 정리하기보다는 여유 공간이 충분할 때 Docker 사용량을 관리하는 것이 좋습니다.

Docker 로그 저장 공간을 관리하는 방법

장기적으로 Docker 로그 문제를 예방하려면 다음과 같은 관리 방법을 고려할 수 있습니다.

첫째, 정기적으로 Docker 사용량을 확인합니다.

특정 컨테이너의 용량이 갑자기 증가하지 않았는지 확인합니다.

둘째, 반복적인 오류를 확인합니다.

로그가 빠르게 증가한다면 최근 로그에서 동일한 오류가 반복되는지 확인합니다.

셋째, 로그 로테이션을 적용합니다.

로그가 무한정 증가하지 않도록 크기와 보관 개수를 적절하게 제한합니다.

넷째, 사용하지 않는 Docker 이미지와 컨테이너를 정리합니다.

오래된 이미지가 계속 남아 있지 않은지 확인합니다.

다섯째, Docker 볼륨의 용량도 확인합니다.

로그가 아닌 데이터가 저장 공간을 차지하고 있을 가능성도 함께 확인합니다.

Docker에서 발생한 데이터가 저장 공간의 ‘기타’ 용량 증가로 나타나는 경우도 있기 때문에 저장 공간 분석을 함께 진행하는 것이 좋습니다.

시놀로지 Docker 저장 공간 부족 확인 순서

저장 공간이 갑자기 부족해졌다면 다음 순서로 확인하면 원인을 찾기 쉽습니다.

1. DSM에서 전체 저장 공간을 확인합니다.

NAS 전체 저장 공간이 얼마나 남았는지 확인합니다.

2. Container Manager에서 Docker 사용량을 확인합니다.

컨테이너와 이미지, 볼륨 등의 용량을 확인합니다.

3. 용량이 큰 컨테이너를 찾습니다.

특정 컨테이너에 용량이 집중되어 있는지 확인합니다.

4. 해당 컨테이너의 로그를 확인합니다.

동일한 오류가 반복되고 있는지 살펴봅니다.

5. Docker 이미지와 볼륨을 확인합니다.

로그가 아니라 다른 데이터가 공간을 차지하고 있는지도 확인합니다.

6. 반복되는 오류의 원인을 해결합니다.

로그가 계속 생성되는 원인을 찾아 수정합니다.

7. 로그 로테이션을 설정합니다.

앞으로 로그가 무한정 증가하지 않도록 관리합니다.

이 순서로 접근하면 단순히 로그를 삭제하는 것보다 근본적인 해결에 가까워질 수 있습니다.

로그를 삭제하기 전에 확인해야 할 것

로그를 정리하기 전에 현재 로그가 문제 해결에 필요한 자료인지 확인하는 것이 좋습니다.

특히 최근에 컨테이너에서 오류가 발생했다면 로그를 삭제하기 전에 내용을 확인해야 합니다.

로그에는 다음과 같은 정보가 포함될 수 있습니다.

오류 발생 시간

서비스 상태

네트워크 연결 상태

데이터베이스 연결 상태

권한 오류

애플리케이션 오류

따라서 로그를 단순한 불필요한 파일로 생각해서는 안 됩니다.

문제가 발생했을 때 원인을 찾을 수 있는 중요한 자료이기도 합니다.

마무리

시놀로지 NAS에서 Docker를 장기간 운영하다 보면 저장 공간이 예상보다 빠르게 줄어드는 경우가 있습니다.

그중 하나가 계속 증가하는 Docker 로그 파일입니다.

특히 특정 컨테이너에서 오류가 반복되고 있다면 로그가 빠르게 증가하면서 NAS의 저장 공간을 상당 부분 차지할 수 있습니다.

하지만 저장 공간 부족 문제를 단순히 로그 삭제만으로 해결해서는 안 됩니다.

먼저 어떤 컨테이너의 로그가 커지고 있는지 확인하고, 왜 로그가 계속 생성되는지 원인을 찾는 과정이 필요합니다.

그다음 반복되는 오류를 해결하고 로그 로테이션을 설정해 앞으로 로그가 무한정 증가하지 않도록 관리하는 것이 좋습니다.

또한 Docker 저장 공간은 로그만 차지하는 것이 아닙니다.

이미지, 컨테이너, 볼륨, 로그 등이 각각 저장 공간을 사용할 수 있기 때문에 실제 사용량을 확인하고 원인을 구분해야 합니다.

특히 Docker 로그 파일을 직접 찾아 삭제하거나 시스템 영역의 파일을 무작정 삭제하는 방식은 주의해야 합니다.

결국 시놀로지 Docker 로그 문제를 해결하는 핵심은 “로그를 어떻게 삭제할 것인가”보다 “왜 로그가 계속 쌓이는가”를 먼저 확인하는 것입니다.

로그가 증가하는 원인을 해결하고 적절한 로그 관리 정책까지 적용해야 NAS의 저장 공간 부족 문제를 장기적으로 예방할 수 있습니다.