Redis 설계와 운영 지도

Overview

Redis는 메모리를 중심으로 String, Hash, List, Set, Sorted Set 같은 자료구조와 TTL, 원자 연산을 제공하는 데이터 저장소다. 빠르다는 이유만으로 붙이는 부속품이 아니라 데이터 수명, 정합성, 장애 복구, 메모리 상한을 함께 설계해야 하는 운영 컴포넌트다.

한 문장 설명: Redis는 자주 접근하거나 짧게 살아야 하는 상태를 자료구조 단위의 원자 연산으로 빠르게 다루는 도구다.

왜 필요한가

• 반복 조회를 캐시해 원본 DB의 부하와 응답 시간을 줄인다.
• 카운터, 순위, 세션, 중복 방지, Rate Limit을 원자 연산으로 구현한다.
• 만료 시점이 분명한 임시 데이터를 TTL과 함께 관리한다.

선택 전에는 데이터 유실 허용 범위, 최신성, 최대 크기, 접근 패턴을 묻는다. 영구 보존과 복잡한 관계 질의가 핵심이면 관계형 DB를 대체하려 해서는 안 된다.

핵심 원리

Redis 명령은 서버의 주 실행 경로에서 순차 처리되므로 단일 명령은 원자적이다. 그러나 GET 후 계산하고 SET하는 여러 명령은 그 사이에 다른 요청이 끼어든다. 이때는 INCR, 조건부 SET, Lua Script 등 하나의 원자 작업으로 바꾼다.

Cluster는 Key를 16,384개 Hash Slot에 나눈다. 여러 Key를 한 번에 다루려면 같은 Slot이어야 하며 {userId} 같은 Hash Tag를 쓸 수 있다. 편중된 Tag는 특정 Slot을 Hotspot으로 만들 수 있다.

내부 동작

요청은 Network I/O와 Command 실행을 거쳐 메모리 자료구조를 변경한다. TTL이 있는 Key는 접근 시 만료 검사와 주기적인 능동 만료의 조합으로 제거된다. maxmemory에 도달하면 설정한 Eviction 정책에 따라 Key를 축출하거나 쓰기를 거부한다. 복제본은 Primary의 변경 스트림을 비동기로 따라가므로 Failover 직전 쓰기가 유실되거나 읽기가 잠시 뒤처질 수 있다.

flowchart LR; A[Application] --> R[Redis Primary]; R --> M[(Memory)]; R -.비동기 복제.-> P[Replica]; S[Sentinel 또는 Cluster] -->|장애 감지·승격| P

Example

SET product:42 '{...}' EX 300
SET signup:request:abc 1 NX EX 60
INCR rate:user:123:20260811T10

첫 명령은 5분 캐시, 둘째는 요청 중복 방지, 셋째는 원자 카운터다. Key 이름에는 도메인과 식별자, 목적을 드러내고 개인정보를 그대로 넣지 않는다.

실무에서 발생하는 문제

동시 만료는 Cache Stampede, 존재하지 않는 Key 반복 조회는 Cache Penetration, 과도한 TTL과 큰 Value는 메모리 압박을 만든다. KEYS와 큰 Collection 전체 조회는 Event Loop를 오래 점유한다. Replica 읽기는 최신 값이 아닐 수 있고 Failover 뒤 연결 재수립도 고려해야 한다.

Trade-off

응답 시간과 DB 부하는 줄지만 이중 저장과 무효화, 메모리 비용, 복제 지연, 장애 전환 복잡성이 생긴다. 캐시 적중률만 높이는 것이 목표가 아니라 원본 DB까지 포함한 전체 실패 비용을 낮추는 것이 목표다.

흔한 오해

• Redis의 모든 명령이 항상 O(1)이고 빠른 것은 아니다.
• 단일 명령 원자성이 여러 명령의 원자성을 보장하지 않는다.
• TTL은 캐시 정합성 전략 전체를 대신하지 않는다.
• Replica와 영속화를 켰다고 데이터 무손실이 자동 보장되지 않는다.

Production Considerations

used_memory, fragmentation, evicted_keys, expired_keys, command latency, slow log, hit ratio, connection 수, replication lag를 함께 본다. Memory 상한과 Eviction 정책을 명시하고, 장애 전환 훈련과 DB Fallback 부하 테스트를 한다. 운영 중 전체 Key 탐색이 필요하면 SCAN을 작은 단위로 사용한다.

Interview Questions / Follow-up Questions

1. Redis를 DB가 아니라 캐시로 사용할 때 원본은 무엇인가?
2. 단일 명령 원자성과 분산 락의 안전성은 왜 다른 문제인가?
3. 메모리가 가득 찼을 때 정책별 결과는 어떻게 다른가?
4. 후속: Hit Ratio는 높은데 서비스 지연이 증가하는 경우를 설명해보라.
5. 후속: Cluster의 Hash Tag가 유용하면서 위험한 이유는 무엇인가?

Related Topics

캐시 전략, 자료구조와 원자성, 메모리·영속화·고가용성, Spring Cache 직렬화로 이어진다.