[Redis] Redis 요약 및 정리

1. Redis 참고 사이트

Redis 사용법에 대해 자세히 나열되어있는 사이트이다. (redisgate.kr/redis/introduction/redis_intro.php)

Redis 참고 사이트

 

 

 

2. Redis

1) Redis

REmote Dictionary Server의 약자로, 메모리 기반의 키-값 구조 데이터 관리 시스템이며, 모든 데이터를 메모리에 저장하고 조회하기에 빠른 Read, Write 속도를 보장하는 비관계형 데이터베이스이다. 키-값 스토리지형 NoSQL로, 아주 많은 양의 데이터를 효율적으로 처리가 필요할 때, 데이터의 분산처리, 빠른 쓰기 및 데이터의 안정성이 필요할 때 사용한다. Redis는 크게 String, List, Set, Sorted Set, Hash의 데이터 형식을 지원한다.

 

Redis는 특별한 경우가 아니라면 주로 캐시용으로 많이 사용한다.

2) 데이터 유형

데이터 유형

3) redis.conf

설치된 Redis의 설정파일에는 RDB 지속성 설정, AOF 지속성 설정, Replication(Slave) 설정, 각종 보안 설정, 메모리 제한 설정 등 목적에 따라 다양하게 설정이 가능하다.

4) Look Aside, Write-Through 구조

Look Aside 구조

Write-Through 구조

 

 

 

3. Redis 특징

1) Persistence

Redis 는 데이터를 메모리에 저장한다. 따라서 서버가 비정상적으로 종료가 되면 모든 데이터가 날아간다. 이런 문제를 해결하기 위하여 Redis는 크게 2가지(RDB, AOF) 방식을 지원한다.

2) RDB (Snapshot, 백업)

순간적으로 메모리에 있는 내용을 디스크에 전체를 옮겨 담는 방식이다. 서버 재시동시 스냅샷만 로딩하면 되기에 재시동 시간이 빠르지만 스냅샷을 추출하는데 시간이 오래걸리며 백업 시점의 데이터만 유지되기에 백업 이후의 데이터는 유실된다.

3) AOF (Append Only File, 보관)

Redis의 모든 쓰기, 업데이트 연산 자체를 모두 로그 파일에 기록하는 형태이다. 서버가 재시작될 때 기록된 write, update 연산을 순차적으로 재실행하여 데이터를 복구한다. 연산이 발생할 때마다 매번 기록하기 때문에 RDB와는 다르게 특정 시점이 아닌 항상 현재 시점까지의 로그를 기록할 수 있으며 기본적으로 Non-Blocking Call이다. 데이터 유실이 발생하지 않으며 로그 write 속도가 빠르지만, 로그 양이 많으며 재시작시 속도가 느리다는 단점을 가지고 있다.

※ RDB와 AOF 혼용하여 사용하는 것을 권장한다.

4) Pub/Sub

간단히 말한다면 메시지를 보내고 받는 기능이다. 1:1 형태뿐만이 아닌 1:N 형태로 메시징을 지원한다. 즉, 하나의 클라이언트가 Publish를 할 경우, 이 Topic에 연결된 다수의 클라이언트가 메시지를 받을 수 있다.

5) Replication (Master-Slave 구조)

쉽게 말하면, Master-Slave 구조를 뜻한다. 즉, Master 노드에 write된 내용을 Slave 노드가 복제하는 Non-Blocking 구조이다. 또한 이 구조에서는 Query Off Loading을 통한 성능 향상을 할 수 있는데,  Master는 write only, Slave는 read only로 Redis의 성능을 높이는 효과적인 방법이있다.

 

Master-Slave 구조에서 복제 연결이 되어있는 동안 Master 노드의 데이터는 실시간으로 Slave 노드에 복사된다. (Master 노드는 자식 프로세스를 만들어 백그라운드로 덤프파일을 생성하고 이를 Slave 노드에 보낸다.) 따라서 서비스를 제공하던 Master가 종료되더라도 Slave 노드에 애플리케이션을 재연결해주면 서비스를 계속 사용할 수 있다.

 

하지만 데이터 복제는 비동기 방식으로 이루어지기 때문에 애플리케이션에서 Master까지만 데이터가 입력된 후 Master 노드가 종료될 경우 Slave까지 전달이 되지 않고 데이터가 유실될 수 있다.

 

 

4. Redis Mode

1) Standalone Mode

Standalone은 말 그대로 하나의 Redis 인스턴스로 서비스를 하는 방식이다.

2) Sentinel Mode

Sentinel은 Redis의 Master/Slave를 모니터링하는 서버로 관리하는 서버의 상태 체크, Failover 기능을 자동으로 지원해준다. 쉽게 말하면, Master-Slave 구조에서 Master가 비정상적으로 종료되었을 때 Slave 노드에서 Master 연결을 해제하고 애플리케이션에서 Redis 연결 설정을 변경해주는 번거로운 작업을 해결해주는 방식이다.

 

Sentinel은 Master와 Slave 노드를 계속 모니터링하며 장애상황에는 Slave 노드를 Master 노드로 승격시키기 위해 자동 Failover를 진행한다. 정상적인 기능을 위해서는 적어도 3개의 Sentinel 인스턴스가 필요하고, 각 Sentinel 인스턴스는 Redis의 모든 노드를 감시하며 서로 연결되어 있다. Sentinel 노드 중 과반 수 이상이 동의해야만 Failover를 시작할 수 있다. (홀수로 구성)

 

예를 들어 Sentinel 노드 1, 2, 3이 존재할 때, Sentinel 1이 Master 노드가 응답이 없다고 2와 3에게 알린다. 만약 2와 3이 Master 노드와 응답에 성공했을 경우 Master의 상태를 정상으로 판단하고 응답에 실패하면 장애라 판단하여 Slave 노드를 Master 노드로 변경한다. (응답이 없다고 알린 상태를 Subjective Down, 응답에 실패하여 장애로 판단한 상태를 Objective Down이라고 한다.)

Sentinel Mode

3) Cluster Mode

Redis 클러스터는 데이터셋을 여러 노드에 자동으로 분산하는 확장성 및 고성능의 특징과 일부 노드가 종료되어도 계속 사용 가능한 고가용성의 특징을 가지고있다.

 

Redis 클러스터를 알기 이전에 성능 향상과 데이터 샤딩에 대해 이해해야 한다. 복제는 데이터를 똑같이 다른 노드에 복사를 하는 것이라면, 샤딩은 데이터를 분산하여 저장하는 기법이다. 즉, 복제에 비해 더 많은 데이터를 나눠서 저장할 수 있다.

 

데이터 샤딩을 하게 될 경우, 일부 노드가 죽어도 다른 노드에 영향을 주지 않는다. 만약 일부 노드의 데이터가 전부 유실되어 복구할 수 없을 경우 서비스에 장애가 발생하기에, 보통 클러스터 인프라를 구축할 때 Master 노드에 Slave 노드를 최소 1대 이상 연동한다.

데이터를 어떤 노드에 저장되는지에 대한 알고리즘은 기본적으로 해시 함수를 적용해서 노드에 할당하며 단일 장애점이 없는 Mesh 토폴로지를 이용한다.

※ AWS에서는 Redis용 ElasticCache를 지원한다.

---

[참고] brunch.co.kr/@beennote/220

[참고] brunch.co.kr/@springboot/218

[참고] medium.com/garimoo

[참고] Database - Practice - Redis Replication (Master-Slave)

[참고] Database - Practice - Redis Sentinel

[참고] Database - Practice - Redis Cluster