디스크 용량 관리는 장애 예방 작업입니다

Linux 서버에서 디스크가 가득 차면 애플리케이션 오류보다 더 넓은 장애가 생깁니다. 로그를 쓰지 못해 원인 분석이 어려워지고, 데이터베이스가 임시 파일을 만들지 못하고, 배포 스크립트가 새 파일을 풀지 못합니다. 작은 클라우드 서버나 사내 업무 시스템 서버는 디스크 여유 공간을 크게 잡지 않는 경우가 많아 로그 증가만으로도 며칠 사이 문제가 발생할 수 있습니다.

실무에서는 사용량을 가끔 확인하는 것보다, 커지는 파일의 종류별로 관리 정책을 두는 편이 중요합니다. 애플리케이션 로그는 logrotate로 회전하고, systemd journal은 보관 용량을 제한하며, 오래된 임시 파일과 업로드 잔여 파일은 주기적으로 삭제해야 합니다. 여기에 간단한 알림 기준을 붙이면 갑작스러운 용량 부족을 대부분 예방할 수 있습니다.

먼저 어디에서 용량이 늘어나는지 확인합니다

자동 정리부터 적용하면 필요한 파일을 지우거나, 실제 원인을 놓칠 수 있습니다. 먼저 루트 파티션과 주요 디렉터리의 사용량을 확인합니다. 운영 서버에서는 전체 용량만 보지 말고 어떤 마운트가 꽉 찼는지, 어떤 디렉터리가 빠르게 커지는지, 삭제해도 되는 파일인지까지 같이 봐야 합니다.

df -hT
sudo du -xhd1 /var | sort -h
sudo du -xhd1 /var/log | sort -h
sudo journalctl --disk-usage
find /tmp -xdev -type f -mtime +7 -print | head

df -hT는 파일 시스템 종류와 사용률을 보여 줍니다. du -xhd1의 -x 옵션은 다른 파일 시스템으로 넘어가지 않게 합니다. Docker 볼륨, 백업 디스크, 네트워크 마운트가 섞인 서버에서는 이 옵션을 써야 원인 범위를 잘못 판단하지 않습니다.

애플리케이션 로그는 logrotate로 관리합니다

서비스가 /var/log/myapp/app.log처럼 파일 로그를 남긴다면 logrotate 설정을 따로 두는 것이 안정적입니다. 로그 파일을 무한히 키우지 말고, 일정 크기 또는 주기로 나누고, 오래된 로그는 압축하고, 보관 개수를 제한합니다.

