Redis write-back 구조에서 스케줄러와 벌크 처리 개념 혼동

문제 상황

리뷰 좋아요 기능에서 DB 부하를 줄이기 위해

Redis에 좋아요 값을 누적한 뒤,

스케줄러를 통해 일정 주기로 DB에 반영하는 write-back 구조를 적용하였다.

 

이 과정에서

Redis에 누적된 데이터를 일정 시간 후 한 번에 DB에 반영하는 구조를 보고

이 방식 자체가 벌트 처리(Bulk Processing)라고 착각하였다.

 

즉,

여러 데이터를 모아서 한 번에 처리한다 = 벌크 처리

라고 이해하고 있었다.

---

헷갈렸던 이유

Redis에 데이터가 누적된 후

스케줄러가 실행되면

그동안 쌓인 데이터가 DB에 반영된다.

 

이 흐름만 보면

• 여러 데이터가 한 번에 처리되는 것처럼 보였고
• 따라서 벌크 처리라고 오해하게 되었다.

하지만 실제 코드를 확인해보니

DB 반영은 다음과 같이 개별 처리 방식으로 이루어지고 있었다.

for (Map.Entry<Object, Object> entry : entries.entrySet()) {
    Review review = reviewRepository.findById(reviewId);
    review.applyLikeDelta(delta);
}

 

즉,

• 데이터는 Redis에 모여 있었지만
• DB에는 여전히 하나씩 조회 + 하나씩 업데이트가 수행되고 있었다.

---

개념 정리

1️⃣ 스케줄러 (write-back 구조)

Redis에 데이터를 누적한 뒤

일정 주기로 DB에 반영하는 방식이다.

• DB 호출을 줄이기 위해 지연 반영
• 트래픽이 많은 환경에서 성능 개선에 효과적

⭐ 언제 DB에 반영할 것인가 (타이밍 전략)

 

2️⃣ 벌크 처리 (Bulk Insert / Update)

여러 데이터를 하나의 쿼리로 한 번에 처리하는 방식이다.

• DB와의 통신 횟수를 줄여 성능을 개선
• 대량 데이터 처리에 유리

⭐ DB를 어떻게 효율적으로 처리할 것인가 (처리 방식)

---

비유로 이해하기

기존 잘못된 이해

• 음식 여러 개를 모아서
• 한 번에 배달하면 벌크라고 생각

실제 개념

현재 코드

• 음식 10개를 모음
• 하지만 10번 나눠서 배달

⭐ DB 호출 10번 발생

벌크 처리

• 음식 10개를 모아서
• 한 번에 배달

⭐ DB 호출 1번

---

핵심 깨달음

데이터를 모아서 처리하는 것과

DB를 한 번에 처리하는 것은 전혀 다른 개념이었다.

• Redis에 데이터를 모으는 → write-back 전략
• DB를 한 번에 처리하는 것 → 벌크 처리

즉,

현재 구조는

• 스케줄러를 통해 지연 반영은 하고 있지만
• DB 처리 방식은 여전히 개별 업데이트 방식이었다.

---

개선 방향

더 효율적인 구조를 위해서는

다음과 같은 방식으로 개선할 수 있다.

Redis 누적 → 스케줄러 실행 → 벌크 업데이트 → DB 반영

 

즉,

• 스케줄러로 타이밍을 제어하고
• 벌크 처리로 DB 호출을 최소화하는 구조

---

정리

• 스케줄러 → DB 반영 시점을 제어하는 전략
• 벌크 처리 → DB 호출을 줄이기 위한 처리 방식

두 개념은 서로 다른 역할을 가지며,

함께 사용하는 것이 가장 효율적인 구조이다.