Redis 알고 사용하자!

1. Redis

Temporary Location For Speed

데이터의 원래 소스보다 더 빠르고 효율적으로 액세스할 수 있는 임시 데이터 저장소

많은 애플리케이션에서 속도 향상을 위해 캐시를 이용한다.
 당연히 속도를 높이려면 원본에 접근하는것보다 캐시에 접근하는게 빨라야 한다. 그리고 데이터의 반복적 액세스가 많아질수록 캐시를 사용하는게 유리하다.

아래와 같은 특징을 가진다.

• 단순한 key-value 구조
• In-memory 데이터 저장소 (RAM)
• 빠른 성능
  • 평균 작업속도 < 1ms
  • 초당 수백만 건의 작업 가능

이외에도

최신 버전의 Redis는 데이터 저장뿐만 아니라 PUB/SUB 구조를 통해 메시지를 전달하는 용도로도 사용 가능하다.

Redis는 메모리에 데이터를 저장하기 때문에 저장 공간에 제약이 있으므로, 주로 보조 데이터 저장소로 이용된다.
하지만 더 많은 공간을 이용하기 위해서는 Redis 클러스터 기능을 사용하여 저장공간을 확장할 수 있다.

싱글스레드 전략

Redis는 사용자들이 실행한 명령어들을 Event Loop 방식으로 처리한다. 즉, 클라이언트가 실행한 명령어들이 Event Queue에 적재되고 싱글 스레드로 하나씩 처리한다.
메모리를 사용하기 때문에 싱글 스레드로 데이터를 빠르게 처리할 수 있다.

따라서 아래의 장점과 단점을 가지게 된다.

• 장점
  • 1. 멀티 스레드 환경이 아니라서 Context Switching이 발생하지 않으므로 효율적인 시스템 리소스 사용이 가능하다.
  • 2. 멀티 스레드 환경이 아니므로 DeadLock이 발생하지 않는다.
• 단점
  • 1. 싱글 스레드이므로 전체 데이터 스캔과 같은 오버헤드가 큰 명령어를 처리하는 동안 다른 명령어를 처리 불가하다.
  • 2. 이때, 다른 명령어들은 이벤트 큐에 저장되어 있는 시간이 길어지므로 응답 속도가 저하된다.

 

2. Memory Hierarchy

예시로 PC사양이 아래와 같다고 가정하자.

• i7 CPU - 12MB Cache Memory
• 16GB DRAM
• 512GB SSD

12MB Cache Memory 는 SRAM으로 CPU Cache에 해당한다. 해당 캐시 메모리는 엄청 빠르고, 엄청 비싸고, 용량이 작다.
16GB DRAM은 Main Memory로 적당히 빠르고, 적당히 비싸고, 적당히 크고, 휘발성이다.
512GB SSD Storage는 비교적 느리고, 비교적 저렴하고, 엄청 크고, 비휘발성이다.

Redis는 데이터가 많아지고 커지고 트래픽이 늘어남에 따라 Man Memory에 데이터를 저장해서 조금 더 빠르고 쉽게 데이터에 접근하는 개념이다.

 

3. 캐싱 전략

읽기 전략

(1) Look-Aside 전략

가장 일반적인 Look-Aside 전략은 먼저 데이터를 찾을 때 캐시에서 먼저 검색하고 데이터가 없다면 데이터베이스에 직접 접근하여 찾아온뒤 다시 Redis에 저장하는 구조이다. 따라서 캐시는 찾는 데이터가 없을 때만 데이터가 입력되기 때문에 Lazy Loading이라고도 한다.

해당 구조는 Redis가 다운되더라도 바로 장애로 이어지지 않고, DB에서 데이터를 가져올 수 있다.
하지만 Redis에 붙어있던 커넥션이 많았다면 갑자기 DB로 조회하는 커넥션이 많아지기 때문에 DB에 부하가 많이 걸릴 수 있다.

캐시를 처음 투입하거나, 새로운 데이터를 DB에만 저장했다면 Cache Miss가 많이 발생해서 성능 저하가 올 수 있다.
이를 방지하기 위해 DB에서 미리 캐시로 데이터를 밀어 넣어주는 Cache Warming 과정을 진행할 수 있다.

쓰기 전략

(1) Write-Around

Write-Around 방식은 DB에만 데이터를 저장하는 방식이다. Cache Miss가 발생한 경우에 캐시로 데이터를 끌어온다.
DB내의 데이터와 캐시내의 데이터가 다를 수 있다는 단점이 있다.

(2) Write-Through

