티스토리 뷰

반응형

이번글은 AWS EC2로 서비스를 배포해서 운영하면서 지속적으로 EC2 인스턴스가 죽어버리는 이슈를 트러블슈팅한 내용을다룬다.

 

쓰레드 기아상태에 빠진 작고 귀여운 우리 서버찡...

 

해당 글의 연장선이다.

 

https://mopil.tistory.com/128

 

지속적인 EC2 의문사 오류를 찾기 위한 조사 과정에 대한 회고

이상하게 DDD 동아리 프로젝트 서버가 종종 죽는 상황이 발견되었다. 꽤 오래전부터 식별되었던 문제였는데, 초반에는 그냥 죽을 때마다 재부팅하는 식으로 해결하다가 원천 해결을 해야겠다고

mopil.tistory.com

 

# 장애 원인

핵심 원인 : DB 커넥션 부족으로 인한 EC2 CPU 사용량 99% 초과, EC2 상태검사에 통과하지 못 해서 서버 중단

 

우선 원인은 이거였는데 무엇때문에 이게 발생하는지 알 수 없었다.

(초기에는 위의 글 처럼 프론트 분들의 실수로 무한루프 요청이 들어오는 줄 알았는데 이는 아니였다... 의심해서 죄송합니다 우리팀 ㅠㅠ)

 

# 원인 분석을 위한 노력, 대처

보다 정확한 원인을 파악하기 위해 로깅을 강화했다. logback을 설정해서 로그파일들을 저장하게끔 했고, 필요없는 로그들은 최소화 했으며 요청의 흐름을 파악하기 위해 IP와 엔드포인트를 로깅하도록 설정했다.

 

이를 통해 파악된 1차 장애 원인은 무분별한 해외 IP 유입이었다.

로그를 보아하니 해외 출신의 IP들이 대거 찍혀있었고, swagger 접근을 하는것을 보아 뭔가 크롤링 봇 같아보였다.

 

여튼 해외 IP의 트래픽 때문에 EC2 프리티어 인스턴스가 버티지 못 하는것으로 판단되어 AWS CloudFront의 지역 IP 차단 기능을 통해서 해외 IP 유입을 차단했다.

 

https://mopil.tistory.com/133

 

AWS CloudFront로 EC2 해외 유입 IP 차단하기

SSL 인증서가 AWS CloudFront로 설정되어있다면 EC2로 유입되는 트래픽을 제한하는 걸 아주 쉽게 할 수 있다. # CloudFront 설정 # 테스트 https://tools.pingdom.com/ Pingdom Tools Full Page Test Analysis tools.pingdom.com 다

mopil.tistory.com

 

추가로, DB 커넥션이 부족해서 발생하는 문제이기에 커넥션 풀 사이즈를 20으로 늘리고 스프링 부트 실행 메모리를 EC2 자원을 최대한 활용하게끔 설정했다.

 

# 하지만 끝나지 않은 이슈

해외 IP를 차단하고 상황을 모니터링하는데도 계속해서 Thread starvation or clock leap detected 오류가 발생하면서 서버가 죽었다. 

 

당연히 로그에는 해외 IP 유입이 없었다. 

 

프리티어 인스턴스로 서버를 운영하면서 처음 발생하는 이슈라 이제 남은 옵션은 다음과 같았다.

 

1. 오토스케일링 설정하기 -> 하지만 서버 유지비용으로 부담

2. EC2 인스턴스 scale-up 하기 -> 이것 역시 유지비용으로 부담

 

우리팀은 일단 서버 유지비용을 최소화해야하기 때문에 (BM도 없고... 이 서비스는 서비스 출시 목적이 아니라 경험이 목적인 플젝이였다.) 해당 옵션들은 최후순위로 밀어놨었다.

 

그러다가 다른 실마리를 찾은 것 같았다.

 

https://velog.io/@mbsik6082/Spring-Data-JPA-Transaction-Propagation-EntityManager-PersistContext%EC%97%90-%EA%B4%80%ED%95%9C-%EA%B3%A0%EC%B0%B0

 

Spring Data JPA Transaction Propagation, EntityManager, PersistContext에 관한 고찰

https://velog.io/@mbsik6082/Thread-starvation-or-clock-leap-detected-Dead-Lock-hikari-%EC%98%A4%EB%A5%98이 글을 작성하게 된 이유는 친구와 면접 준비를 하다가 내가 트러블슈팅한

velog.io

 

해당 글을 읽고 서비스와 리포지토리에서 불필요한 어노테이션이 없는지 확인했는데... 딱 한 곳 

QueryDSL로 Imple 리포지토리를 만든 부분에서 @Repository 어노테이션이 달려있는걸 발견했다!! (아마 팀원의 실수인 것 같다...)

 

여튼 이걸 제거하고 다시 상황을 지켜봐야겠다.

 

# 02-10

위와 같이 수정을 해도 동일한 문제가 발생했다.

 

우선 처음에는 실행 메모리가 -Xmx로 최대만 설정되어있고, -Xms는 설정되어있지 않아서 이를 설정해줬는데 뭔가 더 빨리 서버가 다운되는 것 같았다.

 

그래서 실행 메모리 옵션을 둘 다 제거했다. (당장은 OOM이 뜨지 않았으므로...)

 

그래도 동일한 이슈가 계속 발생하자 마지막 옵션인 Scale-up을 진행했다. 

vCPU가 2개인 t3.small로 일단 업그레이드를 했고, 상황을 추가로 지켜보기로 했다.

 

반응형
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크