Batch: ✏️ 매일 정기 푸시 알림 배치 성능 개선

[psychology50]

작업 이유

모든 연구 내용은 블로그에 정리해두었습니다.

• Batch 성능 평가 후, RepositoryItemReader의 Performance가 매우 느리다고 판단하여, 성능 개선

작업 사항

1️⃣ 성능 측정 지표

• Common Case에 해당하던 Reader의 Perfomance을 94.59% 개선 (데이터 100,000개 기준)
• 데이터 천만 개 기준, 수행 시간 12min 소요

2️⃣ QueryDsl no offset 방식의 커스텀 ItemReader

이동욱님 포스트 읽어보시는 게 훨씬 도움이 됩니다.

• 위 코드는 Reader로 조회한 응답의 결과가 QEntity여야 한다는 전제가 필요함.
• 우리 서비스에선 값을 Dto에 매핑하여 결과를 가져와야 하므로, 생성자를 추가하여 해결

리뷰어가 중점적으로 확인해야 하는 부분

• 내용이 많이 어렵긴 하지만, 대부분 Batch 애플리케이션 내 작업이기 때문에 상세한 설명은 불필요하다고 생각해서 간략하게 PR을 적었습니다.
• 만약 궁금한 내용이 있다면 PR 커멘트나 디코로 말씀해주세요.

발견한 이슈

지금 당장 고려해야 할 만큼 중요한 이슈는 아니지만, 데이터 1억 개를 삽입하여 테스트 했을 시
초기 firstKey와 lastKey를 조회하는 쿼리가 심각한 성능 저하를 유발할 뿐만 아니라, 실행 시간이 너무 길어서 timeout이 나기도 함.

이는 QuerydslNoOffsetOptions 클래스 내부에서, Reader를 위한 쿼리를 기반으로 min, max를 사용해 key를 구하려 하기 때문이라 생각. (join을 한 후, user.id로 min, max를 하기 때문에 index를 사용하지 못해 fullscan이 되어버림)
따라서 firstKey, lastKey를 직접 할당하거나, key를 결정하기 위한 쿼리를 따로 제공할 수 있는 메서드를 추가하여 개선할 여지가 있음.