✍️ 필사 모드: Redis 프로덕션 운영 완전 가이드 2025: 클러스터, 영속화, 메모리 관리, Redis 7+ 기능

TL;DR

• Redis는 단순 캐시가 아니다: 8가지 데이터 구조 (String, List, Hash, Set, Sorted Set, Stream, Bitmap, HyperLogLog) + 모듈로 시계열, 검색, JSON 처리
• 영속화 선택: RDB(스냅샷, 빠름, 데이터 손실 가능) vs AOF(로그, 안전, 느림). 프로덕션은 보통 둘 다 활성화
• Cluster vs Sentinel: Sentinel은 고가용성만, Cluster는 샤딩 + HA. 단일 데이터셋이 16GB 미만이면 Sentinel로 충분
• 메모리 관리: maxmemory + maxmemory-policy 필수 설정. OOM 방지의 핵심
• 2024 라이선스 변경: Redis 7.4부터 SSPL/RSAL → Valkey fork 등장 (Linux Foundation, BSD)

1. Redis가 여전히 표준인 이유

1.1 핵심 강점

1. 단일 스레드 모델 — 락 없이 원자성 보장
2. 인메모리 + 영속화 — 빠른 속도 + 내구성
3. 풍부한 데이터 구조 — Memcached보다 훨씬 다양
4. Pub/Sub + Stream — 메시지 큐 기능
5. Lua 스크립트 — 복잡한 원자 연산
6. 모듈 시스템 — RedisJSON, RediSearch, RedisGraph 등

1.2 2024 라이선스 변경과 Valkey 탄생

2024년 3월, Redis Inc.가 라이선스를 BSD에서 SSPL/RSAL로 변경했습니다. 이는 클라우드 제공자(AWS, Google)가 Redis를 매니지드 서비스로 제공하는 것을 제한하는 의도였습니다.

결과: Linux Foundation이 Redis 7.2.4를 fork하여 Valkey를 만들었습니다. AWS, Google, Oracle, Ericsson 등이 후원합니다.

선택 가이드:

• 상용 모듈 필요 (RediSearch, RedisJSON 등): Redis
• 순수 오픈소스: Valkey
• AWS ElastiCache: 곧 Valkey로 전환

2. 데이터 구조 마스터하기

2.1 String (가장 기본)

SET user:1000:name "Alice"
SET counter 0
INCR counter
INCRBY counter 10
SETEX session:abc123 3600 "data"  # TTL 1시간

활용: 캐싱, 카운터, 세션, 분산 락(SET key value NX EX 10)

2.2 Hash (객체 표현)

HSET user:1000 name "Alice" age 30 email "alice@example.com"
HGET user:1000 name
HGETALL user:1000
HINCRBY user:1000 age 1

활용: 사용자 프로필, 설정, 메모리 효율적 객체 저장

2.3 List (FIFO/LIFO)

LPUSH queue:tasks "task1"
RPUSH queue:tasks "task2"
LPOP queue:tasks
BLPOP queue:tasks 0  # 블로킹 (메시지 큐)

활용: 메시지 큐, 작업 큐, 최근 항목 목록

2.4 Set (순서 없음, 중복 없음)

SADD tags:post:1 "redis" "database" "cache"
SISMEMBER tags:post:1 "redis"
SINTER tags:post:1 tags:post:2  # 교집합
SUNION tags:post:1 tags:post:2  # 합집합

활용: 태그, 친구 목록, 중복 제거

2.5 Sorted Set (순위)

ZADD leaderboard 100 "Alice" 95 "Bob" 87 "Charlie"
ZRANGE leaderboard 0 9 WITHSCORES  # 상위 10명
ZRANGEBYSCORE leaderboard 80 100   # 80-100점
ZINCRBY leaderboard 5 "Alice"

활용: 리더보드, 우선순위 큐, 시간 정렬 데이터

2.6 Stream (이벤트 스트리밍)

XADD mystream * sensor temp 25.5
XREAD COUNT 10 STREAMS mystream 0
XGROUP CREATE mystream consumer-group $
XREADGROUP GROUP consumer-group consumer1 COUNT 10 STREAMS mystream >

활용: Kafka 같은 이벤트 스트리밍 (소규모), IoT 센서 데이터, 로그

2.7 Bitmap

SETBIT user:active:2025-04-15 1000 1  # 사용자 1000번이 오늘 활성
BITCOUNT user:active:2025-04-15

활용: 일일 활성 사용자(DAU), 출석 체크, 비트 플래그

2.8 HyperLogLog (확률적 카운팅)

PFADD visitors:2025-04-15 "user1" "user2" "user3"
PFCOUNT visitors:2025-04-15  # 약 0.81% 오차로 카운트

활용: 유니크 방문자 카운트 (메모리 12KB로 수십억 항목)

3. 영속화 (Persistence)

3.1 RDB (Redis Database)

원리: 주기적 스냅샷을 디스크에 저장.

# redis.conf
save 900 1      # 900초 안에 1개 이상 변경 시 저장
save 300 10
save 60 10000

dbfilename dump.rdb
dir /var/lib/redis

3.2 AOF (Append-Only File)

원리: 모든 쓰기 명령을 로그로 기록.

appendonly yes
appendfsync everysec  # everysec | always | no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

3.3 RDB + AOF (권장)

프로덕션 모범 사례: 둘 다 활성화.

• AOF로 데이터 손실 최소화
• RDB로 빠른 백업/복원

save 900 1
appendonly yes
appendfsync everysec

복구 시 Redis는 AOF를 우선합니다 (더 최신).

