로그 로테이트(Logrotate) 설정으로 서버 하드 용량 부족 방지하기

서버 하드 용량 부족 이젠 안녕 Logrotate로 똑똑하게 로그 관리하기

서버를 운영하다 보면 예상치 못한 문제에 직면하곤 합니다. 그중 하나가 바로 ‘하드 용량 부족’입니다. 특히 로그 파일은 시간이 지남에 따라 엄청난 크기로 불어나 서버의 저장 공간을 잠식하고, 결국 서비스 장애로 이어질 수 있습니다. 마치 방치된 쓰레기가 집 안을 가득 채워 생활이 불가능해지는 것과 같습니다. 하지만 걱정 마세요. 리눅스 시스템에는 이러한 문제를 해결해 줄 강력한 도구, 바로 ‘로그 로테이트 Logrotate’가 있습니다.

이 가이드는 로그 로테이트가 무엇인지, 왜 중요한지, 그리고 어떻게 설정하여 서버를 쾌적하게 유지할 수 있는지에 대한 모든 것을 알려드릴 것입니다. 더 이상 하드 용량 부족 알림에 당황하지 마세요. 지금부터 로그 로테이트의 세계로 함께 떠나봅시다.

로그 로테이트 Logrotate 왜 필요한가요

로그 파일은 서버에서 발생하는 모든 활동을 기록하는 중요한 문서입니다. 웹 서버의 접속 기록부터 데이터베이스의 쿼리, 시스템 오류 메시지까지, 모든 것이 로그로 남습니다. 이 로그들은 문제 발생 시 원인을 파악하고 시스템 성능을 분석하는 데 필수적인 자료입니다.

하지만 시간이 흐를수록 로그 파일의 크기는 기하급수적으로 커집니다. 수십 기가바이트를 넘어 테라바이트에 달하는 로그 파일도 흔합니다. 이렇게 거대해진 로그 파일은 다음과 같은 심각한 문제를 야기합니다.

하드 용량 부족 서버의 디스크 공간을 빠르게 소모하여 새로운 데이터를 저장할 수 없게 만듭니다. 이는 서비스 장애로 직결될 수 있습니다.

성능 저하 로그 파일이 너무 크면 파일을 읽거나 쓰는 데 더 많은 시간이 소요되어 서버 전체의 I/O 성능이 저하될 수 있습니다.
문제 분석의 어려움 너무 많은 로그 중에서 필요한 정보를 찾아내는 것이 사실상 불가능해집니다.
백업 및 복구의 어려움 거대한 로그 파일을 백업하거나 복구하는 데 엄청난 시간과 자원이 소모됩니다.

로그 로테이트는 이러한 문제를 해결하기 위해 오래된 로그 파일을 주기적으로 잘라내고(rotate), 압축하며(compress), 일정 기간이 지나면 삭제하는(remove) 자동화된 시스템입니다. 이를 통해 서버의 디스크 공간을 효율적으로 관리하고, 필요한 로그만 적절한 기간 동안 보관할 수 있게 됩니다.

Logrotate의 기본 원리 이해하기

로그 로테이트는 시스템의 크론(cron) 작업과 연동되어 정해진 주기에 따라 작동합니다. 일반적으로 매일 또는 매주 한 번씩 실행되도록 설정되어 있습니다. Logrotate가 실행되면 설정 파일을 참조하여 각 로그 파일에 대한 처리 규칙을 적용합니다.

핵심적인 작동 방식은 다음과 같습니다.

로그 파일 이름 변경 현재 사용 중인 로그 파일(예: `access.log`)의 이름을 변경하여 새로운 로그 파일을 생성할 준비를 합니다(예: `access.log.1`).

새 로그 파일 생성 원래 이름으로 비어 있는 새 로그 파일(예: `access.log`)을 생성합니다. 이제 애플리케이션은 이 새 파일에 로그를 기록합니다.
이전 로그 파일 관리 이름이 변경된 이전 로그 파일들(`access.log.1`, `access.log.2` 등)을 설정에 따라 압축하거나 삭제합니다.

