[Spring Boot] 음식 주문 관리 플랫폼 개발 - Redis와 Scheduler를 활용한 리뷰 평점 구현

📖 목차

 

 

 

---

SpringBoot를 기반으로 AI활용 비즈니스 프로젝트로 '음식 주문 관리 플랫폼'을 개발하게 되었다.

음식점과 리뷰 도메인을 맡아 기능을 구현하게 되었는데,

가게 조회 시 리뷰의 평점과 개수가 함께 조회되어야 하는 요구사항이 있었다.

 

여러 번의 고민을 거쳐 리뷰 평점과 리뷰 개수를 N+1 문제없이 조회 가능하도록 구현하였다.

어떤 문제점이 있었는지와 그 해결방법에 대해 알아보자.

 

 

 

 

 

 

📌  프로젝트 요구사항

  이 프로젝트의 필수 기능 요구사항 중 하나이다. 기능 요구사항을 살펴보면, 가게 목록을 조회 시 평점을 노출해야 한다고 되어있다.

처음에 기능만 생각하고 구현을 하다 보니 가게를 상세 조회하거나 검색해서 가게 목록을 조회할 때, 리뷰 수와 평점을 그때그때 계산하여 보여주도록 로직을 작성했다.

💡 리뷰 및 평점 기능
✔️ 주문을 통해 가게의 리뷰 및 평점을 저장합니다.
✔️ 주문 검색 조회 시 음식점 고윳값을 통해 호출하면 리뷰 리스트를 볼 수 있습니다.
✔️ 평점은 1 - 5점으로 계산합니다.
✔️ 가게 목록을 조회 시 평점을 노출하려면 어떻게 구현해야 할지 고민해 봅니다.
    (가게 목록을 호출 시에 평점을 계산하면 n+1 문제가 발생할 수 있습니다.)

 

@Service
@RequiredArgsConstructor
public class StoreService {

  private final StoreRepository storeRepository;
  private final ReviewRepository reviewRepository;

  @Transactional(readOnly = true)
  public StoreDetailResponseDto getStore(UUID storeId) {
    Store store = findStore(storeId);

    Integer reviewCount = reviewRepository.countByStoreId(storeId);
    BigDecimal ratingAvg = reviewRepository.calculateAverageRatingByStoreId(storeId);

    return new StoreDetailResponseDto(
        storeId,
        String.valueOf(store.getCategory()),
        store.getName(),
        store.getContent(),
        store.getAddress(),
        store.getPhone(),
        ratingAvg,
        reviewCount
    );
  }
}

 

public interface ReviewRepository extends JpaRepository<Review, UUID> {

  @Query("SELECT COUNT(r) FROM Review r WHERE r.store.id = :storeId AND r.deletedAt IS NULL")
  Integer countByStoreId(UUID storeId);

  @Query("SELECT AVG(r.star) FROM Review r WHERE r.store.id = :storeId AND r.deletedAt IS NULL")
  BigDecimal calculateAverageRatingByStoreId(UUID storeId);
}

 

 

 

가게 조회 시에 계산이 함께 이루어지도록 작성했고, 그 결과로 가게를 한 번 조회할 때마다 이렇게 총 3번의 쿼리가 생성되어 버렸다.

<store select 쿼리 생성>

<리뷰 평점 계산을 위한 쿼리 생성>

<리뷰 수 계산을 위한 쿼리 생성>

 

 

 

  설계단계에서 캐싱까지는 사용하지 않을 생각이었고, 우려하던 N+1문제는 아니지만 결과적으로는 성능에 안 좋은 영향을 끼칠 수 있다고 판단되어 로직을 수정하게 되었다. 

 

 

 

 

 

---

 

 

 

 

 

📌  리뷰 데이터를 반영하는 방식

  우선 '리뷰가 생성/수정/삭제될 때마다 실시간으로 평균 평점과 개수를 업데이트할 것인가?'라는 고민에 대한 답을 순차적으로 찾아보도록 하자. 리뷰의 평점과 개수를 반영하는 방식은 두 가지로 나눴다. 이 두 가지 방법 중에 어떤 방식이 더 나은지 장단점을 비교해 보자.

 

