🚨 캐시가 있는데 DB 조회가 10번? Cache Stampede를 Single Flight로 해결한 과정

인기 숙소 조회 성능을 개선하기 위해 Redis 응답 캐시를 적용했다.

캐시가 존재하는 동안에는 동일한 인기 숙소 요청이 들어와도 Redis에 저장된 완성 응답을 바로 반환하기 때문에 Redis 랭킹 조회와 MySQL 조회를 생략할 수 있었다.

그런데 캐시를 적용했다고 해서 모든 문제가 끝난 것은 아니었다.

캐시의 TTL이 만료되는 순간 동일한 요청이 동시에 들어오면, 모든 요청이 Cache Miss로 판단하여 같은 Redis 랭킹과 MySQL 데이터를 반복해서 조회할 수 있었다.

이번 글에서는 이 Cache Stampede 문제를 직접 재현하고, 여러 해결 방법을 비교한 뒤 Key 단위 Single Flight를 적용하여 원본 조회를 10회에서 1회로 줄인 과정을 정리한다.

---

📌 기존 인기 숙소 조회 구조

RoomPick의 인기 숙소 조회는 다음 순서로 동작한다.

사용자 요청
→ 인기 숙소 응답 캐시 조회
→ Cache Hit라면 완성된 응답 반환
→ Cache Miss라면 Redis 인기 랭킹 조회
→ MySQL에서 ACTIVE 숙소 정보 일괄 조회
→ Redis 랭킹 순서 복원
→ 비공개·삭제 숙소 필터링
→ rank 계산 및 응답 DTO 생성
→ 완성된 응답을 Redis 캐시에 저장

응답 캐시 키에는 다음 값이 포함된다.

조회 기간 + 기간 기준 날짜 + limit

예를 들면 다음과 같다.

DAILY + 2026-08-05 + limit 10
WEEKLY + 2026-08-04 + limit 10
DAILY + 2026-08-05 + limit 20

기간이나 limit이 다르면 서로 다른 캐시로 관리된다.

---

⏱️ 인기 숙소 캐시 TTL을 60초로 정한 이유

현재 인기 숙소 응답 캐시의 기본 TTL은 60초다.

60초는 업계에서 공통으로 사용하는 표준값이 아니라, RoomPick의 데이터 특성과 성능 요구를 기준으로 정한 초기 절충값이다.

인기 숙소 순위는 예약 가능 여부나 결제 금액처럼 거래 정합성을 결정하는 데이터가 아니다.

예약 가능 여부가 오래된 경우
→ 이미 예약된 객실을 예약할 수 있다고 판단할 수 있음
→ 거래 정합성 문제 발생

인기 숙소 순위가 약 60초 오래된 경우
→ 최근 조회수가 순위에 잠시 늦게 반영됨
→ 거래 정합성에는 직접적인 영향이 없음

따라서 인기 숙소 순위에는 약간의 최신성 지연을 허용하고, 그 대신 반복되는 Redis 랭킹 조회와 MySQL 조회를 줄이는 방향을 선택했다.

TTL이 너무 짧다면

TTL을 10초나 30초로 설정하면 최근 랭킹을 더 빠르게 반영할 수 있다.

하지만 다음 비용이 증가한다.

캐시 만료 횟수 증가
→ Cache Miss 증가
→ Redis 랭킹 조회 증가
→ MySQL 조회 증가
→ DTO 재생성 증가
→ Cache Stampede 발생 기회 증가

현재 인기 순위를 수 초 단위로 갱신해야 한다는 제품 요구는 없었다.

TTL이 너무 길다면

TTL을 3분이나 5분으로 설정하면 Cache Hit 비율은 높아질 수 있다.

그러나 캐시가 만들어진 직후 랭킹이 변경되면 사용자는 최대 5분 전의 인기 순위를 보게 된다.

인기 숙소는 최근 사용자의 관심 흐름을 보여주는 기능이므로, 초기 정책에서는 최대 반영 지연을 약 1분으로 제한했다.

60초가 최적값이라고 단정한 것은 아니다.
실제 트래픽을 기준으로 30초, 60초, 180초, 300초 등을 비교한 뒤 조정할 수 있는 운영 설정으로 관리한다.

---

💥 Cache Stampede란?

