[Redis] Cache Patterns: Cache-Aside, Stampede, Eviction

정의

Cache Pattern 은 Redis (또는 다른 캐시) 를 어떤 경로로 읽고 쓰는지 의 디자인 결정. 같은 인프라로도 패턴 선택에 따라 일관성 / 지연 / 부하 가 완전히 달라진다.

가장 흔한 다섯 가지:

1. Cache-aside (look-aside): 애플리케이션이 캐시를 직접 본다. miss 면 DB 로 가서 직접 캐시에 채운다.
2. Read-through: 캐시 라이브러리 가 miss 시 자동 으로 backing store 를 조회.
3. Write-through: write 시 캐시 + DB 동시 갱신. 일관성 ↑.
4. Write-behind / Write-back: 캐시 먼저 쓰고 비동기 로 DB 반영. 쓰기 빠름, 손실 위험.
5. Refresh-ahead: TTL 만료 직전 에 백그라운드 refresh. miss 자체를 줄임.

Cache Hit / Miss 의 시각

행복 경로 (HIT):

캐시 채우는 경로 (MISS → DB → set):

5가지 패턴 비교

flowchart LR
    subgraph CA[Cache-Aside]
        A1[App] -->|GET| C1[Cache]
        C1 -->|miss| A1
        A1 -->|SELECT| D1[(DB)]
        D1 --> A1
        A1 -->|SET| C1
    end
    subgraph WT[Write-Through]
        A2[App] -->|UPDATE| L2[Cache lib]
        L2 -->|동시| C2[Cache]
        L2 -->|동시| D2[(DB)]
    end
    subgraph WB[Write-Behind]
        A3[App] -->|UPDATE| L3[Cache lib]
        L3 -->|즉시| C3[Cache]
        L3 -.비동기.-> D3[(DB)]
    end

매트릭스:

Cache-aside 의 정석

GET → miss → SELECT → SET:

sequenceDiagram
    autonumber
    participant App
    participant Cache as Redis
    participant DB as PostgreSQL

    App->>Cache: GET user:42
    alt HIT
        Cache-->>App: 데이터 반환
    else MISS
        Cache-->>App: (nil)
        App->>DB: SELECT * FROM users WHERE id=42
        DB-->>App: row
        App->>Cache: SET user:42 ... EX 600
        Cache-->>App: OK
    end

여러 언어로 같은 패턴:

# Rails 의 표준
def find_user(id)
Rails.cache.fetch("user:#{id}", expires_in: 10.minutes) do
  User.find(id)
end
end

import redis, json
r = redis.Redis()
​
def find_user(id: int):
  key = f"user:{id}"
  cached = r.get(key)
  if cached:
      return json.loads(cached)
  user = db.query("SELECT * FROM users WHERE id=%s", id).fetchone()
  r.set(key, json.dumps(user), ex=600)
  return user

import { Redis } from 'ioredis';
const r = new Redis();
​
export async function findUser(id: number) {
const key = `user:${id}`;
const cached = await r.get(key);
if (cached) return JSON.parse(cached);
​
const user = await db.queryOne('SELECT * FROM users WHERE id=$1', [id]);
await r.set(key, JSON.stringify(user), 'EX', 600);
return user;
}

@Service
class UserService {
private final RedisTemplate<String, User> redis;
private final UserRepo repo;
​
public User find(long id) {
  var key = "user:" + id;
  User cached = redis.opsForValue().get(key);
  if (cached != null) return cached;
​
  User user = repo.findById(id).orElseThrow();
  redis.opsForValue().set(key, user, Duration.ofMinutes(10));
  return user;
}
}

동일 입력 → 동일 응답. miss 시 첫 호출만 DB 왕복.

Cache Stampede (Thundering Herd / Dogpile)

TTL 이 동시에 만료 되면 수많은 클라이언트 가 동시에 DB 를 친다. 원래 막아주던 캐시 가 증폭기 가 되는 사고.

sequenceDiagram
    autonumber
    participant C1
    participant C2
    participant C3
    participant Cache
    participant DB

    Note over Cache: TTL 0, 만료된 순간
    par C1, C2, C3 모두 동시에
        C1->>Cache: GET
        Cache-->>C1: nil
        C2->>Cache: GET
        Cache-->>C2: nil
        C3->>Cache: GET
        Cache-->>C3: nil
    end
    par 모두 DB 로 (stampede!)
        C1->>DB: SELECT
        C2->>DB: SELECT
        C3->>DB: SELECT
    end
    par 같은 결과를 캐시에 N 번 SET
        C1->>Cache: SET
        C2->>Cache: SET
        C3->>Cache: SET
    end

완화 패턴 4가지

