Batch: 🐛 정기 푸시 알림 배치 쿼리 픽스 & ItemReader 기능 수정

[psychology50]

작업 이유

• Batch: ✨ 정기 지출 등록 알림 배치 & 스케줄러 #124 Batch: ✏️ 매일 정기 푸시 알림 배치 성능 개선 #137 에서 작업한 쿼리 오류 수정
• QuerydslNoOffsetItemReader 기능 및 Builder 추가

작업 사항

😩 기존 방식의 문제점

자세한 이유는 블로그 가장 하단에 추가해두었습니다.

SELECT u.id, u.name, d.token 
FROM device_token d
INNER JOIN user u ON d.user_id = u.id AND u.deleted_at IS NULL
WHERE d.activated = true AND u.account_book_notify=true AND u.id > currentId AND u.id <= lastId
ORDER BY u.id
LIMIT 0, chunkSize;

-> Limit: 1000 row(s)  (cost=2532.33 rows=274) (actual time=0.077..44.888 rows=1000 loops=1)
    -> Nested loop inner join  (cost=2532.33 rows=274) (actual time=0.076..44.758 rows=1000 loops=1)
        -> Filter: ((u.account_book_notify = true) and (u.id > 0) and (u.id <= 5000) and (u.deleted_at is null))  (cost=1932.82 rows=479) (actual time=0.050..2.891 rows=2590 loops=1)
            -> Index range scan on u using PRIMARY  (cost=1932.82 rows=9582) (actual time=0.048..2.023 rows=2590 loops=1)
        -> Filter: (d.activated = true)  (cost=1.14 rows=1) (actual time=0.015..0.016 rows=0 loops=2590)
            -> Index lookup on d using FKo3afeawl2mah4kjjvx2chwlbu (user_id=u.id)  (cost=1.14 rows=1) (actual time=0.015..0.016 rows=0 loops=2590)

• 테이블을 읽는 포커싱이 device_token 테이블이 아니라 user에 맞춰져 있음.
• 사용자마다 푸시 알림 데이터가 저장되는 것은 보장하지만, 모든 device_token에 대해 푸시 알림을 보낸다는 것은 보장할 수 없음.

• currentId와 lastId를 찾기 위한 쿼리에 불필요한 JOIN이 포함됨.
• 이 방식대로라면 JOIN이 먼저 수행이 될 가능성이 높은데, JOIN이 된 테이블은 인덱스를 사용할 수 없으며, 더 이상 user.id가 pk도 아니기 때문에 사용해서는 안 됨.
• 또한 user.id를 기준으로 탐색하는 것은 위에서 언급한 대로 문제의 소지가 있기 때문에 deviceToken.id를 기반으로 탐색할 필요가 있음.

1️⃣ Query 수정

SELECT u.id, u.name, d.id, d.token 
FROM device_token d
INNER JOIN user u ON d.user_id = u.id AND u.deleted_at IS NULL
WHERE d.activated = true AND u.account_book_notify=true AND d.id > currentId AND d.id <= lastId
ORDER BY d.id
LIMIT 0, chunkSize;

-> Limit: 1000 row(s) (cost=12856797.61 rows=1000) (actual time=0.244..167.040 rows=1000 loops=1)
     -> Nested loop inner join (cost=12856797.61 rows=474067) (actual time=0.243..166.889 rows=1000 loops=1)
         -> Filter: ((d.activated = true) and (d.id > 76258) and (d.id <= 38150113) and (d.user_id is not null)) (cost=3823747.36 rows=9481344) (actual time=0.076..2.493 rows=1000 loops=1)
             -> Index range scan on d using PRIMARY (cost=3823747.36 rows=18962689) (actual time=0.072..1.810 rows=1000 loops=1)
         -> Filter: ((u.account_book_notify = true) and (u.deleted_at is null)) (cost=0.85 rows=0) (actual time=0.164..0.164 rows=1 loops=1000)
             -> Single-row index lookup on u using PRIMARY (id=d.user_id) (cost=0.85 rows=1) (actual time=0.163..0.163 rows=1 loops=1000)

• device_token 테이블 스캔
  • Primary 인덱스로 range scan
  • 예상 rows: 18,962,689, 실제 rows: 1,000 (LIMIT 조건)
  • 실행 시간: 약 1.810ms
• user 테이블 조회
  • 각 device_token 행에 대해 primary 인덱스로 single-row lookup
  • 1,000번의 루프를 돌며 각각 약 0.163ms 소요
• 전체 쿼리 성능
  • 총 실행 시간: 약 167.040ms
  • 반환된 행 수: 1,000

