Redis란

 

◆  Redis(Remote Dictionary Server)
- NoSQL 데이터베이스 중 하나이며 오픈소스 소프트웨어 ! 
 주요한 특징은 'key - value' 형태로 데이터를 저장하고 데이터를 '인-메모리 데이터 저장소'에 저장하는 형태를 가지는 데이터 베이 스임
- 'key-value' 형태로 데이터를 저장하며 '다양한 종류의 값'을 지정 가능함. 값으로는 문자열, 리스트, set, hash등을 지원
- '인 메모리 데이터 저장소'를 사용하기에 서버의 메인 메모리에 모든 데이터를 저장하므로, 디스크 I/O를 거치는 다른 데이터베이스 시스템보다 훨씬 빠른 성능을 보여줌
- 메모리에 저장되는 데이터 베이스는 디스크에 저장하여 휘발성으로 사용되는 데이터를 영구적으로 저장하는 기능을 제공하여 서버가 다운되더라도 데이터를 복구할 수 있음
- 주로 데이터베이스, 캐시, 메시지 브로크 등 다양한 용도로 사용가능

※ Redis는 모든 데이터를 저장하는 공간이 아님
    실제 사용하는 모든 데이터를 저장하는것이 아닌 많이 사용하는 데이터를 가져와서 조회하는것이 핵심

https://www.sunjesoft.co.kr/faq/__faq/in-memory-dbmswa-disk-dbms-yi-caijeomi-mueosingayo

Tip
NoSQL
- Not Only SQL 또는 Non-Relational SQL 이라는 의미를 가지며 관계형 데이터베이스(RDBMS)
  가 아닌 다른형태의 데이터 저장소를 의미하며 스키마가 없거나 유연한 스키마를 가지고 있어 
  데이터 구조가 고정되어 있지 않습니다. 이로 인해 다양한 형태의 데이터를 저장하고 관리할 수 있음
  
Redis 서버를 내리고 다시 서버를 올리면 데이터가 모두 사라질까?
- Redis는 기본적으로 인-메모리 데이터 구조 저장소이기 때문에, 서버가 종료되면 메모리에 저장된
  데이터는 사라진다
  
  하지만 Redis는 디스크에 데이터를 저장하는 영구 저장 기능을 제공함 이 기능을 사용하면
  서버가 종료되어도 데이터를 복구할 수 있음
  이 영구저장방식은 RDB(Redis Database)와 AOF (Append Only File) 두 가지 방법이 있음

Redis를 알려면 NoSQL 데이터베이스의 구조부터 알아야 겠지?

https://learn.microsoft.com/ko-kr/dotnet/architecture/cloud-native/relational-vs-nosql-data

 

구분	정의	특징	종류
문서저장소(documet store)	데이터 및 메타데이터는 데이터베이스 내의 JSON 기반 문서에 계층적으로 저장됩니다.	유연한 데이터 구조를 가질 수 있음	MongoDB, Couch DB
키-값 저장소(Key-value Store)	NoSQL 데이터베이스 중 가장 간단하며, 데이터가 키-값 쌍 컬렉션으로 표시됩니다.	단순하고 빠른 읽기/쓰기가 가능	Redis, Riak
열 지향 데이터베이스(Wide-Column Stroe)	관련 데이터가 단일 열 내부에 중첩 키/값 쌍 세트로 저장됨	대량의 데이터를 빠르게 처리할 수 있음	Cassandra, Hbase
그래프 저장소 (Graph Store)	데이터가 그래프 구조에 노드, 에지 및 데이터 속성으로 저장됨	복잡한 관계를 가진 데이터를 저장하고 조회할 수 있음	Neo4j, ArangoDB

 

◆  Redis 데이터 저장구조 : Collection Type
- 키-값(Key-Value) 형태로 데이터를 저장하는 Redis 내에서는 '키'는 문자열 형태로 고정되어 있지만,
'값'은 Strings, Bitmaps, Bit field, Hashes, Lists, Sets, Sorted Sets, Geospatial Indexes, Hyperloglogs, Streams 형태로 다양한 데이터 저장이 가능함

