Java heap dump, JVM OOM(Out of Memory)

200개가 넘는 국가에서 2000개가 넘는 IP를 통해 수십만건의 요청(공격)이 1분동안 발생했다. 유효한 API 요청이였지만 파라미터 값이 모두 널(null) 값 이기에 일반적으로 제공하지 않는 요청이였다. 이것이 DDOS 공격인가 싶었다.

 

이전에 토이프로젝트로 만들어둔 RateLimiter를 사용할 때인가 싶었지만, 수천개의 IP에서 보내는 것이기에 룰이 애매했다. 

https://github.com/sh970901/TOTORO

 

이로 인해 JVM OOM(Out Of Memory)이 발생하였고 서비스는 장애가 났다. 

 

이정도 TPS에 뻗을만한 일인가 싶었다. SEO 이후에 자주 이런 비정상요청이 있었지만 서비스가 뻗은 것은 처음이였다. 

생각해보니 늘 요청하는 API는 달랐고 이번에 공격받은 API는 처음인가 싶기도 했다. 

한편으로는 팀장님께서 우리 서비스가 널리 알려진 것으로 생각해봐도 좋을 것 같다 하셨고 그 말이 큰 힘이 되었고 동기부여가 되었다. 

 

일단 첫번째 실수는 EC2 자체 메모리는 16G였지만 JVM 최대 힙 사이즈는 4G로 서버 자원의 낭비가 심했다. 이건 추후 맞춰나갈 예정이지만 이 JVM heap size를 늘리기 보단 근본적인 원인을 찾아 해결하고 싶었다. 메모리가 올라가면서 CPU도 순간적으로 100을 치긴하였지만 너무 순간적이기 때문에 스케일아웃은 되지 않았다.

 

따라서 스케일아웃룰을 CPU가 아닌 unhealth 인스턴스 체크로 바꾸기로 했다. 그리고 20년부터인가 로드밸런서에서 health한 타겟에만 트래픽을 전달하는 아주 유효한 알고리즘이 있다하여 이를 활용한다면 다운타임을 최소화 할 수 있지 않을까 생각했다. 하지만 이것은 이미 장애상황이 발생한 후 빠르게 대처하기 위한 자동화일 뿐이였다. 근본적인 원인을 찾고 싶었다.  

 

힙 사이즈가 오버된 주요 원인을 분석하고 싶었지만 코드만 봐서는 문제점을 찾기 힘들었다. 그래서 heap dump를 시도했고 과정을 공유해보려고 한다. 

 

(현재 환경 Amzon Linux 2, JDK 17)

jps

jps 명령어를 사용하여 현재 실행중인 java 프로세스와 PID를 확인한다. 

 

jmap -dump:format=b,file=[FILE_NAME] [PID]
//jmap -dump:format=b,file=service-heapdump.hprof [pid]

jmap 툴을 사용하여 Heap dump를 뜨면 된다.

 

Heap Dump 분석 툴 중 이클립스에 제공하는 무료 툴을 사용했다 .

https://eclipse.dev/mat/

해당 사이트에서 OS 환경에 맞는 툴을 다운받고 Memory Analyzer.exe를 실행하자.

 

참고로 최신 버전의 Memory Analyzer는 jdk 17 이상부터 지원되는듯하다. 

 

이전에 다운받은 힙 덤프 파일을 업로드하자. 

 

Overview 탭에서 Dominator Tree를 선택하면 Heap Dump를 뜰 당시에 만들어진 Java 객체들을 한 눈에 확인할 수 있다.

비정상적으로 높은 퍼센트를 차지하는 객체가 어떤 것인지 확인할 수 있을 것이고, 이 객체가 결국 Heap의 높은 사용량을 만든 주범이라는 것을 쉽게 알아낼 수 있다.

 

가장 많은 비율을 차지하는 자바 객체를 확인하고 비정상적으로 높다고 판단된다면 해당 객체를 사용하는 부분을 다시 디버깅해보는 과정을 가져보면 될 듯 하다.

 

 

 

 

 

그럼 다시 원인 분석하러,,,