Redis vs Memcached

개요

프로젝트를 진행하면서 인메모리 캐시를 도입해야 했던 시점이 있었습니다.
처음에는 많은 개발자들이 사용하는 Redis를 선택하려고 했지만,
Memcached라는 대안도 있다는 사실을 알고 두 엔진을 비교해보게 되었습니다.
 

---

특징

Memcached

• 멀티 스레드 아키텍처로 높은 병렬 처리에 강함
• Key-Value 기반 순수 메모리 캐시
• 오직 문자열 기반 캐시
• 매우 가벼움
• 단일 목적: 빠른 읽기/쓰기

Redis

• Key-Value 기반의 데이터 구조 서버(data structure server)
• 문자열, Hash, List, Set, Sorted Set 등 다양한 자료구조 지원
• Persistence(RDB, AOF) 지원
• Pub/Sub, Lua Script 등 부가 기능 풍부
• 트랜잭션 제공

비교

성능 (읽기/쓰기 속도)

• Redis
  • 자료구조 기반 기능을 고려하면 속도도 매우 빠름

• Memcached
  • 초고속 단순 캐싱에 매우 적합

기능/자료구조

• Redis
  • 다양한 자료구조 → 랭킹, 세션, 카운터 등에 최적
• Memcached
  • “문자열 캐시”만 필요할 때 적합

메모리 관리 방식

• Redis
  • 메모리를 자료구조별로 효율적으로 관리
• Memcached
  • Slab Allocator 사용 → 작은 value 연속 삽입 시 비효율 발생 가능

스케일링

• Redis
  • Cluster 모드 지원
• Memcached
  • 수평 확장 쉬움(Stateless라 단순히 여러 개 띄우면 끝)

Persistence(데이터 영속성)

• Redis
  • RDB / AOF로 디스크 저장 가능
• Memcached
  • 영속성 없음 → 캐시 miss 발생해도 괜찮은 서비스에 적합

Replication & High Availability

• Redis
  • Replica, Sentinel, Cluster 등 다양한 HA 옵션
• Memcached
  • 자체 HA 기능 없음, 앱 레벨에서 해결

TTL (Time-To-Live) 정확성 & 동작 방식

• Redis
  • TTL이 지나면 즉시 만료 처리
  • TTL 조회 가능
  • 다양한 eviction 정책 제공 → TTL 유지 보장 가능
  • Persistence(RDB/AOF) 시 TTL도 함께 저장됨
• Memcached
  • TTL은 lazy expiration(접근 시 만료)
  • 메모리 부족 시 TTL 남아도 LRU로 먼저 삭제됨
  • TTL 조회 불가
  • TTL 정확성이 낮아 임시 데이터/토큰 저장에는 부적합

도입 사례

진행했던 프로젝트에서 In-Memory 캐시를 사용하는 기능은 2가지였습니다.

1. 인기글 캐싱
2. 회원가입 시 회원 정보 임시 저장 (key: token, value: 회원 정보)

---

인기글 캐싱

프로젝트에서는 지정된 시간마다 DB에서 정렬된 인기글 post Id들을 조회하고 이를 캐싱하는 방식을 선택했습니다.
이러한 구현 방식에서는 MemCache를 사용해도 무방하다고 생각합니다.

---

반면, 게시글 Count을 Sorted Set에 저장하고 변동이 있는 게시글의 postId: Count를 기반으로 캐싱하는 방식이라면 Redis를 선택해야 한다고 생각합니다.

• Redis의 원자적 증가 연산(HINCRBY/ZINCRBY)
• Sorted Set 기반 랭킹
• RDB/AOF로 복구 가능

회원 정보 임시 저장

회원가입 절차가 2단계로 이루어져 있기 때문에
1단계에서 입력한 회원 정보를 임시 저장 할 필요가 있었습니다.
적합한 캐싱 엔진은 Redis라고 생각했습니다.

• TTL 정확성
• RDB/AOF로 복구 가능
• Hash/JSON 기반으로 구조화된 데이터 저장 가능

정리

결론적으로, 이 프로젝트에서는 Redis가 더 적합하다고 판단해 Redis를 도입했습니다.
비교를 하면 Redis가 훨씬 강력해 보이지만 단점도 분명히 존재합니다.

• 구조가 복잡함
  • 다양한 자료구조 제공 → 잘못 사용 시 성능 저하 가능
• 러닝커브가 높음
  • Sentinel, Cluster 등 구성이 어려움
  • 운영/모니터링/메모리 튜닝 필요
• 싱글 스레드 기반이라 CPU 병목 가능
  • Redis는 단일 스레드 이벤트 루프라 CPU가 높은 환경에서는 한계 발생 → Redis Cluster
• 메모리 비용이 상대적으로 높음
  • 자료구조로 인해 Memcached보다 메모리 사용량 많음
• Persistence 비용
  • RDB/AOF는 디스크 I/O 부담
  • 재시작 시 복구 시간이 길어질 수 있음
• 복잡한 자료구조 운영의 어려움
  • Hash/ZSet 크기가 커지면 마이그레이션, 프래그멘테이션, 성능 이슈 발생

결국 중요한 것은 “무조건 Redis를 쓰자” 보다는, 서비스의 요구 사항에 맞는 적절한 기술을 선택하는 것 이라고 생각합니다.