https://velog.io/@tilsong/Redis%EC%9D%98-%EC%A3%BC%EC%9A%94-%EA%B8%B0%EB%8A%A5-1-%EC%9D%B8-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4

데이터 타입	설명	예시
Strings	텍스트 또는 숫자 등의 문자열을 저장할 수 있는 기본 타입입니다.	"Hello, World!"
Bitmaps	각각의 비트 위치에 0과 1 값을 저장하여 사용하는 비트 단위의 연산을 지원하는 데이터 타입입니다.	0101
Bit field	Bitmap과 유사하지만, 더 큰 크기의 비트 필드를 다룰 수 있습니다.	00010011
Hashes	키-값 쌍을 저장하는 데이터 타입으로, 객체를 표현하기에 적합합니다.	{name: "John", age: 30}
Lists	순서가 있는 문자열의 집합을 나타내는 데이터 타입으로, 새로운 요소는 앞이나 뒤에 추가할 수 있습니다.	["apple", "banana", "cherry"]
Sets	순서가 없는 유일한 문자열의 집합을 나타내는 데이터 타입입니다.	["apple", "banana", "cherry"]
Sorted Sets	Sets와 유사하지만 각 멤버는 점수를 가지며, 이 점수에 따라 정렬됩니다.	[(1, "apple"), (2, "banana"), (3, "cherry")]
Geospatial Indexes	지리적 위치 정보를 다루는 데 사용되는 데이터 타입입니다.	{"latitude": 37.7749, "longitude": 122.4194}
Hyperloglogs	크기가 큰 데이터 세트의 카디널리티를 추정하는데 사용되는 중복된 요소를 세는데 유용한 구조입니다.	["apple", "apple", "banana", "cherry", "cherry", "cherry"]
Streams	메시지 큐 시스템에 사용되는 데이터 타입으로, 메시지는 키-값 쌍으로 구성되며, 각 메시지는 유일한 ID를 가집니다.	{"id": 1, "message": "Hello"}

 

◆ 인 메모리 데이터 구조

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

https://blog.naver.com/shakey7/221310751665

Tips. RDBMS와 In Memory DB 비교

구분	RDBMS	In Memory DB
데이터 저장 위치	디스크	메모리(RAM)
속도	상대적으로 느림(디스크 I/O가 발생하기 때문)	매우 빠름(메모리에서 직접 데이터를 읽고 쓰기 때문)
데이터 유실	트랜잭션이 완료된 시점에서의 데이터는 안전하게 보존됨	전원 공급이 중단되거나 시스템이 다운될 경우 데이터 유실 가능성 있음
용도	대용량 데이터 저장 및 관리	빠른 응답 시간이 필요한 실시간 처리, 캐싱, 임시 데이터 처리 등에 적합
데이터 복구	디스크에 데이터가 저장되므로 시스템 장애 후에도 데이터를 복구할 수 있음	추가적인 조치(예: 디스크에 스냅샷 저장, 복제 등)가 없는 경우 데이터 복구가 어려움
비용	하드웨어 비용이 상대적으로 적게 듦	대용량의 메모리가 필요하므로 하드웨어 비용이 높을 수 있음

 

◆ Redis Disk 저장방식 : RDB(Snapshot), AOF (Append On File), No Persistence, RDB + AOP

방식	설명	장점	단점
RDB(Redis Database)	설정한 시간 간격에 따라 데이터의 스냅샷을 일정한 시점에 디스크에 저장	빠른 백업 가능, 백업 파일 크기 작음	스냅샷 이후의 데이터 손실 가능, 데이터의 일관성이 중요한 애플리케이션에는 적합하지 않음
AOF(Append On File)	모든 write or update 연산을 로그 형태로 저장	데이터 복구 시점에서 최신의 데이터 상태 유지 가능	로그 파일 크기가 커질 수록 디스크 공간을 많이 차지, 디스크 I/O 부하 큼
No Persistence	디스크에 데이터를 저장하지 않음	디스크 공간을 절약함	서버가 다운되면 모든 데이터가 손실됨
RDB + AOF	RDB와 AOF를 결합한 방식	RDB의 빠른 백업과 AOF의 데이터 일관성 장점을 모두 가짐	디스크 공간과 I/O 부하가 많이 필요함

 

