해당 포스팅에서는 Redis cluster에 대해서 다룬다.
Sharding
일반적으로 샤딩을 할 때 아래와 같이 Hash-Based Sharding을 사용할 수 있다.
문제는 위의 경우 샤드가 하나 늘어날 때마다 기존 데이터들을 전혀 다른 곳으로 이동시켜야 한다. Redis(레디스)는 이러한 점을 해결하고자 HashSlot을 사용한다.
- Redis는 16384개의 Hash Slot으로 Key 공간을 나누어서 관리한다.
- 각 키는 CRC16 해싱 후 16384로 Modulo Op(나머지 연산)를 하고 Hash Slot에 매핑한다.
- Hash slot은 각 노드들에게 나누어 분배한다.
이러한 과정으로 인해 새로운 샤드가 추가되더라도 모든 데이터가 영향을 받지 않고 Slot이 겹쳐지는 일부 샤드의 데이터만 옮겨주면 된다.
Moved Error
클러스터 노드는 요청이 온 Key에 해당하는 노드로 자동으로 Redirect 해주지 않고 Moved Error를 발생한다.
클라이언트는 Moved Error를 받고 해당 노드로 다시 요청을 해야 한다.
- ex.
(error) MOVED 16000 127.0.0.1:7005를 반환받고 해당 주소로 다시 요청
클라이언트의 라이브러리가 Key값과 노드의 매핑 테이블을 캐싱하고 있기 때문에 이런 경우가 자주 발생하지는 않는다.
만약 클라이언트의 라이브러리가 구현이 잘 되어있는 환경이 아니라면 redirect를 직접 구현해야 한다.
데이터 일관성
레디스 클러스터(Redis Cluster)는 고성능과 확장성을 제공하고, 적절한 수준의 데이터 안정성과 가용성을 유지하는 것을 목표로 설계되었다.
아래 그림과 같이 Redis Cluster는 Strong consistency를 제공하지 않는다.
즉, 복제가 완료된 후 응답을 보내는 것이 아니라, 높은 성능을 제공하기 위해 응답과 동시에 비동기로 복제를 수행하기 때문에 복제가 완료되기 전에 master가 죽으면 데이터가 유실될 수 있다.
가용성
일부 Master 노드가 죽더라도 과반수 이상의 master가 남아있고, 사라진 master의 replace가 있다면 클러스터는 failover된다.
해당 Master 노드는 스스로 error 상태로 빠지고, 더이상 write 요청을 받지 않게 된다.
이후 해당 Slave 노드 중 1개가 Master 노드로 승격하게 된다.
Spring에서 Redis Cluster 환경을 구성했다면 해당과 같이 Fail over가 일어났을 때, yaml을 별도로 수정하지 않아도 Sentinel이나 Redis Client 라이브러리가 자동으로 새로운 Master 노드로 연결한다.
제약
1. Cluster에서는 DB0만 사용 가능하다.
- 싱글 Redis는 인스턴스에 여러 데이터베이스를 가질 수 있다.
- 클러스터에서는 해당 기능을 사용할 수 없고 DB0으로 고정된다.
2. Multi key operation 사용이 불가능하다.
- Cluster 환경에서는 MSET과 같은 multi-key operation을 사용할 수 없다.
- 같은 노드 안에 속한 key들에 대해서는 multi-key operation이 가능
- hash tags를 사용해서 여러 key들이 같은 hash slot에 속하게 할 수 있음 (ex. MSET {user:a}age 20 {user:a}city seoul)
참고
'Database > NoSQL' 카테고리의 다른 글
| NoSQL - MongoDB 다양한 데이터 모델링 기법! (0) | 2023.03.21 |
|---|---|
| NoSQL - MongoDB는 대용량 데이터를 처리하는 Database일까? (0) | 2023.03.16 |
| ElasticSearch 이해하기! (0) | 2023.02.23 |
| 레디스 데이터 타입 정리! (0) | 2022.12.29 |
| MongoDB란 무엇인가?! (기본 이해하기!) (0) | 2022.12.28 |