Redis

주제 선정 이유

서비스를 개발하다 보면 데이터 저장을 위해 자연스럽게 RDB를 사용하게 되지만, 트래픽이 증가하고 요청이 많아지면 디스크 기반 처리 방식의 한계로 인해 응답 속도가 느려지거나 병목이 발생하는 상황을 마주하게 되며, 이러한 문제를 어떻게 해결할 수 있을지에 대한 고민이 들게 됩니다.

현대 백엔드 환경에서는 Redis와 같은 인메모리 데이터 저장소를 활용하여 성능을 개선하는 방식이 널리 사용되고
있지만, 단순히 캐시로 사용한다는 개념을 넘어 TTL(Time To Live)을 활용한 데이터 만료 처리, Refresh Token과
같은 인증 정보의 생명주기 관리, 그리고 분산 환경에서의 데이터 처리 방식에 대해서는 명확하게 이해하지 못한 채
사용하는 경우가 많고 또한, 성능 최적화와 데이터 정합성 사이에서 균형을 맞추는 것이 중요하지만, 내부 동작 원리를
제대로 이해하지 못한다면 단순히 빠른 저장소를 사용하는 수준을 넘어서 안정적인 시스템을 설계하기 어렵다는 점을
느끼게 됩니다.

그래서 이번 글에서는 Redis의 기본 개념과 인메모리 데이터 처리 구조를 정리해보면서, 캐싱 전략과 데이터 만료 정책을 통해 성능과 안정성을 동시에 확보하는 설계 방향에 대해 정리해보고자 합니다.

Redis가 뭘까?

NoSQL 데이터베이스 중 하나이며 오픈소스 소프트웨어이고 주요한 특징은 키-값(Key-Value) 형태로 데이터를
저장하고 데이터를 인-메모리 데이터 저장소에 저장하는 형태를 가지는 데이터베이스입니다.

NoSQl 데이터베이스 구조의 종류

전반적인 NoSQL의 종류 및 특징에 대해서 알아보겠습니다.

구분	정의	특징	대표 DB
문서 저장소 (Document Store)	JSON 형태의 문서 단위로 데이터를 저장	스키마가 유연하고 구조 변경이 용이	MongoDB, CouchDB
키-값 저장소 (Key–Value Store)	Key와 Value 쌍으로 데이터를 저장	단순 구조로 빠른 조회/저장 가능	Redis, Riak
열 지향 DB (Wide–Column Store)	컬럼 단위로 데이터를 저장하는 구조	대용량 데이터 처리에 유리	Cassandra, HBase
그래프 저장소 (Graph Store)	노드와 관계(엣지) 기반으로 데이터 저장	관계 중심 데이터 처리에 강점	Neo4j, ArangoDB

Redis 데이터 저장구조

데이터 타입	설명	대표 활용
String	문자열, 숫자 등을 저장하는 가장 기본적인 타입	캐싱, 토큰 저장
Bitmap	비트 단위로 0/1 값을 저장하는 타입	방문 여부 체크, 플래그 관리
Bitfield	Bitmap을 확장하여 다양한 크기의 비트 필드를 다루는 타입	카운팅, 상태 값 저장
Hash	필드-값 형태로 데이터를 저장 (객체 표현에 적합)	사용자 정보, 객체 캐싱
List	순서가 있는 데이터 집합 (양쪽 삽입 가능)	큐, 스택 구현
Set	중복을 허용하지 않는 데이터 집합	태그 관리, 중복 제거
Sorted Set	점수를 기준으로 정렬되는 Set	랭킹 시스템
Geo	위도/경도 기반 위치 데이터 저장	위치 기반 서비스
HyperLogLog	대용량 데이터의 중복 없는 개수 추정	방문자 수 추정
Stream	로그/이벤트를 저장하는 메시지 큐 구조	이벤트 처리, 로그 수집

인 메모리 데이터 구조

컴퓨터 메모리 내에서 데이터를 저장하고 조작하는 방식인데 이 방식은 디스크에 데이터를 저장하고 검색하는 대신
RAM과 같은 메모리에 데이터를 저장하여 훨씬 빠른 속도로 데이터에 접근할 수 있게 해줘서 대량의 데이터를 빠르게
처리해야 하는 애플리케이션에서 유용합니다만 데이터가 메모리에 저장되므로 컴퓨터가 꺼지거나 재시작되면 데이터가 사라질 수 있기 때문에 인-메모리 데이터구조를 사용할때는 이러한 특성을 고려하여 데이터 유실을 방지하는 방안을 마련해야 합니다.

