Redis 베스트 프랙티스
Redis 베스트 프랙티스는 캐시를 빠르게 쓰는 방법만이 아니라, 장애가 나도 서비스가 무너지지 않게 만드는 운영 기준입니다.
Key 설계
| 권장 |
이유 |
domain:{id}:purpose 형태로 작성 |
의미와 삭제 범위가 명확함 |
| key prefix를 표준화 |
모니터링과 장애 분석이 쉬움 |
| Cluster 다중 key는 hash tag 사용 |
CROSSSLOT 방지 |
| key version 고려 |
payload 구조 변경 시 충돌 방지 |
TTL 설계
| 권장 |
이유 |
| 캐시 key에는 TTL 기본 적용 |
무한 증가 방지 |
| TTL jitter 적용 |
동시 만료 방지 |
| null cache는 짧은 TTL |
penetration 방지와 메모리 절충 |
| TTL 없는 key는 목록화 |
의도치 않은 영구 key 방지 |
캐시 설계
| 권장 |
이유 |
| Cache Aside를 기본으로 시작 |
단순하고 fallback이 쉬움 |
| DB update 후 cache delete |
stale data를 줄이는 안전한 기본값 |
| Cache Warming은 핵심 데이터만 |
과도한 warming으로 DB·Redis 부하 방지 |
| Hit Ratio를 API별로 관찰 |
평균 착시 방지 |
분산락
| 권장 |
이유 |
SET NX PX 사용 |
원자적 락 획득 |
| value에 owner token 저장 |
내 락인지 확인 |
| Lua로 해제 |
다른 요청의 락 삭제 방지 |
| DB unique와 함께 사용 |
Redis 장애·중복 실행 대비 |
| 작업 시간보다 TTL 여유 |
작업 중 락 만료 방지 |
Stream
| 권장 |
이유 |
| consumer는 멱등하게 구현 |
재처리와 중복 대비 |
XACK 시점 명확화 |
처리 전 ACK로 인한 유실 방지 |
| PEL 모니터링 |
죽은 consumer 메시지 확인 |
| DLQ stream 준비 |
poison message 격리 |
| trim 정책 설정 |
stream 무한 증가 방지 |
Spring Boot 연동
| 권장 |
이유 |
| serializer 명시 |
운영 중 데이터 호환성 관리 |
| command timeout 설정 |
Redis 장애 전파 방지 |
| fallback 정책 정의 |
조회 캐시 장애 대응 |
| Testcontainers 사용 |
실제 Redis 명령 검증 |
| RedisTemplate과 Spring Cache 역할 분리 |
추상화 혼동 방지 |
운영 환경
| 권장 |
이유 |
maxmemory와 eviction 정책 명시 |
메모리 장애 동작 예측 |
KEYS 금지, SCAN 사용 |
event loop blocking 방지 |
| big key/hot key 점검 |
대표 장애 예방 |
| slowlog와 latency 알림 |
장애 전조 감지 |
| failover 훈련 |
실제 복구 가능성 확인 |
보안
| 권장 |
이유 |
| private network 배치 |
외부 노출 방지 |
| AUTH/ACL 적용 |
접근 제어 |
| 최소 권한 user 분리 |
피해 범위 축소 |
| 위험 명령 제한 |
운영 사고 예방 |
| TLS 검토 |
네트워크 암호화 |
장애 대응
| 권장 |
이유 |
| Runbook 작성 |
장애 시 판단 시간 단축 |
| fallback과 circuit breaker |
Redis 장애 격리 |
| backup/restore 훈련 |
복구 가능성 검증 |
| DB 기준 복구 경로 확보 |
Redis 유실 대응 |
| 장애 후 보정 쿼리 준비 |
카운터·랭킹 정합성 회복 |
Redis 안티패턴
| 안티패턴 |
문제 |
| Redis를 원장 DB처럼 사용 |
유실·정합성·감사 문제 |
| TTL 없는 캐시 key 방치 |
메모리 증가 |
KEYS * 운영 사용 |
전체 지연 |
| 큰 Hash/Set 하나에 무한 저장 |
big key |
| 인기 key 하나에 모든 요청 집중 |
hot key |
| 락만 믿고 멱등성 없음 |
중복 실행 위험 |
| serializer 변경 계획 없음 |
기존 데이터 역직렬화 실패 |
실무 체크리스트
| 체크 |
질문 |
| 용도 |
캐시, 상태, 락, 메시징 중 무엇인가 |
| 원본 |
Redis가 비어도 복구 가능한가 |
| TTL |
만료 정책이 명확한가 |
| Key |
prefix와 삭제 범위가 명확한가 |
| 메모리 |
maxmemory와 eviction이 설정됐는가 |
| 성능 |
big key, hot key, O(N) 명령을 피했는가 |
| 장애 |
fallback과 circuit breaker가 있는가 |
| 보안 |
외부 노출, AUTH/ACL, 위험 명령을 점검했는가 |
| 관찰 |
hit ratio, latency, memory, evictions 알림이 있는가 |
| 검증 |
failover와 restore를 실제로 해봤는가 |
관련 파일:
- Redis 개요
- 장애 대응과 트러블슈팅
- 모니터링과 보안