캐시가 유지되는 동안에는 같은 요청이 여러 번 들어와도 문제가 없다.

요청 10건
→ 모두 Cache Hit
→ Redis 랭킹 조회 0회
→ MySQL 조회 0회

문제는 캐시가 만료되는 순간이다.

캐시가 사라진 직후 동일한 요청 10건이 동시에 들어오면 모든 요청이 다음과 같이 판단할 수 있다.

요청 1 → 캐시가 없다
요청 2 → 캐시가 없다
요청 3 → 캐시가 없다
...
요청 10 → 캐시가 없다

각 요청은 다른 요청이 동일한 응답을 만들고 있다는 사실을 알 수 없다.

결국 모든 요청이 동일한 원본 조회를 실행한다.

요청 1 → Redis 조회 → MySQL 조회 → 응답 생성
요청 2 → Redis 조회 → MySQL 조회 → 응답 생성
요청 3 → Redis 조회 → MySQL 조회 → 응답 생성
...
요청 10 → Redis 조회 → MySQL 조회 → 응답 생성

최종 결과는 같지만 Redis와 DB에는 불필요한 요청이 반복된다.

이처럼 캐시가 만료된 순간 다수의 요청이 동시에 원본 데이터로 몰리는 현상을 Cache Stampede, 즉 캐시 쇄도 현상이라고 한다.

---

🍽️ 식당 안내판으로 이해해 보기

식당에 오늘의 인기 메뉴가 적힌 안내판이 있다고 생각해 보자.

안내판이 유효한 동안 손님들은 안내판만 확인하면 된다.

손님 10명
→ 안내판 확인
→ 직원에게 질문하지 않음

그런데 안내판 교체 시간이 되어 안내판이 비어 있을 때 손님 10명이 동시에 들어오면 어떻게 될까?

기존 방식에서는 손님 10명이 모두 주방 직원에게 같은 질문을 한다.

손님 10명
→ 오늘의 인기 메뉴가 무엇인지 각각 질문
→ 직원이 같은 내용을 10번 확인
→ 같은 안내판을 10번 작성

우리가 원하는 방식은 다음과 같다.

첫 번째 손님
→ 주방 직원에게 인기 메뉴 질문
→ 새 안내판 작성

나머지 손님 9명
→ 첫 번째 손님이 받아올 결과를 기다림
→ 완성된 같은 안내판을 함께 사용

요청을 거부하는 것이 아니라 이미 진행 중인 동일 작업의 결과를 공유하는 것이다.

---

🧪 추측하지 않고 먼저 문제를 재현했다

처음부터 락을 적용하지 않았다.

실제로 현재 코드에서 Cache Stampede가 발생하는지 통합 테스트로 먼저 확인했다.

테스트 조건은 다음과 같다.

캐시 상태: Cold cache
조회 기간: DAILY
limit: 1
동시 요청: 10건

Cold cache는 해당 요청의 응답이 캐시에 존재하지 않는 상태를 의미한다.

동시에 요청을 시작시키기

단순히 스레드 10개를 실행하는 것만으로는 정확한 재현이 어려웠다.

첫 번째 요청이 너무 빨리 캐시를 생성하면 나머지 요청은 Cache Hit가 되어 문제를 재현하지 못할 수 있기 때문이다.

그래서 CountDownLatch를 사용했다.

ready
→ 모든 요청 스레드가 시작 준비를 마쳤는지 확인

start
→ 준비된 요청 10건을 동시에 출발

rankingLookupEntered
→ 요청이 실제 Redis 랭킹 조회에 진입했는지 확인

releaseRankingLookup
→ 첫 요청이 너무 빨리 캐시를 만들지 못하도록 원본 조회 반환을 잠시 차단

핵심 흐름은 다음과 같다.

CountDownLatch ready =
    new CountDownLatch(THREAD_COUNT);

CountDownLatch start =
    new CountDownLatch(1);

CountDownLatch rankingLookupEntered =
    new CountDownLatch(THREAD_COUNT);

CountDownLatch releaseRankingLookup =
    new CountDownLatch(1);

모든 요청이 Cache Miss 이후 원본 조회에 진입할 때까지 Redis 랭킹 결과를 반환하지 않도록 구성했다.

재현 결과

