자정 배치 스케줄러 실행 중 발생하는 캐시 재오염(Stale Data) 방지 및 분산 락 제어

• 분야: MSA, Batch Processing, Cache Consistency (Stale Data), Distributed Lock (ShedLock), Race Condition
• 관련 파일: CatalogVisibilityScheduler.java, ShedLockConfig.java

---

1. 발단: 조회 성능 최적화와 자정 배치 스케줄러 도입

카탈로그 서비스는 커머스 메인 화면의 대규모 조회 트래픽을 감당하기 위해 상품 목록을 Redis에 캐싱(products_cache)하여 제공하고 있었음.
또한 매일 자정(00:00:00), 상품의 노출 상태(isVisible)를 일괄 동기화하는 배치 스케줄러(CatalogVisibilityScheduler)가 구동됨.

초기 설계에서는 DB 업데이트 전 캐시를 초기화하기 위해 @CacheEvict(beforeInvocation = true)를 적용했음.

2. 문제 인식: 시간차 엣지 케이스로 인한 캐시 오염 (Stale Data)

배치 스케줄러가 10만 건 이상의 데이터를 청크 단위로 업데이트하는 데 약 10초가 소요된다고 가정했을 때, "배치가 도는 도중 유저가 접속하면 어떻게 될까?"라는 의문에서 Race Condition을 발견함.

[시나리오 타임라인]

1. [00:00:00] 자정 배치 시작 -> @CacheEvict가 발동되어 products_cache 캐시가 일괄 초기화됨.
2. [00:00:02] 배치가 DB를 10% 정도 업데이트하고 있는 도중, 일반 유저가 메인 화면 상품 목록 조회를 요청함.
3. [00:00:02] 캐시가 비어있으므로(Cache Miss), 애플리케이션은 DB에서 직접 상품을 조회함.
   (문제 발생) 이때 배치가 아직 건드리지 않은 '과거 데이터(Stale Data)'를 조회하여 다시 캐시에 저장해 버림.
4. [00:00:10] 배치가 종료되고 DB 업데이트가 100% 완료됨.

결과: DB에는 최신 상태가 반영되었으나, 캐시에는 배치 도중 유저 조회로 인해 채워진 과거 데이터가 남아있게 됨. 결과적으로 다음 날 배치가 돌기 전까지 DB와 캐시 간의 심각한 데이터 불일치(정합성 파괴)가 지속될 것이 예상되는 상황이었음.

3. 1차 해결: 분산 락(ShedLock) 도입과 AOP 우선순위 제어

캐시 문제를 해결하기 전에, MSA 환경(Scale-out)에서 발생할 수 있는 또 다른 문제를 선제적으로 방어했음. 현재는 인스턴스가 1대이지만, 서버 인스턴스가 3대로 늘어날 경우, 자정에 3대의 서버가 동시에 배치를 실행하여 DB 풀 스캔과 업데이트를 중복으로 치는 문제가 발생함.

이를 방지하기 위해 ShedLock(분산 락)을 도입하여 딱 1대의 서버만 배치를 실행하도록 제어함. 이때, 스프링 AOP의 실행 순서를 정확히 제어하지 않으면 "락 획득 전에 3대가 동시에 캐시부터 지워버리는" 현상이 발생할 수 있으므로, ShedLockConfig의 우선순위(order = 0)를 캐시 삭제보다 높게 설정함.

// [ShedLockConfig.java]
@Configuration
// order = 0 으로 설정하여 @CacheEvict 보다 먼저 분산 락을 획득하도록 강제!
@EnableSchedulerLock(defaultLockAtMostFor = "PT30M", order = 0)
public class ShedLockConfig {
    @Bean
    public LockProvider lockProvider(RedisConnectionFactory connectionFactory) {
        return new RedisLockProvider(connectionFactory, "catalog-service-lock");
    }
}

4. 2차 해결: Double Eviction (try-finally) 패턴 적용

