1. Redis는 왜 사용할까?

일반적인 애플리케이션에서는 데이터를 데이터베이스에 저장하고 필요할 때 조회한다.

예를 들어 사용자 정보를 조회한다고 생각해보자.

Client
 ↓
Spring Server
 ↓
Database
 ↓
사용자 조회
 ↓
응답

그런데 동일한 데이터를 매우 자주 조회한다면 매 요청마다 DB에 접근하는 것은 비효율적일 수 있다.

이때 자주 사용하는 것이 Cache이다.

캐시는 자주 사용하는 데이터를 더 빠른 저장소에 임시로 저장해 두었다가 다시 사용하는 방식이다.

캐시를 사용하면 3가지의 장점을 발생할 수 있다.

1. 자주 접근하는 데이터의 빠른 검색
→ 사용자가 자주 요청하는 데이터를 미리 저장해두어, 재요청시 빠르게 제공

2. 원본 데이터 소스의 부하 감소
→ 캐시가 유효한 동안 반복적인 DB 조회를 줄여 DB의 부하 감소

3. 네트워크 지연 시간 최소화
→ 물리적으로 가까운 곳에 데이터를 꺼내기 때문에 응답 속도가 비약적으로 향상

대표적으로 Redis를 캐시로 사용하면 다음과 같은 구조를 만들 수 있다.

Client
  ↓
Server
  ↓
Redis
 │
 ├─ 데이터 있음 → 바로 반환
 │
 └─ 데이터 없음
        ↓
       DB 조회
        ↓
   Redis에 저장
        ↓
       반환

캐시에 데이터가 있는 경우를 Cache Hit, 없는 경우를 Cache Miss라고 한다.

Cache Miss가 발생하면 DB에서 데이터를 가져온 뒤 Redis에 저장하는 방식이 대표적인 Cache-Aside 패턴이다.

2. Redis란?

**Redis(Remote Dictionary Server)**는 데이터를 주로 메모리에 저장하는 In-Memory Data Structure Store이다.

기본적으로 Key-Value 형태로 데이터를 저장하지만 Value에 단순 문자열뿐 아니라 다양한 자료구조를 사용할 수 있다.

String
Hash
List
Set
Sorted Set
Stream

그래서 Redis는 단순한 캐시뿐 아니라 세션, Counter, Ranking, 메시징 등에도 활용할 수 있다.

3. Redis의 주요 자료구조

Redis에서는 데이터의 특성에 맞는 자료구조를 선택하는 것이 중요하다.

SET user:1:name "Evan"

GET user:1:name
→ "Evan"

SET views 100

INCR views
→ 101

user:1
 │
 ├─ name → Evan
 ├─ age  → 30
 └─ job  → Backend

HSET user:1 name Evan age 30

HGET user:1 name
→ Evan

LPUSH / RPUSH
LPOP  / RPOP

task1 → task2 → task3

post:1:likes

user1
user2
user3

A = {Redis, Kafka, Spring}
B = {Redis, Docker, Spring}

교집합
= {Redis, Spring}

userA → 1200
userB → 1700
userC → 1500

1. userB → 1700
2. userC → 1500
3. userA → 1200

Set
→ 중복 X
→ 정렬 기준 X

Sorted Set
→ 중복 X
→ Score 기준 정렬 O

1 → 주문 생성
2 → 결제 완료
3 → 배송 시작

             Stream
                ↓
        Consumer Group
         /           \
 Consumer A       Consumer B

4. TTL은 왜 필요할까?

캐시에는 DB와 다른 오래된 데이터가 남을 수 있다.

예를 들어 DB의 사용자 이름은 변경됐는데 Redis에는 이전 이름이 계속 저장되어 있을 수 있다.

이런 데이터를 Stale Data라고 한다.

Redis에서는 Key에 **TTL(Time To Live)**을 설정해 일정 시간이 지나면 자동으로 만료시킬 수 있다.

SET user:1 "data" EX 300

캐시 저장
   ↓
300초
   ↓
자동 만료