1. RDB

RDB (Redis Database)
- 설정한 시간 간격에 따라 데이터의 스냅샷을 일정한 시점에 디스크에 저장.
  빠른 백업이 가능하며 크기가 작어 백업 파일을 다른 서버로 이동하는것이 용이
  
- 그러나 스냅샷을 수행한 이후 발생한 데이터 손실이 발생할 수 있기 때문에
  데이터의 일관성이 중요한 애플리케이션에는 적합하지 않음

https://server-talk.tistory.com/489

 

2. AOF(Append On File)

 AOF(Append On File)

- 모든 write or update 연산을 로그 형태로 저장하는 방식 
  이 방식은 모든 데이터 변경 작업을 디스크에 기록하기 때문에
  데이터 복구 시점에서 최신의 데이터 상태를 유지할 수 있습니다.

- 그러나 로그 파일 크기가 커질수록 디스크 공간을 많이 차지하게 되고, 
  또한 많은 데이터 변경 작업을 기록하기 때문에 디스크 I/O 부하가 
  RDB 방식보다 크게 될 수 있습니다.

https://server-talk .tistory.com/489

 [더 알아보기 ]

 .aof 파일이 로그파일을 의미하는가?

- Redis에서 AOF(Append Only File)는 데이터 변경 작업을 기록하는 로그 파일을 의미합니다.
  이 방식은 모든 데이터 변경 작업을 디스크에 기록하기 때문에,
  데이터 복구 시점에서 최신의 데이터 상태를 유지할 수 있습니다.

 

3. No Persistence

No Persistence

- 데이터를 디스크에 저장하지 않는 방식입니다.
  이 방식은 메모리에만 데이터를 저장하기 때문에 빠른 응답 시간을 제공할 수 있습니다.

- 그러나 서버가 다운되면 데이터가 모두 손실됩니다. 
  따라서, 데이터의 지속성이 중요하지 않은 일시적인 캐시 등에 사용됩니다.

 

4. RDB + AOF

RDB + AOF

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

https://adjh54.tistory.com/447

 

◆ Redis 주요 특징 및 사용 목적

1. 특징

특징	설명
인-메모리 데이터 구조 저장소	데이터를 컴퓨터 메모리에 저장하여 빠른 속도로 데이터에 접근할 수 있습니다.
키-값 형태의 데이터 구조	다양한 종류의 값(문자열, 리스트, 셋, 정렬된 셋, 해시 등)을 지원합니다.
영구적인 데이터 저장	데이터를 디스크에 저장하는 방식을 사용하면 휘발성 데이터를 영구적으로 저장할 수 있습니다.
고성능	인-메모리 저장, 단순한 데이터 모델, 비동기 복제 등으로 높은 성능을 제공합니다.
다양한 용도	데이터베이스, 캐시, 메시지 브로커 등 다양한 용도로 사용될 수 있습니다.
데이터 복제	비동기식 복제를 지원하여 데이터의 안정성과 가용성을 높입니다.
지속성	RDB와 AOF 방식을 통해 데이터를 디스크에 저장하므로 서버가 다운되더라도 데이터를 복구할 수 있습니다.
싱글 스레드	모든 요청을 순차적으로 처리합니다. 이로 인해 동시성 문제를 피하며, 복잡한 동기화 기법이 필요 없습니다.
클라이언트 샤딩	데이터를 여러 노드에 분산시키는 기법으로, 더 높은 수준의 가용성과 성능을 제공합니다.
Pub/Sub 지원	발행/구독 모델을 지원하여, 메시지 통신이나 이벤트 기반 아키텍처를 구현하는데 이용됩니다.

 

2. 사용용도