캐시 오염(Stale Data)을 근본적으로 해결하기 위해, 배치가 도는 도중에는 최종 일관성를 허용하되, 배치가 끝나는 시점에 캐시를 명시적으로 한 번 더 초기화(Double Eviction)하는 패턴을 적용했음.

배치 도중 OptimisticLockingFailureException 등의 예외가 발생하여 로직이 중단되더라도 반드시 캐시 세탁이 보장되도록 try-finally 블록을 활용했음.

// [CatalogVisibilityScheduler.java]
@Scheduled(cron = "0 0 0 * * *", zone = "Asia/Seoul")
@SchedulerLock(name = "syncVisibilityAtMidnight", lockAtLeastFor = "PT5M", lockAtMostFor = "PT25M")
@CacheEvict(value = "products_cache", allEntries = true, cacheManager = "catalogCacheManager", beforeInvocation = true)
public void syncVisibilityAtMidnight() {
    log.info("[Catalog Batch] 자정 isVisible 일괄 동기화 스케줄러 시작");
    int totalUpdated = 0;

    try {
        // ... (청크 단위 DB 업데이트 로직 / 낙관적 락 Fallback 처리) ...
        log.info("[Catalog Batch] 총 {}개의 상품 노출 상태(isVisible) 동기화 완료", totalUpdated);

    } finally {
        // 배치 도중 발생한 유저 요청으로 인해 캐시가 과거 데이터로 재오염되었을 가능성을 차단.
        // 메서드 종료 직전, 명시적으로 캐시를 한 번 더 날려주어 최종 정합성 보장.
        Cache cache = catalogCacheManager.getCache("products_cache");
        if (cache != null) {
            cache.clear();
            log.info("[Catalog Batch] 배치 종료 후 products_cache 명시적 초기화 완료 (Stale 데이터 방지)");
        }
    }
}

5. 검증 및 기술적 의사결정

💡 검증 (실제 운영 로그)
테스트 결과, 분산 락에 의해 단 1대의 인스턴스만 배치를 수행했으며, 배치 도중 유도된 유저의 조회 트래픽으로 인한 캐시 오염도 finally 블록의 명시적 초기화를 통해 깔끔하게 지웠음.

[Instance-1] INFO: [Catalog Batch] 자정 isVisible 일괄 동기화 스케줄러 시작
[Instance-2] (ShedLock에 의해 실행 차단됨 - 조용함)
[Instance-1] INFO: [Catalog Batch] 총 10500개의 상품 노출 상태(isVisible) 동기화 완료
[Instance-1] INFO: [Catalog Batch] 배치 종료 후 products_cache 명시적 초기화 완료 (Stale 데이터 방지)

💡 기술적 의사결정 Q&A

Q. try-finally를 이용한 Double Eviction이 가장 올바른 해결책인가?

A. 대안으로 '배치 수행 중 캐시나 DB 테이블에 글로벌 Lock을 걸어 유저 조회를 막는 방법'이 있으나, 이는 서비스 Downtime을 유발하므로 대규모 트래픽 환경에서는 맞지 않다고 생각했음. 배치 수행 시간(N초) 동안의 약간의 지연(Eventual Consistency)은 허용하되, 배치 종료 직후 캐시를 확정적으로 비워주어 최종 정합성을 보장하는 방식이 가장 보편적이고 안전한 정석이라고 판단했음.

Q. ShedLock 도입이 오버스펙은 아닌가? 현재 단일 인스턴스인데?

A. 본 프로젝트는 Eureka, Kafka 등을 활용한 MSA 환경으로 설계되었음. 이는 곧 "트래픽에 따라 언제든 Catalog 서버가 Scale-out 될 수 있음"을 의미함. 단일 인스턴스일 때도 분산 락 비용(Redis I/O 수 ms)은 크지 않다고 생각했고, 미래의 확장을 대비해 스케줄러 동시성 문제를 사전에 차단할 수 있었기에 맞는 선택이었다고 판단함.