예약내역 페이징 조회 기능 성능 최적화 (totalCount in Redis)

1. 성능 최적화 계기

현재 관리자 페이지에서 예약 내역을 페이징 처리하여 조회할 수 있는 기능이 있다.
limit는 20으로 한 페이지당 20개의 예약 컨텐츠를 보여주고 있다.

전체 예약 데이터는 354,200개인 상황이고 해당 API의 성능이 평균적으로 1.74초의 시간이 걸렸고 최대 1.99초까지 걸림으로써 성능이 좋지 못했다. 해당 성능을 최적화할 수 있는 방법을 모색하기 시작했다. 

 

미리 말하자면, 평균 56.2%의 성능향상을 맛보게 되었다!

2. 반복되는 Count Query를 개선해보자!

해당 부분에서 성능을 최적화할 수 있는 부분으로 가장 눈에 띈것은 매번 반복되는 전체 데이터의 수를 측정하는 Count Query였다.
"굳이 Count Query가 페이지마다 매번 반복될 필요가 있을까?" 생각했고 아래와 같이 정리하게 되었다.

• 한번 조회 요청이 들어왔을 때 totalCount를 Redis 캐시에 저장해두었다가, 예약이 새로 들어오기전에는 캐시에서 totalCount를 꺼내서 사용하는 방식으로 진행하면 된다.
• 만약, 새로운 예약이 발생하면 캐시에 있는 totalCount의 데이터를 삭제하여 정합성이 맞지 않을 수 있는 문제도 해결할 수 있다.

우선 코드를 보자!

public Page<SearchReservationByPagingRes> findAllByConditionAndPageable(ReservationSearchCondition condition, Pageable pageable) {
        List<SearchReservationByPagingRes> content = queryFactory
                .select(xxx)
                .from(reservation)
		... join
                ... where
                .orderBy(reservation.startAt.desc())
                .offset(pageable.getOffset())
                .limit(pageable.getPageSize())
                .fetch();

        JPAQuery<Long> countQuery = queryFactory
                .select(reservation.count())
                .from(reservation)
              	... join
                ... where 

        return PageableExecutionUtils.getPage(content, pageable, countQuery::fetchOne);
    }

기존에는 findAllByConditionAndPageable() 메서드를 호출하면 무조건 검색조건에 맞는 👎🏻contents를 조회하는 쿼리와 전체 데이터 개수를 조회하는 쿼리가 세트로 발생하는 문제가 있었다.

 

3. 해결 과정

(1) 우선, 아래와 같이 countQuery를 따로 분리하였다.

 

(2) 다음으로 Look-Aside 전략을 이용하여 예약 내역 페이징 조회 서비스 계층에서 아래와 같이 Redis 캐시에 totalCount 값이 있으면 캐시에서 읽어오고, 만약 totalCount가 없어서 Cache Miss가 발생한다면 위의 countQuery를 실행하여 RDB에서 값을 읽어와서 캐시에도 저장해주는 전략을 사용한다.
(여기서는 동적 검색 조건이 포함된 기능이어서 키 값이 아래와 같이 구성된 것입니다!)

 

(3) 이제 Repository의 페이징 쿼리 메서드의 인자로 totalCount를 넘겨주어서 Page 인터페이스의 구현체인 PageImpl을 생성하는데 사용한다.

public Page<SearchReservationByPagingRes> findAllByConditionAndPageable(ReservationSearchCondition condition, Pageable pageable, Long count) {
	.... 컨텐츠 조회 쿼리
		
        return new PageImpl<>(content, pageable, count);
    }

 

(4) 예약이 발생하면 캐시에 저장된 데이터를 삭제해주는 작업만 추가하면 끝이다.

 

4. 성능을 비교해보자

우선 한번 실행해봤는데 위와 같이 실행 시간이 1173ms로 대폭 감소한 것을 볼 수 있었다.

한번으로는 부족하다. 여러번 더 측정해보고 비교해보았다.

전체 예약 데이터는 354,200개, limit는 20이다.

빨간선은 totalCount를 캐싱하지 않았을 때, 파란선은 totalCount를 캐싱한 경우를 나타낸다.

각 10회씩 반복해보았을때,

• 평균 비교 : 56.2% 성능향상
• Redis O의 최솟값과 Redis X의 최댓값 비교 : 105% 성능향상
• 서로 최대값끼리 비교 : 64.5% 성능향상

이렇게 성능이 향상된 것을 경험할 수 있었다.

 

5. 동적 쿼리로 필터링 조건을 추가

하지만, 그래도 평균적으로 1113.6ms 가 소모 된다.
결코 짧은 시간이 아니기에 관리자가 느끼는 딜레이를 더 줄이기 위해 편법?은 아니지만 필터링 조건들을 여러개 더 추가하였다. 

위와 같이 관리자 페이지에서는 기간별로, 회원의 이름, 아이디별로, 회의실 이름별로, 예약 상태별로 검색할 수 있는 조건을 추가하였다.
Querydsl을 사용하여 해당 조건을 동적으로 사용할 수 있게 구현함으로써 더 유연하게 구현하였다.

그리고 해당 조건에 대해서 인덱스를 걸 수 있는 부분이 있다면 카디널리티, 선택도, 활용도, 수정빈도를 고려해서
추가하면 더 좋은 성능을 얻을 수 있다.

실제로, Member 테이블의 name(회원이름) 컬럼에 인덱싱하여
회원이름을 조건으로 관리자의 예약 내역 조회 기능의 실행 시간은 563ms -> 78ms로 줄어들게 되었다.