스케일링 가운틀렛, Pt. 3: Cache Rules Everything Around Me

Source: Dev.to

모든 거짓 새벽이 그렇듯, 좋은 소식으로 시작합니다.

Postgres Pete는 차분합니다.
팀은 축하합니다. 누군가가 밈을 만듭니다.

하지만 뭔가 이상합니다.

• “앱이 다운된 것”은 아니지만, 그냥… 흐물흐물합니다.
• 로그아웃한 사용자의 지연 시간이 급증합니다.
• 보고서 생성이 여전히 CPU를 많이 차지합니다.
• 누군가가 홈페이지에 접속할 때마다, 서버는 이번 주에 400,000번째로 같은 쿼리를 실행합니다.

이제 느린 것이 아니라, 낭비하고 있습니다.

Chapter 3에 오신 것을 환영합니다: 이제 아키텍처가 충분히 빨라져서 얼마나 중복된 작업을 하고 있는지 드러납니다.

전쟁 이야기: 모든 것을 녹인 리더보드

몇 년 전, 우리는 게임화된 캠페인을 시작했습니다: Leaderboard, Badges, Daily rewards.

문제는?
우리는 모든 요청마다 리더보드를 재계산했습니다.

• 각 요청은 수백만 행에 걸친 대규모 정렬, 조인, 필터링을 트리거했습니다.
• 출시 초에는 별 문제가 없었습니다—시간당 약 100명 정도.
• 바이럴이 되자? 하루에 90,000건의 요청이 있었습니다.

우리 DB는 다운되지 않았지만 성능은 끔찍했습니다. 60초 Redis 캐시를 추가하면 응답 시간이 912 ms → 38 ms 로 감소하고 쿼리 부하가 99.7 % 감소했습니다.

Postgres Pete가 감사 편지를 써 주었습니다.

Chapter 3: Caching Isn’t Cheating

• 작은 규모에서는 캐싱이 선택 사항이다.
• 큰 규모에서는 모든 것이다.

환상은 데이터베이스를 빠르게 만들고 쿼리를 효율적으로 하면 된다는 것이다.
1,000명의 사용자가 같은 라우트를 호출하고 1,000개의 동일한 응답을 생성한다면—축하합니다, 낭비를 최적화한 겁니다.

캐싱은 당신이 단순히 주문 즉시 조리하는 요리사가 아니라, 준비 스테이션을 갖춘 셰프가 되게 합니다.

캐싱 스택

레이어별로 나눠서 살펴보자, 도구가 아니라.
누군가 블로그 글을 읽었다고 해서 Redis가 필요하지는 않다. 올바른 작업에 맞는 적절한 캐시가 필요하다.

1. 페이지 및 프래그먼트 캐싱

2. 쿼리 결과 캐싱

3. 객체 캐싱

4. 엣지 캐싱 및 CDN

Redis 예시: 캐시‑어사이드 패턴

// Basic cache-aside pattern
const getCachedUser = async (userId) => {
  const cached = await redis.get(`user:${userId}`);
  if (cached) return JSON.parse(cached);

  const user = await db.users.findById(userId);
  await redis.setex(`user:${userId}`, 300, JSON.stringify(user));
  return user;
};

구체적인 예시: 홈페이지 지연 시간

단 3개의 컴포넌트(추천 제품, 블로그 티저, 고객 후기)를 캐시한 것만으로 가장 큰 영향을 미쳤습니다.

Cache Busting: The Forgotten Half of Caching

캐시에 쓰는 것은 쉽습니다.
올바르게 무효화하는 것이 성숙한 시스템과 실험적인 시도를 구분합니다.

+------------------------+
|   Does the data        |
|   change often?       |
+------------------------+
          |
+----------------+----------------+
|                |                |
Yes              No
|                |
+--------------+  +--------------------+
| Can you hook |  | Use long TTL with  |
| into writes? |  | fallback refresh   |
+------+-------+  +--------------------+
       |Yes
       |
+--------------+
| Event-driven |
| invalidation |
+--------------+
       |No
       |
+--------------+
| Use low TTL  |
| w/ polling   |
+--------------+

Cache Busting Methods

Time‑Based (TTL)

• 이해하기 쉽습니다.
• 약간의 오래된 데이터(스테일니스)를 허용합니다.
• 대시보드, 통계, 가격 책정 등에 “충분히 좋음”을 제공합니다.

Event‑Driven