이 과정이 주기적으로 반복되면서 로그 파일의 크기는 항상 일정 수준으로 유지되고, 서버의 디스크 공간은 안정적으로 관리됩니다.

Logrotate 설정 파일 파헤치기

Logrotate의 모든 동작은 설정 파일에 의해 결정됩니다. 주요 설정 파일은 두 가지 위치에 있습니다.

/etc/logrotate.conf Logrotate의 전역 설정을 담고 있는 메인 파일입니다. 모든 로그 파일에 기본적으로 적용될 규칙을 정의하거나, 다른 설정 파일을 포함(include)하는 역할을 합니다.
/etc/logrotate.d/ 이 디렉토리 안에는 개별 애플리케이션(예: Nginx, Apache, MySQL)에 대한 로그 로테이트 설정 파일들이 위치합니다. 각 애플리케이션의 특성에 맞춰 세부적인 규칙을 정의할 수 있습니다.

주요 지시어 설명

Logrotate 설정 파일은 다양한 지시어(directive)를 사용하여 로그 파일 관리 방식을 정의합니다. 몇 가지 핵심적인 지시어를 살펴보겠습니다.

지시어	설명	예시
`rotate [횟수]`	로그 파일을 몇 주기 동안 보관할지 지정합니다. 이 횟수를 초과하는 오래된 파일은 삭제됩니다.	`rotate 4` (4주기 보관)
`daily \| weekly \| monthly \| yearly`	로그 로테이트 주기를 설정합니다. 매일, 매주, 매월, 매년 중 하나를 선택합니다.	`daily`
`size [크기]`	로그 파일의 크기가 지정된 크기를 초과할 때 로테이트를 수행합니다. 주기 설정과 함께 사용될 경우, 주기 도래 전이라도 크기가 초과되면 로테이트됩니다. (예: 100M, 100k)	`size 100M`
`compress`	로테이트된 로그 파일을 gzip으로 압축합니다. 디스크 공간 절약에 매우 효과적입니다.	`compress`
`delaycompress`	새로 로테이트된 파일은 압축하지 않고, 그 다음 주기부터 압축을 시작합니다. 현재 로테이트된 파일이 바로 압축되면 디버깅 시 불편할 수 있으므로, 하루 정도의 여유를 두는 데 유용합니다.	`delaycompress`
`notifempty`	로그 파일이 비어 있으면 로테이트를 수행하지 않습니다.	`notifempty`
`create [권한] [사용자] [그룹]`	로테이트 후 새로운 로그 파일을 생성할 때의 권한, 소유자, 그룹을 지정합니다. 지정하지 않으면 원본 파일의 설정을 따릅니다.	`create 0640 root adm`
`olddir [경로]`	로테이트된 로그 파일들을 지정된 디렉토리로 이동시킵니다. 원본 디렉토리와 분리하여 관리할 때 유용합니다.	`olddir /var/log/archive/nginx`
`missingok`	로그 파일이 존재하지 않아도 오류를 발생시키지 않고 다음 파일로 넘어갑니다.	`missingok`
`sharedscripts`	스크립트(`prerotate`, `postrotate` 등)가 여러 로그 파일에 적용될 때, 모든 로그 파일이 처리된 후 한 번만 실행되도록 합니다. 이 지시어가 없으면 각 파일마다 스크립트가 실행됩니다.	`sharedscripts`
`postrotate / endscript`	로그 파일 로테이트가 완료된 후 실행될 스크립트를 정의합니다. 주로 웹 서버나 애플리케이션 서비스를 재시작하거나 로그 파일을 다시 열도록 신호를 보내는 데 사용됩니다.	`postrotate systemctl reload nginx.service endscript`

예시 설정 파일

예를 들어, Nginx 웹 서버의 로그를 관리하는 `/etc/logrotate.d/nginx` 파일은 다음과 같이 설정될 수 있습니다.