구분	RDBMS	In-Memory DB
데이터 저장 위치	디스크에 저장	메모리(RAM)에 저장
속도	디스크 I/O로 인해 상대적으로 느림	메모리 접근으로 매우 빠름
데이터 유실	트랜잭션 완료 시 안전하게 보존	장애 시 유실 가능 (별도 설정 필요)
용도	영구 데이터 저장 및 관리	캐싱, 세션, 실시간 처리
데이터 복구	장애 후에도 복구 가능	스냅샷/복제 없으면 복구 어려움
비용	비교적 저렴	메모리 비용으로 상대적으로 높음

디스크 저장 방식

방식	설명	장점	단점
RDB	일정 시점마다 스냅샷을 생성하여 디스크에 저장	빠른 백업, 파일 크기 작음	스냅샷 이후 데이터 유실 가능
AOF	모든 쓰기 연산을 로그로 기록	최신 데이터까지 복구 가능	파일 크기 증가, 디스크 I/O 부담
No Persistence	디스크에 저장하지 않음	성능 최적화, 디스크 사용 없음	장애 시 데이터 전부 유실
RDB + AOF	스냅샷 + 로그 방식 병행	안정성과 성능을 모두 확보	디스크 사용량 및 I/O 증가

RDB (Redis Database)

설정한 시간 간격에 따라 데이터의 스냅샷을 일정한 시점에 디스크에 저장하는데 이렇게 하면 빠른 백업이 가능하며
크기가 작아 백업 파일을 다른 서버로 이동하는 것이 용이합니다만 스냅샷을 수행한 이후에 발생한 데이터 손실이
발생할 수 있기 때문에, 데이터의 일관성이 중요한 애플리케이션에서는 적합하지 않을 수 있습니다.

AOF (Append On File)

모든 write or update 연산을 로그 형태로 저장하는 방식인데 이 방식은 모든 데이터 변경 작업을 디스크에 기록하기 때문에, 데이터 복구 시점에서 최신의 데이터 상태를 유지할 수 있습니다만 로그 파일 크기가 커질수록 디스크 공간을
많이 차지하게 되고, 많은 데이터 변경 작업을 기록하기 때문에 디스크 I/O 부하가 RDB 방식보다 크게 될 수 있습니다.

No Persistence

데이터를 디스크에 저장하지 않는 방식인데 이 방식은 메모리에만 데이터를 저장하기 때문에 빠른 응답 시간을 제공할 수는 있으나 서버가 다운되면 데이터가 모두 손실되기 때문에 데이터의 지속성이 중요하지 않은 일시적인 캐시 등에
사용됩니다.

RDB + AOF

RDB와 AOF의 장점을 결합한 방식인데 스냅샷 방식의 RDB와 로그 형태로 데이터를 저장하는 AOF를 동시에
사용함으로써, 빠른 백업 및 데이터 복구 능력을 모두 갖출 수 있기 때문에 데이터의 일관성과 복구 능력을 중요시하는
애플리케이션에 사용됩니다.

그래서 어떻게 쓰라고?

Redis는 사용 용도, 가용성, 확장성에 따라서 사용하는 방법이 달라지게 되는데 처리하고자 하는 데이터가 실시간성을 얼마나 요하는지, 그리고 유실되어도 괜찮은 데이터인지에 따라 아키텍처의 방향성이 결정됩니다.

사용 용도

사용 사례	설명	활용 포인트
캐싱	자주 조회되는 데이터를 메모리에 저장하여 빠르게 응답	DB 부하 감소, 응답 속도 향상
세션 저장	사용자 세션 정보를 저장 및 공유	서버 간 세션 공유, 로그인 유지
실시간 분석	빠른 연산으로 실시간 데이터 집계 및 처리	방문자 수, 실시간 통계
메시지 큐	Pub/Sub 구조로 비동기 메시지 처리	서비스 간 이벤트 전달
대기열	요청을 순차적으로 처리하기 위한 큐 구조	작업 처리 순서 보장
속도 제한	일정 시간 내 요청 횟수 제한	API 보호, 트래픽 제어

고 가용성 (HA: High Availability) & 확장성 (Scalability)

고 가용성을 유지하기 위한 방법으로 Redis 서버가 어떠한 장애 상황에서도 계속하여 서비스를 제공할 수 있게 하는
기능을 말하며 이를 유지하기 위한 방법으로 Master-Slave Replication과 Sentinel의 두 가지 주요 기능을 통해
제공하고 확장성을 가지기 위해 클러스터(Cluster)를 이용하는 방법으로 확장성을 높입니다.