Write-Through 방식은 데이터를 저장할 때 캐시에도 함께 저장하는 방식이다.
캐시는 항상 최신 정보를 가지고 잇다는 장점이 있지만, 저장할 때마다 두단계 스텝을 거쳐야 하므로 상대적으로 느리다.
캐시에 넣은 데이터가 재사용되지 않을수도 있으므로 주의해야 하며 Expire Time을 잘 설정해줘야 한다. 

 

4. Redis 데이터 타입

레디스는 자체적으로 다양한 자료구조를 제공한다.

• setCommand를 이용해서 저장되는 데이터는 모두 String 형태로 저장된다.
• 비트 단위 연산이 가능한 Bitmap
• 데이터를 순서대로 저장하는 List는 큐로 사용하기 적절하다.
• 하나의 키에 또다시 여러 필드와 값의 쌍으로 데이터를 저장하는 Hash가 있다.
• 중복되지 않는 값의 집합의 Set
• 중복되지 않고 특정값으로 정렬되는 Sorted Set
• 굉장히 많은 데이터를 다룰 때 사용하며 중복되지 않는 값의 개수를 카운트할 때 HyperLogLog를 사용한다.
• 로그를 저장할 때 Stream을 사용한다.

 

5. Redis 데이터를 영구 저장하는 방법

Redis는 In-memory 데이터 스토어이다. 따라서 아래의 문제를 가진다.

• 서버 재시작 시 모든 데이터 유실
• 복제 기능을 사용해도 사람의 실수 발생 시 데이터 복원 불가
• Redis 캐시 이외의 용도로 사용한다면 적절한 데이터 백업이 필요

AOF (Append Only File)

Redis Protocol 형태로 저장되며, 데이터를 변경하는 커맨드가 들어오면 커맨드를 그대로 모두 저장한다.
AOF는 append only하게 동작하므로 데이터가 추가만 되므로 보통 RDB보다 커지게 된다.
따라서, AOF 파일은 주기적으로 압축해서 재작성되는 과정을 거쳐야 한다.

 

자동/ 수동 파일 저장 방법

• 자동: redis.conf 파일에서 auto-aof-rewrite-percentage 옵션 (크기 기준)
• 수동: BGREWRITEAOF 커맨드를 이용해 CLI 창에서 수동으로 AOF 파일 재작성

RDB

Binary 형태로 저장되며, Snapshot 방식으로 동작하기 때문에 저장 당시의 메모리에 있는 데이터 그대로를 사진찍듯이 그대로 저장한다.

 

자동/ 수동 파일 저장 방법

• 자동: redis.conf 파일에서 SAVE 옵션 (시간 기준)
• 수동: BGSAVE 커맨드를 이용해 cli 창에서 수동으로 RDB 파일 저장
  • SAVE 커맨드는 절대 사용 X

 

RDB vs AOF 선택 기준

• 백업은 필요하지만 어느 정도의 데이터 손실이 발생해도 괜찮은 경우
  • RDB 단독 사용
  • redis.conf 파일에서 SAVE 옵션을 적절히 사용
• 장애 상황 직전까지의 모든 데이터가 보장되어야 할 경우
  • AOF 사용 (appendonly yes)
  • APPENDFSYNC 옵션이 everysec인 경우 최대 1초 사이의 데이터 유실 가능(기본 설정)
• 제일 강력한 내구성이 필요한 경우
  
  • RDB & AOF 동시 사용

 

6. Redis 아키텍처의 종류

• 1. Replication 아키텍처
  • Master와 Replica로 구성
  • 단순한 복제 연결 시 사용 (replicaof)
  • 비동기식 복제로 복제가 성공했는지 확인하지 않음
  • HA(고가용성) 기능이 없으므로 장애 상황 시 수동으로 복구
• 2. Sentinel 아키텍처
  • Sentinel, Master, Replica로 구성
  • Sentinel 노드가 Redis 마스터와 레플리카 노드를 모니터링
  • Master가 비정상 상태일 때 자동으로 failover
  • 연결 정보 필요 없음
  • sentinel 노드는 항상 3대 이상의 홀수로 존재해야 함
    • 과반수 이상의 sentinel이 동의해야 failover 진행
• 3. Cluster 아키텍처
  • 최소 3대의 Master가 필요하며 Sharding 기능을 제공
  • 스케일 아웃과 HA 구성 (High Availability)
  • 키를 여러 노드에 자동으로 분할해서 저장
  • 모든 노드가 서로를 감시하여, 마스터 비정상 상태일 때 자동 failover

 

7. 아키텍처 선택 기준

위의 플로우 차트를 잘 따라가보면서 아키텍처를 선택해야 한다.