동일한 캐시 Key로 요청 10건을 동시에 실행한 결과는 다음과 같았다.

Redis 인기 랭킹 조회: 10회
MySQL ACTIVE 숙소 조회: 10회
동일 응답 생성: 10회

캐시가 최종적으로 저장되기는 했지만, 캐시가 만들어지기 전 동일한 계산을 10번 반복하고 있었다.

즉, Cache Stampede가 이론적으로만 가능한 문제가 아니라 현재 RoomPick 코드에서 실제로 발생하는 문제임을 확인했다.

---

🔍 해결 방법 비교

문제를 재현한 뒤 다음 세 가지 대안을 비교했다.

1. @Cacheable(sync = true)
2. Redis Locking Cache Writer 또는 분산 락
3. 애플리케이션 내부 Key 단위 Single Flight

---

1️⃣ @Cacheable(sync = true)

Spring Cache에는 동일한 캐시 Key의 동시 조회를 동기화하기 위한 옵션이 있다.

@Cacheable(
    cacheNames = "popularAccommodations",
    key = "...",
    sync = true
)

처음에는 가장 간단한 해결 방법으로 보였다.

하지만 RoomPick의 Redis Cache Manager는 기본 Non-locking Redis Cache Writer를 사용하고 있었다.

중요한 것은 문서만 보고 동작한다고 가정하지 않는 것이었다.

실제로 sync = true를 적용한 뒤 동일한 Stampede 테스트를 다시 실행했다.

결과는 다음과 같았다.

동시 요청 10건
→ Redis 랭킹 조회 10회
→ MySQL 조회 10회

현재 Redis 캐시 구성에서는 sync = true만 추가해도 원본 조회가 하나로 합쳐지지 않았다.

효과가 없는 설정이므로 다시 제거했고 커밋에도 포함하지 않았다.

---

2️⃣ Redis Locking Cache Writer

Redis Cache Writer를 Locking 방식으로 바꾸는 방법도 검토했다.

그러나 우리가 원하는 잠금 범위는 동일한 캐시 Key다.

DAILY:2026-08-05:10
→ 이 키와 동일한 요청만 대기

캐시 이름 전체를 잠그는 방식은 서로 관계없는 요청까지 기다리게 할 수 있다.

DAILY + limit 10 갱신 중

WEEKLY + limit 10
→ 다른 요청이지만 대기할 가능성

DAILY + limit 20
→ 다른 요청이지만 대기할 가능성

Stampede를 막는 대신 캐시 전체가 새로운 병목 지점이 될 수 있다.

---

3️⃣ Redis 분산 락

Redis 분산 락을 사용하면 여러 애플리케이션 서버 사이에서도 중복 갱신을 제어할 수 있다.

하지만 분산 락에는 다음과 같은 추가 설계가 필요하다.

락 획득 실패 처리
락 대기 시간
락 만료 시간
재시도 정책
락 소유권 확인
서버 장애 시 락 해제
Redis 장애 처리

현재 RoomPick은 단일 애플리케이션 인스턴스를 기준으로 운영하고 있었다.

아직 존재하지 않는 다중 인스턴스 문제를 해결하기 위해 분산 락의 복잡성을 미리 추가하는 것은 과도하다고 판단했다.

---

✅ 최종 선택: Key 단위 Single Flight

현재 구조에서 가장 적은 복잡도로 문제를 해결할 수 있는 애플리케이션 내부 Key 단위 Single Flight를 선택했다.

Single Flight는 다음과 같은 방식이다.

동일한 작업이 이미 진행 중이라면 새로운 작업을 실행하지 않고, 진행 중인 한 번의 작업 결과를 함께 사용한다.

새로운 Service를 추가했다.

PopularAccommodationSingleFlightService

전체 호출 구조는 다음처럼 변경됐다.

변경 전

Controller
→ AccommodationFacade
→ PopularAccommodationQueryService
→ Redis 랭킹 조회
→ MySQL 숙소 조회

변경 후

Controller
→ AccommodationFacade
→ PopularAccommodationSingleFlightService
→ PopularAccommodationQueryService
→ Redis 랭킹 조회
→ MySQL 숙소 조회

각 계층의 책임은 다음과 같다.

