디스크 사용률은 80%부터 관리해야 합니다

Linux 서버에서 디스크가 가득 차면 단순히 새 파일을 저장하지 못하는 수준에서 끝나지 않습니다. 애플리케이션 로그 기록, 데이터베이스 임시 파일 생성, 배포 파일 교체, 인증서 갱신, 컨테이너 이미지 내려받기까지 연쇄적으로 실패할 수 있습니다. 특히 운영 서버는 사용률이 100%가 된 뒤 원인을 찾기보다, 80%를 경고 기준으로 정하고 증가 추세를 확인하는 방식이 안전합니다. 먼저 어떤 파일시스템이 얼마나 찼는지 확인합니다.

df -hT; df -i

df -hT는 용량과 파일시스템 유형을, df -i는 inode 사용량을 보여 줍니다. inode는 파일 하나당 하나씩 소비되는 관리 단위입니다. 작은 파일이 수백만 개 쌓이면 용량이 남아 있어도 inode가 먼저 소진될 수 있습니다. df -h 결과만 보고 여유가 있다고 판단하면 이 문제를 놓치기 쉽습니다.

가득 찬 경로와 실제 원인을 분리해서 찾기

사용률이 높은 마운트 지점을 찾았다면 그 경로 안에서 큰 디렉터리부터 좁혀 갑니다. 루트 파일시스템이 찼을 때는 다른 마운트 지점을 넘나들지 않도록 -x 옵션을 사용합니다. 권한 오류 메시지는 필요할 때만 확인하고, 운영 계정 권한으로 무리하게 전체 파일을 변경하지 않습니다.

sudo du -xhd1 / | sort -h; sudo du -xhd1 /var | sort -h; sudo find /var/log -type f -size +500M -printf '%10s %p\n' | sort -n

대부분의 경우 /var/log, /var/lib/docker, 애플리케이션 업로드 경로, 배포 아티팩트 보관 디렉터리에서 원인이 나옵니다. 디렉터리 크기를 확인한 뒤에는 큰 파일의 생성 주체를 파악해야 합니다. 로그 파일이라면 서비스의 로그 레벨, 로그 회전 설정, 예외 반복 발생 여부를 함께 살펴봅니다. 컨테이너 환경이라면 이미지와 중지된 컨테이너, 빌드 캐시가 누적되었는지도 확인합니다.

삭제했는데 용량이 돌아오지 않는 경우

운영 중 가장 혼란스러운 상황은 큰 로그 파일을 삭제했는데 df의 사용량이 줄지 않는 경우입니다. 실행 중인 프로세스가 삭제된 파일을 계속 열고 있으면, 디렉터리 항목만 사라지고 실제 블록은 프로세스가 파일을 닫을 때까지 유지됩니다. 이때 lsof의 deleted 표기를 확인합니다.

sudo lsof +L1; sudo lsof | grep '(deleted)'

삭제된 대용량 파일을 잡고 있는 프로세스가 확인되면 해당 서비스의 정상 재시작 절차를 따릅니다. 무조건 프로세스를 강제 종료하는 것은 요청 처리 중단이나 데이터 유실을 부를 수 있습니다. 로그 파일을 비워야 할 긴급 상황이라면 애플리케이션이 해당 파일을 계속 사용 중인지 확인한 후 truncate를 검토할 수 있지만, 근본 해결은 로그 회전 정책과 오류 원인 수정입니다.

logrotate로 로그 증가를 제어하기

logrotate는 날짜 또는 용량 기준으로 로그를 교체하고, 오래된 압축 로그를 정리합니다. 서비스별 설정은 보통 /etc/logrotate.d 아래에 두며, 애플리케이션의 로그 형식과 재시작 방식에 맞춰 검증해야 합니다. 다음은 매일 회전하되 파일이 100MB를 넘으면 즉시 회전하고, 14개 보관본만 유지하는 예시입니다.

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

postrotate의 신호는 프로그램이 새 로그 파일을 다시 열도록 하는 역할을 합니다. 모든 서비스가 USR1 신호를 지원하는 것은 아니므로 공식 운영 문서나 서비스 설정을 확인해 정확한 방법을 적용해야 합니다. 설정 파일을 바로 운영에 반영하기 전에는 디버그 모드와 강제 실행으로 대상 파일을 검토합니다.

sudo logrotate -d /etc/logrotate.d/myapp; sudo logrotate -f /etc/logrotate.d/myapp

컨테이너와 임시파일도 정기 점검 대상입니다

Docker를 쓰는 서버에서는 이미지, 중지된 컨테이너, 사용하지 않는 볼륨, 빌드 캐시가 디스크를 빠르게 잠식할 수 있습니다. 먼저 docker system df로 종류별 사용량을 확인합니다. 정리 명령은 삭제 범위가 넓으므로, 출력 내용을 검토하고 현재 배포나 롤백에 필요한 이미지가 아닌지 확인한 뒤 실행해야 합니다.

docker system df; sudo find /tmp -xdev -type f -mtime +7 -ls; sudo journalctl --disk-usage

systemd journal도 설정에 따라 예상보다 커질 수 있습니다. journalctl --disk-usage로 현황을 파악한 다음, journald의 SystemMaxUse 또는 RuntimeMaxUse를 서버 용량에 맞게 정하면 로그가 무제한으로 증가하는 일을 줄일 수 있습니다. /tmp 정리 역시 애플리케이션의 실행 중인 소켓이나 업로드 처리 파일을 지우지 않도록 파일 생성 주기와 서비스 특성을 먼저 점검해야 합니다.

운영 체크리스트

  • df -hT와 df -i를 함께 확인해 용량과 inode 부족을 구분합니다.
  • 80% 경고, 90% 긴급 대응처럼 기준을 정하고 사용률 변화도 기록합니다.
  • du로 큰 경로를 찾은 뒤 로그, 이미지, 업로드, 임시파일 중 원인을 분류합니다.
  • 삭제 후에도 사용량이 남으면 lsof +L1로 열린 삭제 파일을 확인합니다.
  • logrotate와 journald 보관 한도를 설정하고, 운영 반영 전 회전 동작을 검증합니다.
  • 정리 작업은 대상과 복구 필요성을 확인한 뒤 서비스 영향이 작은 시간에 수행합니다.