1. DB에 저장하지 않고 가게 조회 시, 리뷰를 동적으로 계산하여 매번 최신 데이터를 유지한다.
2. DB에 저장하여 조회를 해오며, 리뷰 변경 시에만 업데이트를 한다.

구분	동적 계산	DB 저장 방식
리뷰 갯수 및 평점 저장 위치	매 요청마다 동적으로 계산	Store 엔티티의 reviewCount와 ratingAvg 필드에 저장
데이터 정합성 유지	항상 최신 상태 유지됨	리뷰 추가/수정/삭제 시 수동 업데이트 필요
성능	매번 쿼리를 실행해야 하므로 성능 저하 가능	조회 시 바로 가져올 수 있어 성능 향상
유지보수성	서비스 로직이 복잡할 수 있음	리뷰 변경 시에만 업데이트 하면 되므로 단순
트랜잭션 처리	별도 관리 필요 없음	리뷰 변경 시 트랜잭션 내에서 업데이트 필요

 

 

  두 가지 방식의 장단점 비교를 통해 매번 즉시 계산을 하게 되면 그때마다 쿼리가 실행되고, 데이터가 많아질수록 성능에 영향을 줄 것이라고 판단하여 DB에 저장하는 방식을 선택했다.

 

그다음으로 생각한 부분은 리뷰 데이터의 업데이트 시점이었다. 데이터가 많아질수록 실시간 업데이트는 부담이 될 수 있다. 그렇다면 실시간이 아닌 일정 주기마다 한 번에 업데이트를 한다면 성능적으로 이점이 있지 않을까?

 

 

 

 

 

💡 변경된 데이터를 일정 주기로 업데이트를 해볼까?

  다음과 같은 고민을 해본 결과, 실시간 업데이트를 하는 것은 데이터가 많아질수록 부담이 될 수 있기 때문에 일정 주기마다 업데이트를 할 수 있도록 스프링 부트에서 지원하는 스케줄러의 사용을 고려하게 되었다.

 

 

 

 

 

 

 

📌  리뷰 데이터의 변경 감지

  스케줄러의 도입을 고려하면서 어떤 리뷰가 변경되었는지 추적하는 방법이 필요했다. 리뷰 데이터의 변경 감지는 어떻게 이루어지는 것이 좋을까? 우선, 리뷰의 총 개수와 평점을 계산하려면 아래의 변경 사항을 확인하여 반영해야 한다. 

✔️ 리뷰가 생성되었을 경우
→ 총 갯수 증가, 평균 평점 업데이트 필요
✔️ 리뷰가 수정되었을 경우
→ 평점이 변경될 수 있으므로 평균 평점 업데이트 필요
✔️ 리뷰가 삭제되었을 경우
→ 총 갯수 감소, 평균 평점 업데이트 필요

즉, 생성/수정/삭제된 리뷰를 모두 조회해서 스토어별로 통계를 다시 계산해야 한다.

 

 

 

💡 이때, 모든 가게를 조회해서 각 가게의 리뷰 수와 평점을 다시 계산하고 업데이트한다면 어떨까?

  DB에서 createdAt, updateAt, deletedAt을 직접 조회하는 경우, 데이터가 많아질수록 OR 조건 때문에 인덱스 활용이 어려워지고 성능 저하의 가능성이 있다. 또한, 리뷰 테이블 전체를 조회할 가능성이 높기 때문에 Full Table Scan의 위험성도 있다.

이런 문제점을 해결하려면 어떤 방식을 택해야 할까 고민하던 중에
'리뷰가 변경된 해당 가게의 ID만을 사용해서 그 가게에 대해서만 통계를 업데이트하면 어떨까?'라는 생각을 하게 되었다.

 

 

 

 

 

 

 

📌  변경된 가게의 ID를 기록하는 방식

  그렇다면 '리뷰가 변경된 가게의 ID는 어디에 기록하는 게 좋을까? 로그를 남길 수 있도록 테이블을 하나 더 생성해야 할까?' 어떤 방법이 효율적 일지 고민하다가 불필요하게 데이터가 쌓일 것을 고려해서 인메모리 데이터베이스인 Redis를 사용해 보면 어떨까 생각하게 되었다. 마침 현재 프로젝트에서 Redis를 활용한 AccessToken과 RefreshToken으로 로그아웃 기능을 구현하고 있었고, Redis의 Set을 사용해 보기로 결정했다.

 