사용 사례	설명
캐싱	데이터를 메모리에 저장하여 빠른 읽기/쓰기 작업을 제공합니다. 데이터베이스로부터 반복적으로 데이터를 가져오는 대신, Redis를 사용하여 캐시로서 데이터를 저장하고 조회하는 데 사용됩니다.
세션 저장	웹 애플리케이션에서 사용자 세션 정보를 저장하는 데 주로 사용됩니다. 빠른 응답 시간을 제공하며, 세션 정보를 실시간으로 공유해야 하는 환경에서 유용합니다.
실시간 분석	빠른 읽기/쓰기 성능과 다양한 데이터 구조를 지원하기 때문에 실시간 분석에 사용될 수 있습니다. 웹사이트 방문자 수, 주식 가격 등을 실시간으로 추적하고 분석하는데 사용됩니다.
메시지 큐	발행/구독 및 리스트 데이터 구조를 지원하기 때문에 메시지 큐 시스템으로 사용될 수 있습니다. 서비스 간에 비동기 메시징을 처리하는 데 사용됩니다.
대기열	작업 요청 등을 순서대로 처리하기 위해 사용됩니다. 사용자가 요청을 보내면 이를 대기열에 추가하고, 시스템은 대기열에서 요청을 꺼내서 처리합니다.
속도 제한	특정 시간 동안의 요청 수를 제한하여 서비스의 과부하를 방지합니다. 이는 API 호출 수 제한이나 로그인 시도 횟수 제한 등에 사용될 수 있습니다.

 

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

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

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

- 또한 확장성을 가지기 위해 클러스터(Cluster)를 이용하는 방법으로 확장성을 높입니다.

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

 

1) 복제 (Replication)

복제(Replication)

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

- 마스터 노드에서 시작되며, 슬레이브 노드는 마스터에 연결하여 데이터를 복제하라는 명령을 보냅니다.
  마스터 노드는 자신의 데이터 세트를 슬레이브에게 전송하고, 
  이후에는 모든 새로운 명령(데이터 변경을 일으키는 명령)을 슬레이브에게 전송하여 
  슬레이브의 데이터 세트를 최신 상태로 유지합니다.

- 슬레이브 노드는 복제된 데이터를 사용하여 읽기 쿼리를 처리할 수 있으므로, 
  전체 시스템의 읽기 성능이 향상됩니다. 또한, 마스터 노드에 문제가 발생한 경우 
  슬레이브 노드는 마스터의 역할을 수행할 수 있으므로 시스템의 가용성이 높아집니다.

맨위에 말했듯 Redis는 모든 데이터를 저장하는 공간이 아니기 때문에 일반 DB보다 용량이 적음
그래서 데이터를 복제하여 Master (쓰기, 수정, 삭제) , Slave (읽기)를 나누어 처리
Master는 하나 Slave는 여러개 두어서 자주쓰는 데이터들은 Slave를 통하여 조회

예시

상황: 회원 정보 시스템

1. 회원가입 요청 (쓰기)
   → Master Redis에 저장
   → Master가 자동으로 Slave들에게 복제
   
2. 회원 정보 조회 (읽기)
   → Slave Redis에서 조회
   
3. 또 다른 회원 정보 조회 (읽기)
   → 다른 Slave Redis에서 조회
   
결과
Master 1개: 읽기 1000건/초 처리 가능
Slave 3개 추가: 총 4000건/초 처리 가능!

[사용자1] → Slave1 읽기
[사용자2] → Slave2 읽기  
[사용자3] → Slave3 읽기
[사용자4] → Master에서 쓰기

정리 : Replication은 같은 데이터를 여러곳에 복사해두는것이야 / 읽기요청을 여러 서버로 분산시켜서 성능을 향상시킴

추가설명
Redis 복제(Replication) 방식

- 해당 아키텍처에서는 ‘Master Node’를 기준으로 복제(Replication)를 통해서 
  ‘Slave Node’를 구성합니다.

- Master node와 Slave node의 동기화 시점은 ‘복제(Replication)’가 수행된 이후 
  마스터 노드에서 새로운 명령(데이터 변경을 일으키는 명령)을 수행하면 
  슬레이브 노드에서 데이터를 최신 상태로 유지합니다.
- 데이터 쓰기 작업 : App에서는 Master Node에 데이터를 Write 합니다.
- 데이터 읽기 작업 : App에서는 Slave Node에서 데이터를 Read 합니다.

