[실전 레디스] 1. 레디스의 시작

하야시 쇼고 님의 "실전 레디스" 책을 정리한 포스팅 입니다.

 

1. 레디스를 사용하기까지

NoSQL

구분	내용
특징	- 빠른 속도 - 특정 데이터 모델에 최적화됨 (일부 데이터 모델은 RDBMS로 구현 시 복잡)
유형	- Key-Value Store - Column-Oriented DB - Document-Oriented DB - Graph DB

 

예시) 소셜 네트워크 (Graph DB)

연결 정보를 저장해야 함 (A는 B의 친구이고, B는 C의 친구이고, C는 A의 친구다)

 

RDBMS

• Join 반복이나 재귀 쿼리를 써야 함 → 느리고 복잡함

GraphDB(Neo4j)

• 관계 중심 모델에 최적화
• 각 사람을 노드, 친구 관계를 엣지로 표현 (MATCH (a)-[:FRIEND]-(b)-[:FRIEND]-(c))

 

예시) 이용자 맞춤 설정 데이터 (Document-Oriented DB)

사용자마다 설정 정보가 다름
예: A는 알림 설정만, B는 테마 설정만, C는 둘 다 + 프로필 설정까지

 

RDBMS

• 미리 모든 컬럼을 만들어야 함
• 대부분의 칼럼이 NULL일 수 있음 → 비효율

Document DB(MongoDB)

• 각 사용자의 설정을 JSON 문서처럼 저장
• → 구조가 자유롭고 사용자가 다르게 설정해도 문제 없음

 

Redis

구분	내용
라이선스	BSD 라이선스
작성 언어	ANSI C
유형	- NoSQL Database - In-Memory Data Storage

 

2. 특징

기능	설명
인메모리 데이터베이스	데이터를 메모리에 저장 → 빠른 처리 속도
메모리 사용량 최소화	자료구조 단순화 및 최적화 → 적은 메모리로 많은 데이터를 처리할 수 있음
빠른 응답 속도	지연 시간 짧음 → 실시간 통신 애플리케이션에 적합 (게임, 채팅, 알림 등)
다양한 자료형 지원	String, List, Hash, Set, Sorted Set 등 → 구조화된 데이터 관리 쉬움
낮은 의존성	외부 라이브러리 없이 독립적으로 동작함 → 외부 버그 발생 위험 없음

 

싱글스레드

• 기본적으로 단일 스레드로 동작 → 동시성 문제 방지

특징	설명
이벤트 기반 처리	클라이언트 요청을 하나의 이벤트로 인식
이벤트 루프 형성	내부적으로 이벤트 루프라는 반복 구조를 가짐 - 이벤트 감지 및 순차 처리 → 간단하고 빠르게 동작함
고유 이벤트 라이브러리 (ae)	ae(Async Event) 라이브러리를 사용하여 이벤트 관리
CPU 병목 방지
📌 부분적 멀티스레드 지원	일부 명령어에서 멀티스레딩을 활용 (예: RDB 저장 등)
📌 비동기 처리 지원	UNLINK, FLUSHDB, FLUSHALL 명령어에 ASYNC 옵션 제공 → 백그라운드로 처리함

 

기능

특징	설명
Pub/Sub	메시지 Publish-Subscribe 모델 지원 - 메시지 브로커 역할 담당 - 채널을 통해 메시지 통신 → 실시간 메시지 시스템 구축 가능
Lua Script	서버에서 스크립트 실행 가능 - RDBMS의 스토어드 프로시저와 유사한 기능 → 복잡한 로직을 서버에서 처리 가능
Transaction	여러 개의 Redis 명령을 한 번에 원자적으로 실행 가능
TTL(Time-To-Live)	키에 만료 시간을 설정하면, 시간이 지나면 자동으로 삭제됨
레플리케이션 및 클러스터	여러 노드 간 데이터 복제 및 수평 확장을 위한 클러스터 기능 제공 → 대규모 서비스에서도 안정적인 운영 가능

 

예제) Transaction

하나의 명령어처럼 묶어 실행 (MULTI, EXEC 명령어 사용)

MULTI
INCR user:1000:balance
DECR user:1000:points
EXEC

 

 

한계

• 롤백 X
• 예외 처리 X
• 일관성 약함 (복제 지연, 클러스터 환경 등에서 일시적으로 데이터 불일치 발생 가능

 

영속성

특징	설명
RDB 스냅샷	일정 시간 간격으로 메모리 데이터를 디스크에 저장 → 백업 가능
AOF (Append-Only File)	모든 변경 사항을 로그 형태로 저장 → 장애 복구 가능

 

3. vs RDBMS

비교 항목	RDBMS	Redis
스키마	테이블을 만들 때 스키마 정의 필요	스키마 없이 유연한 데이터 저장 가능
데이터 일관성	정합성 유지 용이	정합성 유지가 어려움
데이터 변경	데이터 모델 변경이 어렵고 비용이 큼	데이터 모델 변경이 자유롭고 빠름
트랜잭션 (ACID)	ACID 보장	간단한 트랜잭션만 지원 일부 일관성 문제 존재
일관성 요구사항	엄격한 일관성이 필요한 경우 적합	일시적인 불일치 허용 가능한 시스템에 적합
주요 사용 사례	금융 시스템, ERP, CRM 등 (정확한 데이터 관리)	캐싱, 실시간 분석, 메시지 큐 등 (빠른 응답)

 

 

RDBMS와 조합

• RDBMS에서 보관하는 데이터양이 많아지면 여러 문제가 발생할 수 있음
  • 성능이 떨어짐 → 인덱스 설정 및 쿼리 튜닝
  • 용량이 부족함 → 클러스터링으로 서버 대수 늘리기
  • → 문제 해결을 위해 여러 설계 및 관리 비용이 부과됨
• 레디스를 캐시로 활용하여 서비스 성능을 높일 수 있음
  
  • 특히 조인한 결과가 여러번 사용되는 경우 유용함

 

예제) 서비스 흐름

Cache - Aside 패턴

1. 클라이언트: 웹 페이지 열람
2. 서버: 레디스에 질의
   • 레디스에 데이터 있으면 → 클라이언트에 바로 응답
   • 레디스에 데이터 없으면 → RDBMS에 데이터 질의 → 조회 결과를 Redis에 캐싱 → 응답

 

4. vs Memcached

비교 항목	Redis	Memcached
주 용도	데이터베이스, 캐시, 메시지 브로커 등	캐시 전용 (DB 보완)
데이터 유형	String, List, Set, Sorted Set, Hash 등 다양한 자료형 지원	String 자료형만 지원
데이터 영속성	데이터 저장 가능 (AOF, RDB 방식 지원)	휘발성 (데이터 저장 불가)
스냅샷 기능	RDB 스냅샷, Append Only File(AOF) 지원	없음
분산 처리	클러스터링 및 복제 기능 제공	기본적으로 단일 인스턴스
메모리 효율	메모리 최적화 가능 (LRU, LFU 정책 지원)	단순한 키-값 저장 방식으로 빠르지만 최적화 기능 부족
주요 사용 사례	세션 관리, 실시간 데이터 처리, 랭킹 시스템, 큐 시스템	DB 조회 결과 캐싱, 웹 페이지 캐싱