AccommodationFacade
→ 인기 숙소 조회 흐름 조율
→ Redis 장애 fallback 처리

PopularAccommodationSingleFlightService
→ 동일한 캐시 Key의 동시 요청 제어

PopularAccommodationQueryService
→ 인기 숙소 데이터 조합
→ @Cacheable을 통한 응답 캐싱

PopularAccommodationRankingService
→ Redis 인기 랭킹 조회

AccommodationService
→ MySQL ACTIVE 숙소 조회

동시성 제어 책임을 별도 Service로 분리하여 QueryService나 Repository가 과도한 책임을 가지지 않도록 했다.

---

🗂️ Single Flight의 핵심 자료구조

구현에서는 다음 두 가지를 사용했다.

ConcurrentHashMap
CompletableFuture

진행 중인 작업을 다음 형태로 관리한다.

private final ConcurrentMap<
    String,
    CompletableFuture<List<PopularAccommodationResponseDto>>
> inFlightRequests = new ConcurrentHashMap<>();

개념적으로는 다음 정보가 들어 있다.

Key
→ DAILY:2026-08-05:10

Value
→ 현재 진행 중인 인기 숙소 조회 작업

---

🥇 최초 요청 처리

동일 키로 들어온 요청 중 최초 요청만 실제 조회를 수행한다.

CompletableFuture<List<PopularAccommodationResponseDto>>
    newRequest = new CompletableFuture<>();

CompletableFuture<List<PopularAccommodationResponseDto>>
    existingRequest = inFlightRequests.putIfAbsent(
        cacheKey,
        newRequest
    );

putIfAbsent()는 다음과 같이 동작한다.

Map에 해당 Key가 없다
→ 내가 만든 Future 등록
→ 내가 최초 요청

Map에 해당 Key가 이미 있다
→ 기존 Future 반환
→ 다른 요청이 이미 작업 중

여러 요청이 동시에 접근해도 ConcurrentHashMap과 putIfAbsent()를 사용하기 때문에 한 요청만 최초 요청이 된다.

요청 A → 등록 성공 → 실제 조회 실행
요청 B → 기존 Future 발견 → A의 결과 대기
요청 C → 기존 Future 발견 → A의 결과 대기

---

⏳ 나머지 요청 처리

이미 같은 Key의 요청이 진행 중이라면 새로운 원본 조회를 시작하지 않는다.

if (existingRequest != null) {
    return awaitResult(
        existingRequest
    );
}

최초 요청의 CompletableFuture가 완료될 때까지 기다린 뒤 같은 결과를 반환한다.

최초 요청
→ Redis 랭킹 조회
→ MySQL 조회
→ 응답 생성
→ Future 완료

대기 요청
→ 기존 Future 대기
→ 최초 요청이 만든 응답 반환

---

🎉 성공 결과 공유

최초 요청이 정상적으로 처리되면 결과로 Future를 완료한다.

currentRequest.complete(
    result
);

대기 중인 모든 요청은 같은 결과를 전달받는다.

요청 10건
→ 실제 원본 조회 1회
→ 결과 객체를 10개 요청이 공유

---

🚨 실패 결과도 공유해야 한다

성공 결과만 공유해서는 안 된다.

Redis 조회에 실패했을 때 최초 요청만 예외를 받고, 대기 요청들이 멈추거나 다른 동작을 하면 안 된다.

따라서 최초 요청에서 예외가 발생하면 Future도 예외 상태로 완료한다.

currentRequest.completeExceptionally(
    exception
);

대기 요청은 CompletionException 내부의 원본 예외를 꺼내 다시 전달한다.

if (cause instanceof RuntimeException runtimeException) {
    throw runtimeException;
}

if (cause instanceof Error error) {
    throw error;
}

이를 통해 성공뿐만 아니라 실패도 같은 작업의 결과로 공유한다.

최초 요청 성공
→ 모든 대기 요청이 같은 성공 결과 반환

최초 요청 Redis 장애
→ 모든 대기 요청이 같은 Redis 장애 예외 전달

---

🧹 완료된 작업은 반드시 Map에서 제거한다

Single Flight Map은 현재 진행 중인 요청만 관리해야 한다.

완료된 Future가 계속 남아 있으면 이후 요청이 오래된 결과를 계속 재사용하거나 메모리가 증가할 수 있다.

