jowoohyeong
commented
1 year ago 2. Redis 구조
- 명령어 전달을 통해 데이터를 저장하거나 조작할 수 있다.
- Redis는 In Mermory 데이터 구조 저장소로써 위 그림에서 해당되는 데이터 구조는 모두 메모리에 상주한다.
- Resident Area는 명령어를 통해 실제 데이터가 저장 및 작업이 수행되는 공간이다.
- 초록색 영역은 내부적으로 서버 상태를 저장하고 관리하기 위한 메모리 공간으로 사용
- Memory는 휘발성이기 때문에, 프로세스를 종료하면 데이터는 모두 유실된다.
- 단순 캐시 용도가 아닌 Persistence저장소로 활용하기 위해서 Disk에 저장하여 데이터 유실이 발생하지 않도록 AOF(Append Only File)기능과 RDB(Snapshot)기능이 존재한다.
- AOF는 전달된 명령을 별도에 파일에 기록하는 방법으로 RDBMS의 Redo 메커니즘과 유사하다.
- AOF의 역할은 재기동 시 파일에 기록된 명령어를 일괄 수행하여 데이터를 복구하는데 사용된다.
AOF는 데이터 유실이 발생하지 않지만, 매 명령어마다 File과 동기화가 필요하기 때문에 처리 속도가 현격히 줄어든다. 이를 해소하기 위해 File Sync옵션(appendfsync)이 존재하며, 해당 옵션에 따라 Sync주기를 조절할 수 있으나 그만큼 데이터 유실이 발생할 수 있다.
반면 RDB는 특정 시점의 메모리 내용을 복사하여 파일에 기록하는 방법으로 RDBMS Full Backup에 해당. 따라서, 정기적 혹은 비정기적으로 저장이 필요할 시점에 데이터 저장이 가능합니다.
RDB의 장점으로는 AOF에 비해 부하가 적으며, LZF 압축을 통해 파일 압축이 가능하다. 또한 덤프 파일을 그대로 메모리에 복원하므로 AOF에 비해 빠르다. 반면 덤프를 기록한 시점 이후 데이터는 저장되지 않으므로 복구 시에 데이터 유실이 발생할 수 있는 문제점이 있다.
AOF와 RDB를 사용할 때는 유의해야 할 점
Copy On Write
AOF를 백그라운드로 수행하거나 RDB를 수행할 때 Redis-server에서 자식 프로세스를 fork하여 처리를 위임한다. 만약 이 과정에서 redis-server의 데이터에 쓰기 작업을 수행한다면, 기존 페이지를 수정하는 것이 아닌 이를 별도 공간에 저장 후 처리한다. 따라서 해당 작업을 수행 도중에 쓰기 작업이 증가한다면, 메모리 사용량이 급격히 증가될 수 있으므로 유의해야 함. (최대 2배)
Redis는 충분히 빠르고 안정적이다. 하지만 서비스가 갑자기 잘되어 트래픽이 몰린다면 어떻게 될까? 서버의 한계점을 넘어간다면, 인스턴스 장애가 발생할 수 있다. 이 때 만약 단일 인스턴스로만 구성되었다면, Redis의 장애가 모든 Application에 영향을 미친다.
위 그림은 Master/Replica의 구조를 나타냅니다. 최초 Master/Replica 구성 시 Master의 데이터는 모든 Replica에 복사한다. 따라서 어느 Redis 인스턴스에서 데이터를 조회해도 원하는 결과를 얻을 수 있다.
ReplicaOf 명령어를 통해 Master/Replica 구조가 되면, Master 인스턴스에서는 내부적으로 repl-backlog-size 옵션 만큼의 Backlog Buffer가 만들어진다.
이후 Replica와의 단절이 발생하게 되면, Master 인스턴스에서는 변경 데이터를 Backlog Buffer에 저장. Backlog Buffer는 유한한 크기를 지녔으므로, 지연이 오랫동안 발생한다면 Buffer가 넘칠 수 있다.
단절 이후 다시 재연결 되었을 때 과정
Master/Replica 장점
우선 Master 인스턴스와 Replica 인스턴스간 데이터가 공유되어있다. 따라서 Replica 중 어느 인스턴스가 다운되더라도 Application의 영향을 최소화할 수 있다.
또한, 데이터 조회를 위해 굳이 Master에게 요청하지 않아도 되므로 Read 작업에 대한 부하를 여러 인스턴스로 분산시킬 수 있는 장점이 있다.
Master 인스턴스에 장애가 발생해도 다른 Replica에 데이터가 모두 복제되어 있으므로 읽기 연산은 무제가 없다. 하지만 쓰기 작업은 Master를 통해 이루어지므로 더이상 쓰기 작업이 수행될 수 없는 문제가 있다.
따라서 단순 Master/Replica 구성을 했을 경우에는 관리자가 모니터링을 통해 장애 여부를 감지하고, 수동으로 Replica인스턴스 중 하나를 Master로 선정하고, 나머지 Replica에서 새로 변경한 Master를 바라보도록 설정을 변경해야함.
위 그림은 Master/Replica/Sentinel의 구조이다. 여기서 녹색으로 연결된 선이 Sentinel과 연결된 네트워크 Path 의미
Sentinel은 다른 Sentinel을 포함한 모든 Redis 인스턴스와 연결한다. 이후 1초마다 HeartBeat 통신을 통해 Master 및 Replica 서버가 정상적으로 작동 중인지 여부 확인하고 이상 발생 시 자동으로 Failover 및 Application에 알림을 전송한다.
Sentinel과 연결된 노드 중 HeartBeat에 일정 시간동안 응답하지 않는 경우 해당 Sentinel은 장애가 발생한 것으로 간주하고 해당 노드를 주관적 다운(Subjectively Down)으로 인지
만약 장애가 발생한 인스턴스가 Master일 경우에는 모든 Sentinel에게 Master Down 여부를 묻는다. Master Down 여부를 전달받은 Sentinel들은 실제 Master 인스턴스가 죽었는지를 확인 후 이를 응답
Sentinel 리더가 선출되면, 리더는 Replica 인스턴스 중 하나를 Master로 승격합니다. 이후 나머지 Replica에서 Master 인스턴스를 모니터링할 수 있도록 명령을 수행하고 장애 복구 작업을 종료
위 그림은 기존 Master 인스턴스와 나머지 Redis 인스턴스 사이 네트워크가 단절된 모습입니다. 네트워크 이슈이므로 Master 인스턴스는 현재 정상적으로 Client와 통신이 가능하며, 데이터 쓰기 작업이 발생하면 Master 인스턴스에 데이터가 저장
Redis 구조
1. Redis 접속