[Redis] 레디스에 대해 알아보자

 

1. Redis 란 

레디스(Redis)는 메모리 기반의 데이터 저장소이다. 키-밸류(key-value) 데이터 구조에 기반한 다양한 형태의 자료 구조를 제공하며, 데이터들을 저장할 수 있는 저장소이다. 최신 버전의 레디스는 PUB/SUB 형태의 기능을 제공하여 메세지를 전달할 수 있다. 즉, 데이터 저장 뿐만 아니라 다양한 목적으로 사용할 수 있다.레디스는 메모리에 데이터를 저장하기 때문에 저장 공간에 제약이 있어, 주로 보조 데이터 저장소로 사용한다. 이를 극복하기 위해 레디스 클러스터 기능을 제공하고 있어 저장 공간을 확장할 수 있다. 또한 저장된 데이터를 영구적으로 디스크에 저장할 수 있는 백업 기능을 제공하므로 애플리케이션의 주 저장소로도 사용할 수 있다. 또한 메모리에 데이터를 저장하기 때문에 빠른 처리 속도가 장점이다. 레디스 내부에서 명령어를 처리하는 부분은 싱글 스레드 아키텍처로 구현되어 있다. 멀티 스레드 아키텍처보다 구조가 단단하게 설계되어 여러 장점이 있다. (출처 : 스프링 부트로 개발하는 MSA 컴포넌트 - 김병부)

 

2. Redis 캐시로 사용하는 방법 

먼저 캐시란, 데이터의 원래 소스보다 더 빠르고 효율적으로 액세스할 수 있는 임시 데이터 저장소를 말한다. (Temporary Location For Speed)
앞서 설명한 것처럼, Redis 는 단순한 key-value 구조이며, In-memory 데이터 저장소(RAM)를 가지고 있으며 빠른 성능을 가지고 있다.
평균 작업 속도가 1 ms 미만으로 초당 수백만건의 작업이 가능하다는 것을 뜻하기 때문에, 지연 시간도 감소하고 처리량도 증가하게 된다.

 

 

캐시는 찾는 데이터가 없을 때에만 입력되기 때문에 이를 Lazy Loading 이라 부른다. 

 

2. Redis 데이터 타입 활용

 

▶ String : 문자열 데이터를 저장 및 조회할 수 있는 기본 자료 구조.
    단순 증감 연산으로 사용 가능 (INCR / INCRBY / INCRBYFLOAT / HINCRBY / HINCRBYFLAOT / ZINCRBY)

▶ Bitmap : String의 변형이라고 볼 수 있으며, 비트 연산을 사용할 수 있는 자료 구조

▶ List : 리스트 데이터, 그림과 같이 리스트 아이템은 링크드 리스트(Linked List) 형태로 서로 연결되어 있으며, 큐(Queue) 로 사용하기 적절하다.

▶ Hashe : 해시 자료 구조. 해시 필드(field)와 밸류(value)로 구성된다. 해시 데이터는 레디스 키와 매핑되어 있으므로 해시 밸류를 생성 및 조회 하려면 레디스 키와 필드를 동시에 사용해야 한다.

▶ Set : 리스트와 비슷한 집합 데이터, 중복을 허용하지 않는 자료 구조이다.

▶ Sorted Set(ZSet) : Set과 비슷한 집합 데이터, 정렬 기능을 제공한다. 중복을 허용하지 않으며, 이 때 데이터는 스코어와 함께 저장할 수 있다. Sorted Set은 스코어 값을 사용하여 정렬하고, 스코어 값이 중복되면 사전 순으로 정렬한다.

▶ Hypperloglog : 집합의 데이터 개수를 추정할 수 있는 알고리즘 이름이자 이를 사용할 수 있는 레디스 자료 구조이다. 이 알고리즘은 비트 패턴을 분석하여 비교적 정확한 추정 값(오차 0.81%)을 계산할 수 있다. 많은 데이터를 다룰 때 사용한다. set과 비슷하지만 저쟝되는 용량은 12KB 고정되어 있다. 단점은 저장된 데이터를 다시 확인할 수 없다는 것이다. 경우에 따라 데이터를 보호할 목적으로도 적절하게 사용할 수 있다.