Redis의 Set을 사용한다면 자료구조 특성의 이점으로 인해 빠른 조회가 가능하고, 중복을 방지할 수 있다. TTL도 설정할 수 있고, 리뷰 통계를 업데이트 한 뒤, 해당 리스트를 비울 수도 있다.

 

 

 

 

 

✔️ 이렇게 최종적으로 'Redis Set + Scheduler'의 조합으로 구현해 보기로 결정했다.
해당 로직에 대해 리팩토링을 진행해 보자.

 

 

 

 

 

 

 

---

 

 

 

 

 

 

 

  조회를 호출 시 매번 계산이 이루어지는 게 아닌 리뷰 데이터의 변경이 있을 경우에만 계산을 하고 최신데이터를 반영할 수 있도록, 변경 사항이 없다면 select 쿼리만 생성될 수 있도록 개선을 해보자.

// 기존 서비스 로직
@Service
@RequiredArgsConstructor
public class StoreService {

  private final StoreRepository storeRepository;
  private final ReviewRepository reviewRepository;

  @Transactional(readOnly = true)
  public StoreDetailResponseDto getStore(UUID storeId) {
    Store store = findStore(storeId);

    Integer reviewCount = reviewRepository.countByStoreId(storeId);
    BigDecimal ratingAvg = reviewRepository.calculateAverageRatingByStoreId(storeId);

    return new StoreDetailResponseDto(
        storeId,
        String.valueOf(store.getCategory()),
        store.getName(),
        store.getContent(),
        store.getAddress(),
        store.getPhone(),
        ratingAvg,
        reviewCount
    );
  }
}

 

// 수정 후 서비스 로직
@Service
@RequiredArgsConstructor
public class StoreService {

  private final StoreRepository storeRepository;

  @Transactional(readOnly = true)
  public StoreDetailResponseDto getStore(UUID storeId) {
    Store store = findStore(storeId);

    return new StoreDetailResponseDto(
        storeId,
        String.valueOf(store.getCategory()),
        store.getName(),
        store.getContent(),
        store.getAddress(),
        store.getPhone(),
        store.getRatingAvg(), // DB에 저장된 리뷰 평점
        store.getReviewCount() // DB에 저장된 리뷰 갯수
    );
  }
}

 

 

  기존에 작성했던 로직에서는 StoreService에서 가게를 조회할 때마다 리뷰 평점과 개수를 계산했다. DB에 저장된 리뷰 평점과 개수를 조회해 오도록 수정해 준다. 리뷰 통계에 관련해서는 ReviewService에서 처리해 주도록 수정할 것이다.

 

 

 

  해당 로직에서는 리뷰가 변경될 때마다 어떤 가게에서 리뷰가 변경되었는지 추적하고, 해당 가게의 ID만을 사용하여 그 가게에 대해서만 통계를 업데이트하도록 구현해 보았다. 리뷰가 변경될 때마다 변경된 가게의 ID만을 기록해 두고, 스케줄러는 그 기록된 가게들만 업데이트하도록 처리한다. 리뷰가 생성 수정 삭제될 때마다 trackStoreId 메서드를 호출하여 해당 가게의 storeId를 기록한다.

@Service
@RequiredArgsConstructor
public class ReviewService {

  private final ReviewRepository reviewRepository;
  private final OrderRepository orderRepository;
  private final StoreRepository storeRepository;
  private final ReviewStatisticsScheduler reviewStatisticsScheduler;

