Redis 이해하기

 

 

 

Redis란?

 

 

Redis는 빠르고 가볍고 유연한 현대 백엔드 시스템의 핵심 중 하나이다.

 

레디스를 공부하지 않을 수가 없다는 걸 알 수 있다.

 

 

Redis(REmote DIctionary Server)는 키-값(key-value) 구조로 데이터를 저장하는 인메모리 기반의 NoSQL 데이터 저장소이다.

• 메모리에 저장하므로 속도가 매우 빠름 (읽기/쓰기 모두 수 밀리초 수준)
• 디스크에도 저장 가능 (RDB, AOF) → 영속성 보장 가능
• 다양한 자료구조 지원: 문자열, 리스트, 셋, 해시, 정렬된 셋 등
• 분산 환경에서도 사용 가능 → 클러스터, Sentinel 지원

 

Redis는 RAM 기반 처리로 빠른 응답을 한다.

 

간단하게 redis를 사용하는 이유를 보자면

 

 

이렇게 설명할 수 있다.

 

 

 

어디에 쓰일까?

단순히 사람들이 많이 써서 나도 해야 한다는 것보단 어디서 어떻게 유용하게 쓰이는지를 알아야 빠르게 학습할 수 있다고 생각한다.

 

어떤 상황에서 어떻게 쓰이는지 알아보자.

 

 

 

세션 관리

웹 애플리케이션에서 사용자가 로그인하면 그 사용자의 로그인 상태를 일정 시간 동안 유지해야 한다.

 

이때 로그인 정보나 인증 토큰을 어디에 저장해야 할까?

 

Redis는 메모리에 데이터를 저장하므로 속도가 빠르고 TTL(Time-To-Live)을 설정할 수 있어서 일정 시간 후 자동 만료되는 세션 관리에 적합하다.

 

사용자가 로그인 하면 Redis에 사용자 ID와 세션 토큰을 저장하고, 요청마다 이 값을 확인해서 로그인 상태를 유지한다.

 

 

캐시 처리

Redis 하면 보통 떠오르는게 캐싱이다.

 

데이터베이스에서 동일한 쿼리를 반복적으로 조회하면 성능 저하가 발생한다. (인기 상품 목록, 공지사항 등 자주 조회되지만 변경 잘 안됨)

 

이런 자주 조회되지만 변경이 드문 데이터를 Redis에 저장해두고 요청이 들어올 때마다 DB가 아닌 Redis에서 바로 값을 반환하면 속도가 크게 향상된다.

 

이걸 캐싱이라고 하는데 대표적인 캐시 전략으로 SET key value EX 300 같은 명령으로 TTL 설정도 함께 한다.

 

 

순위 시스템

게임 앱에서 점수 기반 랭킹 보드, 커뮤니티 사이트의 좋아요/댓글 수 기반 인기글 정렬 등, 실시간 순위 정보를 제공해야 할 때가 꽤 많다.

 

여기선 Sorted Set 자료구조를 사용하면 유용하다.

 

• ZADD ranking 1000 "홍길동" → 홍길동 점수 1000으로 등록
• ZRANGE ranking 0 9 WITHSCORES → 상위 10명 조회
  점수(Score)를 기준으로 자동 정렬되므로 순위 계산이 매우 간단하고 빠르다.

 

 

실시간 채팅

여러 사용자가 동시에 메시지를 주고 받는 실시간 채팅 시스템 같은 경우에도 Redis의 Pub/Sub 기능을 활용하면 발행 - 구독 모델로 메시지를 실시간 처리가 가능하다.

 

• A 사용자가 메시지를 Publish 하면
• 같은 채널을 Subscribe한 B,C 사용자에게 실시간으로 전파된다.

 

 

메시지 큐

사용자의 요청을 즉시 처리하지 않고 비동기적으로 백그라운드에서 처리해야 할 때가 있다

-> 회원가입 후 환영 이메일 전송, 주문 알림 전송

 

Redis의 List 자료구조를 이용하면 간단한 큐를 구성할 수 있다.

 

생산자는 LPUSH로 메시지 큐에 넣고 소비자는 RPOP이나 BRPOP으로 메시지를 하나씩 꺼내서 작업을 수행할 수 있다.

 

이것 외에도 여러가지 상황에서 Redis를 사용할 수 있다.

 

 

 

 

Redis의 동작 방식

 

Redis는 단순한 키-값 저장소지만 내부적으로는 매우 체계적이고 빠른 방식으로 데이터를 주고받는다. 전체적 흐름을 보자.

 

 

1. 클라이언트가 Redis 서버에 접속 요청

 

Redis를 사용하려면 먼저 클라이언트(사용자 또는 애플리케이션)가 Redis 서버에 연결해야 한다.

• Redis는 주로 TCP/IP 기반으로 통신한다 (기본 포트는 6379).
• 연결은 하나의 세션처럼 유지되며, 그 안에서 여러 명령을 주고받을 수 있다.
• 클라이언트는 직접 명령을 입력할 수도 있고 코드(Java, Python, Node 등)로 명령을 전송할 수도 있다.

 

 

