티스토리 뷰
개인 프로젝트를 운영하던 중 예기치 못한 문제가 발생하여 원인 분석과 해결하는 과정을 정리해보았습니다.
개발 환경 : AWS EC2 프리티어(ubuntu 24), Nginx 1.24.0, Sentry
1. 문제 시작
개인적으로 운영하는 사이트에서 백엔드 API 요청 시 500 에러가 발생하였습니다. (어라? 어제까지는 잘 됐는데..)
2. 원인 분석
일단 원인을 찾기 위해 모니터링 툴인 Sentry 들어가서 이슈를 확인했는데 새로운 이슈는 없었습니다.
그 다음, 운영 서버에 들어가서 백엔드 프로젝트에 에러 로그를 보았습니다.
하지만 에러 로그에는 기록이 남겨있지 않았습니다. 요청 로그에도 요청한 기록이 없었습니다.
백엔드에 문제가 아니라 "다른 문제일 수도 있겠구나" 생각이 들어서 Nginx 로그를 확인해보았습니다.
Nginx 로그를 확인해보니 에러 로그가 있었습니다.
/var/log/nginx/error.log
2024/09/09 15:09:04 [crit] 55596#55596: *66 pwrite() "/var/lib/nginx/body/0000000007" failed (28: No space left on device), client: 27.35.44.119, server: api.seolyu.com, request: "POST /applicants HTTP/1.1", host: "api.seolyu.com", referrer: "https://seolyu.com/"
이 에러는 /var/lib/nginx/body/ 디렉토리 안에 요청 데이터를 저장하려고 할 때, 디스크 공간이 부족해서 파일을 기록하지 못하는 에러 로그입니다.
그렇게 원인은 Nginx에서 요청 데이터를 저장하는데 디스크 공간이 부족하여 API 요청 시 500 에러를 발생한다는 것을 알았습니다.
서버의 디스크 공간을 확인해보니, 여유 공간이 없었습니다.
/dev/root 를 보면 사용할 수 있는 Avail 항목에서 0 이었고 Use% 항목에서 100% 나타났습니다.
3. 해결 방법
[ 방안 1. 디스크 여유 공간 만들기 ]
디스크 여유 공간을 만들기 위해 용량을 가장 많이 사용하는 디렉터리 10개를 찾아보았습니다.
sudo du -h --max-depth=1 / | sort -hr | head -n 10
현재 /usr, /opt, /home, /var 디렉토리가 상당한 용량을 차지하고 있습니다.
용량을 많이 차지하는 디렉토리 중에서 불필요한 패키지나 캐시를 삭제하여 여유 공간을 만들어줍니다.
이 방법은 임시적으로 여유 공간을 만들 수 있지만 장기적으로 봤을 때 수동적으로 정리를 해줘야 하고 잘못된 패키지 삭제로 인해 중요한 프로그램이나 라이브러리가 삭제될 수 있어, 시스템이나 애플리케이션의 작동에 문제가 발생할 수 있습니다.
[ 방안 2. 스케일 업 ]
이 방안은 EC2 볼륨을 확장하는 방안입니다.
현재 디스크 용량은 8GB 설정되어 있습니다.
EC2 프리티어의 최대 용량은 30GB 까지 쓸 수 있어서, 디스크 용량을 8GB -> 30GB 변경합니다.
보통 스케일 업은 청구 비용이 더 비싸지는 문제점이 있지만, 무료로 볼륨을 확장시킬 수 있어서 이 문제점을 해결할 수 있었습니다.
4. 스케일 업 하기
AWS 접속하여 EC2 볼륨을 30GB 수정합니다.
EC2 볼륨을 수정해도 서버의 디스크 용량이 변경되지 않습니다.
변경 사항을 적용하려면 운영 체제에서 추가 작업이 필요합니다.
적용법은 다음과 같습니다.
1. 디스크 용량 확인
ubuntu@seolyu-1:~$ sudo df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 6.8G 6.7G 0 100% /
tmpfs 479M 0 479M 0% /dev/shm
tmpfs 192M 932K 191M 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/xvda16 881M 133M 687M 17% /boot
/dev/xvda15 105M 6.1M 99M 6% /boot/efi
tmpfs 96M 16K 96M 1% /run/user/1000
tmpfs 96M 16K 96M 1% /run/user/0
2. 인스턴스에 연결된 볼륨의 디바이스 이름 확인
ubuntu@seolyu-1:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 25.2M 1 loop /snap/amazon-ssm-agent/7993
loop1 7:1 0 55.7M 1 loop /snap/core18/2829
loop2 7:2 0 38.8M 1 loop /snap/snapd/21759
xvda 202:0 0 30G 0 disk
├─xvda1 202:1 0 7.9G 0 part /
├─xvda14 202:14 0 4M 0 part
├─xvda15 202:15 0 106M 0 part /boot/efi
└─xvda16 259:0 0 913M 0 part /bootxvda 보면 30GB 볼륨이 있는 것을 확인할 수 있습니다.
xvda1 는 7.9GB 로 현재 사용하고 있는 파티션입니다.
3. 파티션 확장
sudo growpart /dev/xvda 1growpart 명령어를 통해 xvda1 파티션에 크기를 확장합니다.
유의할 점은 디바이스 이름(xvda)과 파티션 번호(1) 사이의 공백을 넣어줘야 합니다.
4. 파티션 확장 확인
ubuntu@seolyu-1:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 25.2M 1 loop /snap/amazon-ssm-agent/7993
loop1 7:1 0 55.7M 1 loop /snap/core18/2829
loop2 7:2 0 38.8M 1 loop /snap/snapd/21759
xvda 202:0 0 30G 0 disk
├─xvda1 202:1 0 29G 0 part /
├─xvda14 202:14 0 4M 0 part
├─xvda15 202:15 0 106M 0 part /boot/efi
└─xvda16 259:0 0 913M 0 part /bootxvda1 파티션을 보면 7.9GB에서 29GB 변경되었습니다.
5. 파일 시스템 확장
sudo resize2fs /dev/rootresize2fs 명령어를 통해 /dev/root 파일 시스템을 확장합니다.
여기서 의문이 들었던 게 왜 /dev/root 파일 시스템을 확장하는거지? 생각이 들었습니다.
그 이유를 찾아보니, /dev/root 파일 시스템과 xvda1 파티션의 Mountpoints 연결 되어 있어서 확장하는 것이었습니다..!
6. 디스크 용량 변경 확인
ubuntu@seolyu-1:~$ sudo df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 29G 6.6G 22G 24% /
tmpfs 479M 0 479M 0% /dev/shm
tmpfs 192M 932K 191M 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
/dev/xvda16 881M 133M 687M 17% /boot
/dev/xvda15 105M 6.1M 99M 6% /boot/efi
tmpfs 96M 16K 96M 1% /run/user/1000
tmpfs 96M 16K 96M 1% /run/user/0/dev/root 파일 시스템의 용량이 29GB 변경되었습니다.
5. 느낀점
Nginx 의 에러 로그만 보고 /var/lib/nginx/body/ 디렉토리 용량이 부족하다 부분에 꽂혀서 1시간 동안 삽질하긴 했지만, 결과적으로 무료로 스케일 업을 하게 되었고 정상적으로 API 요청을 보낼 수 있게 되었습니다.
'∙Server' 카테고리의 다른 글
| Nginx와 헬스체크를 활용한 무중단 배포하기 (0) | 2024.09.02 |
|---|---|
| Nginx에서 SSL 인증서 갱신하기 (0) | 2023.11.10 |
| Nginx 다중 도메인 서버 설정하기 (0) | 2023.11.07 |
| NGINX + HTTPS 적용하기 (0) | 2022.05.10 |
| AWS 엑세스키 해킹 후기 (0) | 2022.04.22 |