Java 힙 공간 에러 발생한 배치 성능개선후기

2022.08.19
개발된지 3년이 넘은 이후로 마지막 수정 2019년 초 나 입사 전
그 뒤 전혀 수정 없이 매달 루틴하게 잘쓰던 자료 추출용 정기작업 배치에서 오류가 발생하였다.

[문제점]
에러 로그를 보다보니 한가지 특이한 점, statistic에서 눈에 띄게 cpu time이 높은 걸 확인할 수 있었음
10분짜리 (워낙 대용량 자료를 인풋으로 하고있음) 작업이라 치면 8분이상은 cpu를 잡아먹음
그리고 로그에 찍힌 에러 발생한 원인도 java 힙 공간 에러 java.lang.outofmemory 어쩌고 저쩌고
로그가 가리키는 줄은 if (조건 a를 만족) -> b 로 출력한다 같은 단순한 라인이었지만
저 라인만이 문제가 아닐 것이라고 생각하여 코드 전체에 대한 분석을 팀원들과 함께 진행하였음

워낙 대용량 수십 수백만건 계약을 처리하는 배치라지만
지금까지 아무 문제 없이 쓰고 있다기에는, 생각보다 문제점이 적지 않았음.
이번에 처음 터진게 신기할 정도.
그리고 나는 해당 배치를 먼슬리로 담당하고 있었으나,
타 팀원은 똑같은 배치를 데일리로 사용하고 있는데 왜 지금까지 한번도 안 터졌는지 의문.
단순히 인프라 서버상황 탓하기에는 코드에서도 고칠 점이 생각보다 적지않아 수정을 진행함.

[수정한 부분]
1. 데이터 담는 부분을 전역변수로 설정하여 사용하고 있는데, 특정 메소드에서 갑자기 객체 호출을 새로 매번 하고 있음.
private로 해당프로그램 안에서만 사용할 전역변수를 지정했으면 그냥 쓰면 되지 수백만번을 매번 호출해서 쓰고있었음?

2. 매번 DB를 읽는 수고를 덜기 위해 기초 인사정보데이터를 해쉬맵에 저장하여 사용하는데,
매달 인사db에 들어가는 사람 수는 늘어나고 하다보니 해쉬맵에 들어가는 데이터가 점점 많아짐.
다른 팀원들도 해쉬맵에 정보 담아놓고 쓰다가 터진 배치들이 실제로 종종 존재했던 모양.
일단 담는 부분을 줄이기 위해, 퇴사자를 제외하는 조건을 걸어서 담는 분량을 줄인 후
혹여나 퇴사자 계약으로 판단되는 경우 그냥 db를 다시 읽으러 다녀오기로 함.


[결과]
수행 속도에 큰 차이 없음
데이터 정합성 문제 발생하여 1번 롤백하여 재수행
애초 모델링부터가 잘못되어 있었는데 이 부분 놓쳐서
같은 메모리주소에 세번을 덮어써서 출력해버림.
이는 메소드 수행할 때마다 객체 재실행하지 않으면 해결되지 않음이 확인되었음.
모델을 본격적으로 고치기에는 데일리로도 같은 배치가 돌고 있어서 불가.


내가 짠 코드는 아니었지만, 기본적인 부분에 있어서 생각을 좀더 하면서 프로그램을 짜야겠다고 느낌
그리고 클린 코드 주문함.