Redis Cache Best Practices

Redis를 붙였다고 캐시 전략이 끝나는 것은 아니다

Redis는 빠르지만, 캐시 설계가 잘못되면 장애를 더 빠르게 전파할 수도 있다. 중요한 것은 Redis 자체보다 무엇을, 얼마나 오래, 어떤 방식으로 캐시할지를 정하는 일이다.

기본 원칙

키를 명확히 설계

키는 사람이 읽기 쉬우면서도 충돌을 피해야 한다.

• product:123
• user-profile:v2:42
• feed:home:region:kr

버전 정보와 도메인 prefix를 포함하면 무효화 전략과 스키마 변경 대응이 쉬워진다.

TTL에 근거를 두기

TTL이 너무 짧으면 미스가 잦아지고, 너무 길면 오래된 데이터가 남는다. 데이터 변경 주기와 허용 가능한 stale window를 기준으로 정하는 편이 낫다.

미스 비용을 같이 보기

캐시는 결국 미스가 났을 때 원본 저장소가 감당할 수 있어야 의미가 있다. DB, 외부 API, 계산 비용을 함께 고려해야 한다.

자주 하는 실수

• 모든 데이터를 Redis에 넣으려 한다.
• TTL 없이 영구 캐시처럼 사용한다.
• 큰 객체를 무분별하게 직렬화한다.
• 무효화 전략 없이 덮어쓰기만 반복한다.
• hot key를 방치한다.

운영 지표

• hit ratio
• eviction 발생량
• key/value 크기
• TTL 분포
• hot key 존재 여부
• 네트워크 왕복 지연

Redis는 메모리 기반이라 빠르지만, 여전히 원격 네트워크 호출이다. 로컬 캐시와 함께 2계층으로 설계하는 이유도 여기에 있다.

정리

Redis 캐시 운영의 핵심은 “무조건 넣는다”가 아니라, 비용이 큰 읽기를 어디까지 흡수하고 stale 데이터를 어디까지 허용할지를 명확히 정하는 데 있다.