따라서 실제 캐시에서는 TTL 설정이나 캐시 삭제·갱신 등을 통해 DB와 캐시 사이의 데이터를 관리해야 한다.

5. Pub/Sub과 Stream의 차이

Redis에서는 Pub/Sub(Publish/Subscribe) 방식의 메시징도 사용할 수 있다.

Publisher
    ↓
 Channel
  /     \
 ↓       ↓
A         B
Subscriber

Publisher가 메시지를 발행하면 현재 해당 Channel을 구독 중인 Subscriber에게 바로 전달된다.

하지만 Pub/Sub은 메시지를 저장하지 않는다.

따라서 Subscriber가 연결되어 있지 않았다면 해당 메시지를 나중에 다시 받을 수 없다.

Stream과 비교하면:

즉:

저장이나 재처리가 필요 없는 실시간 메시지 전파
→ Pub/Sub

메시지를 기록하고 처리 상태까지 관리
→ Stream

이라고 이해하면 된다.

6. Redis의 원자성과 Transaction

Redis의 INCR처럼 하나의 명령은 원자적으로 처리할 수 있다.

하지만:

GET stock
↓
값 계산
↓
SET stock

처럼 여러 명령을 조합하면 그 사이에 다른 Client의 명령이 실행될 수 있다.

즉:

Redis가 명령을 순차적으로 처리한다
= 여러 명령으로 만든 로직 전체가 자동으로 원자적이다

는 아니다.

이런 경우 Redis의 **Transaction(MULTI/EXEC)**이나 Lua Script 등을 사용할 수 있다.

또 Pipeline도 자주 등장하는데 Transaction과 목적이 다르다.

Pipeline
→ 여러 명령을 묶어서 전송
→ 네트워크 RTT 감소
→ 성능 최적화

Transaction
→ 여러 명령을 Queue에 저장한 뒤 실행
→ 실행 중 다른 Client의 명령이 끼어들지 않음
→ 단, Redis Transaction은 일반적인 RDB Transaction과 달리 실행 중 오류가 발생했다고 해서 이미 실행된 명령을 Rollback하지 않는다.

따라서 Pipeline을 사용했다고 해서 자동으로 Transaction이 되는 것은 아니다.

7. RDB와 AOF

Redis는 In-Memory 기반이지만 데이터를 디스크에 저장하는 Persistence(영속성) 기능도 제공한다.

대표적인 방법이 RDB와 AOF이다.

Redis 상태
   ↓
Snapshot

SET A 1
INCR A
SET B 10
...

RDB
→ Snapshot

AOF
→ 쓰기 명령 Log

8. Sentinel과 Cluster

Redis 서버 하나에 장애가 발생하면 서비스를 계속 사용할 수 없을 수 있다.

Primary 장애
    ↓
Sentinel 감지
    ↓
Replica 승격

Node A → 데이터 일부
Node B → 데이터 일부
Node C → 데이터 일부

Sentinel
→ 장애 대응 / 고가용성

Cluster
→ 데이터 분산 / 수평 확장 + 고가용성

9. Redis를 이용한 분산 락

여러 서버가 동일한 자원을 동시에 수정해야 한다면 한 서버 내부의 Lock만으로는 충분하지 않다.

Server A ─┐
          ├→ 동일한 자원
Server B ─┘

이때 모든 서버가 접근할 수 있는 Redis를 이용해 분산 락을 구현할 수 있다.

Redis의 SET NX 등을 이용해 Lock이 없는 경우에만 획득하도록 만들 수 있다.

다만 단순히 SETNX만 사용해서는 충분하지 않다.

안전하게 사용하려면:

Lock 소유자 식별

TTL 설정

해제 시 소유권 확인

등을 함께 고려해야 한다.

원본 자료에서도 Redis 분산 락에서는 소유자를 식별하는 값과 만료 시간을 사용하고, 해제 시 소유권을 원자적으로 확인해야 한다고 설명한다.

10. 핵심 정리

Redis 기능을 요구사항 기준으로 정리하면 다음과 같다.