[AWS] EC2 인스턴스 t 타입. 프리티어 EC2 인스턴스 먹통되는 현상 (502 bad gateway)

프로젝트를 진행하면서 스프링부트 API 서버를 EC2에 배포하였다.

 

프론트 분들께서 개발하시도록 API 서버를 24시간 동안 가동하였는데 EC2 인스턴스가 얼마 가지 못하고 계속 먹통이 되는 현상이 발생하였다,

 

보통 아래와 같은 현상이 발생하였다,

1. 응답까지 시간이 매우 오래 걸린다.
2. 502 bad gateway 에러가 발생한다.

임시 방편으로 EC2를 중지하였다가 다시 실행 후 서버를 다시 배포하면 괜찮아졌으나 이마저도 1시간도 채 지나지 않아서 다시 먹통이 되는 현상이 발생하였다.

 

뭔가 내가 놓치는 부분이 있을 거라 생각하여 EC2 프리티어 인스턴스 타입인 t2.micro에 대해서 알아보았다.

 

먼저 EC2의 유형을 보기위한 방법은 다음과 같다.

 

t 2 . micro (인스턴스 타입) (세대) (크기)

차례대로 타입, 세대, 크기를 의미한다.

 

즉 EC2 프리티어 인스턴스는 t 타입 2세대 micro인 것이다.

 

https://aws.amazon.com/ko/ec2/instance-types/

Amazon EC2 인스턴스 유형 – Amazon Web Services

 

위 링크에서 t2 타입에 대한 설명을 보면 다음과 같다.

기본 수준의 CPU 성능과 더불어 기본 수준을 넘어 버스트할 수 있는 기능을 제공하는
버스트 가능 성능 인스턴스

 

기본 수준을 넘어 버스트할 수 있는 기능을 제공하는 버스트 가능 성능 인스턴스라고 설명하고 있다.

 

위 설명에서 알 수 있다싶이 버스트라는 기능은 기본적으로 제공해주는 성능을 넘어서는 기능이라고 볼 수 있다.

 

예를 들어 인스턴스의 기준 cpu 사용률이 10%로 제한되어 있다고 하자.

 

그런데 이 10%를 넘어서는 작업을 할 때 버스트를 하게 되는데 이 때 크레딧(credit)이라는 것을 소모한다.

 

크레딧 하나가 있으면 vcpu 하나가 1분 동안 100% 사용할 수 있다.

 

이 크레딧은 기준 cpu 사용량(위 예시에서는 10%) 아래로 사용하면 생성이 된다.

 

즉 t 타입의 경우 평소에는 기준 cpu 사용률 아래로 cpu를 사용하다가 가끔씩 기준 cpu 사용률 보다 높게 cpu를 사용하는 경우에 적합한 타입이다.

t 타입이 적합한 예시

 

평소에는 cpu를 적게 사용하여 크레딧을 모아뒀다가 갑자기 트래픽이 증가하는 이벤트가 일어난 것과 같은 특수한 경우에 크레딧을 사용하여 버스트 하는 것이다.

 

그러면 이제 t2.micro의 제한 사항을 확인해 볼 차례이다.

 

인스턴스	vCPU	메모리 (GiB)	시간당 cpu 크레딧	최대 누적 크레딧	vCPU당 기준 사용률
t2.micro	1	1	6	144	10%

가장 먼저 의심가는 상황은 평균적인 cpu 사용률이 기준 사용률보다 높은 상황이다.

 

cloud watch -> 모든 지표 -> EC2에 들어가서 CPUUtilization을 통해 EC2의 사용률을 확인해보았다.

 

 

cpu 사용률이 9%에서 11% 사이로 왔다갔다 하였다.

 

CPUCreditBalance를 통해 크레딧 수도 확인해보았다.

크레딧이 계속 사용되어 모이지 않는 모습도 확인할 수 있었다.

 

t2.micro의 CPU 기준 사용률인 10%보다 높은 경우가 많았기 때문에 cpu가 먹통이 되는 현상이 발생했던 것이다.

 

해결 방안은 여러가지가 있었다.

 

1. 크레딧 사양을 standard에서 unlimited로 변경한다.
2. EC2 인스턴스 스펙을 올린다.

1번의 경우 기준 사용률보다 높을 때 크레딧을 사용하다가 다 떨어지면 잉여 크레딧을 사용하는 것이다.

 

그리고 이 잉여 크레딧은 24시간 내에 cpu 기준 사용률보다 적게 cpu를 사용할 때 청산하게 된다.

 

청산하지 못한다면 비용을 지불해야 한다.

 

그런데 나는 평균적으로 기준 사용률보다 높게 cpu 사용률이 측정되었기 때문에 큰 의미는 없을 것 같아서 2번 방식을 택했다.

 

t2.micro에서 t2.large로 스펙을 올렸다. 물론 t2.large는 프리티어에 해당되지 않아서 요금이 부과된다.

 

t2.micro와 t2.large의 차이는 다음과 같다.

인스턴스	vCPU	메모리 (GiB)	시간당 cpu 크레딧	최대 누적 크레딧	vCPU당 기준 사용률
t2.micro	1	1	6	144	10%
t2.large	2	8	36	864	30%

스펙을 올리고 다시 크레딧 수를 측정해보았다.

 

크레딧이 쌓이는 모습을 확인할 수 있다. 계속 기준 사용률 밑으로 cpu를 사용하고 있다는 뜻이다.

 

cpu 사용률도 측정해보았다.

 

평균 0.5% 아래로 측정되었다.

 

이렇게 기준 사용률보다 평균 cpu 사용률이 높을 때 스펙을 올려 기준 사용률을 높이는 방식으로 해결해보았다.

 

그런데 지금 생각해보면 평균 cpu 사용률이 높아서 발생한 문제이기는 했지만 이것이 본질적인 문제는 아니었던 것 같다.

 

개발 단계에서 api 테스트 용도로 사용하던 중이었는데 평균적으로 cpu 사용률이 10%가 나오는 것이 이상하다.

 

트래픽 또한 거의 없었을텐데 말이다.

 

그래서 EC2 인스턴스를 처음 시작했던 한 달 전 지표를 확인해보니 그 때도 평균적으로 0.5% 아래로 cpu 사용률이 측정되었다.

 

이것을 보니 아마 EC2 인스턴스 자체의 문제이지 않았을까 싶다.

 

프리티어 EC2 인스턴스를 아예 종료했다가 다시 프리티어 EC2 인스턴스를 새롭게 만들어서 서버를 배포했어도 이 문제를 해결할 수 있었을 것 같다.

 

참고

https://www.youtube.com/watch?v=lmJBrtpJkNU 

https://aws.amazon.com/ko/ec2/instance-types/

https://hjjooace.tistory.com/42