따라서 성공과 실패 여부에 상관없이 finally에서 제거한다.

finally {
    inFlightRequests.remove(
        cacheKey,
        currentRequest
    );
}

단순히 다음처럼 제거하지 않았다.

inFlightRequests.remove(cacheKey);

대신 다음 메서드를 사용했다.

inFlightRequests.remove(
    cacheKey,
    currentRequest
);

이는 Map에 저장된 값이 현재 요청의 Future와 같을 때만 제거한다는 의미다.

혹시 새로운 작업이 같은 Key에 등록된 상태라면 그 작업을 잘못 제거하지 않도록 방어할 수 있다.

---

🔑 서로 다른 요청까지 기다리지 않도록 Key를 분리했다

Single Flight 식별 Key는 기존 응답 캐시 Key와 동일한 조건으로 생성했다.

return popularAccommodationKeyGenerator
    .generateCurrentKey(period)
    + ":"
    + limit;

따라서 아래 요청들은 같은 작업을 공유한다.

DAILY + 2026-08-05 + limit 10
DAILY + 2026-08-05 + limit 10

반면 다음 요청들은 서로 독립적으로 실행된다.

DAILY + limit 10
DAILY + limit 20
WEEKLY + limit 10

즉, 캐시 전체에 락을 거는 것이 아니라 동일한 Key의 요청만 묶는다.

---

🛟 기존 Redis 장애 fallback 유지

RoomPick에는 Redis 인기 랭킹을 사용할 수 없을 때 API 전체 장애를 막기 위한 fallback이 존재한다.

Redis 인기 랭킹 조회 실패
→ PopularAccommodationRankingUnavailableException 발생
→ AccommodationFacade에서 예외 처리
→ 최신 ACTIVE 숙소를 MySQL에서 조회
→ 임시 rank 부여
→ fallback 응답 반환

Single Flight가 예외를 내부에서 삼켜버리면 기존 fallback 흐름이 깨진다.

그래서 Single Flight는 예외를 처리하는 것이 아니라 대기 요청에도 동일한 예외를 전달하는 역할만 한다.

Single Flight
→ 동일 요청의 성공 또는 실패 결과 공유

Facade
→ Redis 장애일 때 DB fallback 실행

책임을 분리하여 기존 장애 대응 흐름을 유지했다.

Redis 장애

Redis 랭킹 조회 실패
→ 예외 공유
→ Facade에서 최신 ACTIVE 숙소 fallback

MySQL 장애

MySQL 조회 실패
→ Redis 장애가 아니므로 fallback하지 않음
→ DB 예외 그대로 전달

비즈니스 예외

잘못된 limit 등 비즈니스 예외
→ fallback으로 숨기지 않음
→ 예외 그대로 전달

---

📊 캐시 비활성화 시 Single Flight도 우회

RoomPick에서는 캐시 적용 전후의 성능을 비교하기 위해 캐시를 비활성화할 수 있다.

roompick.cache.popular-accommodations-enabled=false

캐시만 비활성화하고 Single Flight는 유지하면 동시 요청이 하나로 합쳐진다.

그러면 캐시 미적용 상태의 원래 비용을 정확하게 측정할 수 없다.

따라서 캐시가 비활성화된 경우 Single Flight도 우회했다.

if (!popularAccommodationCacheCondition.isEnabled()) {
    return popularAccommodationQueryService
        .getPopularAccommodations(
            period,
            limit
        );
}

정책은 다음과 같다.

캐시 활성화
→ Single Flight 적용
→ 동일 Key의 원본 조회를 하나로 묶음

캐시 비활성화
→ Single Flight 우회
→ 모든 요청이 기존 조회 흐름 실행

성능 테스트의 기준 조건을 유지하기 위한 결정이다.

---

🧪 개선 후 통합 테스트

기존 재현 테스트를 Single Flight 개선 검증 테스트로 변경했다.

동일한 조건으로 다시 실행했다.

Cold cache
동일 캐시 Key
동시 요청 10건

최초 요청이 원본 조회에 진입하면 Redis 랭킹 응답을 잠시 막아 나머지 요청들이 동일한 진행 중 작업을 발견할 수 있도록 했다.

CountDownLatch rankingLookupEntered =
    new CountDownLatch(1);

