문제상황
Spring 애플리케이션 로그를 EC2 인스턴스 root 볼륨(8GB)에 저장하는 구조로 운영 중이었다.
어느 순간 서비스 장애 원인을 파악하기 위해 로그를 확인하려 했는데, root 디스크가 꽉 차 있는 상태였다.
결과적으로, 로그 파일을 기록할 수 없고, docker logs 조차 정상 동작하지 않는 상태였다.
해결 과정
1. EBS 볼륨 확장
AWS 콘솔에서 EC2 root EBS 볼륨을 8GB → 16GB로 확장했다.
EBS 볼륨을 확장해도 리눅스 레벨에서 여전히 8GB로만 보이데, 이유는 다음과 같다.
- EBS 볼륨 크기 확장은 물리적 디스크를 늘리는 작업
- 리눅스에서 실제 데이터를 올려 사용하는 건 파티션 → 파일시스템 계층
- OS는 여전히 “8GB 파티션 위의 파일시스템”만 바라보고 있음
즉, 디스크(16GB) 는 늘어났으나 파티션(8GB) 과 파일시스템(8GB) 은 그대로이다.
2. 파티션 확장
AWS 공식 가이드에 따라 growpart를 사용해서 파티션을 확장했다. 이는 GPT/MBR 파티션 테이블을 수정해 디스크 크기에 맞춰 파티션을 확장하는 역할을 한다.
sudo growpart /dev/nvme0n1 1
출력예시:
CHANGED: partition=1 start=24576 old: size=16752607 end=16777183 new: size=33529823 end=33554399여기서 중요한 점은 데이터를 건드리지 않고, 파티션 테이블만 수정한다는 것.
이 과정은 수 초 만에 끝나고, 무중단으로 실행할 수 있다.
3. 파일시스템 확장
파티션이 늘어났다고 끝이 아니다. 파일시스템(XFS/ext4)이 파티션 크기를 인지하도록 확장 작업을 해줘야 한다.
Amazon Linux 2의 기본 root 파일시스템은 XFS 이므로 다음과 같이 확장한다.
sudo xfs_growfs -d /이 명령어는 커널 레벨에서 마운트된 상태로 온라인 확장이 가능하다. 서비스 중단 없이 운영 서버에서도 바로 적용 가능하다.
4. 확인
root 파티션이 정상적으로 16GB까지 확장되었다.
운영 환경 고려사항
1. 스냅샷 백업 필수
파티션/파일시스템 확장은 원칙적으로 안전하지만, 운영 환경에서는 항상 예외 상황을 고려해야 한다.
- EBS 스냅샷은 증분 백업 구조라 비용이 크지 않고, 몇 초 내에 완료된다.
- 장애 발생 시 스냅샷 → 새 볼륨 생성 → 인스턴스에 재마운트로 빠른 복구 가능하다.
2. 로그 관리 전략
근본적으로 root 디스크에 로그를 직접 쌓는 것은 위험하다.
- Docker 로그 드라이버(log-driver=json-file) 로테이션 설정
- CloudWatch Logs / ELK / Loki 등 외부 로그 수집기로 이관
- root 볼륨은 애플리케이션 실행 환경만 담당하게 분리하는 것이 바람직하다.
3. 확장 전략
- 단일 디스크 확장은 단기적 대응. 다만, 운영환경에서 8GB는 부족하다고 판단해 볼륨 확장을 결정했다.
- 장기적으로는 EBS 볼륨 분리 (root ↔ data), 스토리지 계층화(S3/Glacier 활용) 검토가 필요하다.
정리
- 문제: 로그 누적으로 root 디스크(8GB) 꽉참
- 원인: EBS는 늘렸지만, OS 파티션/파일시스템은 8GB 상태
- 해결:
- growpart로 파티션 확장
- xfs_growfs로 파일시스템 확장
- 운영 환경 고려: 스냅샷 백업 → 로그 아키텍처 개선 → 장기적 스토리지 전략
이 과정을 통해 “운영 환경에서 무중단으로 디스크를 확장하는 법”을 경험했고, 단순 용량 확대를 넘어 스토리지 아키텍처 설계의 중요성을 다시 느낄 수 있었다.