Redis 자료구조와 원자성

Overview

Redis의 장점은 값 저장보다 서버 안에서 자료구조를 직접 변경하는 명령에 있다. 요구사항에 맞는 자료구조와 원자 명령을 고르면 애플리케이션의 읽기-수정-쓰기 경쟁을 줄일 수 있다.

한 문장 설명: 계산을 애플리케이션으로 가져오지 말고 가능한 한 Redis의 원자 명령 하나로 표현한다.

왜 필요한가

동시에 두 요청이 GET한 값에 각각 1을 더해 SET하면 한 번의 증가가 사라질 수 있다. INCR는 이 과정을 서버의 한 명령으로 수행한다. 순위에는 Sorted Set, 중복 없는 구성원에는 Set, 개별 필드 갱신에는 Hash처럼 접근 패턴이 구조를 결정한다.

핵심 원리

String: 캐시, Counter, Bitmap의 기반이다.
Hash: 객체의 일부 필드를 개별 변경한다.
List: 양끝 Push/Pop이 필요한 단순 Queue에 적합하다.
Set: 중복 제거와 집합 연산에 적합하다.
Sorted Set: Score 기반 순위와 시간 범위 조회에 적합하다.

시간 복잡도는 명령과 반환 원소 수를 함께 본다. 작은 데이터에서 빠른 명령도 거대한 Collection을 한 번에 반환하면 Network와 Event Loop를 점유한다.

내부 동작

단일 명령은 중간 상태를 다른 명령이 관찰하지 못한다. MULTI/EXEC는 명령 묶음을 순서대로 실행하지만 관계형 DB처럼 자동 Rollback하지 않는다. WATCH는 낙관적 충돌 감지를 제공한다. Lua Script는 조건 검사와 변경을 서버 안에서 원자적으로 수행하지만 긴 Script는 다른 요청을 막는다.

flowchart LR; A[GET 후 애플리케이션 계산] --> B[경쟁 구간 발생]; C[INCR·SET NX] --> D[단일 원자 명령]; E[조건+여러 변경] --> F[짧은 Lua 또는 WATCH]

쉬운 비유

여러 사람이 장부 숫자를 읽어 밖에서 계산해 다시 쓰면 덮어쓰기가 생긴다. 장부 담당자에게 “1 증가”라는 한 지시를 내리면 순서대로 정확히 처리된다.

Example

INCR page:view:42
ZINCRBY leaderboard 25 user:123
SET job:42:lock token NX PX 30000

Lock 해제는 저장한 Token과 현재 값을 비교한 뒤 삭제하는 Lua Script로 수행해야 남의 Lock을 지우지 않는다. 단일 Redis 장애 전환까지 포함한 강한 분산 Lock이 필요하면 요구 수준을 별도로 검토한다.

실무에서 발생하는 문제

큰 Hash/Set 전체 조회, KEYS, 긴 Lua는 지연을 만든다. Counter TTL을 별도 명령으로 설정하면 중간 실패로 만료 없는 Key가 남을 수 있다. Cluster에서 여러 Key Script는 동일 Slot 제약을 받는다. Queue 기능이 복잡해지면 재처리와 소비자 그룹을 제공하는 전용 Broker가 더 적합하다.

Trade-off

서버 측 원자 명령은 경쟁과 왕복을 줄이지만 Redis 명령 모델에 도메인이 결합된다. Lua는 강력하지만 관측과 배포, 실행 시간 관리가 어렵다. 자료구조를 세분화하면 부분 갱신은 쉬워지나 Key 관리가 복잡해진다.

흔한 오해

Event Loop 기반이라는 말이 Redis 전체에 Worker가 하나뿐이라는 단순 설명은 아니다.
MULTI/EXEC는 SQL Transaction과 같은 Rollback을 제공하지 않는다.
SET NX 한 번만으로 모든 장애 조건에서 안전한 분산 Lock이 되지 않는다.

Production Considerations

명령별 호출 수와 P95/P99, 반환 크기, Slow Log를 본다. Collection 크기 상한을 정하고 전체 반환 대신 범위·페이지 명령을 사용한다. Script는 짧고 결정적으로 유지하며 Cluster Slot과 Failover 조건을 테스트한다.

Interview Questions / Follow-up Questions

GET-SET Counter와 INCR의 차이는?
MULTI/EXEC, WATCH, Lua를 언제 선택하는가?
후속: Sorted Set으로 순위를 만들 때 동점과 삭제 정책은?
후속: Redis Lock의 Token이 필요한 이유는?

Redis 운영 지도, 캐시 전략, CAS의 공통점은 경쟁 상태를 명시적으로 다룬다는 점이다.