  @Transactional(readOnly = true)
  public Page<StoreReviewsResponseDto> getReviewsByStore(
      UUID storeId,
      int page,
      int size,
      String sortedBy,
      Direction direction
  ) {
    Pageable pageable = PageRequest.of(page, size, direction, sortedBy);
    Page<Review> reviewPage = reviewRepository.findAllByStoreId(storeId, pageable);

    Store store = findStore(storeId);

    // DB에 저장된 정보를 가지고 온다.
    Integer reviewCount = store.getReviewCount();
    BigDecimal ratingAvg = store.getRatingAvg();

    return reviewPage.map(review -> new StoreReviewsResponseDto(
        review.getId(), review.getUser().getId(),
        review.getOrder().getId(), review.getStar(), review.getContent(), ratingAvg, reviewCount));
  }

  @Transactional
  public ReviewResponseDto createReview(ReviewRequestDto requestDto, User user) {
    validateCustomer(user);
    Order order = findOrder(requestDto);

    validateOrderUser(user, order);

    // 3일 제한 검증
    validateReviewPeriod(order);

    // 중복 리뷰 체크
    validateReviewDuplicate(requestDto);

    Review review = reviewRepository.save(new Review(requestDto, user, order.getStore(), order));

    // 리뷰 생성 시 해당 가게 ID 추적
    reviewStatisticsScheduler.trackStoreId(review.getStore().getId());

    return new ReviewResponseDto(review);
  }
}

 

 

 

 

  Redis를 사용하기 위해 의존성과 Config class를 추가해 준 뒤 스케줄러 클래스를 작성해 준다. 그리고 실제 스케줄링 작업을 할 클래스를 만들어준다. 해당 클래스는 @Component를 통해 스프링 빈에 등록된 클래스여야 한다.

@Scheduled 어노테이션을 사용하기 위해 Application Class에 @EnableScheduling을 추가해 준다.

@SpringBootApplication
@EnableScheduling
public class DeliveryApplication {

  public static void main(String[] args) {
    SpringApplication.run(DeliveryApplication.class, args);
  }
}

 

 

  스케줄러 메서드는 void 타입이어야 하며, 해당 메서드는 매개변수 사용이 불가하다. Cron 표현식으로 일정 주기를 지정할 수 있다. 스케줄러에 관한 자세한 내용은 여러 포스팅을 참고하길 바란다. 

@Component
@RequiredArgsConstructor
@Slf4j
public class ReviewStatisticsScheduler {

  private final ReviewRepository reviewRepository;
  private final StoreRepository storeRepository;
  private final RedisTemplate<String, Object> redisTemplate;

  // Redis key 설정
  private static final String UPDATED_STORE_ID_KEY = "review:updated_storeId";
  // TTL 1시간 설정
  private static final long TTL_IN_SECONDS = 3600;

  // 리뷰 변경 시 호출하여 변경된 가게를 추적
  public void trackStoreId(UUID storeId) {
    log.info("trackStoreId 호출됨: {}", storeId);
    redisTemplate.opsForSet().add(UPDATED_STORE_ID_KEY, storeId.toString());
    log.info("Redis에 저장 요청: {}", storeId);
    redisTemplate.expire(UPDATED_STORE_ID_KEY, TTL_IN_SECONDS, TimeUnit.SECONDS);
  }

  // 스케줄러에서 변경된 가게만 통계 업데이트
  @Scheduled(cron = "0 */30 * * * *")  // 30분 간격으로 업데이트
  public void updateReviewStatistics() {
    log.info("리뷰 통계 업데이트 시작");

    Optional<Set<Object>> updatedStoreIdsOptional = Optional.ofNullable(
        redisTemplate.opsForSet().members(UPDATED_STORE_ID_KEY));

    updatedStoreIdsOptional.ifPresent(updatedStoreIds -> {
      if (!updatedStoreIds.isEmpty()) {
        for (Object storeIdObj : updatedStoreIds) {
          UUID storeId = UUID.fromString(storeIdObj.toString());

          Integer reviewCount = reviewRepository.countByStoreId(storeId);
          BigDecimal ratingAvg = reviewRepository.calculateAverageRatingByStoreId(storeId);

          storeRepository.updateReviewStatistics(storeId, reviewCount, ratingAvg);
          log.info("가게 {} 통계 업데이트 완료", storeId);
        }
        // 업데이트 후 추적 리스트 비우기
        log.info("삭제 전 키 존재 여부: {}", redisTemplate.hasKey(UPDATED_STORE_ID_KEY));
        redisTemplate.delete(UPDATED_STORE_ID_KEY);
        log.info("삭제 후 키 존재 여부: {}", redisTemplate.hasKey(UPDATED_STORE_ID_KEY));
      } else {
        log.info("변경된 가게가 없습니다.");
      }
    });
  }
}

 

 

 

  ReviewRepository에서는 리뷰의 개수와 평점을 계산하는 쿼리를 @Query 어노테이션을 통해 직접 작성해 준다. 

