지나공 : 지식을 나누는 공간

Redis 이모저모 본문

Tech

Redis 이모저모

해리리_ 2023. 12. 10. 23:57

메모리와 디스크

  • 메모리 : RAM. 빠른 액세스를 위해 데이터를 임시로 저장하는 저장소로, 컴퓨터 전원이 꺼지면 휘발된다.
  • 디스크 : HDD, SSD처럼 영구적으로 데이터를 저장하는 저장소. 디스크 내의 데이터는 CPU 처리 속도가 메모리보다 느림. 그러나 저장 용량이 크고 전원 꺼져도 휘발되지 않는다.

Redis는 메모리 기반의 저장소다. 그러니 전원 끄면 Redis의 데이터가 날아가지만 Redis는 영속성을 위한 기능을 제공한다.

Redis의 백업. 영속성

redis에서 데이터 접근은 메모리에서 일어나지만, 쌓인 데이터를 디스크에 저장할 수도 있다. Redis가 이렇게 데이터 영속성을 지원하는 방버베는 아래 두 가지 방식이 있는데, 이를 통해 Redis를 껐다 켰을 때 기존 데이터가 유지되게 할 수 있다.

 

  • RDB save 스냅샷 방식 : 데이터의 변경이 한번이라도 일어났으면 그에 대한 스냅샷을 떠서 .rdb 파일로 만들고 이걸 저장한다.
    • 장점 : 메모리 스냅샷을 그대로 뜬 거라 서버 재기동 시 스냅샷을 로드하기만 되어서, 로드가 빠름.
    • 단점 : 스냅샷을 추출할 때 오래 걸리고, 스냅샷 추출하고 나서 다음 스냅샷을 추출하는 시간 사이에 서버가 죽으면 마지막 스냅샷 추출 시점 이후의 데이터는 유실된다.
    • 시간 단위로 파일 저장 가능. 그래서 장애나서 죽으면 데이터 유실 될 수도 있음. 그렇기 때문에 DB에 다 있는 데이터인데 캐시로만 활용하기 위해 Redis를 사용 중인 상황에서 쓰는게 좋다.
  • AOF rewrite (Append On File)방식 : redis에 실행하는 write 연산을 기록하고, 서버가 재기동될 때 그 기록된 연산들을 순차실행하여 데이터를 복구한다.
    • 장점 : 로그 파일에 append만 하니까 이 작업을 하는 속도는 빠르다.
    • 단점: 재기동 시 저장되었던 연산들을 쭉 다시 실행하니까 이때 속도가 느리다.
    • 파일의 크기를 기준으로 압축되는 시점을 지정할 수 있다.
  • 권장 방식
    • 주기적으로 스냅샷을 통해 백업해두고, 그 주기를 길게 갖게 한 다음, 다음 스냅샷 전까지는 AOF 방식을 활용하는게 좋다. 둘을 병행하면 서버 재기동 시에는 스냅샷을 로드해서 빠르게 로드하고, 소량의 AOF만 replay 하면 되니까 좋다.
    • Redis 를 캐시로만 쓴다면, 그냥 이런 영속성 기능 없이 디스크 RDB만 사용해도 된다. 데이터 손실이 나더라도 DB에 다 있으니까.
    • 장애 직전까지 모든 데이터가 보장되어야 하는 중요한 redis라면 AOF가 좋다. 스냅샷에 비해 데이터 손실의 위험이 없으니까.

 

우리팀은 AWS Elasticache를 통해 글로벌 캐시를 구현하고 있고, 영속성 기능으로는 데이터 스냅샷 방식을 사용하고 있다. 그리고 이 스냅샷은 AWS S3라는 스토리지에 일정한 주기로 저장하고 있다. 우리는 Redis를 캐시 기능으로만 쓰지 않고 또다른 데이터도 저장하고 있어서 Redis 영속성 기능을 사용해온 것 같다. 근데 유실되면 안되는 중요한 데이터도 있던 거 같은데 AOF는 안쓰네..?ㅎㅎㅎ 암튼 그렇다. (혹시 쓰는데 모르는 걸까봐 redis info 명령어 실행해 봤는데 스냅샷만 쓰고 AOF는 안 쓰고 있는거 맞는 듯!)

AWS Elasticache

redis는 기본적으로 메모리 기반의 데이터 저장소라서 전원이 꺼지면 데이터가 손실되는 휘발성을 가진다. 그래서 redis를 사용할 때 지속성 보장을 위해 Snapshot(rdb) 방식이나 AOF(Append-Only File) 의 방식을 사용할 수 있다.

Elasticache도 일반적인 Redis 처럼 기본적으로는 휘발성이라서 EC2 인스턴스가 중지되거나 종료되면 해당 인스턴스에 할당된 메모리가 손실되면서 Redis 데이터도 손실될 수 있다. EC2 인스턴스를 비활하지 않고 재부팅하는 경우, Redis 데이터는 유지된다.

 

HA란?

