일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
- 버그
- gitignore
- 인스턴스
- rest
- 소프트웨어 아키텍처
- react
- S3
- 오류
- springboot
- Collide
- API
- Cloud
- ckad
- import
- 개발 효율
- 개발
- solution
- VUE
- kubernetes
- 개발 패턴
- 이슈
- 에러
- IntelliJ
- AWS
- excluded file
- HTTP
- Java
- EC2
- 입출력
- 단축키
- Today
- Total
Hungry Developer
AWS EC2 멈춤 현상 (CPU & Network이슈) 본문
한 프로젝트에서 AWS EC2에 SpringBoot 서버를 올리는 과정에서 CPU사용량이 급격하게 늘어나서 서버가 죽었고, 2 주간의 삽질 끝에 이슈를 해결했습니다. 누군가는 이런 이슈들 때문에 삽질하는 일이 없도록 포스팅 하게 되었습니다.
AWS EC2 스팩
- 서버: AWS EC2
- 위치: Asia Pacific (Seoul)
- 사양: t2.micro (Free Tier)
- 용량: 8GB (Free Tier)
- OS: Linux
포스팅 순서
- 현상 파악
- 제시된 해결방안
- 해결된 방법
현상 파악
nohup java -jar \
-Dspring.config.location=classpath:/application.yml,/home/ec2-user/db_setting/application-real-db.yml \
-Dspring.profiles.active=real \
$REPOSITORY/$JAR_NAME > $REPOSITORY/nohup.out 2>&1 &
위의 명령어를 친 뒤에 Spring Boot 기동 후 1시간 ~ 2시간 가량 기동 후에 항상 CPU 사용량이 급증하다가 EC2 서버가 뻗어버리면서 Network가 끊어지는 현상이 있었습니다.
아래에 그림은 Cloud watch를 이용해 CPU 사용량과 Network에 대한 지표입니다.
지표를 자세히 보시면 중간 중간 치솟는 순간이 있는데 이때가 서버가 죽었을 때의 순간이었습니다.
원인
2주간 여러 게시글들을 확인해보니 이러한 경우 크게 4가지의 원인으로 압축되었다.
1. 매우 낮은 스팩의 메모리를 가진 경우(t2.nano와 같은 경우) 또는 자신이 사용하는 애플리케이션의 메모리가 가진 스팩보다 높은 경우
2. 누군가가 나의 EC2를 해킹하여 사용하는 경우
3. AWS EC2 인스턴스의 크레딧을 전부 사용한 경우
4. AWS EC2 인스턴스의 하드웨어의 문제
해결방안
각 원인들에 대한 해결 방안들을 순서대로 번호에 맞춰서 쓰도록 하겠습니다.
필자의 경우엔 4번의 경우에 해당했고 4번의 해결방법을 이용해 이슈를 해결했습니다.
1. Swap 파일 생성
메모리가 부족한 경우 Spec 자체를 높이는 경우도 있지만 우리는 가난한 개발자이지 않은가?
그렇기 때문에 스팩을 올리는데 큰 부담이 생길 수 있다ㅠㅠ
Swap 파일의 생성은
RAM이 부족할 경우가 있으므로 HDD의 일정공간을 마치 RAM처럼 사용하는 것이다. 그래서 우리는 반 강제적으로 RAM을 증설한 듯한 효과를 만들수 있다.
먼저
1. 빈 디스크 만들기
블럭사이즈가 1MB, 블럭 갯수가 2000K 인 빈파일을 만듭니다. (2000000 = 2GB)
dd if=/dev/zero of=/root/swapfile bs=1k count=2000000 conv=excl
swapfile의 권한을 생성합니다.
chmod 600 /root/swapfile
그리고 스왑 파일로 설정을 해줍니다.
mkswap /root/swapfile
스왑파일을 실행해줍니다.
swapon /root/swapfile
free -h
해당 메모리를 확인하면 Swap에 약 2G가 생성된 것을 확인 할 수 있습니다.
인스턴스를 재식할때마다 swap 파일을 기동시켜줘야하는데 이 작업은 너무 번거롭기 때문에
fstab파일에 값을 추가해주면 인스턴스를 재시작할때 자동으로 해당 swap을 실행시켜준다.
vi /etc/fstab
/root/swapfile swap swap auto 0 0
이를 통해서 메모리 이슈를 해결할 수 있다.
2. IP 차단 및 인바운드 규칙 설정
누군가 나의 EC2를 해킹하여 사용하는 경우 최대한 빨리 EC2를 중지시키는 작업을 먼저하시길 바랍니다.
이러한 경우가 많지는 않지만 간혹 과금을 맞으셔서 몇백에서 몇천만원까지 비용이 청구를 받으신 분들이 있었습니다.
누군가 서버에 붙어서 기생하는 경우가 있습니다.
아래 포스팅의 경우에도 누군가가 나의 EC2리소스를 기생한 경우에 대해서 설명했고 여기에 대한 해결법을 적어놨습니다. 이부분은 해당 포스팅에서 확인하시기 바랍니다.
3. 크래딧 설정
AWS에서 Credit 설정작업을 해줍니다.
설정해주는 방법은 하단 링크를 통해 들어가면 확인할 수 있습니다.
4. EC2 인스턴스 교체
매우 드문 경우인데 AWS EC2를 기동시키는 하드웨어 자체의 이슈였습니다.
필자의 경우엔 인스턴스를 교체하여 작업을 했을때 해결되었습니다.
기존의 Instance를 종료하고 새로운 인스턴스를 생성하시면 됩니다.
자세한 원인은 Underlying hardware CPU Clock Speed가 문제가 있는 경우라고 합니다.
아래 참조링크를 확인하시면 저와 같은 이슈를 더 깊이 고민하셨던 분의 내용을 확인할 수 있었습니다.
Reference : https://brunch.co.kr/@alden/59
마치며,
2주간 이 부분을 해결하기 위해 여러 스트레스를 받으며 수많은 삽질을 했었지만, 돌아보면 많은 배울 수 있는 좋은 기회였다고 생각한다. 이 글을 보시는 모든 분들의 건승을 빕니다~
만약 이 포스팅으로 해결이 되었다면 많은 사람들이 삽질하는걸 줄이기 위해 공감이나 댓글 부탁드려요~
https://sundries-in-myidea.tistory.com/102
https://blog.lael.be/post/6810