작성 이유

회사에 들어오고 3주차였나 4주차였나 처음으로 냈던 에러가 batch job 관련 된 것이었다. 30만명을 대상으로 푸시 / 알림을 발송하는 기능이었는데 아침에 모니터링을하며 로그를 보니 2명에게만 발송되었다 (꿈인줄 알았다).

Batch를 정말 Batch답게 쓰지않고 그냥 일반 메서드처럼 구성해서 쓰기는 하지만 그래도 경험에서 배운점들이 몇 개 있었다.

비즈니스 규칙
1. 이벤트는 대상군이 존재한다.
2. 이벤트 대상군 중 퀴즈를 그날 푼 유저는 푸시/알림을 보내지 않는다.
3. 이벤트 대상 군 중 퀴즈를 풀지 않았고 푸시/알림 동의를 한 유저들에게 알림을 본내다.

1. 중단 시점

여기서 검은색은 이벤트 대상군이다. 파란색은 작업 단위인데 1000명씩 가져와서 작업을 하는거다. 1000명 작업을 한 뒤에는 마지막 작업한 대상의 id를 넘겨줘서 그 다음에는 그 아이디보다 큰 1000명을 또 가져오는거다. 빨간색은 잘라온 1000명중에서 푸시/알림 수신 동의를 하고 그날 문제를 풀지 않은 유저들을 나타낸다.

처음에는 로직을 잘못 생각하여 가져온 1000명 중 푸시/알림 수신 동의한 사용자(빨간색)의 크기가 0이면 batch job이 종료되도록 하였다. 하지만 그림에서 볼 수 있듯, 지금 잘라온 1000명 중에는 푸시/알림 수신 동의한 사용자의 크기가 0일지라도 다음 1000명에는 또 있을 수 있다. 그림으로 보니 명확하지만 코드로만 보니 이 부분을 놓쳤었다.

또 데이터를 불러오는 단위가 1000이다 보니 dev 환경에서 테스트 데이터를 1000개를 넣지 않고 테스트를해서 당시에는 정상적으로 동작했었다.

2. Stckoverflow

이벤트가 잘되어서 이벤트 대상군이 확대되었다. 즉 1번에서 나온 검은색이 길어진거다. 자연스럽게 파란색 조각 막대들의 개수가 많아졌고, 나중에는 Stackoverflow가 발생했다. (파란 막대들을 하나하나 돌아보는 작업을 재귀로 구성했다). 단순히 문제 해결을 위해서는 반복문으로 바꾸면되었겠지만, 로그를 살펴보니 비효율적인 면들이 있었다.

기존 방식은 전체 대상군 중 1000명 잘라오기 -> 그날 문제를 푼 유저들 제거 -> 남은 사람 중 알림/푸시 동의한 사람들 대상으로 보내기였는데 1000명을 가져와서 두 조건으로 거르고 나니 50명 이하로 보내는 작업들이 많았다.

알림 수신 동의한 유저들은 전부 이벤트 대상군이니 알림 수신 동의한 유저 중 1000명 잘라오기 -> 그날 문제 푼 유저 제거 후 알림 보내기 이렇게 변경을 하니 1000명중 800명이상 알림을 보내게되었고 당연히 전체 도는 횟수도 줄어들게 되었다. 이것도 간단하지만 조금만 생각을 잘하면 1번 그림에서 검은색 막대가 뭐가 될지 잘 잡을 수 있고, 효율적인 작업이 가능하다.

3. Cursor

어느날 DBA 분께서 느린 쿼리가 있으니 확인을 해달라고 하셨다. 확인을 해보니 데이터 분포를 고려하지 않은 것이 문제였다. 검은색이 전체 각종 알림들 동의 관련 테이블이다. 이 각종 알림 동의에는 나와 상관 없는 다른 동의들이 다 들어있어 테이블의 크기가 매우 크다. 내가 만드는 이벤트는 최근에 만든 것이기 때문에 처음 퀴즈 이벤트 관련 알림 row가 id 1억을 훌쩍 넘어있었다.

이걸 고려하지 않고 id가 0번인 것부터 퀴즈 알림 수신 동의를 하는 1000개를 찾게 했으니 1억이 넘는 데이터를 보느라 쿼리가 느려진거다. 예전 속닥속닥 프로젝트를 하며 페이지네이션에 대해 공부를 한적이 있어 쉽게 커서를 떠올릴 수 있었다.

1. 퀴즈 알림 수신 동의한 첫 id 찾는 쿼리 날리기
2. 여기서 얻은 id를 탐색 시작 id로 전달해서 작업 시작하기

이렇게 개선해서 슬로 쿼리를 없앨 수 있었다.

기타

스케줄 잡을 구성하다보니 크론탭도 얕게 찾아보며 써보았다. 이것도 정규식처럼 필요할때만 얕게 찾아보고 쓸지 따로 학습을 할지는 아직 고민중이다.

아직은 제대로된 스프링 배치가 아니라 스케줄 잡 비슷하게 쓰고 있는 점도 고민이다. 이 부분은 필요를 느끼면 더 학습을 해볼 예정이다.