▶ Stream : 레디스 5.0 버전부터 제공하는 기능, 이벤트성 로그를 처리할 수 있다. Log를 저장하기 가장 좋은 자료구조

 

3. Redis에서 데이터를 영구 저장하는 방법 (RDB vs AOF)

1) RDB : 스냅샷 방식으로 동작하기 때문에 저장 당시 메모리에 있던 데이터 그대로 사진찍듯 찍어 파일로 저장한다.  
- 자동 : redis.conf 파일에서 SAVE 옵션 (시간기준)
- 수동 : BGSAVE 커맨드를 이용해 CLI 창에서 수동으로 RDB 파일을 저장 (SAVE 커맨드는 절대 사용 X)

 

2) AOF (Append Only File) : 데이터를 변경하는 커멘드가 들어올 경우 커멘드를 그대로 모두 저장한다. 말 그대로 데이터가 추가만 되기 때문에 대부분
RDB 파일보다 커지게 된다. 따라서 AOF파일은 주기적으로 압축하여 재작성 되는 과정을 거쳐야 한다.
- 자동 : redis.conf 파일에서 auto-aof-rewrite-percentage 옵션 (크기기준)
- 수동: BGREWRITEAOF 커맨드를 이용해 CLI 창에서 수동으로 AOF 파일을 재작성

 

3-1. RDB와 AOF를 선택하는 기준

▶ 백업은 필요하지만 어느 정도읭 데이터 손실이 발생해도 괜찮은 경우 : RDB 단독 사용

    redis.conf 파일에서 SAVE 옵션을 적절하게 사용한다. (예시: SAVE 900 1)

▶ 장애 상황 직전까지의 모든 데이터가 보장되어야 할 경우 : AOF 사용 (AppendOnly Yes)

    APPENDFSYNC 옵션이 everysec인 경우 최대 1초 사이의 데이터 유실 가능 (기본설정)

▶ 제일 강력한 내구성이 필요한 경우 : RDB와 AOF를 동시 사용

 

4. Redis 아키텍처 선택 노하우 (Replication vs Sentinel vs Cluster)

복제 구조를 뜻하는 Replication은 마스터와 레플리카만 존재하는 간단한 구조이다. 

Sentinel 구성에서는 마스터와 레플리카 노드 외에 추가로 센티널 노드가 필요하다. 센티널은 일반 노드들을 모니터링 하는 역할을 한다. Cluster 구성에서는 최소 3대의 마스터가 필요하며 샤딩 기능을 제공한다.

 

• Replication 구성
  • 단순히 복제만 연결된 상태
  • 비동기식 복제
  • HA 기능이 없으므로 장애 상황시 수동 복구 
• Sentinel 구성 
  • 자동 페일오버가 가능한 HA 구성 (High Availability)
  • sentinel 노드가 다른 노드를 감시한다.
  • 마스터가 비정상 상태일 때 자동으로 페일오버가 된다.
  • 연결 정보를 변경할 필요가 없다. 
  • sentinel 노드는 항상 3대 이상의 홀수로 존재해야 한다. (과반수 이상의 sentinel이 동의해야 페일오버 진행이 가능하다)
• Cluster 구성 
  • 스케일 아웃 HA 구성
  • 키를 여러 노드에 자동으로 분할해서 저장 (샤딩)
  • 모든 노드가 서로 감시하며 마스터가 비정상일 때 자동으로 페일오버 된다.
  • 최소 3대의 마스터 노드가 필요하다. 

 

아키텍처 선택 기준

 

참고 

https://www.youtube.com/watch?v=92NizoBL4uA