문제 상황
git pull을 하고 다시 build를 하는데, 갑자기 굉장히 느려지더니 서버가 먹통이 되었었다.
우선 서버 재시작을 해봤더니 일시적으로 해결되었으나, 다시 서버가 매우 느려지는 현상이 발생했다.
EC2 서버 사양
- AWS EC2
- 위치 : 아시아 태평양 (서울)
- 사양 : t2.micro (Free Tier)
- 용량 : 30GB (Free Tier 최대)
- OS : ubuntu22.04
원인 예측
이 서버에는 작은 SpringBoot project 하나만 올라가 있었기 때문에 용량 문제는 아닐 거라고 판단했다.
또한, 갑자기 느려졌기에 다른 문제가 있을 거라고 생각했다.
서버에 부하가 큰 것도 아닐 것이라고 생각했다. 현재 FrontEnd 측 로컬에서 테스트 정도로만 사용하고 있었다.
검색해 보니 AWS 서버에 문제가 있는 경우는 크게 두 가지라고 한다.
1. 서버 자체의 물리적 결함
2. EC2는 결국 물리적 서버가 아닌 VM이기 때문에 같은 물리적 서버의 다른 VM이 많은 자원을 사용해서 함께 느려지는 경우
간단하게 해결하기 위해선 이 물리적 서버를 벗어나면 된다고 한다.
해결
서버를 중지 후 시작을 해서 해결했다.
재시작과 중지 후 시작은 다르다!
인스턴스를 선택 후 인스턴스 상태 - 인스턴스 중지를 선택하여 서버를 stop 한다.
중지되는 데에는 최대 10분까지 소요된다고 한다.
정상적으로 중지되면 인스턴스 시작 버튼이 활성화되고, 시작 버튼을 눌러 서버를 다시 시작하면 된다.
서버를 중지 후 시작 하면 다른 물리적 서버를 사용하게 된다고 한다.
서버를 재시작하면 물리적 서버는 그대로인 채 서버만 재시작된다고 한다.
(추가) 진짜 문제 발견
위의 방법은 일시적인 문제를 해결하는 방법이었다.
그러나, 위의 원인 때문에 서버가 터지는게 아니었다.
SpringBoot 프로젝트를 아래 명령어를 이용해서 백그라운드에서 실행시켰다.
sudo nohup java -jar USports-0.0.1-SNAPSHOT.jar &
이렇게 하면, nohup.out 이라는 파일에 log가 찍히게 되고, 이 log는 계속해서 쌓이게 된다.
배포 서버 API를 이용할때마다 log가 쌓이게 되고, log가 계속 쌓이다가 EC2 인스턴스의 용량을 초과해 버리면 서버가 터지게 되는 것이었다.
우리는 일시적으로 배포 테스트를 위한 배포였기 때문에 AWS EC2의 t2.micro 서버를 이용하고 프리티어로 무료로 사용하고 있었기 때문에, 용량이 적어서 발생하는 문제였다.
그래서 log가 쌓이지 않도록, 파일을 생성하지 않고 log를 버리는 방식으로 문제를 해결했다.
위의 백그라운드 명령어를 아래와 같이 수정하여 해결하였다.
sudo nohup java -jar USports-0.0.1-SNAPSHOT.jar > /dev/null 2>&1 &
해당 명령어에서 발생하는 output을 /dev/null로 보내도록 설정한다.
/dev/null은 리눅스에서 특수한 파일로 모든 데이터를 버릴 때 이용된다.
즉, 출력을 무시하고자 할 때 사용한다고 한다.
'DevOps > Deploy' 카테고리의 다른 글
[Linux / ubuntu] AWS Ubuntu 20.04에 swap 메모리 설정하기, Freetier 메모리 부족 현상 해결 (0) | 2024.01.28 |
---|---|
[AWS EC2 / 배포] SpringBoot Project 배포, EC2 ubuntu, docker (2) | 2024.01.24 |
[Spring / S3] SpringBoot 프로젝트 - S3 이미지 업로드 (4) | 2024.01.21 |
[AWS/S3] Spring boot project 이미지 업로드를 위해 S3 버켓 만들기 (0) | 2024.01.21 |
[AWS / SpringBoot] 스프링 부트 프로젝트 변경사항 rebuild 후 재배포 (기록용) (0) | 2023.12.15 |