갑자기 느려진 AWS CPU Credit Balance 확인하기

오늘 아침부터 갑자기 웹 페이지 로딩이 너무 느린 문제를 확인하다 AWS CPU Credit Balance 라는 확인하게 되어 글을 남깁니다.

환경

t2.micro ubuntu 18.04 instance

호스팅 – nginx + gunicorn + flask

Back end program – python과 mysql RDS를 사용하는 back end program

이 환경으로 실시간으로 동작하는 서버입니다.

아침에 일어나니 웹페이지가 죽은건 아닌데 Refresh를 하면 504 Bad Gateway가 한참 있다 발생하고 있었습니다.

gunicorn Log를 보니 다음 Timeout Error가 발생하고 있었습니다.

[WARNING] Worker with pid 9302 was terminated due to signal 9
[INFO] Booting worker with pid: 9459
[CRITICAL] WORKER TIMEOUT (pid:9459)

재부팅을 해도 처음에 잠깐 동작하는것 같다가 조금 있으니 곧바로 다시 동작을 하지 않았습니다.

당황스러웠던 것은 새벽에 잠들때까지는 괜찮았다는 것입니다.

RDS DB Log도 확인해봐도 문제가 없습니다.

그러다 Monitoring을 보다가 우연히 CPU Credit Balance를 발견하였습니다.

AWS의 Instance에서 Monitoring 항목을 확인하다 확인하였습니다.

뭔가 내려가다 오늘 거의 0에 수렴하는 것을 발견하였습니다.

그래서 AWS에서 관련 문서를 찾아봤습니다.

T 계열의 Instance에서 CPU를 부스팅을 할 수 있는데 이를 사용할 수 있는 Credit을 평소에 누적하고 있다가 필요할때 사용한다는 개념입니다.

나름 합리적이네요. 좀 저렴하게 Instance를 사용하고 대신 필요할때 부스팅을 사용하는 개념이네요.

아래 그림은 문서에 나와 있는 instance별 누적가능한 Credit 수에 대한 표입니다.

어쩔 수 없이 웹 서버와 백엔드 프로그램을 분리했습니다.

돈이 없는 저로써는 t2.nano를 하나 더 생성해서 백엔드 프로그램을 옮겼습니다.

그 결과 다음과 같이 12h view로 변경해서 보니 서서히 Credit이 다시 올라가고 더이상 웹 페이지 로딩이 느리거나 TimeOut이 발생하지 않음을 확인하였습니다.

아침에 당황했지만 주말에 발생한 걸 다행으로 여기며 나름 시간을 들여 해결하였고 또 하나 배웠다는 느낌이 좋네요.

현재 instance를 꽤 많이 운용하고 있고 앞으로도 이러한 문제들이 있을것 같아 오늘 분석중에 또 알게된 AWS Compute Optimizer 를 설정해봤습니다.

결과가 표시되는데 최소한 12시간이 걸리기 때문에 지금은 아무것도 나오지 않지만 나중에 이러한 성능 분석에 큰 도움이 될것 같습니다.

다음에 AWS Compute Optimizer도 유의미한 사항을 발견하면 정리해보겠습니다.