Basic

Redis(Remote Dictionary Server)는 ‘Key-Value’ 기반의 In-Memory 데이터 저장소로, 디스크 기반 데이터베이스보다 빠른 읽기/쓰기 속도를 제공하는 것이 가장 큰 특징이다.

Redis의 주요 특징

In-Memory DB

Redis는 모든 데이터를 메모리에 저장·처리해 낮은 지연 시간(Latency)과 높은 처리량(Throughput)을 달성한다.

• 속도의 근거: 메인 메모리(RAM) 접근은 수십수백 ns, NVMe SSD는 수십 μs, HDD는 수 ms로 대략 35자릿수 차이
  • 디스크 I/O에서 발생하는 커널 블록 I/O·파일 시스템 레이어를 건너뛰므로 명령당 오버헤드가 작음
• 단점
  • 메모리는 휘발성이므로, 서버 장애나 전원 공급 중단 시 데이터가 유실될 위험이 존재
  • 물리적 메모리 크기에 따라 저장할 수 있는 데이터 총량이 제한
• 영속성(Persistence) 보완: 데이터 유실 위험을 보완하기 위해 디스크에 데이터를 저장하는 영속성 기능 제공
  • RDB(Redis Database): 특정 시점의 데이터 전체를 디스크에 스냅샷 형태로 저장하는 방식
  • AOF(Append Only File): 모든 쓰기/수정 명령을 로그 파일에 순차적으로 기록하는 방식

다양한 데이터 구조 지원

애플리케이션 개발에 유용한 여러 자료구조를 지원하여 복잡한 요구사항을 쉽게 해결하도록 돕는다.

• String: 가장 일반적인 데이터 형태로, 문자열, 숫자, 바이너리 데이터를 저장
• List: Array와 유사한 자료구조로, 데이터의 순서가 보장되며 중복을 허용
• Set: 순서가 없고, 데이터의 중복을 허용하지 않는 집합
• Sorted Set: Set에 점수(score)를 더하여, 점수를 기준으로 정렬된 상태를 유지하는 집합
• Hash: 하나의 키 아래에 여러 필드(field)와 값(value) 쌍을 저장하는 구조

싱글 스레드 아키텍처

Redis의 핵심적인 특징으로, 클라이언트의 명령(Command)을 처리하는 부분은 단일 스레드로 동작한다.

• 싱글 스레드 이유
  • 모든 데이터가 메모리에 있어 명령 1건의 실제 연산은 수 μs 단위로 매우 짧음 → 이 정도 연산에 락을 걸면 락 획득/해제 비용이 연산 비용을 초과
  • 단일 스레드가 순차 처리하면 락 없이도 모든 명령이 원자적으로 실행되어 자료구조 구현이 단순하고 빠름
• 동시 연결 처리 방법 (I/O Multiplexing + Event Loop)
  • I/O 멀티플렉싱(epoll on Linux, kqueue on BSD/macOS) 기반 이벤트 루프로 처리하여 싱글 스레드지만 수만 개 연결을 처리 가능
  • 커널에 소켓 집합을 등록해 두고, “읽을/쓸 준비가 된 소켓”만 통지받아 순회 처리 → 연결 수에 비례해 스레드를 늘리지 않아도 됨
  • 이벤트 루프: 소켓 이벤트 감지 → 명령 파싱 → 실행 → 응답 버퍼링을 한 스레드에서 반복
• 장점
  • 락 없이 원자성(Atomic) 보장 → INCR, LPUSH 등이 중간 상태 노출 없이 실행
  • 경쟁 조건(Race Condition)과 컨텍스트 스위칭·캐시 무효화 비용이 없어 단일 코어 활용도가 극대화
• 단점
  • 한 명령이 길면 이벤트 루프 전체가 블로킹되어 다른 모든 요청 지연(예: KEYS *, FLUSHALL, 거대한 SORT)
  • CPU 연산이 많은 작업(Lua 스크립트의 CPU-bound 로직 등)에는 부적합

Redis 6.0부터는 네트워크 I/O 단계에 한해 멀티 스레드를 도입해 다중 클라이언트의 요청/응답 처리량을 높였다.

• 멀티 스레드로 처리되는 구간: 소켓 read / 요청 파싱 / 응답 write
• 여전히 싱글 스레드인 구간: 실제 명령 실행(자료구조 조작)
• 효과: 네트워크 패킷 처리가 병목이던 워크로드에서 처리량 향상 → 데이터 조작 자체의 원자성은 그대로 유지되므로 애플리케이션 시맨틱 변화 없음
• 활성화: io-threads 설정(기본 1, 멀티 스레드화하려면 2 이상), io-threads-do-reads yes로 read도 스레드화

고가용성 & 확장성

복제·Sentinel·Cluster 세 요소가 각각 다른 문제를 해결한다.

• Replication(복제): Master 노드의 데이터를 Replica(Slave) 노드로 비동기 전파 → 읽기 부하 분산과 장애 시 데이터 보존의 기반
• Sentinel(센티널): Master-Replica 구성을 감시해 장애 시 자동 페일오버 수행 → 고가용성은 얻지만 데이터는 여전히 한 Master에 집중되어 쓰기 처리량 한계는 그대로
• Cluster(클러스터): 키를 해시 슬롯(0~16383)으로 분할해 여러 Master 노드에 자동 분산(Sharding)
  • 데이터와 쓰기 부하를 수평 확장하면서 각 샤드에 Replica를 두어 HA도 동시 확보

정리: “장애 복구만 필요” → Sentinel, “쓰기 처리량/용량 확장까지 필요” → Cluster.

Redis 활용

활용 분야	설명	예시
캐싱 (Caching)	자주 조회되지만 변경은 적은 데이터를 메모리에 저장하여 DB 부하를 줄이고 응답 속도를 향상시킴	로그인 세션, 상품 목록
세션 관리 (Session Management)	분산 서버 간 세션 정보를 중앙에서 관리하여 일관성을 유지함	여러 서버 간 세션 공유
메시지 큐 (Message Queue)	List 구조의 LPUSH, RPOP 명령으로 간단한 메시지 큐를 구현하여 비동기 작업 처리에 활용	실시간 알림, 채팅 애플리케이션
분산 락 (Distributed Lock)	SETNX 명령을 활용해 여러 서버 환경에서 공유 자원에 대한 동시 접근을 제어	자원 동시 수정 방지

참고자료

• 개발자를 위한 레디스