CountDownLatch releaseRankingLookup =
    new CountDownLatch(1);

모든 요청은 다음 Service를 호출한다.

popularAccommodationSingleFlightService
    .getPopularAccommodations(
        DAILY,
        LIMIT
    );

최종 검증 조건은 다음과 같다.

then(popularAccommodationRankingService)
    .should(times(1))
    .findRankedAccommodationIds(
        DAILY,
        LIMIT,
        0L,
        4L
    );

then(accommodationService)
    .should(times(1))
    .findAllActiveSummaryByIds(
        rankedAccommodationIds
    );

---

📈 개선 전후 결과

항목	개선 전	개선 후
동시 요청 수	10건	10건
Redis 랭킹 조회	10회	1회
MySQL 숙소 조회	10회	1회
응답 DTO 생성	10회	1회
사용자 요청 결과	모두 성공	모두 성공
최종 Redis 캐시 저장	성공	성공

사용자가 받는 응답은 동일하지만 내부에서 발생하는 중복 비용은 크게 감소했다.

개선 전

동일 요청 10건
→ Redis 조회 10회
→ MySQL 조회 10회
→ 같은 응답 10번 생성

개선 후

동일 요청 10건
→ Redis 조회 1회
→ MySQL 조회 1회
→ 최초 요청 결과를 10건이 공유

특히 MySQL 조회가 10회에서 1회로 줄어 DB Connection과 쿼리 실행 비용을 줄일 수 있었다.

---

✅ 회귀 테스트

Single Flight 적용 후 기존 기능이 깨지지 않았는지 다음 테스트를 실행했다.

인기 숙소 관련 통합 테스트

./gradlew integrationTest \
  --tests "*PopularAccommodation*"

Stampede 통합 테스트

./gradlew integrationTest \
  --tests "*PopularAccommodationCacheStampedeIntegrationTest"

전체 단위 테스트

./gradlew clean test

Facade가 기존 PopularAccommodationQueryService 대신 PopularAccommodationSingleFlightService를 호출하도록 변경됐기 때문에 기존 Facade 단위 테스트의 Mock 대상도 함께 수정했다.

모든 테스트가 최종적으로 성공했다.

---

🏗️ 최종 구조

Controller
    ↓
AccommodationFacade
    ↓
PopularAccommodationSingleFlightService
    ↓
PopularAccommodationQueryService
    ↓
PopularAccommodationRankingService
    ↓
Redis Repository

그리고 숙소 공개 정보는 다음 흐름으로 조회된다.

PopularAccommodationQueryService
    ↓
AccommodationService
    ↓
AccommodationRepository
    ↓
MySQL

각 계층은 다음 책임을 가진다.

계층	책임
Controller	요청 수신 및 응답 반환
Facade	전체 비즈니스 흐름 조율, Redis 장애 fallback
SingleFlightService	동일 캐시 Key의 동시 요청 제어
QueryService	랭킹과 숙소 데이터를 조합하고 응답 캐싱
RankingService	Redis 랭킹 조회
AccommodationService	ACTIVE 숙소 DB 조회
Repository	Redis 및 MySQL 명령 실행

---

⚠️ 현재 구현의 한계

이번 Single Flight는 애플리케이션 인스턴스 내부에서만 동작한다.

서버가 한 대라면 다음과 같다.

서버 A에 동일 요청 10건
→ 서버 A 내부에서 원본 조회 1회

서버가 두 대라면 각 서버가 자신의 Map을 가지고 있다.

서버 A에 요청 5건
→ 서버 A에서 원본 조회 1회

서버 B에 요청 5건
→ 서버 B에서 원본 조회 1회

전체적으로는 원본 조회가 2회 발생할 수 있다.

하지만 현재 RoomPick은 단일 인스턴스 구조이므로 애플리케이션 내부 Single Flight가 현재 문제를 해결하기 위한 가장 단순하고 적절한 방식이라고 판단했다.

향후 다중 인스턴스 환경에서 인스턴스 간 중복 갱신이 실제 문제로 확인된다면 다음 방법을 검토할 수 있다.

Redis 분산 락
분산 Single Flight
Soft TTL
캐시 선제 갱신
백그라운드 Refresh

