Redis 비교와 선택 기준
Redis는 빠르고 편하지만 모든 문제의 답은 아닙니다. 비교 기준은 데이터를 얼마나 오래 안전하게 보관해야 하는지, 어떤 조회가 필요한지, 장애 시 무엇을 잃어도 되는지입니다.
용어
| 용어 |
의미 |
| Local Cache |
애플리케이션 프로세스 안의 캐시 |
| Distributed Cache |
여러 서버가 공유하는 외부 캐시 |
| Message Broker |
메시지를 저장하고 consumer에게 전달하는 시스템 |
| RDBMS |
관계형 데이터베이스 |
| Document DB |
JSON 문서 중심 NoSQL |
Redis vs Memcached
| 기준 |
Redis |
Memcached |
| 자료구조 |
다양함 |
단순 key-value 중심 |
| persistence |
지원 |
보통 없음 |
| 기능 |
TTL, Lua, Stream, Pub/Sub 등 |
캐시 중심 |
| 선택 |
캐시 외 기능도 필요 |
단순 캐시만 필요 |
Redis vs Local Cache
| 기준 |
Redis |
Local Cache |
| 공유 |
여러 서버 공유 |
서버별로 따로 보관 |
| 속도 |
네트워크 RTT 있음 |
가장 빠름 |
| 정합성 |
중앙 저장소라 비교적 관리 쉬움 |
서버 간 stale 문제 |
| 사용 |
여러 인스턴스가 같은 캐시 공유 |
아주 짧은 설정·hot key 완화 |
Redis vs Caffeine
| 기준 |
Redis |
Caffeine |
| 위치 |
외부 서버 |
JVM 프로세스 내부 |
| 공유 |
가능 |
불가 |
| 장애 |
Redis 장애 고려 |
앱 메모리 영향 |
| 사용 |
분산 캐시 |
초고속 local cache |
Redis와 Caffeine은 함께 쓰기도 합니다. Caffeine은 1차 local cache, Redis는 2차 shared cache 역할을 맡습니다.
Redis vs Kafka
| 기준 |
Redis |
Kafka |
| 핵심 |
빠른 상태 저장 |
분산 이벤트 로그 |
| 메시징 |
Pub/Sub, Stream |
topic, partition, offset |
| 보관 |
메모리와 trim/TTL 영향 |
긴 retention과 재처리 |
| 사용 |
짧은 상태, 가벼운 메시징 |
서비스 간 핵심 이벤트 |
Redis Stream vs Kafka
| 기준 |
Redis Stream |
Kafka |
| 운영 난도 |
상대적으로 단순 |
더 복잡하지만 강력 |
| 재처리 |
가능 |
offset 기반 강점 |
| scale |
Redis 메모리와 cluster 설계 영향 |
대규모 처리량 강점 |
| 사용 |
Redis 내부 작업, 작은 이벤트 |
장기 이벤트 파이프라인 |
Redis Pub/Sub vs Message Queue
| 기준 |
Pub/Sub |
Message Queue |
| 저장 |
없음 |
보통 저장 |
| 재처리 |
어려움 |
가능 |
| 구독자 부재 |
메시지 손실 |
나중에 소비 가능 |
| 사용 |
실시간 알림 |
작업 큐, 이벤트 처리 |
Redis vs RDBMS
| 기준 |
Redis |
RDBMS |
| 강점 |
속도, TTL, 원자 명령 |
트랜잭션, 조인, 정합성 |
| 저장 |
메모리 중심 |
디스크 중심 |
| 원장 |
부적합 |
적합 |
| 사용 |
보조 저장소 |
원본 저장소 |
Redis vs NoSQL Document DB
| 기준 |
Redis |
Document DB |
| 목적 |
빠른 key-value 상태 |
JSON 문서 저장과 조회 |
| 검색 |
제한적, 모듈 필요 |
문서 조건 조회 |
| 영속성 |
가능하지만 캐시 성격 강함 |
원본 저장소로 사용 가능 |
| 사용 |
캐시·임시 상태 |
문서 데이터 저장 |
Redis를 쓰면 좋은 경우
| 상황 |
이유 |
| 반복 조회가 많음 |
DB 부하 감소 |
| TTL 상태가 필요 |
자동 만료 |
| 원자 카운터 필요 |
INCR |
| 랭킹 필요 |
Sorted Set |
| 짧은 분산 락 필요 |
SET NX PX |
| 실시간 가벼운 알림 |
Pub/Sub |
Redis를 쓰면 안 되는 경우
| 상황 |
이유 |
| 결제 원장 |
유실·정합성 위험 |
| 복잡한 조인 |
RDBMS 사용이 적합 |
| 긴 메시지 보관과 재처리 |
Kafka 등 브로커 적합 |
| 대용량 검색 |
검색 엔진 또는 Redis Stack 검토 |
| 메모리 비용이 감당 안 됨 |
디스크 기반 저장소 검토 |
베스트 프랙티스
| 권장 방식 |
이유 |
| Redis를 원본 저장소로 볼지 먼저 질문 |
위험한 설계 방지 |
| 캐시와 원장 역할 분리 |
장애 복구 기준 명확화 |
| 메시징 요구는 Kafka와 비교 |
재처리·보관 요구 확인 |
| local cache와 조합 검토 |
hot key와 RTT 완화 |
실무에서는?
| 요구 |
선택 |
| 빠른 조회 캐시 |
Redis |
| 서버 내부 초고속 캐시 |
Caffeine |
| 서비스 간 이벤트 로그 |
Kafka |
| 트랜잭션 원장 |
RDBMS |
| 문서 검색 |
Document DB 또는 검색 엔진 |
관련 파일:
- Kafka
- 캐시 전략과 정합성
- Redis Stack과 확장 기능