[Spring Cache] LoadingCache와 캐시 스탬피드

캐시 스탬피드란

인기 게시글 목록을 캐시하고 있다고 하자. TTL이 만료되는 순간, 100개의 요청이 동시에 들어온다. 캐시가 없으니 100개 요청이 전부 DB로 동일한 쿼리를 날린다.

TTL 만료 → 캐시 미스
    → 요청 1: DB 조회 (SELECT ...)
    → 요청 2: DB 조회 (SELECT ...)  ← 같은 쿼리!
    → 요청 3: DB 조회 (SELECT ...)  ← 같은 쿼리!
    → ...
    → 요청 100: DB 조회 (SELECT ...)

이것이 캐시 스탬피드 (Cache Stampede)다. "Thundering Herd"라고도 부른다. 캐시가 만료된 순간 대량의 동일 요청이 DB를 동시에 강타하는 현상이다.

평소에 캐시가 잘 동작하다가, TTL이 끊기는 순간 DB에 순간적으로 부하가 폭증한다. 트래픽이 많은 서비스에서는 이 순간 DB가 과부하로 응답 불능에 빠질 수 있다.

일반 캐시의 문제

@Cacheable의 기본 동작은 캐시 스탬피드에 취약하다. TTL이 만료되는 순간, 대기하고 있던 모든 요청이 동시에 캐시 미스를 만나서 DB로 직행한다.

조율 장치가 없다. 100개 요청이 오면 DB 쿼리가 100번 날아간다. 분홍 영역에서 보이듯 전원이 캐시 미스를 맞고, 그대로 DB로 직행한다. DB 응답이 느릴수록 대기 요청이 더 쌓이고, 더 많은 쿼리가 중복 실행된다.

LoadingCache의 해결법

Caffeine의 LoadingCache는 이 문제를 해결한다. 동일 키에 대한 첫 번째 요청만 DB를 조회하고, 나머지는 그 결과를 기다린다.

LoadingCache 내부에서 같은 키에 대한 동시 요청을 하나로 병합한다. 초록 영역에서 보이듯 첫 번째 요청만 로딩 함수를 실행하고 나머지는 완료될 때까지 블로킹된다. 결과가 돌아오면 파란 영역처럼 대기 중이던 요청 전부에 결과를 공유한다. DB 조회가 1번으로 줄어든다.

LoadingCache 설정

Spring Cache 추상화(@Cacheable)로는 LoadingCache를 직접 설정하기 어렵다. Caffeine API를 직접 사용해서 Java Config로 설정해야 한다.

@Configuration
@EnableCaching
public class CacheConfig {

    @Bean
    public CacheManager cacheManager(PostRepository postRepository) {
        SimpleCacheManager cacheManager = new SimpleCacheManager();
        cacheManager.setCaches(List.of(
            buildLoadingCache("popularPosts", 1, 300, key ->
                postRepository.findTop10ByOrderByViewCountDesc()
            ),
            buildSimpleCache("users", 200, 600),
            buildSimpleCache("notifications", 100, 60)
        ));
        return cacheManager;
    }

    private CaffeineCache buildLoadingCache(String name, int maxSize,
                                             int ttlSeconds, Function<Object, Object> loader) {
        return new CaffeineCache(name,
            Caffeine.newBuilder()
                .maximumSize(maxSize)
                .expireAfterWrite(ttlSeconds, TimeUnit.SECONDS)
                .recordStats()
                .build(loader::apply)
        );
    }

    private CaffeineCache buildSimpleCache(String name, int maxSize, int ttlSeconds) {
        return new CaffeineCache(name,
            Caffeine.newBuilder()
                .maximumSize(maxSize)
                .expireAfterWrite(ttlSeconds, TimeUnit.SECONDS)
                .recordStats()
                .build()
        );
    }
}

Caffeine.newBuilder().build(loader::apply)의 loader가 핵심이다. 캐시 미스 시 이 함수가 호출되어 값을 로딩한다. 동일 키에 대한 동시 요청은 이 함수를 한 번만 실행하고 결과를 공유한다.

refreshAfterWrite

TTL이 만료된 순간 캐시가 비어서 스탬피드가 발생한다. refreshAfterWrite는 다른 접근을 취한다. TTL이 지나면 캐시를 비우지 않고, 백그라운드에서 값을 갱신한다. 갱신 중에도 기존 값을 계속 반환한다.

Caffeine.newBuilder()
    .maximumSize(1)
    .refreshAfterWrite(300, TimeUnit.SECONDS)
    .expireAfterWrite(600, TimeUnit.SECONDS)
    .build(key -> postRepository.findTop10ByOrderByViewCountDesc());

캐시 항목이 시간에 따라 어떻게 동작하는지를 타임라인으로 보면 이렇다.

정상 갱신 흐름에서 보이듯, 5분이 지나도 캐시를 비우지 않고 기존 값을 반환하면서 백그라운드에서 비동기 갱신을 시작한다. 사용자는 응답 지연을 전혀 경험하지 않는다. 예외 방어 구간의 expireAfterWrite(10분)는 안전장치다. 정상적으로 갱신되고 있다면 아무 일도 일어나지 않지만, DB 장애 등으로 갱신이 계속 실패하면 10분 시점에 캐시를 제거한다.

정리 — 캐시 스탬피드 대응 전략

세 전략은 구현 복잡도와 스탬피드 방어 수준이 다르다. 트래픽 규모와 요구 사항에 따라 선택한다.

• @Cacheable : 구현이 가장 단순하지만 스탬피드에 무방비다.
• LoadingCache : 동일 키 동시 요청을 1개로 줄인다. 트래픽이 많은 공유 데이터에 적합.
• refreshAfterWrite : 사용자가 캐시 미스를 경험하지 않는다. 중단 없는 서비스가 핵심일 때 선택.

기본 미션에서는 @Cacheable만으로 충분하다. 캐시 스탬피드는 대규모 트래픽에서 발생하는 문제이므로, 개념을 이해해두고 필요할 때 적용하면 된다.

Q&A