Redis 실무 유즈케이스
Redis 유즈케이스는 대부분 빠르게 읽기, 짧게 저장하기, 원자적으로 증가시키기, 중복 실행 막기로 나뉩니다.
용어
| 용어 |
의미 |
| 조회 캐시 |
DB 조회 결과를 Redis에 저장 |
| 세션 |
로그인 상태를 서버 외부에 저장 |
| Refresh Token |
재발급용 토큰 상태 저장 |
| 인증번호 |
이메일/SMS 코드처럼 짧게 살아야 하는 값 |
| Idempotency Key |
같은 요청이 여러 번 와도 한 번만 처리하기 위한 key |
| Presence |
사용자의 접속 상태 |
질문
Redis에 저장해도 되는 데이터인가?
아래 질문에 “예”라고 답하기 어려우면 Redis 단독 저장을 피합니다.
| 질문 |
이유 |
| Redis가 비어도 다시 만들 수 있는가? |
캐시 적합성 |
| TTL이 있어도 되는가? |
임시 상태 적합성 |
| 유실되어도 보정 가능한가? |
장애 허용 범위 |
| 원본은 DB에 있는가? |
복구 기준 |
대표 유즈케이스
| 유즈케이스 |
자료구조 |
설계 기준 |
| 단순 캐시 |
String |
TTL, null cache |
| DB 조회 캐시 |
String/Hash |
Cache Aside, update 후 delete |
| 세션 관리 |
String/Hash |
TTL, 로그아웃 삭제 |
| JWT blacklist |
String |
token 만료까지 TTL |
| Refresh Token 저장 |
String/Hash |
사용자·기기 단위 key |
| 인증번호 저장 |
String |
짧은 TTL, 시도 횟수 제한 |
| 랭킹 보드 |
Sorted Set |
기간별 key, 오래된 key 만료 |
| 좋아요 목록 |
Set |
중복 방지, cardinality 확인 |
| 조회수 카운터 |
String INCR |
DB 반영 주기와 유실 허용 범위 |
| 중복 요청 방지 |
String SET NX EX |
idempotency key |
| Rate Limiting |
String/ZSet |
window 방식 선택 |
| 대기열 시스템 |
List/Sorted Set/Stream |
순서, 재처리 요구 확인 |
| 결제 임시 상태 |
String |
TTL, DB 원장 검증 필수 |
| 외부 API 응답 캐시 |
String |
실패 fallback, TTL |
| 실시간 알림 |
Pub/Sub/Stream |
유실 허용 여부 |
| 채팅 Presence |
String/Set |
짧은 TTL, heartbeat |
| 분산 환경 설정 공유 |
String + Pub/Sub |
local cache 무효화 |
세션 관리
key: session:{sessionId}
value: userId, roles, createdAt
TTL: 세션 만료 시간
| 장점 |
주의 |
| 여러 서버가 세션 공유 가능 |
Redis 장애 시 재로그인 정책 필요 |
| TTL로 자동 만료 |
세션 탈취와 보안 설정 필요 |
JWT / Refresh Token
| 항목 |
기준 |
| Access Token blacklist |
로그아웃·탈취 대응이 필요할 때 |
| Refresh Token |
사용자·기기별 저장, rotation 검토 |
| TTL |
토큰 만료 시간과 맞춤 |
Redis에 토큰을 저장하더라도 인증의 최종 보안 정책은 서버 로직과 DB 사용자 상태를 함께 봐야 합니다.
인증번호 저장
SET auth:email:user-1 "123456" EX 180
INCR auth:email:user-1:attempt
인증번호는 TTL이 명확해서 Redis에 잘 맞습니다. 다만 재전송 제한, 검증 횟수 제한, brute force 방지가 필요합니다.
랭킹 보드
ZADD rank:daily:20260427 1200 user-1
ZREVRANGE rank:daily:20260427 0 99 WITHSCORES
기간별 key를 나누고 오래된 랭킹은 TTL로 정리합니다.
좋아요 / 조회수 카운터
| 기능 |
방식 |
주의 |
| 좋아요 여부 |
Set |
사용자가 많으면 big key 주의 |
| 조회수 |
INCR |
DB 반영 전 장애 시 유실 허용 범위 결정 |
| 중복 조회 방지 |
Set/Bitmap |
기간별 key 분리 |
Idempotency Key
SET idempotency:payment:req-123 "processing" NX EX 300
중복 결제, 중복 쿠폰 발급처럼 같은 요청이 여러 번 들어올 수 있는 곳에 사용합니다. Redis key만 믿지 말고 DB unique 제약을 함께 둡니다.
대기열 시스템
| 방식 |
특징 |
| List |
단순 FIFO |
| Sorted Set |
점수 기반 순서 |
| Stream |
consumer group과 재처리 |
대기열이 핵심 기능이고 유실·재처리가 중요하면 Kafka나 전용 큐와 비교합니다.
베스트 프랙티스
| 권장 방식 |
이유 |
| key에 도메인과 사용자/리소스 ID 포함 |
추적과 삭제가 쉬움 |
| TTL이 필요한 유즈케이스부터 Redis 적용 |
Redis 장점을 살리기 쉬움 |
| 원장성 데이터는 DB 기준으로 검증 |
Redis 유실 대비 |
| 기간별 key 분리 |
랭킹·카운터 정리 쉬움 |
| 장애 시 fallback 정책 결정 |
인증·결제·제한 기능의 동작이 달라짐 |
실무에서는?
| 상황 |
판단 |
| "없어져도 다시 만들 수 있음" |
캐시로 적합 |
| "짧은 시간만 필요함" |
TTL 상태로 적합 |
| "중복 실행만 줄이면 됨" |
락/idempotency key 적합 |
| "돈·재고·포인트 원장" |
Redis 단독 저장 부적합 |
관련 파일:
- 캐시 전략과 정합성
- 트랜잭션과 동시성
- Spring Boot Redis 연동