1. Redis 란?
Redis (Remote Dicionary Server)는 메모리(RAM)를 주 저장 공간으로 사용하는 초고속 Key-Value 기반의 인 메모리 데이터 저장소이며, 문자열 뿐아니라 Hash, List, ZSet, Stream 같은 자료구조를 제공한다.
1-1. 그렇다면, Redis vs RDB (MySQL)
- Redis
- Key / Value ( String, Hash, List, Stream )
- 조인 x, 단건 /간단 연산에 빠름
- 메모리 기반 → 엄청 빠름 (지연시간 ↓)
- 기본이 메모리라 장애 시 유실 가능성이 있지만, RDB/AOF로 조절 가능하긴 하다.
- 단일 명령은 원자적, 복합 로직은 Lua 스크립트로 원자 처리하거나 분산락으로 제어
- RDB
- 테이블 (행/열) + 관계(FK) 기반
- 조인/집계 같은 복잡한 질의에 강함
- 디스크 기반 → 상대적으로 느리지만 범용적
- 기본이 영구 저장 + 트랜잭션 (ACID) 강력 + 백업/복구 유리
- 트랜잭션 + 락 + 격리수준으로 정합성 보장
- 활용 용도
- RDB : 정확하고 영구적으로 쌓는 메인 데이터베이스
- Redis : 빠른 처리 (캐시,세션,락,큐)에 특화된 인메모리 데이터 저장소
2. Redis 활용 용도 (캐시, 세션, 락, 큐)
2-1. 캐시(Cache)
캐시란?
자주 조회되는 데이터를 Redis에 잠깐 저장해두고, 다음 요청부터는 DB나 외부 API를 다시 안 타게 만드는 방식이다.
- Redis 로 캐시를 활용하는 이유
- Redis는 메모리 기반이라 응답 속도가 빠르고, DB 부하를 줄이는데 효과적이다.
- 특히 트래픽이 몰리는 서비스에서 “조회 성능 개선 + DB 보호” 용도로 많이 사용된다.
- Redis는 메모리 기반이라 응답 속도가 빠르고, DB 부하를 줄이는데 효과적이다.
- 캐시 적용 시 고려할 3가지
- TTL (만료 시간)
: 캐시는 원본 데이터와 달라질 수 있으므로, 일정 시간이 지나면 자동으로 삭제 되도록 만료시간 설정을 해야한다. - 캐시 무효화 (Cache Invalidation)
: 원본 데이터가 변경되면 캐시도 함께 삭제하거나 갱신해야 오래된 데이터 문제를 줄일 수 있다. - 캐시 스탬피드(Cache Stampede)
: 캐시가 동시에 만료되거나 미스가 발생하면 요청이 한꺼번에 DB로 몰려 폭주할 수 있다.
이를 방지하기 위해 락을 걸거나, singleFlight(동일 요청 1개만 원본 조회) 같은 방식으로 제어 한다.
- TTL (만료 시간)
2-2. 세션(Session Store)
세션이란?
사용자의 로그인 상태나 사용자별 상태(장바구니, 인증 상태 등)을 Redis에 저장해두고 서버들이 공통으로 읽도록 하는 방식이다.
- Redis로 세션을 활용하는 이유
- 서버가 여러 대일 때 (로드밸런싱)도 로그인/상태를 유지하기 좋다.
→ 로드밸런싱이란? 여러 대의 서버에 들어오는 요청(트래픽)을 골고루 나눠주는 것 - 세션 데이터를 애플리케이션 서버 메모리에 두지 않아도 되어 확장성(Scale-out)이 좋아진다.
- 메모리 기반이라 세션 조회가 빠르다.
- 서버가 여러 대일 때 (로드밸런싱)도 로그인/상태를 유지하기 좋다.
- 세션 적용 시 고려할 3가지
- TTL (세션 만료)
: 세션은 영구 데이터가 아니라 만료가 필요하다. Redis에 TTL을 두고 자동 만료되게 설계한다. - 보안(세션 하이재킹 방지)
: 쿠키 설정 (HttpOnly, Secure(Https), SameSite) 같은 옵션을 적절히 적용한다. - 세션 정리/무효화 전략
: 로그아웃, 비밀번호 변경, 권한 변경 시 기존 세션을 강제만료 시키는 전략이 필요하다.
- TTL (세션 만료)
2-3. 락(Lock)
락이란?
동시에 여러 요청이 같은 자원을 수정하려 할 때, 한 번에 하나만 처리되도록 막는 동시성 제어 방식이다.
- Redis로 락을 활용하는 이유
- Redis는 단일 명령이 원자적으로 처리되어 락 구현에 유리하다.
- DB 락에 의존하지 않고도 분산환경에서 공통 락을 잡을 수 있다.
- 예약/결제/선착순 같은 동시 요청 충돌을 막는 데 효과적이다.
- Redis는 단일 명령이 원자적으로 처리되어 락 구현에 유리하다.
- 락 적용 시 고려할 3가지
- TTL (락 만료시간)
: 락을 잡은 서버가 죽으면 영원히 잠길 수 있으니, 반드시 TTL을 둬서 자동 해제되게 한다. - 락 해제 안정성
: 락을 풀 때는 “내가 잡은 락인지”를 검증하고 해제해야 한다. 보통 락 value에 랜덤 토큰을 넣고, Lua 스크립트로 검증+삭제를 원자적으로 처리한다. - 재시도/대기 전략
: 락 획득 실패 시 바로 실패할지, 일정 시간 재시도할지, 대기(백오프)를 둘지 정책이 필요하다.
대기 시간이 길면 UX 가 나빠질 수 있어 “빠른 실패+안내”도 흔한 선택이다.
- TTL (락 만료시간)
2-4. 큐(Queue) / 이벤트
큐란?
처리해야 할 작업을 바로 실행하지 않고 “대기열”에 넣고, 워커가 순서대로 처리하는 방식이다. 이벤트는 “무언가 발생했다”는 사실을 전달하는 메시지이다.
- Redis로 큐를 활용하는 이유
- 느린 작업(알림 발송, 로그 저장, 이미지 처리)을 요청 흐름에서 분리하면 응답이 빨라진다.
- 트래픽이 몰려도 큐가 완충 역할을 해 시스템이 안정적이다.
- Redis 자료구조 (List, Stream)로 간단히 구현할 수 있다.
- 느린 작업(알림 발송, 로그 저장, 이미지 처리)을 요청 흐름에서 분리하면 응답이 빨라진다.
- 큐 적용 시 고려할 3가지
- 유실/재처리 요구 수준
: Pub/Sub 는 빠르지만 구독자가 잠깐 죽으면 메시지가 유실 위험이 있다.
유실이 치명적이면 Streams(컨슈머 그룹) 또는 별도 메시지 브로커 (RabbitMQ, Kafka)를 고려해야 한다. - 중복 처리 (Idempotency)
: 큐 기반 시스템은 재시도 과정에서 같은 메시지가 중복 처리될 수 있다.
따라서 “중복이어도 결과가 안전한” 멱등성을 설계해야한다.
→ 멱등성이란? 같은 요청을 여러번 보내도 결과가 한 번 보낸것과 똑같이 유지되는 성질 - 처리량/지연 모니터링
: 큐 길이, 처리 속도, 실패율, 재시도 횟수를 관찰해야 한다.
적체가 심하면 컨슈머 스케일 아웃, 작업 분리, 우선순위 큐 같이 개선이 필요하다.
- 유실/재처리 요구 수준