NestJS 성능과 확장

캐싱 전략: 캐시 키와 TTL 실패 모드 점검

캐시는 빠르게 만드는 기술이 아니라 언제 틀릴 수 있는지를 정하는 기술입니다. key, TTL, 무효화, 동시 만료 방어를 함께 봅니다.

01

Cache key와 TTL 정책

사용자, 권한, query param이 결과에 영향을 주면 key에 포함하고 TTL은 데이터 변경 주기보다 짧게 둡니다.

key 설계
02

CacheInterceptor와 Redis 경계

Nest CacheInterceptor, custom key builder, Redis client, invalidation event를 같은 domain key 규칙으로 연결합니다.

Redis 경계
03

Stale data와 stampede

무효화가 누락되면 오래된 값이 남고 hot key가 동시에 만료되면 DB가 몰리므로 lock, jitter, prewarm 기준을 둡니다.

만료 방어
04

Hit ratio와 key 만료 증거

hit/miss ratio, key cardinality, TTL 분포, DB query 감소량, Redis slow log를 측정 기록으로 남깁니다.

cache 지표
책임
cache key는 응답을 바꾸는 입력을 모두 포함해야 한다 userId, tenant, query param, locale 같은 값이 빠지면 서로 다른 요청이 같은 캐시를 공유합니다.
key
경계
TTL과 invalidation은 데이터 변경 이벤트와 함께 관리한다 CacheInterceptor의 기본 TTL과 Redis key builder, domain event 무효화를 같은 namespace로 묶어 stale data를 줄입니다.
TTL
Stampede
hot key 만료와 cache stampede는 부하 테스트로 확인한다 동시 요청이 몰릴 때 lock, jitter, fallback TTL이 DB full load를 막는지 hit ratio와 query 수로 검증합니다.
load

Cache key와 TTL 무효화 검증 지점

Cache hit와 fallback cache key 생성, Redis hit, TTL 설정, 원본 provider fallback이 같은 요청 조건을 기준으로 움직이는지 확인합니다.
Stale과 key collision stale data, key collision, stampede를 재현하지 않으면 빠른 응답 뒤에 잘못된 데이터가 남습니다.
Hit ratio와 slow log hit ratio, TTL 분포, Redis slow log, DB query 감소량을 배포 전후로 남깁니다.

Cache TTL 점검

질문: 캐시 키와 TTL이 사용자별 응답을 섞지 않고 stale data를 제한하는가
순서: key 구성값 정의 -> TTL/invalidation event 연결 -> hit ratio와 DB query 감소량 측정
위험: tenant나 query param이 key에서 빠지면 권한이 다른 사용자가 같은 cached response를 볼 수 있습니다.