이를 고려하지 않는다면 단일 Redis만 존재하는 Standalone형태를 사용하지만 고려한다면 Replication, Sentinel, Cluster을 사용합니다.

Replication (복제)

마스터-슬레이브 모델을 사용하여 데이터를 여러 Redis 노드로 복사하는 프로세스인데 이를 통해 데이터의 내구성을 향상하고, 읽기 쿼리의 성능을 높이며, 시스템의 가용성을 높일 수 있습니다.

Master node와 Slave node의 동기화 시점은 복제 (Replication)가 수행된 이후 마스터 노드에서 새로운 명령을
수행하면 슬레이브 노드에서 데이터를 최신 상태로 유지합니다.

• 데이터 쓰기 작업
  • Client에서는 Master Node에 데이터를 Write 합니다.
• 데이터 읽기 작업
  • Client에서는 Slave Node에서 데이터를 Read 합니다.

Master Node를 기준으로 Slave Node가 생성되는 시점은 Slave 노드가 Master에 연결하고 데이터 복제를
요청하는 시점에 생성이 됩니다.

Sentinel(보초)

주로 마스터- 슬레이브 모델에서 사용되며 Redis 서버의 모니터링, 알림 및 자동 장애 복구를 수행하는 데 사용이 되고 기본적으로 분산 시스템에서 관찰자 역할을 수행하며, 여러 Redis 서버 또는 인스턴스를 지속적으로 확인하고, 문제가 발생했을 때 알려주며 필요한 경우 자동적으로 복구 작업을 수행합니다.

기능	설명	역할
장애 감지 (Monitoring)	Redis 인스턴스의 상태 및 네트워크 이상 여부 감지	서버 상태 모니터링
자동 장애 복구 (Failover)	마스터 장애 시 슬레이브를 승격하여 서비스 유지	고가용성 보장
구성 제공 (Configuration)	현재 마스터/슬레이브 정보를 클라이언트에 전달	동적 연결 관리
알림 (Notification)	장애 및 구성 변경 이벤트 발생 시 알림 제공	운영 대응 지원

Sentinel을 사용하는 경우 하나의 Sentinel 인스턴스는 여러 Redis 서버(마스터와 슬레이브 모두)를 모니터링
할 수 있고 서로 다른 Sentinel 인스턴스들은 서로 통신하여 투표 메커니즘을 통해 마스터 서버의 장애를 감지하고 슬레이브 중 하나를 새로운 마스터로 승격시킵니다.

Cluster

클러스터 구성은 여러 노드로 구성되며, 키 공간은 노드 간에 자동으로 분할되고 이를 통해 높은 성능과 스케일링을 달성할 수 있고 데이터는 해시 슬롯을 사용하여 노드 간에 분배되며, 이는 데이터를 균등하게 분산시키고, 노드 추가 또는
제거 시 데이터 재분배를 용이하게 합니다.

• Redis 클러스터는 마스터-슬레이브 복제를 지원하여 데이터 안정성을 보장하고 각 마스터 노드는 하나 이상의
  슬레이브 노드를 가질 수 있으며, 마스터 노드가 실패할 경우, 슬레이브 노드가 마스터 노드 역할을 수행하게 됩니다.

마무리

Redis의 핵심 메커니즘과 아키텍처를 깊이 파헤쳐보며 정리한 내용은 다음과 같습니다.

1. 전통적인 디스크 기반 RDB의 I/O 병목 현상을 넘어, 인-메모리 (In-Memory) 아키텍처를 통해 대규모 트래픽에서도 지연 없는 초고속 데이터 처리를 실현합니다.
2. Refresh Token과 같이 유효 기간 관리가 필수적인 휘발성 데이터를 TTL (Time To Live) 기능을 통해 별도의
   삭제 로직 없이 시스템적으로 안전하고 정교하게 통제합니다.
3. 메모리 저장소의 휘발성 리스크를 RDB 스냅샷과 AOF 로그라는 이중 저장 방식을 통해 보완함으로써, 성능과
   데이터 내구성 사이의 최적의 지점을 설계합니다.
4. Replication과 Sentinel을 통한 고가용성 (HA) 확보, 그리고 Cluster를 통한 수평적 확장을 조합하여 어떠한 장애 상황에서도 유연하게 대응하는 견고한 인프라를 구축합니다.