4. Sentinel vs Cluster

4.1 Sentinel (고가용성만)

        ┌──────────┐
        │ Sentinel │
        │ Sentinel │  ← 3+ 노드 (홀수)
        │ Sentinel │
        └────┬─────┘
             │ 모니터링
   ┌─────────┼─────────┐
   │         │         │
┌──▼──┐  ┌──▼──┐  ┌──▼──┐
│ Master  │Replica│Replica│
└─────┘   └─────┘  └─────┘

작동:

1. Sentinel이 Master 모니터링
2. Master 다운 → Sentinel들이 합의하여 Replica를 새 Master로 승격
3. 클라이언트는 Sentinel에 새 Master 주소 질의

장점: 단순함. 단일 데이터셋 16GB 이하면 충분.

4.2 Cluster (샤딩 + HA)

[Slot 0-5460]    [Slot 5461-10922]   [Slot 10923-16383]
   Master 1          Master 2            Master 3
      │                  │                   │
   Replica           Replica             Replica

작동:

1. 16,384 해시 슬롯을 마스터들에 분산
2. 키 → CRC16(key) mod 16384 → 해당 슬롯의 마스터로 라우팅
3. 마스터 장애 시 Replica가 자동 승격

장점: 수평 확장. 데이터셋이 16GB 이상이거나 처리량이 부족할 때.

제약:

• 다중 키 명령(MGET, MSET)은 같은 슬롯 키만 가능 ({tag} 사용)
• 트랜잭션과 Lua 스크립트도 단일 슬롯
• 모듈 일부 미지원

4.3 Cluster 키 태깅

# 같은 슬롯에 강제 배치
SET {user1000}:name "Alice"
SET {user1000}:email "alice@example.com"
MGET {user1000}:name {user1000}:email  # 작동! (같은 슬롯)

5. 메모리 관리

5.1 maxmemory 설정 (필수!)

maxmemory 4gb
maxmemory-policy allkeys-lru

maxmemory-policy 옵션:

5.2 메모리 분석

INFO memory
MEMORY USAGE mykey
MEMORY STATS

# 큰 키 찾기
redis-cli --bigkeys

# 키 패턴별 메모리
redis-cli --memkeys

5.3 메모리 절약 팁

1. Hash 활용 — 작은 객체는 String보다 Hash가 효율적
2. 압축 가능한 인코딩 — hash-max-ziplist-entries, list-max-ziplist-size
3. TTL 설정 — 임시 데이터는 반드시 EXPIRE
4. HyperLogLog — 정확도 손실을 받아들이면 메모리 절감

6. 성능 튜닝

6.1 클라이언트 튜닝

# Pipelining 활용
maxclients 10000
timeout 0
tcp-keepalive 60
tcp-backlog 511

파이프라이닝: 여러 명령을 한 번에 전송 → 네트워크 왕복 시간 절감.

# 일반: 1000 RTT
for i in range(1000):
    r.set(f"key:{i}", i)

# 파이프라인: 1 RTT
pipe = r.pipeline()
for i in range(1000):
    pipe.set(f"key:{i}", i)
pipe.execute()
# 100배 빠름

6.2 슬로우 로그

CONFIG SET slowlog-log-slower-than 10000  # 10ms 이상
SLOWLOG GET 10
SLOWLOG RESET

6.3 ACL (Redis 6+)

ACL SETUSER cacheuser on >mypassword ~cache:* +get +set +del
ACL LIST

원칙: 애플리케이션마다 별도 사용자, 최소 권한.

7. Redis 7+ 새 기능

7.1 Functions (Redis 7)

Lua 스크립트의 후계자. 라이브러리로 함수 등록 → 영속화.

FUNCTION LOAD "#!lua name=mylib
redis.register_function('hello', function() return 'world' end)
"
FCALL hello 0

7.2 Sharded Pub/Sub (Redis 7)

Cluster 모드에서 Pub/Sub이 전체 노드에 브로드캐스트되어 비효율적이었습니다. Sharded Pub/Sub은 채널이 슬롯에 매핑되어 해당 노드에만 전송.

SPUBLISH mychannel "message"
SSUBSCRIBE mychannel

7.3 Multi-Part AOF (Redis 7)

AOF가 RDB + 증분 AOF 두 파일로 분리되어 rewrite가 빨라짐.

7.4 Client-Side Caching (Redis 6)

서버가 클라이언트에게 무효화 메시지를 보내 클라이언트 캐시를 활용. 응답 시간 대폭 감소.

8. 모니터링과 디버깅

8.1 핵심 메트릭

INFO stats | grep instantaneous_ops_per_sec
INFO clients | grep connected_clients
INFO memory | grep used_memory_human
INFO replication
INFO persistence

대시보드 도구:

• RedisInsight (공식 GUI)
• Grafana + redis_exporter (Prometheus 통합)
• Datadog Redis Integration

8.2 latency 측정

redis-cli --latency
redis-cli --latency-history
redis-cli --latency-dist

8.3 흔한 문제

9. Redis vs 대안

9.1 비교표

9.2 DragonflyDB — 새로운 강자

• C++로 처음부터 작성
• Redis API 100% 호환
• 단일 노드에서 100만 QPS+
• 메모리 효율 2-3배
• 단점: 클러스터 없음 (단일 머신용)

퀴즈

참고 자료

• Redis Documentation
• Valkey — Linux Foundation fork
• DragonflyDB
• KeyDB
• RedisInsight
• redis_exporter
• Redis Best Practices
• Redis Memory Optimization
• Redis Cluster Tutorial
• Awesome Redis