XFetch (Probabilistic Early Expiration)

논문 (Vattani et al.) 의 공식:

expiry = now + delta * beta * log(rand())

캐시에 기록 시점에 평균 fetch 시간 delta 를 함께 저장. 읽을 때 위 식이 TTL 만료 시점을 넘으면 자기가 갱신.

import math, random, time

def get_with_xfetch(r, key, fetch_fn, ttl_seconds, beta=1.0):
    payload = r.get(key)
    if payload is None:
        return refresh(r, key, fetch_fn, ttl_seconds)

    value, delta, expiry = decode(payload)
    now = time.time()
    if now - delta * beta * math.log(random.random()) >= expiry:
        # 만료 전이지만 *확률적으로 미리 갱신*
        return refresh(r, key, fetch_fn, ttl_seconds)
    return value

Single-flight: SET NX 락

def cache_aside_with_lock(r, key, fetch_fn, ttl=600):
    val = r.get(key)
    if val is not None:
        return val

    # 락 시도
    lock_key = f"lock:{key}"
    got = r.set(lock_key, "1", nx=True, ex=10)
    if got:
        try:
            fresh = fetch_fn()
            r.set(key, fresh, ex=ttl)
            return fresh
        finally:
            r.delete(lock_key)
    else:
        # 다른 클라이언트가 갱신 중. 잠시 기다렸다가 재시도
        time.sleep(0.05)
        return cache_aside_with_lock(r, key, fetch_fn, ttl)

Eviction Policy (maxmemory-policy)

메모리 한도 (maxmemory) 초과 시 어떤 키부터 버릴지. 패턴 선택만큼 중요.

LRU 의 동작 직관

Eviction 성능 비교 (직관)

같은 워크로드, 다른 정책에서의 히트율 차이 의 직관:

Negative Caching (404 / null 도 캐시)

DB miss 자체가 비싸면 결과 없음 도 캐시.

def get_user(id):
    cached = r.get(f"user:{id}")
    if cached == NULL_SENTINEL:
        return None     # *없음* 도 캐시
    if cached is not None:
        return json.loads(cached)
    user = db_lookup(id)
    if user is None:
        r.set(f"user:{id}", NULL_SENTINEL, ex=60)   # 짧은 TTL
    else:
        r.set(f"user:{id}", json.dumps(user), ex=600)
    return user

무효화 (Invalidation)

“There are only two hard things in Computer Science: cache invalidation and naming things.” (Phil Karlton)

Write 시 캐시 무효화 (가장 흔함)

def update_user(id, **fields):
    db.update("UPDATE users SET ... WHERE id=%s", id, **fields)
    r.delete(f"user:{id}")     # 다음 GET 이 miss → 새로 채움

SET 으로 갱신 보다 DEL 이 일반적으로 안전. 멀티 키 / 파생 캐시까지 정확히 갱신하기 어렵기 때문에 지우고 다시 빠뜨리는 패턴.

Tagged Invalidation (Russian Doll)

특정 그룹의 캐시 일괄 무효화 가 필요할 때. 키에 버전 / 타임스탬프 를 박는다.

def get_post(post_id):
    version = r.get(f"post:{post_id}:version") or "0"
    return cached_get(f"post:{post_id}:v{version}")

def invalidate_post(post_id):
    r.incr(f"post:{post_id}:version")   # 옛 키들은 *자연 만료* 만 기다림

김신건의 현장 메모

• Rails.cache.fetch 의 race_condition_ttl 이 single-flight + stale-while-revalidate 의 내장 버전. 인기 페이지에 반드시.
• Sidekiq job 결과 를 캐시할 때 영구 캐시 + 명시적 invalidation 이 짧은 TTL 보다 DB / Redis 모두 가벼웠다.
• Memcached 에서 Redis 로 갈아탄 가장 큰 이유: negative cache 와 데이터 구조 였다. Memcached 는 단순 캐시 의 끝까지 단단 하지만, 해시 / 정렬셋 / 집합 이 필요해지면 결국 Redis.
• LFU 가 LRU 보다 좋은 경우 의 직관: “대부분의 트래픽은 인기 콘텐츠 20%” 이면 LFU 가 강함. 균일 분포 에서는 LRU 와 LFU 가 비슷.

관련 위키

• Redis (라이센스 / 신 기능)
• Redis Persistence (캐시 전용일 때 영속화 비활성)
• Redis Pub Sub vs Streams (캐시 무효화 fan-out)
• Zero Downtime Deployment (배포 시 캐시 워밍)

참고

• 공식: Eviction policies
• AWS: Caching Best Practices
• Wikipedia: Cache stampede
• Cloudflare: SWR 적용