🔴 REDIS

최근 백엔드 아키텍처에서 대규모 트래픽을 처리하고 응답 속도를 높이기 위해 캐싱(Caching)은 선택이 아닌 필수가 되었습니다.

그중에서도 가장 널리 사용되는 기술이 바로 Redis(Remote Dictionary Server)입니다.

해당 시리즈에서는 Redis의 기본적인 특징부터 다른 데이터베이스와의 비교, 그리고 가용성을 높이기 위한 다양한 아키텍처 설계 기법까지 차근차근 알아보겠습니다.

📖 REDIS 소개

Redis는 오픈 소스 기반의 인메모리(In-Memory) 데이터 구조 저장소입니다.

데이터베이스, 캐시, 메시지 브로커 및 스트리밍 엔진 등 다양한 용도로 활용됩니다.

특징

In-Memory 데이터 저장

모든 데이터를 RAM(메모리)에 저장하므로 디스크 기반 데이터베이스보다 접근 속도가 압도적으로 빠릅니다.

다양한 자료구조 지원

단순한 Key-Value 형태의 String뿐만 아니라 List, Set, Hash, Sorted Set, Bitmap, HyperLogLog 등 다양한 데이터 구조를 지원합니다.

Single Thread 아키텍처

Redis의 핵심 명령어 처리는 메인 스레드 1개에서 순차적으로 실행됩니다.
이로 인해 Race Condition(경쟁 상태)을 피할 수 있고 원자성(Atomicity)을 보장하기 쉽습니다.

영속성(Persistence) 지원

인메모리임에도 불구하고 데이터를 디스크에 저장하여 서버가 재시작되어도 데이터를 복구할 수 있는 기능(RDB, AOF)을 제공합니다.

장점

극강의 성능

데이터를 메모리에서 읽고 쓰기 때문에 지연 시간이 매우 짧습니다.

개발 편의성

제공하는 다양한 자료구조를 활용하면 복잡한 로직(랭킹 구현 등)을 아주 쉽게 처리할 수 있습니다.

원자성 보장

싱글 스레드 특성 덕분에 여러 클라이언트가 동시에 같은 데이터에 접근하더라도 데이터의 일관성을 유지하기 좋습니다.

단점

비용 문제

REDIS 는 메모리 데이터베이스 입니다.
RAM은 디스크(SSD/HDD)에 비해 훨씬 비싼 자원입니다. 대용량 데이터를 모두 Redis에 저장하는 것은 물리적, 금전적 한계가 있습니다.

장애 발생 위험

싱글 스레드이므로, 처리 시간이 오래 걸리는 명령어(예: KEYS *)를 실행하면 다른 모든 요청이 대기 상태에 빠져 전체 시스템 장애로 이어질 수 있습니다.

데이터 유실 가능성

메모리 특성상 서버 전원이 꺼지면 데이터가 날아갑니다.
영속성 옵션을 켜더라도 완벽한 실시간 동기화가 아니면 약간의 데이터 유실이 발생할 수 있습니다.

vs 타 저장소와 비교

Redis가 다른 저장소들과 어떤 차이가 있는지 한눈에 알아보기 쉽게 표로 알아보겠습니다.

비교 항목	Redis	RDB (MySQL 등)	NoSQL (MongoDB)	memcached
저장 매체	Memory (디스크 백업 지원)	Disk	Disk (Memory-Mapped)	Memory (순수 메모리)
데이터 구조	String, List, Set, Hash 등 다양함	테이블 (Row, Column)	JSON (BSON) Document	단순 String (Key-Value)
스레드 모델	Single Thread	Multi Thread	Multi Thread	Multi Thread
주요 용도	캐싱, 세션 저장소, 실시간 랭킹	영구적인 메인 데이터 저장	대용량 비정형 데이터 저장	단순 조회용 캐싱
고가용성	자체 Replication, Cluster 지원	Replication, Clustering 지원	Replica Set, Sharding 지원	기본 미지원

RDB, MongoDB, memcached 등은 각각의 명확한 목적이 있습니다.
Redis는 이들을 대체한다기보다는, 아키텍처 내에서 속도를 극대화하고 부하를 분산시키는 훌륭한 조력자 역할을 한다고 이해하는 것이 좋습니다.

🏗️ 다양한 Cluster 환경 설계 기법 소개

Redis를 실제 프로덕션 환경에 도입할 때는 시스템의 규모와 요구하는 가용성에 따라 다양한 아키텍처를 선택할 수 있습니다.

Single

가장 기본적인 형태입니다. 1대의 Redis 서버(Node)만 띄워서 사용하는 구조입니다.

특징: 설정이 매우 간단하고 관리 포인트가 적습니다. 개발 환경이나 소규모 토이 프로젝트에 적합합니다.

Single - 한계

SPOF (Single Point of Failure)

이 1대의 서버가 죽으면 시스템의 캐시나 세션 기능 전체가 마비됩니다.

스케일 아웃 불가

트래픽이 몰리거나 데이터가 많아져도 서버의 물리적 메모리 용량 이상을 처리할 수 없습니다.

Master-Slave (Replication)

가용성을 높이기 위해 복제(Replication)를 도입한 구조입니다.

1대의 Master 노드와 1대 이상의 Slave(Replica) 노드로 구성됩니다.

특징

Master 노드는 쓰기(Write)와 읽기(Read)를 모두 처리하고, 변경된 데이터를 Slave 노드로 비동기 복제합니다.
Slave 노드는 주로 읽기(Read) 전용으로 사용하여 분산 처리를 돕습니다.