current id 업데이트를 위한 d.id를 추가적으로 가져옴.

2️⃣ idSelectQuery를 추가할 수 있도록 정의

public class QuerydslNoOffsetPagingItemReader<T> extends QuerydslPagingItemReader<T> {
    private QuerydslNoOffsetOptions<T> options;
    private Function<JPAQueryFactory, JPAQuery<T>> idSelectQuery;

    ...

    public QuerydslNoOffsetPagingItemReader(EntityManagerFactory entityManagerFactory,
                                            int pageSize,
                                            QuerydslNoOffsetOptions<T> options,
                                            Function<JPAQueryFactory, JPAQuery<T>> queryFunction,
                                            Function<JPAQueryFactory, JPAQuery<T>> idSelectQuery) {
        this(entityManagerFactory, pageSize, options, queryFunction);
        this.idSelectQuery = idSelectQuery;
    }

    ...

    @Override
    protected JPAQuery<T> createQuery() {
        JPAQueryFactory queryFactory = new JPAQueryFactory(entityManager);
        JPAQuery<T> query = queryFunction.apply(queryFactory);
        options.initKeys((idSelectQuery != null) ? idSelectQuery.apply(queryFactory) : query, getPage()); // 제일 첫번째 페이징시 시작해야할 ID 찾기

        return options.createQuery(query, getPage());
    }

• 사용자는 idSelectQuery 필터를 추가하면, 탐색에 사용할 쿼리와 아이디 범위 선택에 사용할 쿼리를 분리할 수 있음.

3️⃣ Step Builder 패턴의 QuerydslNoOffsetPagingItemReaderBuilder 추가

@Slf4j
@Component
@RequiredArgsConstructor
public class ActiveDeviceTokenReader {
    private final EntityManagerFactory emf;

    private final QUser user = QUser.user;
    private final QDeviceToken deviceToken = QDeviceToken.deviceToken;

    @Bean
    @StepScope
    public QuerydslNoOffsetPagingItemReader<DeviceTokenOwner> querydslNoOffsetPagingItemReader() {
        QuerydslNoOffsetOptions<DeviceTokenOwner> options = QuerydslNoOffsetNumberOptions.of(deviceToken.id, Expression.ASC, "deviceTokenId");

        return QuerydslNoOffsetPagingItemReaderBuilder.<DeviceTokenOwner>builder()
                .entityManagerFactory(emf)
                .pageSize(1000)
                .options(options)
                .queryFunction(queryFactory -> queryFactory
                        .select(createConstructorExpression())
                        .from(deviceToken)
                        .innerJoin(user).on(deviceToken.user.id.eq(user.id))
                        .where(deviceToken.activated.isTrue().and(user.notifySetting.accountBookNotify.isTrue()))
                )
                .idSelectQuery(queryFactory -> queryFactory.select(createConstructorExpression()).from(deviceToken))
                .build();
    }

    private ConstructorExpression<DeviceTokenOwner> createConstructorExpression() {
        return Projections.constructor(
                DeviceTokenOwner.class,
                user.id,
                deviceToken.id,
                user.name,
                deviceToken.token
        );
    }
}

• Builder 변형 패턴인 Step Builder 패턴을 사용함.
  • 메서드 체이닝을 통해 fluent API 스타일을 유지
• idSelectQuery는 선택적으로 사용할 수 있지만, 그 외 모든 속성은 "순차적"으로 "필수" 입력하도록 강제
• 타입 안전성, 불변성, 확장성 모두 고려하여 작성함.

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

• 버그를 수정해서 정상 동작하는 대신 처리 속도가 느려졌습니다 ㅜ
  • 데이터 천만 개 기준 30min 정도 걸리는데, 현재 고려할 필요 없는 경우라 판단하고 처리 안 했습니다.

발견한 이슈

• Job이 하나의 chunk를 처리하는데 약 180ms 소요.
  • device token이 100,000개면 chunk size가 1,000이므로 이론 상 180,00ms (=3min) 소요 (실제: 42,895ms = 0.7min)
• Device Token 개수에 배치의 실행 시간이 결정된다는 점을 고려하면 해결 방법은 아래 두 가지로 귀결
  • JOIN을 제거하고, chunk size를 키워서 개선 (join을 제거하면 이론 상 reader를 162ms to 0.7ms까지 감소시킬 수 있음.)
  • 데이터베이스 파티셔닝
• 하지만 현재 고려할 필요가 없을 정도로 Batch의 성능은 준수한 상태. device token 5,000,000개 까진 3min 내에 수행 가능함. 따라서 이 이상은 오버 엔지니어링이라 판단하여 작업 중단한 상태