서버장애가 발생했다.

2019-12-24 크리스마스 이브를 기념하며 서버 장애가 발생했다.
해당 장애는 우선적으로 고객사에서 처리를 하고자 서버를 재시작 하셨지만
JBOSS를 제대로 중지하지 않고 다시한번 시작을 해버려서 JBOSS가 두개가 실행
되어버렸다.

우선 실행중인 JBOSS 두개를 모두 Kill 시키고 다시 Jboss를 실행시켰다.
다행히도 서비스는 다시 작동을 했고 사용자들은 정상적으로 사용이 가능했졌다.

하지만 이는 근본적인 해결책은 아니였기 때문에 정확한 원인을 찾고 이를 조치해야한다.

시작은 LOG

웹/서버 개발자로 일하며 항상 느끼지만 시작은 로그로 부터 시작된다.
무언가 장애가 발생하면 항상 로그를 보게된다 물론 로그를 본다고 바로 해결을
할 수 있는 실력을 가지진 못했지만 늘 그랬듯이 로그를 열어보게 된다.

OOME

OOME OutOfMemoryError 너무나도 유명한 에러이다
그중에서도 OutOfMemoryError:Java Heap Space 에러 말 그대로
자바 힙영역에 일시적으로 과도한 요구가 이루어지거나 지속적인 누수가
발생하게 되는경우 더이상 메모리를 할당할 수 없는 상태가 되고 이로 인해
장애가 발생하게 된다.

원인은?

다행히도 이미 팀장님이 OOME 발생했을때 Heap Dump 파일을 만들도록
설정을 해두셔서 바로 해당 덤프가 만들어진 위치로 이동해서 파일을 찾았다

Elipse Memory Analyzer Tool MAT를 통해서 Heap Dump를 분석하기로 했다
MAT는 메모리 누수관련 문제를 간편하고 보기쉽게 나타내주는 툴이다

하지만 이렇게 툴을 이용해도 정확한 원인을 찾기가 어려웠다.
아무래도 KeyWords 값을 나온 jex.JexConext. Java.lang.Objext[]는
너무 많은 곳에서 사용이 되고 있는 상황이기 때문이였다.

그래서 더욱 상세하게 힙덤프를 확인 할 수 있는 Dominator tree를 통해서
확인을 해봤다.
…. 하지만 역시 나 정확한 원인을 찾기는 어려운 상황이 였지만
공통적으로 BOT_API가 연관되어 있어 해당부분에 대해서 좀더 찾아보기로했다

우선 다른 고객사와 비교했을때 해당 장애가 발생한 고객사가 BOT_API의 사용량이
월등히 높다는 점을 확인했지만 이것만으로 장애가 발생했다고 보긴 어려웠다

의심과 대책방안

정확한 원인, 팩트가 아닌 의심을 해야하는 상황이 왔다 아직도 많이 부족하다는 생각을 했다.

• 첫번째 의심 우리는 BOT_API를 공통부분을 정리해놓은 JSP에서 쓰레드를 생성하고 있는 상황이다.

내부클래스로 쓰레드를 만들게 되면 외부클래스의 대한 참조값을 유지하기 때문에 암시적으로 외부 클래스에 대한 참조를 가지게 되므로 메모리 누수의 위험을 갖게 된다.

JSP파일은 서블릿을 통해 결국 자바파일과 클래스파일로 변환이 되는데 혹시
이 과정에서 쓰레드를 만들기 위해 선언한 클래스 부분이 내부클래스로 인식이 되고
이를 통해서 메모리 누수가 일어나는 건가?

그렇다면 해당부분을 따로 분리해 클래스를 만드는 방식으로 변경해 조치를 하거나 정적 내부 클래스로 선언을 해주는 방식을 택해야한다.

느낀점

정확한 원인조차 찾기가 어렵다. 아직 너무나도 부족하다는 점을 다시한번 느끼게 되었다.
또한 팀장님과 이야기를 해보니 팀장님은 의심이 가는 부분이 발생하면
테스트를 통해서 이를 확인하고 의심을 확신으로 만들어 해당 문제를 해결하시는데
나는 단순히 의심만 했다는 점에서 더욱 더 열심히 해야겠다는 생각을 했다.

1년전 면접장

전 세계 음악 팬들의 요청을 기반으로 공연을 만들어가는 서비스를 만들던 스타트업 회사에서 받았던 질문이 생각낫다
메모리 릭이 발생했을때 어떤 방식으로 대처를 할건지 질문을 받았었다.

그때는 로그를 본다는 말밖에 하지못했다.
지금은 힙덤프를 분석해본다는 말도 붙일수 있게 되었다면 조금이나마 성장했지 않을까?

결국 아직 해결하지 못했지만 꼭 정확한 원인을 찾아내어 이 포스트의 마무리를 짓고싶다

정확한 원인과 해결방안

– 이 부분을 채우는 날이 빨리 오길 –

Notices

언제나 성공할 수 없기에 실패한 날도 기록하자