public interface ReviewRepository extends JpaRepository<Review, UUID> {

  @Query("SELECT r FROM Review r WHERE r.store.id = :storeId AND r.deletedAt IS NULL")
  Page<Review> findAllByStoreId(UUID storeId, Pageable pageable);

  @Query("SELECT COUNT(r) FROM Review r WHERE r.store.id = :storeId AND r.deletedAt IS NULL")
  Integer countByStoreId(UUID storeId);

  @Query("SELECT AVG(r.star) FROM Review r WHERE r.store.id = :storeId AND r.deletedAt IS NULL")
  BigDecimal calculateAverageRatingByStoreId(UUID storeId);

  boolean existsByOrderId(UUID orderId);
}

 

 

 

  StoreRepository에서는 @Modifying 어노테이션을 사용하여 불필요한 조회 쿼리가 발생하지 않고, 바로 업데이트할 수 있도록 쿼리를 작성해 준다. 업데이트 항목이 없을 경우에는 쿼리가 생성되지 않는다.

@Repository
public interface StoreRepository extends JpaRepository<Store, UUID> {

  @Query("SELECT s FROM Store s WHERE s.name LIKE %:keyword% AND s.deletedAt IS NULL ")
  Page<Store> findAllByName(String keyword, Pageable pageable);

  @Query("SELECT s FROM Store s WHERE s.category = :category AND s.deletedAt IS NULL")
  Page<Store> findAllByCategory(@Param("category") StoreCategory storeCategory, Pageable pageable);

  @Transactional
  @Modifying
  @Query("UPDATE Store s SET s.reviewCount = :reviewCount, s.ratingAvg = :ratingAvg WHERE s.id = :storeId")
  void updateReviewStatistics(UUID storeId, Integer reviewCount, BigDecimal ratingAvg);
}

 

 

 

  위 로직에서는 스케줄러가 동작하는 시간을 30분 간격으로 설정해 두었으나, 기능이 제대로 동작하는지 확인하기 위해 더 짧은 간격으로 수정하여 테스트해 보았다. 테스트 결과는 다음과 같다.

<리뷰 변경이 없을 경우>

<리뷰 변경이 감지되었을 경우>

<업데이트 시작>

<키가 Redis에 저장되었다가 삭제된다.>

 

 

 

  리뷰를 작성하거나 삭제했을 때, 변경된 데이터를 감지하여 통계를 업데이트하는 것을 확인할 수 있다. 또한, 가게를 조회했을 경우에 업데이트된 통계를 select 쿼리만으로 조회해 오는 것을 확인할 수 있다. 평점 및 개수도 제대로 계산되는 것을 확인할 수 있다.

<가게 조회 결과>

 

<가게 조회시 생성되는 쿼리>

 

 

 

<로직의 전체적인 흐름>

 

 

 

  이렇게 리뷰가 변경될 때만 해당 가게를 추적하여 스케줄러가 해당 가게들만 업데이트하도록 리팩토링을 해보았다. 업데이트할 필요가 없는 가게는 조회하지 않기 때문에 훨씬 효율적으로 관리가 가능하다. 기존에 3번의 쿼리가 생성되었던 것을 생각해 보면 불필요한 조회 없이 성능적으로 나아진 것을 확인할 수 있다.

 

 

 

 

 

 

 

이번 프로젝트에서는 Redis의 Set과 스케줄러를 활용해 성능 개선을 해보았다.

다음 프로젝트에서는 메시지 큐를 활용해 볼 수 있도록 해야겠다.

 

 

 

 

 

 

 

 

 

📌  참고

 

[Spring][쇼핑몰 프로젝트][50] 상품 테이블 평균 평점 반영