2. 클라이언트가 명령을 서버에 보냄

 

클라이언트는 원하는 작업(데이터 저장, 조회, 삭제 등)을 Redis에게 명령어(Command) 형태로 보낸다.

 

 

• 명령은 텍스트 기반 프로토콜로 전송된다.
• 예를 들어 SET user 100은 user라는 키에 100이라는 값을 저장하라는 의미이다.
• 클라이언트는 일반적으로 명령어 + 키 + 값 형식으로 데이터를 보낸다.

SET session_token abc123
GET session_token

 

 

 

 

3. 서버가 명령을 해석

 

Redis 서버는 받은 명령을 문자 그대로 처리하지 않고 내부적으로 적절한 방식으로 분석(파싱)하고 검증한다.

 

 

• 이때 명령어가 올바른 형식인지 검사하고 필요한 경우 명령어를 적절한 데이터 타입으로 변환한다.
• 예를 들어 INCR user_count는 해당 키가 숫자인지 확인하고 증가 가능한 상태인지 체크한다.

 

 

4. 실제 데이터 처리

 

명령이 올바르게 해석되면 Redis는 서버의 메모리에 저장된 데이터 구조를 기반으로 실제 작업을 수행한다.

• SET, GET, DEL 등의 작업은 메모리에 있는 키-값 구조를 직접 다룬다.
• 복잡한 자료구조 (List, Set, Hash 등)도 이 단계에서 조작된다.
• 모든 데이터는 메모리에서 처리되므로 속도가 매우 빠르다.

 

예시:

• HSET user:1 name "성민" → user:1이라는 해시 구조에 name 필드 추가
• ZADD ranking 100 "성민" → 점수 100인 유저 '성민'을 랭킹에 추가

 

 

5. 처리 결과를 클라이언트에 응답

 

작업이 완료되면, Redis 서버는 명령 결과를 클라이언트에게 응답한다.

• 응답도 텍스트 기반이며 예외 발생 시 에러 메시지가 함께 전송된다.
• 클라이언트는 이 응답을 받아 결과를 화면에 출력하거나 로직 처리에 활용한다.

GET user
"홍성민"

 

 

 

 

6. 연결 종료 도는 재사용

 

클라이언트는 Redis와의 연결을 계속 유지하거나 작업이 끝났다면 명시적으로 연결을 종료할 수 있다.

• 단일 명령 후 바로 종료하는 단기 연결 방식도 있고,
• 여러 명령을 한 번에 처리하기 위해 연결을 유지한 채 사용하는 장기 연결 방식도 있다.
• 대부분의 애플리케이션에서는 Redis 연결을 계속 유지하다가 필요할 때만 닫는다.

 

 

 

Redis는 기본적으로 싱글 스레드로 동작함에도 불구하고 빠른 이유는 

 

-> 모든 작업이 메모리에서 이루어짐

-> 복잡한 디스크 I/O 없음

-> 명령어 자체가 간결함

 

 

 

Redis 주요 명령어

 

String

SET key value	키에 값 저장
GET key	키의 값 조회
DEL key	키 삭제
INCR key	정수 값을 1 증가
DECR key	정수 값을 1 감소
EXPIRE key seconds	TTL 설정
TTL key	남은 TTL 확인
APPEND key value	문자열 덧붙이기

 

 

 

List

LPUSH key value	왼쪽에 요소 추가
RPUSH key value	오른쪽에 요소 추가
LPOP key	왼쪽에서 꺼내기
RPOP key	오른쪽에서 꺼내기
LRANGE key start stop	특정 범위 요소 조회

 

 

 

Set

SADD key value	요소 추가
SREM key value	요소 제거
SMEMBERS key	모든 요소 조회
SISMEMBER key value	포함 여부 확인
SUNION key1 key2	합집합 반환

 

 

Hash

HSET key field value	해시에 필드-값 저장
HGET key field	필드 값 조회
HDEL key field	필드 삭제
HGETALL key	전체 필드-값 조회

 

 

 

 

서버를 끄면 데이터는 사라지는건가?

 

인메모리 데이터베이스인 Redis는 기본적으로 서버를 끄면 데이터가 휘발된다.

 

그러나 Redis는 데이터 영속성을 위해서 디스크에도 저장하고 이를 위해서 RDB와 AOF 방식을 제공한다.

 

RDB는 주기적으로 데이터 스냅샷을 기록하여 백업한다. -> 스냅샷을 저장하는 동안에 DB가 멈출 수 있음

AOF는 모든 쓰기 작업을 기록하여 내구성을 높인다. -> 서버가 재시작되면 이 로그 파일을 실행해서 데이터를 복원

 

RDB	일정 주기마다 스냅샷을 저장	빠른 복구, 적은 용량	최근 데이터 유실 가능
AOF	모든 명령어를 로그로 저장	데이터 유실 최소화	로그가 커질 수 있음
혼합	RDB + AOF 병행 사용	안정성과 성능 모두 확보	설정 필요

 

 

다음 시간엔 스프링 부트에서 Redis를 활용해보겠다.