고가용성. 장애가 발생하더라도 지속적으로 서비스를 제공할 수 있는 능력

 

Redis가 HA를 지원하는 방식.  그리고 분산 저장

1) Replication 아키텍처

master 1대와 여러 대의 slave로 된 단순한 구조이고, 장애 상황을 수동으로 복구해야 한다.

  1. 분산처리 : master 노드에서 생성된 데이터가 여러 slave노드로, 비동기식으로 복제됨. 즉 master가 slave에 복제가 잘 됐는지 매번 기다리고 확인하지는 않는다.
  2. 조회: 모든 읽기 작업은 주로 슬레이브 노드에서 처리하도록 분산해서 마스터 노드의 부하를 줄임.
  3. 고가용성: 장애 복구 기능이 없어서 장애 나면 수동 복구해야 함. 리플리카 노드에 직접 접속해서 복제 끊고 앱에서도 연결 설정 변경해서 배포해야 함.

replication

2) Sentinel 아키텍처

  1. Sentinel이 모니터링하다가 master가 죽었다고 판단될 때 Slave를 마스터로 승격시켜서 가용성을 보장한다. 즉, 자동 Failover를 제공한다.
  2. Sentinel 도 장애가 날 수 있어서 Sentinel도 3대 이상의 홀수로 존재해야 한다. 과반수 이상의 sentinel이 현재가 장애 상황이 맞다고 동의해야 failover가 진행된다.
  3. 애플리케이션은 센티넬 노드만 알면 되고 연결 정보 바꿔서 앱에서 배포할 필요가 없다.

sentinel

3) Cluster 아키텍처

  1. 클러스터에 포함된 노드들이 서로 통신하면서 고가용성을 유지하고, 샤딩 기능도 기본으로 있다.
    (샤딩은, 데이터를 여러 노드에 나눠서 저장한다고 생각하면 된다. 복제가 아니고 나눠서. 이 데이터는 여기에, 저 데이터는 저기에...)
  2. 클러스터를 구성하려면 최소 3개의 마스터 노드가 필요하고, replica 노드는 0이나 그 이상으로 가능하다.
  3. 데이터를 set할때 해시 함수를 활용해서 어떤 노드에 저장할지 이 key를 결정하는 방식으로 데이터를 분배한다. (샤딩)
  4. 노드 확장 시 애플리케이션의 Redis 연결 정보를 변경하지 않아도 된다. 노드가 새로 연결되면 알아서 클러스터 전체의 상태 정보를 확인할 수 있다. 
  5. 모든 노드가 서로를 감시하다가 마스터 비정상 상태일 경우 자동으로 Failover 한다.

cluster

 

정리하자면 아래 기준으로 Redis 구성 방식을 선택할 수 있다.

  1. HA 필요 없고 복제본 필요 없다면 그냥 노드 1개
  2. HA 필요없고 복제는 필요하다면 Replication. (주로 master는 write하고, read연산은 slave에다가 한다.)
  3. HA 자동 필요한데 샤딩은 필요 없다면 Sentinel
  4. HA 자동 필요하고 샤딩도 필요하면 Cluster

Redis 클러스터의 샤딩과 원리는?

분산 저장

  1. 각 노드들은 이미 각자의 해시 슬롯을 가지고 있어서, 특정 Key의 값이 특정 노드에 저장되게 한다.
  2. 데이터 분산 저장 시, 해시 알고리즘에 따라 해시 슬롯값을 얻는다. CRC16 알고리즘(나눈 나머지를 계속 구하는 것)을 사용한다.

요청 분산 처리

  1. 클라이언트가 클러스터에 접속할 때 특정한 해시 슬롯을 갖는 마스터 노드에 연결된다. 요청 받은 키에 대한 해시를 계산해서 어떤 노드에 저장됐는지 알아낸 뒤 그 노드에 요청을 전달한다.
  2. 각 노드들이 서로 간 지속적 통신으로 상태 정보(다운된 노드나 새로운 노드에 대한 정보)를 공유한다. 노드가 추가되거나 제거되면 슬롯을 자동으로 재배치해서 데이터 균형을 유지한다. 

 

 

위 내용을 잘 몰랐을 때는 우리 팀 설정값이 1샤드라고 되어 있어서 샤딩 기능을 쓰고 있는 줄 알았다.. 바보...

그냥 우리팀은 Replication 구성이다. Sentinel도, Cluster도 안쓰는. 최근에는 전사에서 Cluster 방식을 권장한다고 해서 우리도 Cluster로 바꿀까? 라는 의견이 오갔지만... 우리건 과거에 구성된 시스템이고 딱히 문제가 발생하지도 않아서 당장 여기에 공수를 들이지는 말자.. 로 끝났던 것 같다. ㅎ.ㅎ

 

출처 :

https://ankitsahay.medium.com/redis-multi-node-deployment-replication-vs-cluster-vs-sentinels-8099d15dcc09

https://velog.io/@ekxk1234/Redis-Cluster

728x90
Comments