Master-Slave 한계

수동의 한계

Master 노드가 다운될 경우, 관리자가 직접 개입하여 Slave 중 하나를 Master로 승격(Promote)시키고 애플리케이션의 연결 정보를 수정해야 합니다.
즉, 자동 장애 조치(Failover)가 불가능하여 다운타임이 발생합니다.

Sentinel - Master - Replica

Master-Slave의 '수동 조치' 한계를 극복하기 위해 등장한 아키텍처입니다.

Redis Sentinel이라는 별도의 감시 프로세스를 도입합니다.

특징
Sentinel 프로세스들(보통 3대 이상으로 구성하여 쿼럼 생성)이 지속적으로 Master와 Replica 노드의 상태를 모니터링합니다.
Master 노드가 죽었다고 판단되면, Sentinel이 자동으로 Replica 노드 중 하나를 새로운 Master로 승격시킵니다.

장점
다운타임을 최소화하는 자동 장애 조치(Auto Failover)가 가능해집니다.

동작 방식 및 장애 판단 로직
Sentinel은 장애를 판단할 때 SDOWN과 ODOWN이라는 두 가지 단계를 거칩니다.
SDOWN (Subjective Down, 주관적 다운)
개별 Sentinel 인스턴스가 Master 노드에 PING을 보냈을 때 정해진 시간 동안 응답이 없으면 해당 Sentinel은
"어? Master가 죽은 것 같은데?"라고 주관적으로 판단합니다.
ODOWN (Objective Down, 객관적 다운)
SDOWN 상태를 감지한 Sentinel은 다른 Sentinel들에게 의견을 묻습니다.
사전에 설정된 Quorum(정족수) 이상의 Sentinel이 "나도 Master가 죽었다고 생각해!"라고 동의하면,
이때 비로소 객관적인 장애(ODOWN)로 확정합니다.
Failover (장애 조치)
ODOWN이 확정되면 Sentinel 리더가 선출되고, 살아있는 Replica 중 가장 최신 데이터를 가진 노드를 새로운 Master로 자동 승격시킵니다.

Sentinel 고가용성의 한계

쓰기 분산의 한계
읽기 요청은 Replica로 분산할 수 있지만, 쓰기(Write) 요청은 여전히 단일 Master 노드에서 모두 처리해야 합니다.
메모리 한계
모든 노드가 동일한 전체 데이터를 가지고 있어야 하므로, 시스템이 가질 수 있는 최대 데이터 용량은 결국 노드 1대의 물리적 메모리 크기를 넘지 못합니다.

Redis Cluster (Sharding)

대규모 트래픽과 대용량 데이터 처리를 위한 궁극적인 형태입니다.

데이터를 여러 노드에 분산 저장하는 샤딩(Sharding) 기술을 기본으로 제공합니다.

특징
최소 3대의 Master 노드로 구성되며, 각 Master는 자신만의 Replica를 가질 수 있습니다.
데이터는 Hash Slot이라는 개념을 통해 여러 Master 노드에 쪼개져서(Sharded) 저장됩니다.

장점
쓰기 성능 확장
여러 Master가 존재하므로 쓰기 트래픽도 분산됩니다.
용량 확장
메모리 용량이 부족해지면 노드를 추가하여 수평적 확장(Scale-out)이 자유롭습니다.
자체 Failover
Sentinel 없이도 클러스터 내부적으로 서로를 모니터링하여 장애 발생 시 자동으로 Replica를 Master로 승격시킵니다.

이미지 출처 - 플라퉁의 개발 블로그

주요 개념
Hash Slot (해시 슬롯)
Redis Cluster는 데이터를 분산하기 위해 16,384개의 Hash Slot을 사용합니다.
클라이언트가 키(Key)를 읽거나 쓸 때, Redis는 내부적으로 CRC16(key) % 16384 연산을 수행하여 해당 키가 어느 슬롯에 들어가야 할지 결정합니다. 이 16,384개의 슬롯은 클러스터를 구성하는 여러 Master 노드들에 공평하게 나뉘어 할당됩니다.

MOVED 리다이렉션 (Redirection)
클라이언트가 특정 키를 조회하려고 임의의 노드에 요청을 보냈는데, 그 키가 해당 노드의 Hash Slot에 없다면 어떻게 될까요?
해당 노드는 에러를 뱉는 대신 MOVED <슬롯 번호> <정답 IP:PORT> 응답을 반환합니다.
클라이언트는 이 응답을 받고 올바른 노드로 다시 요청을 보내 데이터를 가져옵니다.
(보통 Lettuce 등 현대의 Smart Client 라이브러리들이 이 리다이렉션 처리를 내부적으로 알아서 수행합니다.)

Gossip Protocol (가십 프로토콜)
Sentinel 없이 어떻게 장애를 감지할까요?
Redis Cluster의 모든 노드들은 가십 프로토콜을 통해 끊임없이 서로의 상태 정보(Health Check)와 클러스터 구성 상태를 주고받습니다.
마치 소문을 퍼뜨리듯 정보를 교환하며, 특정 Master 노드가 죽었다고 판단되면 클러스터 내부에서 투표를 거쳐 해당 노드의 Replica를 Master로 승격시킵니다.

참고 문서

[Redis 완전 정복] Redis 기본 개념과 아키텍처 이해하기