💡 Master Node를 기준으로 Slave Node가 생성되는 시점은 언제인가?

- Slave 노드가 Master에 연결하고 데이터 복제를 요청하는 시점입니다.
- 이 시점에 Master 노드는 자신의 데이터 세트를 Slave 노드에게 전송하고, 
  이후 모든 새로운 명령(데이터 변경을 일으키는 명령)을 Slave에게 전송하여 
  Slave의 데이터 세트를 최신 상태로 유지합니다.


💡 Master Node와 Slave Node 동기화가 수행되는 시점은?

- Slave Node가 Master Node에 연결하고 데이터 복제를 요청하는 시점에 시작됩니다.
- Master Node는 자신의 데이터 세트를 Slave Node에 전송하고, 
  모든 새로운 명령(데이터 변경을 일으키는 명령)을 Slave Node에 전송하여
  Slave Node의 데이터 세트를 최신 상태로 유지하게 됩니다. 따라서, 
  Master Node와 Slave Node의 동기화는 지속적으로 이루어지며,   
  이는 새로운 데이터가 Master Node에 기록될 때마다 발생합니다.


💡 그럼 사실상 복제(Replication) 과정이 수행되면 동기화 작업도 자동으로 이뤄지는 거네?

- 복제(Replication) 과정에서 마스터 노드는 자신의 데이터 세트를 슬레이브 노드에 전송하고, 
  이후 모든 새로운 명령(데이터 변경을 일으키는 명령)을 슬레이브 노드에 전송하여 
  슬레이브 노드의 데이터 세트를 최신 상태로 유지합니다. 따라서, 복제 과정이 지속적으로 
  이루어지면서 동기화도 같이 이루어집니다.


💡 복제(Replication)를 수행하면 메모리를 두 배 사용하는 거 아닌가?

- 복제를 수행하면 각 슬레이브 노드가 마스터 노드의 데이터를 복제하기 때문에, 
  전체적으로 봤을 때 메모리 사용량은 증가하게 됩니다.
- 그러나 이는 데이터의 내구성을 높이고, 읽기 쿼리의 성능을 향상하며, 
  시스템의 가용성을 높이는 데 기여합니다. 이러한 이점을 고려하면 메모리 사용량 
  증가는 투자 대비 효과가 높다고 볼 수 있습니다.

http://russellluo.com/2018/07/redis-replication-demystified.html

 

2. 보초 (Sentinel)

 보초(Sentinel)

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

- 해당 구성은 Replication + Sentinel 형태로 구성합니다.
- Replication 내에서는 Master Node와 Slave Node로 구성된 형태로 구성이 되어 있습니다. 
  해당 과정에서 Sentinel을 두어서 각각 Master Node와 Slave Node를 모니터링합니다.

https://www.stevenchang.tw/blog/2020/12/06/redis-notes-redis-sential

Tip

Sentinel을 사용하는 경우 master, slave에 각각 하나씩 가지고 있는 건가?

- 하나의 Sentinel 인스턴스는 여러 Redis 서버(마스터와 슬레이브 모두)를 모니터링할 수 있습니다.
- 일반적으로는 여러 Sentinel 인스턴스를 사용하여 고가용성을 보장하고, 
  서로 다른 Sentinel 인스턴스들은 서로 통신하여 투표 메커니즘을 통해 
  마스터 서버의 장애를 감지하고 슬레이브 중 하나를 새로운 마스터로 승격시킵니다. 
  따라서, 마스터와 슬레이브에 각각 하나의 Sentinel을 두는 것이 아니라, 
  Sentinel 인스턴스는 전체 Redis 아키텍처를 모니터링하는 역할을 합니다.

 

3. 클러스터 ( Cluster )

클러스터(Cluster)

- 클러스터 구성은 여러 노드로 구성되며, 키 공간은 노드 간에 자동으로 분할됩니다. 
  이를 통해 높은 성능과 스케일링을 달성할 수 있습니다.

- 데이터는 해시 슬롯을 사용하여 노드 간에 분배되며, 이는 데이터를 균등하게 분산시키고, 
  노드 추가 또는 제거 시 데이터 재분배를 용이하게 합니다.

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