• 데이터가 업데이트될 때 캐시를 무효화합니다.
• ORM에 훅을 달거나 pub/sub 시스템을 사용합니다.
• 관리가 더 어렵지만 정확도가 높습니다.

// In your product update handler:
await redis.del(`product:${product.id}`);
await redis.del(`category:${product.category}:featured`);

Dependency‑Tracking (Advanced)

• 어떤 데이터가 어떤 캐시 엔트리를 구동하는지 추적합니다.
• 영향을 받은 부분만 재구성합니다.
• 규율과 도구가 필요합니다(없으면 스스로를 원망하게 됩니다).

캐시가 정상 작동하고 있는지(또는 아닌지) 확인하는 징후

캐시 디버깅: 확인할 항목

• Hit‑rate metrics (Redis INFO stats → keyspace_hits / keyspace_misses).
• Latency – 캐시 읽기와 DB 읽기의 지연 시간을 비교합니다.
• TTL distribution – 키가 너무 빨리 만료되거나 절대 만료되지 않는지 확인합니다.
• Invalidation logs – 키를 무효화해야 하는 모든 쓰기가 실제로 수행되는지 보장합니다.
• Memory pressure – used_memory와 eviction 정책을 주시합니다.

TL;DR

• 올바른 레이어에 캐시 (페이지, 쿼리, 객체, 엣지).
• 각 데이터 유형에 맞는 TTL 또는 이벤트‑기반 전략 선택.
• 히트율과 지연 시간 모니터링; 데이터가 오래되거나 폭발하기 전에 조정.

규율 있는 캐싱 전략을 통해 낭비적인 “충분히 빠름”을 진정으로 효율적이고 확장 가능한 성능으로 바꿀 수 있습니다.

# Cache Health Checklist

✅ INFO 통계 확인

• keyspace_hits와 keyspace_misses를 찾아보세요.

📈 로그 지연 / 놓친 조회

• 캐시가 조용히 실패한 라우트를 태그합니다.

⚡️ Detect Cache Stampedes

• Identify when many users request the same uncached item at once.
• Consider locking or stale‑while‑revalidate strategies.

⏰ TTL 만료 추적

• TTL이 실제 사용 패턴과 일치하는지 확인합니다.

고급 패턴 (준비가 되었을 때)

Stale‑While‑Revalidate

• 오래된 데이터를 즉시 제공한다.
• 백그라운드에서 최신 데이터를 가져와 캐시를 교체한다.
• 사용자에게 대기 시간을 줄이고 인지된 지연을 감소시킨다.
• 구현 옵션:
  • HTTP 헤더: Cache-Control: stale-while-revalidate=60
  • 애플리케이션 내 커스텀 미들웨어.

Soft TTL + Refresh

• 항목에 TTL이 설정되어 있지만, 만료 시점에 가까워지면 백그라운드에서 새로 고친다.
• 콜드 스타트를 방지하고 핫 아이템을 지속시킨다.
• 자주 접근되지만 업데이트는 드물게 일어나는 데이터에 적합하다.
• 구현 옵션:
  • 비동기 작업 큐
  • 미들웨어 훅

Sharded or Namespaced Caches

• 키 접두사를 사용해 캐시 범위를 구분한다.
  • 예시: tenant-42:user:profile, locale-en:settings
• 키 충돌을 방지하고 대량 무효화를 단순화한다.
• 향후 자동화를 지원하도록 구조화된 키‑네이밍 규칙을 채택한다.

캐싱 안티‑패턴

• 사용자별 또는 민감한 데이터를 전역적으로 캐싱 – GDPR 위반이 될 가능성이 높음.
• 매일 변경되는 데이터에 대해 긴 TTL을 하드코딩 – 빠르지만 잘못된 방법.
• 삭제 전략 없이 모든 것을 캐싱 – 두 번째, 관리되지 않는 데이터베이스가 생김.

TL;DR – Cache with Intent

• Don’t optimize slow things – 반복해서 수행하지 않도록 하세요.
• 올바른 문제에 맞는 적절한 캐시를 선택하세요.
• 라이브하기 전에 캐시‑무효화 전략을 설계하세요.
• 캐시 크기만이 아니라 hit rates를 모니터링하세요.
• 캐싱은 부정행위가 아니라 systems scale하는 방식입니다.
• 여러분의 앱은 지금 fast한 것에 그치지 않고 efficient합니다.
• 하지만 don’t relax too long… read and write workloads를 splitting하기 need합니다.

Stay tuned.
Next up: Scaling Reads Without Sharding Your Soul