백엔드/DB
Redis vs Memcached
작은소행성☄️
2025. 11. 26. 16:12
728x90
캐시를 쓰려고 하면 Memcached,Redis 두 개가 있다.
둘 다 “인메모리 캐시”지만, 성격이 다르다.
실무 기준으로 어떤 걸 언제 쓰면 좋은지만 간단히 정리해보겠다.
1. 한 줄 요약
- Memcached
- 단순 key-value 캐시. 가볍고 빠르다.
- 그냥 “DB 앞에 두는 캐시”만 필요할 때.
- Redis
- 인메모리 데이터 스토어. 자료구조, 기능이 매우 많다.
- 캐시 + 세션 + 토큰 + 랭킹 + 큐 + 락 등 “상태”를 다루고 싶을 때.
2. 공통점
- 메모리에 데이터를 올림
- key → value 로 읽기
- DB 앞단에 두고 읽기 부하 줄이는 용도
예를 들어, 상품 상세 조회의 이 패턴까지는 Redis, Memcached 모두 동일하게 가능하다.
1) 캐시에서 product:{id} 조회
2) 있으면 바로 반환
3) 없으면 DB 조회 후 캐시에 저장
3. Memcached
특징
- value는 거의 String(바이트 배열)만 쓴다고 보면 된다.
- 지원 연산: get, set, delete, incr/decr 정도.
- 디스크 저장 없음 → 재시작하면 전부 날아감.
- 구조가 단순해서 순수 캐시 성능/메모리 효율은 좋다.
언제 쓰면 괜찮나?
- HTML이나 JSON 응답처럼 렌더링 결과를 통째로 캐시할 때,
혹은 세션이 날아가도 “다시 로그인하면 그만”인 수준의 아주 단순한 세션 캐시만 필요할 때처럼,
캐시 이외의 기능을 쓸 일이 거의 없다고 확신되는 상황이라면
Memcached처럼 진짜 “캐시 전용” 도구를 선택해도 충분하다.
4. Redis
특징
Redis는 자료구조가 다양하다.
- String, Hash, List, Set, Sorted Set
- 그리고 Pub/Sub, Stream, Geo, HyperLogLog 등등
- RDB/AOF 같은 persistence 옵션으로 디스크 저장 가능
- 분산 락, 큐, 랭킹, 세션 스토어 등 “상태 관리” 패턴을 구현하기 좋다.
언제 쓰면 괜찮나?
- Redis는 단순히 상품 정보나 메타데이터 같은 캐시뿐 아니라, 세션·토큰 저장, 호출 횟수 카운터/레이트 리밋, 랭킹, 간단한 작업 큐, 분산 락까지 한 번에 처리할 수 있는 “캐시 + 상태 관리”용 도구다. 그래서 처음엔 캐시로만 시작해도, 나중에는 세션·큐·락 요구 때문에 Redis로 확장되는 경우가 많다.
실무에서 자주 쓰는 패턴
- 캐시
- 상품 정보, 메타데이터 캐시
- 세션 / 토큰
- session:{id}, access:{token}, refresh:{userId} 형태로 저장
- 카운터 / rate limit
- INCR + TTL로 유저별 호출 횟수 제한
- 랭킹
- Sorted Set으로 “오늘 판매 TOP N” 같은 데이터 관리
- 간단한 큐
- List + RPUSH / BLPOP 으로 작업 큐 구성
- 분산 락
- SET key value NX PX ... 로 여러 서버에서 공유 락 구현
5. 선택 기준
Memcached를 고려할 상황
- 진짜로, 캐시밖에 안 쓴다 는 게 거의 확실함
- value는 문자열/바이트 배열로만 충분
- 장애 시 데이터 날아가도 상관 없음
- 조직이 이미 Memcached 위주로 잘 쓰고 있음
Redis를 고려할 상황 (요즘 대부분 여기에 해당)
- 캐시 + 세션 + 토큰 + 랭킹 + 큐 같은 것들을 같은 스토어에서 처리하고 싶을 때
- 나중에 요구사항이 늘어날 가능성이 높음
- 관리형 Redis(ElastiCache for Redis 등)를 이미 쓰고 있거나, 운영 경험이 있음
- 상품 데이터, member 세션, access/refresh token 같이 로그인/상태 값도 올릴 계획일 때
6. 결론
단순 캐시만 필요하면 Memcached, 앞으로 이것저것 상태를 다루고 싶으면 Redis.
요즘 백엔드/AI/커머스 서비스들은 대체로 후자에 가깝기 때문에 새로 시작하는 서비스라면 보통 Redis 한 방향으로 통일하는 편이 운영·확장 모두 편하다.
728x90
반응형