실제 문제가 발생하기 전에 분산 락의 복잡성을 미리 추가하지 않는 것도 중요한 설계 결정이라고 생각한다.

---

💡 이번 작업에서 배운 점

1. 캐시 적용이 성능 문제의 끝은 아니다

캐시는 평상시 원본 조회를 줄여주지만 캐시 만료 시점에는 요청이 원본 데이터로 한꺼번에 몰릴 수 있다.

Cache Hit 성능뿐 아니라 다음 상황도 함께 검증해야 한다.

Cold cache
TTL 만료 직후
동시 요청
Redis 장애
캐시 비활성화

2. 동시성 문제는 테스트에서 실제로 재현해야 한다

“아마 중복 조회가 발생할 것이다”라는 추측만으로 복잡한 락을 추가하지 않았다.

CountDownLatch와 다중 스레드 테스트를 통해 실제로 Redis와 MySQL 조회가 각각 10회 발생한다는 것을 확인한 뒤 개선했다.

3. 가장 복잡한 기술이 항상 가장 좋은 해결책은 아니다

Redis 분산 락은 강력하지만 현재 단일 인스턴스 구조에서는 과도한 복잡성이 될 수 있다.

현재 문제의 범위에 맞춰 Key 단위 애플리케이션 Single Flight를 선택했다.

4. 성공뿐 아니라 실패도 공유해야 한다

동일 작업을 하나로 합칠 때 성공 결과만 공유하면 안 된다.

최초 요청에서 발생한 예외도 대기 요청에 전달해야 기존 예외 처리와 fallback 흐름을 유지할 수 있다.

5. 성능 개선은 기존 장애 정책을 깨뜨리지 않아야 한다

Redis 중복 조회를 줄이는 것만큼 기존 DB fallback과 비즈니스 예외 정책을 유지하는 것도 중요했다.

최적화 때문에 예외 의미가 달라지거나 잘못된 fallback이 실행되지 않도록 책임을 분리했다.

6. 설정값의 이유를 문서로 남겨야 한다

TTL 60초라는 숫자만 남아 있으면 이후 팀원이 변경 여부를 판단하기 어렵다.

다음을 문서화했다.

왜 60초인가
왜 더 짧지 않은가
왜 더 길지 않은가
어떤 최신성 지연을 허용하는가
어떤 변경은 즉시 캐시를 무효화해야 하는가
현재 결정의 한계는 무엇인가
향후 어떤 비교 측정이 필요한가

숫자보다 중요한 것은 숫자를 선택한 근거라고 느꼈다.

---

🎯 마무리

이번 작업에서는 인기 숙소 응답 캐시가 만료된 직후 동일 요청이 동시에 유입되면 Redis 랭킹과 MySQL 숙소 정보를 중복 조회하는 Cache Stampede 문제를 발견했다.

먼저 10개의 동시 요청을 사용한 통합 테스트로 실제 문제를 재현했다.

개선 전
→ Redis 랭킹 조회 10회
→ MySQL 조회 10회

이후 @Cacheable(sync = true), Redis Locking Cache Writer, Redis 분산 락을 비교했다.

현재 RoomPick의 단일 인스턴스 구조에서는 동일 캐시 Key만 제어하는 애플리케이션 내부 Single Flight가 가장 적은 복잡도로 문제를 해결할 수 있다고 판단했다.

ConcurrentHashMap과 CompletableFuture를 사용해 최초 요청의 성공 결과 또는 예외를 공유하도록 구현했고, 동일한 테스트 조건에서 다음 결과를 확인했다.

개선 후
→ Redis 랭킹 조회 1회
→ MySQL 조회 1회
→ 동시 요청 10건 모두 동일한 결과 반환

또한 캐시 비활성화 성능 측정 조건과 Redis 장애 시 DB fallback 흐름도 그대로 유지했다.

이번 경험을 통해 단순히 캐시를 적용하는 것을 넘어, 캐시가 비어 있거나 만료되는 순간에 시스템이 어떻게 동작하는지까지 검증해야 한다는 것을 배울 수 있었다.

---

🏷️ Tags

Spring Boot Redis Cache Cache Stampede Single Flight CompletableFuture ConcurrentHashMap 동시성 성능 최적화 MySQL Testcontainers Spring Cache