레디스 캐시 스탬피드 현상 (Cache Stampede)

🔸캐시 스탬피드 현상이란?

캐시 스탬피드 현상: 하나의 캐시 항목이 만료되었을 때 다수의 요청이 동시에 캐시를 갱신하려고 하면서 발생하는 문제

레디스를 캐시로 활용할 때 모든 키에 대해 만료 시간을 설정하는 것은 권장되지만, 대규모 트래픽 환경에서 만료시간을 어떻게 설정하느냐에 따라 캐시 스탬피드와 같은 예상치 못한 문제 상황이 발생할 수 있다.

 

위의 그림에서, 애플리케이션 1과 2는 look aside 방식으로 레디스를 사용하고 있다고 생각해보자.
look aside 방식에서 애플리케이션은 레디스에 먼저 데이터가 있는지 질의한 후 데이터가 없을 때 데이터베이스에서 데이터를 읽어오는 과정을 반복한다.

 

이때, 레디스에서 특정 키가 만료되는 시점을 생각해보자.

1️⃣ 다수의 애플리케이션이 동일한 캐시 키를 요청
↓
2️⃣ 캐시가 만료(TTL 초과)되면서 데이터가 삭제됨
↓
3️⃣ 모든 요청이 동시에 DB로 쏠림 (Duplicate Read 발생)
↓
4️⃣ DB에서 데이터를 가져온 후 캐시에 다시 저장
↓
5️⃣ 여러 애플리케이션이 동시에 캐시에 데이터를 저장 (Duplicate Write 발생)

이 과정에서 DB 부하가 급증하고 시스템 응답 시간이 느려지거나 장애가 발생할 수 있다.

 

한번 캐시 스탬피드 현상이 발생하면 결과적으로 더 많은 데이터가 이 현상의 영향을 받게 돼, 더 큰 문제로 이어질 수 있다. 이런 이유로 계단적 실패(cascading failure)라고도 부른다.

---

🔸해결 방법

캐시 스탬피드 현상을 방지할 수 있는 몇 가지 방법에 대해 살펴보고자 한다.

---

1️⃣ TTL 설정

🔹1. 적절한 만료 시간 설정

캐시 스탬피드를 줄이기 위한 가장 간단한 방법은 만료 시간을 너무 짧지 않게 설정하는 것이다.

여러 애플리케이션에서 한꺼번에 접근해야 하는 데이터이며, 반복적으로 사용돼야 하는 데이터라면 저장 시점부터 만료 시간을 충분히 길게 설정해주는 것이 좋다.

 

🔹2. 랜덤 TTL 적용

val ttl = 300 + Random.nextInt(30) // 300초 ~ 330초 사이 랜덤 TTL 적용
redisTemplate.expire("cache-key", ttl, TimeUnit.SECONDS)

TTL 값을 일정 범위 내에서 랜덤하게 설정하여 동일한 시간에 캐시가 만료되지 않도록 할 수 있다.

---

2️⃣ 선 계산

캐시가 만료되기 전에 미리 데이터를 갱신(선계산)하는 기법

---

🔹기존의 문제점

def fetch(key):
    value = redis.get(key)
    if not value:
        value = db.fetch(key)   # DB에서 데이터 조회
        redis.set(key, value)   # 캐시에 저장
    return value

기존의 동작 방식은 다음과 같다.

1️⃣레디스에서 key 값을 조회
↓
2️⃣값이 없다면 DB에서 데이터를 가져옴
↓
3️⃣가져온 데이터를 레디스에 저장 후 반환

하지만 위와 같은 방식은 여러 애플리케이션이 동시에 캐시 만료를 인지하고 DB를 조회하면 트래픽 폭증이 발생하며 중복 읽기와 중복 쓰기가 발생한다.

 

🔹선계산 기법

import random

def fetch(key, expiry_gap):
    ttl = redis.ttl(key)  # 현재 남은 TTL 확인

    if ttl - (random.random() * expiry_gap) > 0:
        return redis.get(key)  # 캐시된 값 반환

    else:
        value = db.fetch(key)  # DB에서 데이터 조회
        redis.set(key, value, KEY_TTL)  # 캐시 갱신
        return value

# 사용 예시
fetch("hello", 2)

위의 코드의 동작 방식은 다음과 같다.

1️⃣TTL 조회random()을 사용해 랜덤한 확률로 TTL을 감소시킴
        → 만약 TTL - 랜덤 값 > 0이면 캐시된 데이터를 그대로 사용
        → 그렇지 않다면 DB에서 데이터를 가져와 캐시에 저장
↓
2️⃣결과적으로 캐시가 완전히 만료되기 전에 일부 요청이 미리 캐시를 갱신하도록 유도

이러한 동작 방식을 통해서 여러 애플리케이션이 동시에 DB를 조회하는 문제를 방지하고 캐시 갱신을 분산하여 동시 DB 부하를 줄일 수 있다.

(🚨이때, 적절한 expiry_gap 설정이 중요하다.)

---

3️⃣ PER(Probabilistic Early Refresh) 알고리즘

캐시 스탬피드현상을 방지하기 위해 캐시가 만료되기 전에 확률적으로 데이터를 갱신하는 기법

캐시가 만료되기 직전에만 데이터를 갱신하는 것이 아니라, 만료 시간이 가까워질수록 점진적으로 갱신 확률을 높여 DB 부하를 분산하는 방식이다.

---

🔹 1. PER 알고리즘의 핵심 수식

currentTime - ( timeToCompute * beta * log(rand()) ) > expiry

각 변수의 의미는 다음과 같다.

• currentTime : 현재 남아있는 캐시 만료 시간
• timeToCompute : 캐시된 값을 다시 계산하는 데 걸리는 시간
• beta (β) : 기본적으로 1.0보다 큰 값으로 설정 가능 (갱신 확률 조절)
• rand() : 0 ~ 1 사이의 랜덤 값을 반환하는 함수
• expiry : 키를 재설정할 때 새로 적용할 만료 시간

 

🔹2. 동작 원리

1️⃣ currentTime이 expiry에 가까울수록 rand()를 통해 무작위 확률로 캐시를 갱신할지 결정
↓
2️⃣ log(rand()) 값을 사용하여 만료 시간에 가까워질수록 갱신 확률을 점진적으로 증가
↓
3️⃣ beta 값을 조절하여 갱신이 더 빠르게 또는 느리게 일어나도록 조정 가능
↓
4️⃣ currentTime에서 timeToCompute * beta * log(rand())를 빼서 나온 값이 expiry보다 작다면 캐시가 만료되기 전에 갱신 수행

즉, 완전히 만료되기 전에 일정 확률로 캐시를 미리 갱신하여 캐시 스탬피드 현상을 방지하는 방식이다.

---

📙 출처

<개발자를 위한 레디스> - 김가림