/var/log/myapp/*.log {
    daily
    rotate 14
    size 100M
    missingok
    notifempty
    compress
    delaycompress
    create 0640 myapp adm
    sharedscripts
    postrotate
        systemctl kill -s USR1 myapp.service >/dev/null 2>&1 || true
    endscript
}

위 설정은 하루 단위로 확인하되 파일이 100MB를 넘으면 회전하고, 최대 14개를 보관합니다. missingok는 로그 파일이 없어도 오류로 처리하지 않고, notifempty는 빈 파일을 회전하지 않습니다. postrotate의 신호 처리는 애플리케이션이 로그 파일 재오픈을 지원할 때만 의미가 있습니다. 지원하지 않는 서비스라면 테스트 서버에서 먼저 확인해야 합니다.

sudo logrotate -d /etc/logrotate.d/myapp
sudo logrotate -f /etc/logrotate.d/myapp
ls -lh /var/log/myapp

-d는 실제 변경 없이 어떤 작업이 일어날지 보여 주는 디버그 모드입니다. 운영 반영 전에는 이 모드로 설정 문법과 대상 파일을 확인합니다. -f는 강제 실행이므로 처음 설정한 뒤 회전 결과와 파일 권한을 검증할 때만 사용합니다.

systemd journal은 상한선을 둡니다

systemd 기반 배포판에서는 많은 서비스 로그가 journal에 쌓입니다. 기본값만으로도 어느 정도 관리되지만, 작은 서버에서는 명시적인 상한선을 두는 것이 좋습니다. 컨테이너 런타임, 프록시, 배치 서비스가 오류를 반복하면 journal 용량이 빠르게 늘어날 수 있습니다.

# /etc/systemd/journald.conf.d/limits.conf
[Journal]
SystemMaxUse=1G
SystemKeepFree=2G
MaxRetentionSec=14day
Compress=yes
sudo mkdir -p /etc/systemd/journald.conf.d
sudo systemctl restart systemd-journald
journalctl --disk-usage
sudo journalctl --vacuum-time=14d
sudo journalctl --vacuum-size=1G

SystemMaxUse는 journal이 사용할 수 있는 최대 용량이고, SystemKeepFree는 파일 시스템에 남겨 둘 최소 여유 공간입니다. --vacuum-time과 --vacuum-size는 이미 쌓인 로그를 정리할 때 사용합니다. 장애 직후라면 필요한 기간의 로그를 먼저 보존한 뒤 정리해야 합니다.

임시 파일은 systemd-tmpfiles로 정리합니다

업로드 처리, 이미지 변환, 리포트 생성, 배치 다운로드처럼 임시 파일을 많이 만드는 서비스는 실패 상황에서 잔여 파일을 남기기 쉽습니다. 애플리케이션 코드에서 삭제를 시도하더라도 프로세스가 중간에 죽으면 파일이 남습니다. 이런 파일은 운영체제 레벨의 보조 정책으로 한 번 더 정리하는 것이 좋습니다.

# /etc/tmpfiles.d/myapp.conf
q /var/tmp/myapp 0750 myapp myapp 7d
q /var/cache/myapp/export 0750 myapp myapp 3d
r! /var/tmp/myapp/*.tmp
sudo systemd-tmpfiles --create /etc/tmpfiles.d/myapp.conf
sudo systemd-tmpfiles --clean /etc/tmpfiles.d/myapp.conf
systemctl status systemd-tmpfiles-clean.timer

보관 기간은 업무 요구사항에 맞춰 정해야 합니다. 사용자가 생성한 다운로드 파일을 7일 동안 다시 받을 수 있어야 한다면 그보다 짧게 잡으면 안 됩니다. 반대로 변환 중간 산출물처럼 재사용 가치가 없는 파일은 1일 또는 3일만 보관해도 충분합니다.

알림 기준은 단순하게 시작합니다

정리 정책을 넣어도 디스크 사용량 알림은 필요합니다. 가장 단순한 기준은 루트 파티션 사용률 80퍼센트 경고, 90퍼센트 긴급입니다. 데이터베이스 서버라면 데이터 파티션과 WAL 또는 binlog 위치를 별도로 봐야 합니다.

#!/usr/bin/env bash
set -euo pipefail
LIMIT=80
usage=$(df -P / | awk 'NR==2 { gsub("%", "", $5); print $5 }')
if [ "$usage" -ge "$LIMIT" ]; then
  echo "disk usage warning: / is ${usage}%"
  du -xhd1 /var | sort -h | tail -10
fi

알림에는 사용률만 넣지 말고 상위 디렉터리 사용량을 함께 남기는 것이 좋습니다. 그래야 접속 후 다시 조사하는 시간을 줄일 수 있습니다. 실제 운영에서는 이 출력을 메일, Slack, Telegram, 모니터링 시스템 중 하나로 보내면 됩니다.

운영 체크리스트

  • 루트, 데이터, 로그, 백업 파티션의 사용률을 분리해서 확인합니다.
  • 파일 로그는 회전 주기, 크기, 보관 개수, 압축 여부를 명시합니다.
  • systemd journal은 용량 상한과 최소 여유 공간을 설정합니다.
  • 업로드 잔여 파일과 오래된 export 파일은 systemd-tmpfiles로 정리합니다.
  • 정리 명령은 운영 반영 전에 디버그 모드와 테스트 경로로 검증합니다.

디스크 용량 관리는 복잡한 도구보다 명확한 정책이 먼저입니다. 어떤 파일을 얼마나 보관할지, 어떤 위치가 빠르게 커질 수 있는지, 어느 시점에 사람이 확인해야 하는지를 정해 두면 작은 서버에서도 예측 가능한 운영이 가능합니다.