/var/log/nginx/.log {

    daily

    missingok

    rotate 14

    compress

    delaycompress

    notifempty

    create 0640 www-data adm

    sharedscripts

    postrotate

        if [ -f /var/run/nginx.pid ]; then

            kill -USR1 `cat /var/run/nginx.pid

        fi

    endscript

}

이 설정은 `/var/log/nginx/` 디렉토리의 모든 `.log` 파일을 대상으로 합니다.

매일(daily) 로테이트하고,

파일이 없어도 오류를 발생시키지 않으며(missingok),

14주기(즉, 14일) 동안 보관합니다(rotate 14).

이전 로그는 압축하고(compress),

바로 직전 로테이트된 파일은 다음 주기까지 압축을 미룹니다(delaycompress).

로그 파일이 비어 있으면 로테이트하지 않으며(notifempty),

새 로그 파일은 0640 권한으로 www-data 사용자, adm 그룹으로 생성합니다(create 0640 www-data adm).

모든 Nginx 로그 파일이 로테이트된 후 한 번만 스크립트를 실행하여(sharedscripts) Nginx 프로세스에 로그 파일을 다시 열도록 신호를 보냅니다(postrotate).

실생활에서 Logrotate 활용하기

Logrotate는 거의 모든 종류의 서버 로그 관리에 적용될 수 있습니다.

웹 서버 로그 관리 (Apache, Nginx)

가장 일반적인 활용 사례입니다. access.log, error.log 등 웹 서버의 접속 및 오류 로그는 트래픽이 많을수록 빠르게 증가합니다. /etc/logrotate.d/apache2 또는 /etc/logrotate.d/nginx 파일을 통해 적절한 보관 주기와 압축 설정을 적용해야 합니다. postrotate 스크립트를 이용하여 웹 서버 프로세스가 새 로그 파일을 인식하도록 재시작하거나 신호를 보내는 것이 중요합니다.

데이터베이스 로그 관리 (MySQL, PostgreSQL)

데이터베이스의 쿼리 로그, 에러 로그, 바이너리 로그 등도 용량 관리의 핵심 대상입니다. 특히 개발 환경에서 디버깅 목적으로 상세한 로그를 활성화했을 경우, 로그 파일이 순식간에 수백 기가바이트로 불어날 수 있습니다. 데이터베이스의 특성상 로그 로테이트 시 서비스에 영향을 줄 수 있으므로, postrotate 스크립트에서 데이터베이스 서비스 재시작 대신 로그 파일 핸들을 닫고 다시 여는 명령어를 사용하는 것이 더 안전합니다.

시스템 로그 관리 (syslog, auth.log)

운영체제 자체에서 생성하는 로그 파일(/var/log/syslog, /var/log/auth.log, /var/log/kern.log 등)은 /etc/logrotate.conf 파일이나 /etc/logrotate.d/rsyslog 같은 파일을 통해 관리됩니다. 이 로그들은 시스템의 전반적인 상태와 보안 관련 정보를 담고 있으므로, 너무 짧은 주기로 삭제하기보다는 적절한 보관 기간을 유지하는 것이 좋습니다.

애플리케이션별 로그 관리 (사용자 정의 로그)

사용자가 직접 개발한 애플리케이션이나 특정 서비스가 생성하는 로그 파일도 Logrotate로 관리할 수 있습니다. 예를 들어, /var/log/my-app/app.log와 같은 경로에 로그를 남긴다면, /etc/logrotate.d/my-app 파일을 생성하여 해당 로그 파일에 대한 로테이트 규칙을 정의하면 됩니다. 이 경우 애플리케이션이 새 로그 파일을 인식하도록 postrotate 스크립트를 작성하는 것이 중요합니다.

Logrotate 설정 시 유용한 팁과 조언

Logrotate를 효과적으로 사용하기 위한 몇 가지 팁과 조언을 드립니다.

로그 보관 주기 결정하기

법적 요구사항: 일부 산업이나 국가에서는 특정 로그를 일정 기간 동안 의무적으로 보관하도록 규정하고 있습니다. 이를 반드시 준수해야 합니다.

디버깅 필요성: 서비스 문제 발생 시 얼마나 과거의 로그까지 필요한지 고려합니다. 일반적으로 며칠에서 몇 주 정도가 적당하지만, 중요한 시스템은 더 길게 보관할 수도 있습니다.

디스크 용량: 서버의 가용 디스크 공간을 고려하여 보관 주기를 설정합니다. compress 지시어를 활용하면 보관 기간을 늘리면서도 용량을 절약할 수 있습니다.

압축의 중요성

compress 지시어는 디스크 공간을 절약하는 데 매우 효과적입니다. 로그 파일은 텍스트 기반이므로 압축률이 매우 높습니다.

delaycompress를 사용하면 로테이트된 직후의 로그 파일은 압축하지 않아, 만약 문제가 발생했을 때 즉시 내용을 확인할 수 있는 유연성을 제공합니다.

오류 발생 시 대처 방법

Logrotate가 제대로 작동하지 않는다면, 먼저 /var/lib/logrotate/status 파일을 확인하세요. 이 파일에는 각 로그 파일의 마지막 로테이트 시점과 상태가 기록되어 있습니다.

시스템 로그(/var/log/syslog 또는 /var/log/messages)에서 Logrotate 관련 오류 메시지를 찾아볼 수 있습니다.

수동으로 Logrotate를 실행하면서 디버그 모드를 활성화하면 문제를 파악하는 데 도움이 됩니다. (sudo logrotate -d /etc/logrotate.conf)

테스트 방법

새로운 Logrotate 설정을 적용하기 전에 항상 ‘dry run’ 모드로 테스트하는 것이 좋습니다. sudo logrotate -d /etc/logrotate.conf 명령어를 사용하면 실제로 파일이 변경되지는 않지만, Logrotate가 어떻게 작동할지 시뮬레이션 결과를 보여줍니다.

특정 설정 파일만 테스트하려면 sudo logrotate -d /etc/logrotate.d/your_app와 같이 경로를 지정할 수 있습니다.

SELinux/AppArmor 등 보안 컨텍스트 고려

SELinux나 AppArmor와 같은 보안 강화 시스템이 활성화되어 있다면, Logrotate가 새 로그 파일을 생성하거나 기존 파일을 이동할 때 권한 문제가 발생할 수 있습니다.

create 지시어로 적절한 권한을 부여하거나, SELinux 컨텍스트를 수동으로 지정해주는 작업이 필요할 수 있습니다. (예: chcon -t var_log_t /var/log/my-app/.log)

흔한 오해와 사실 관계

Logrotate에 대해 사람들이 흔히 가지는 오해와 그에 대한 사실 관계를 명확히 해드리겠습니다.

오해 1 Logrotate만 하면 서버 용량 문제는 완전히 해결된다

사실 Logrotate는 로그 파일로 인한 용량 문제를 해결하는 데 매우 효과적이지만, 서버의 모든 용량 문제를 해결해 주지는 않습니다. 데이터베이스 파일, 업로드된 사용자 파일, 캐시 파일, 임시 파일 등 로그 파일 외에도 서버 용량을 차지하는 요소는 많습니다. Logrotate는 ‘로그’에 특화된 도구이며, 전체적인 서버 용량 관리를 위해서는 다른 파일 시스템 분석 도구(du, ncdu 등)와 함께 사용해야 합니다.

오해 2 로그는 무조건 오래 보관해야 좋다

사실 로그를 오래 보관하는 것이 항상 좋은 것만은 아닙니다. 물론 중요한 로그는 충분한 기간 동안 보관해야 하지만, 불필요하게 오래된 로그는 디스크 공간만 차지하며, 오히려 필요한 정보를 찾는 데 방해가 될 수 있습니다. 보관 주기는 앞서 언급했듯이 법적 요구사항, 디버깅 필요성, 그리고 서버의 디스크 용량을 종합적으로 고려하여 균형 있게 설정해야 합니다. 너무 오래된 로그는 분석 가치가 떨어지는 경우가 많습니다.

오해 3 압축하면 성능이 느려지지 않나요

사실 로그 파일을 압축하는 과정에서 CPU 자원이 사용되는 것은 맞습니다. 하지만 Logrotate는 일반적으로 서버의 활동이 적은 새벽 시간대에 실행되도록 설정됩니다. 이 시간대의 CPU 부하는 대부분 서비스에 큰 영향을 주지 않습니다. 또한, 압축으로 인해 절약되는 디스크 I/O 비용과 스토리지 비용을 고려하면, 압축은 전반적인 시스템 효율성을 높이는 데 기여합니다. delaycompress 지시어를 사용하면 최신 로그 파일을 즉시 압축하지 않아, 최근 로그에 대한 접근 속도 저하 우려를 줄일 수 있습니다.

전문가의 조언

Logrotate를 넘어서는 고급 로그 관리 전략에 대한 전문가적인 조언을 드립니다.

로그 중앙화 솔루션과의 연동 고려단일 서버라면 Logrotate로 충분하지만, 여러 대의 서버를 운영하는 환경에서는 로그를 한곳으로 모아 관리하는 ‘로그 중앙화’ 솔루션(예: ELK Stack(Elasticsearch, Logstash, Kibana), Grafana Loki, Splunk 등)을 고려해야 합니다. Logrotate는 개별 서버의 디스크 공간을 관리하지만, 중앙화 솔루션은 분산된 로그를 한눈에 모니터링하고 분석할 수 있게 해줍니다. 이 경우 Logrotate는 중앙화 솔루션으로 로그를 전송한 후, 로컬 디스크에서 로그를 삭제하는 역할을 수행하게 됩니다.
모니터링 시스템과의 통합Logrotate의 실행 상태와 로그 파일의 크기 변화를 모니터링 시스템(예: Prometheus, Zabbix, Nagios)과 통합하는 것이 좋습니다. Logrotate가 실패하거나, 예상보다 로그 파일이 빠르게 증가하는 경우 알림을 받아 즉시 대처할 수 있도록 설정하세요. /var/lib/logrotate/status 파일의 변경 사항을 감시하거나, 특정 로그 파일의 크기를 주기적으로 확인하는 스크립트를 작성하여 모니터링할 수 있습니다.
자동화된 배포 시스템 활용
Ansible, Chef, Puppet과 같은 자동화 도구를 사용하여 Logrotate 설정을 배포하고 관리하세요. 수동으로 각 서버의 설정을 변경하는 것은 휴먼 에러를 유발하고 비효율적입니다. 자동화된 시스템은 일관된 설정을 보장하고, 새로운 서버를 추가할 때도 빠르고 정확하게 Logrotate를 구성할 수 있도록 돕습니다.

자주 묻는 질문과 답변

Q1 Logrotate가 제대로 작동하는지 어떻게 확인하나요

A1 가장 먼저 sudo logrotate -d /etc/logrotate.conf 명령어를 사용하여 Dry Run 모드로 실행 결과를 확인합니다. 이 명령은 실제 로테이트는 수행하지 않고, 어떤 파일이 어떻게 로테이트될지 보여줍니다. 또한, /var/lib/logrotate/status 파일을 확인하여 각 로그 파일의 마지막 로테이트 시점을 볼 수 있습니다. 마지막으로, 시스템 로그(/var/log/syslog 또는 /var/log/messages)에서 Logrotate 관련 메시지를 검색하여 오류 여부를 확인하세요.

Q2 특정 로그 파일만 로테이트하고 싶어요. 어떻게 해야 하나요

A2 /etc/logrotate.d/ 디렉토리에 새로운 설정 파일을 생성하여 해당 로그 파일에 대한 규칙을 정의하면 됩니다. 예를 들어, /var/log/my_application/app.log 파일을 로테이트하고 싶다면, /etc/logrotate.d/my_application 파일을 만들고 그 안에 해당 로그 파일 경로와 원하는 지시어들을 작성하세요. /etc/logrotate.conf 파일의 include /etc/logrotate.d 지시어 덕분에 자동으로 로드됩니다.

Q3 Logrotate가 실패했어요. 어디서 문제를 찾아야 할까요

권한 문제: Logrotate가 로그 파일을 읽거나 쓰거나 이동할 권한이 없는 경우가 많습니다. 로그 파일의 권한과 소유자를 확인하고, create 지시어의 권한 설정이 올바른지 확인하세요.
파일 경로 오류: 설정 파일에 지정된 로그 파일 경로가 정확한지 다시 확인하세요.
스크립트 오류: postrotate 등의 스크립트 내부에 오류가 없는지 확인합니다. 스크립트가 비정상 종료되면 Logrotate 전체가 실패할 수 있습니다.
SELinux/AppArmor: 보안 컨텍스트 문제일 수 있습니다. SELinux 로그(/var/log/audit/audit.log)를 확인하여 관련 거부 메시지가 있는지 찾아보세요.

이러한 문제를 진단하기 위해 sudo logrotate -f -v /etc/logrotate.conf 명령어를 사용하여 강제로 상세 모드로 실행해보는 것이 좋습니다. -f는 강제 실행, -v는 상세 출력을 의미합니다.

Q4 너무 많은 로그 파일을 한 번에 로테이트하면 서버에 무리가 가지 않을까요

A4 Logrotate는 일반적으로 리소스 사용량이 낮은 편이지만, 매우 많은 수의 대용량 로그 파일을 동시에 처리하거나, postrotate 스크립트가 무거운 작업을 수행하는 경우 서버에 일시적인 부하를 줄 수 있습니다. 이를 완화하려면 다음과 같은 방법을 고려할 수 있습니다.

Logrotate 실행 주기를 조정하여 한 번에 처리하는 파일 수를 줄입니다.
delaycompress를 사용하여 압축 작업을 분산시킵니다.
postrotate 스크립트의 효율성을 높이거나, 부하가 적은 명령어로 대체합니다.
서버의 트래픽이 가장 적은 시간대로 Logrotate 실행 시간을 조정합니다.

대부분의 경우 Logrotate는 서버에 큰 무리를 주지 않도록 설계되어 있습니다.

Q5 Logrotate로 삭제된 로그는 복구할 수 있나요

A5 Logrotate에 의해 삭제된 로그 파일은 일반적으로 휴지통을 거치지 않고 바로 파일 시스템에서 제거됩니다. 따라서 삭제된 파일을 복구하는 것은 매우 어렵거나 불가능할 수 있습니다. 중요한 로그 파일은 rotate 지시어의 값을 충분히 크게 설정하여 보관 기간을 늘리거나, 로그 중앙화 솔루션이나 백업 시스템을 통해 별도로 보관하는 것이 현명합니다. 삭제는 신중하게 결정해야 합니다.

비용 효율적인 Logrotate 활용 방법

Logrotate는 서버 관리 비용을 절감하는 데에도 기여할 수 있습니다.

클라우드 환경에서의 로그 관리 전략AWS S3, Google Cloud Storage, Azure Blob Storage와 같은 클라우드 스토리지 서비스는 온프레미스 서버의 하드 디스크보다 훨씬 저렴한 비용으로 대량의 데이터를 저장할 수 있습니다. Logrotate를 사용하여 오래된 로그 파일을 압축한 후, 이들을 클라우드 스토리지(특히 AWS Glacier와 같은 아카이브 스토리지)로 자동 전송하도록 설정할 수 있습니다. 이를 통해 로컬 서버의 디스크 공간을 확보하고, 저렴한 비용으로 장기 보관 요구사항을 충족할 수 있습니다.
불필요한 로그는 과감히 삭제
모든 로그가 영원히 보관될 필요는 없습니다. 애플리케이션 개발 단계에서만 필요한 디버그 로그나, 이미 중앙화 솔루션으로 전송되어 로컬에 저장할 필요가 없는 로그 등은 과감하게 삭제 주기를 짧게 설정하거나 아예 로테이트 대상에서 제외하여 디스크 공간 낭비를 막을 수 있습니다. 로그의 중요도와 활용도를 주기적으로 진단하여 보관 정책을 최적화하세요.
적절한 압축률과 보관 주기로 스토리지 비용 최적화
compress 지시어를 적극적으로 사용하여 디스크 공간 사용량을 최소화하세요. 압축된 로그 파일은 일반 텍스트 파일에 비해 훨씬 적은 공간을 차지합니다. 또한, 각 로그 파일의 중요도와 접근 빈도에 따라 rotate 주기를 세분화하여 설정함으로써, 불필요하게 많은 용량을 차지하는 로그 파일을 줄이고 스토리지 비용을 최적화할 수 있습니다.