RedisRaft(개발 중)는 여러 Redis 서버를 단일 내결함성, 강력한 일관된 클러스터로 운영할 수 있게 해주는 오픈소스 Redis용 새 모듈입니다. 이름에서 알 수 있듯이 Raft 합의 알고리즘과 이를 구현하는 오픈 소스 C 라이브러리를 기반으로 합니다.
RedisRaft는 Redis 및 Redis 생태계에 엄격한 직렬화 배포 옵션을 통해 새로운 강력한 일관성을 제공합니다. 새로운 모듈을 사용하면 높은 수준의 안정성과 일관성이 필요한 캐시 외 시나리오에서 Redis의 기존 클라이언트, 라이브러리 및 데이터 유형과 함께 Redis를 사용할 수 있습니다.
RedisRaft의 시작
RedisRaft는 Redis 5가 출시되기 직전에 실험적인 "사이드 프로젝트"로 시작되었습니다. Redis 모듈 API는 주로 새로운 데이터 유형 및 명령을 구현하는 모듈을 지원하도록 설계된 Redis 4에 도입되었습니다. 우리는 API를 어디까지 확장할 수 있는지 탐구하고 모듈을 사용하여 Redis를 훨씬 더 급진적인 방식으로 확장하고 싶었습니다. 그러나 우리는 또한 Redis를 위한 강력한 일관성 배포 옵션이라는 유용한 것으로 끝내고 싶었습니다.
RedisRaft 클러스터는 ZooKeeper 또는 Etcd와 같이 잘 알려진 신뢰할 수 있는 데이터 저장소에서 기대하는 것과 동일한 수준의 일관성과 안정성을 제공합니다. 간단히 말해서 RedisRaft에서:
- 승인된 쓰기는 커밋되고 절대 손실되지 않습니다.
- 읽기는 항상 최신 커밋된 쓰기를 반환합니다.
이러한 수준의 일관성을 제공하는 신뢰할 수 있는 데이터 저장소에서 예상되는 바와 같이 이러한 보장은 성능과 가용성에서 절충을 가져옵니다. RedisRaft에서:
- 클라이언트 작업은 메시지를 교환하는 클러스터 노드에 의존하므로 네트워크 대기 시간에 구속됩니다.
- 쓰기를 완료하기 전에 디스크에 플러시해야 디스크 I/O 대기 시간에 바인딩됩니다.
- 클러스터는 대부분의 노드가 작동 중이고 정상 상태이며 서로 통신할 수 있는 경우에만 사용할 수 있습니다.
RedisRaft 작동 방식
RedisRaft 모듈이 Redis에 로드되면 클러스터 노드 간 통신, Raft 로그 또는 스냅샷 복제, 지속성 등을 담당합니다. Redis 코어는 이를 인식하지 못하고 클러스터링, 지속성 또는 복제가 없는 독립 실행형 서버로 작동합니다.
3노드 RedisRaft 클러스터를 설정하는 것은 다음과 같이 3개의 Redis 서버를 시작하는 것만큼 쉽습니다.
redis-server --loadmodule /path/to/redisraft.so
첫 번째 서버에 연결하고 Raft 클러스터를 생성하는 방법은 다음과 같습니다.
10.0.0.1:6379> RAFT.CLUSTER INIT
OK 989645460313dd2ddb051f033c791222
그런 다음 다른 두 서버에 연결하여 클러스터에 연결합니다.
10.0.0.2:6379> RAFT.CLUSTER JOIN 10.0.0.1:6379
OK
10.0.0.3:6379> RAFT.CLUSTER JOIN 10.0.0.1:6379
OK
클러스터 액세스
RedisRaft가 설정되면 클러스터에 데이터를 쓸 수 있습니다.
10.0.0.1:6379> INCR counter:1
(integer) 1
회신을 받는 것은 우리의 쓰기가 최소 복제되었음을 나타냅니다. 대부분의 클러스터 노드(이 경우 2개 노드)는 영구 저장소에 커밋됩니다.
Raft는 강력한 리더 개념을 기반으로 합니다. 즉, 모든 클라이언트 작업은 리더 노드로 이동하여 이 노드에서 시작해야 합니다. 이 경우 우리 클라이언트는 실제로 리더와 연결되었지만 클러스터 리더십은 동적이며 클라이언트는 리더가 누구인지 반드시 알지 못할 수도 있습니다.
추종자(리더가 아닌) 노드에서 동일한 작업을 시도하면 다음 응답이 생성됩니다.
10.0.0.3:6379> INCR counter:1
(error) MOVED 10.0.0.1:6379
따라서 클라이언트로서 이제 이 오류를 포착하고 지정된 대로 리더 노드와 연결을 다시 설정하고 명령을 다시 시도할 수 있습니다.
그러나 기존 애플리케이션을 수정하고 싶지 않다면 어떻게 될까요? 운 좋게도 RedisRaft는 이를 자동으로 처리하도록 구성할 수도 있습니다. 팔로어 프록시 모드 활성화 , 클러스터 노드가 자동으로 요청을 리더에게 전달하고 사용 가능한 경우 응답을 제공하도록 할 수 있습니다.
10.0.0.3:6379> RAFT.CONFIG SET follower-proxy yes
OK
10.0.0.3:6379> INCR counter:1
(integer) 2
물론 이것은 훨씬 간단하지만 리더가 아닌 노드에 도달하면 추가 네트워크 홉이 생성되므로 대기 시간과 네트워크 부하에 영향을 줍니다.
클러스터 변경사항
클러스터를 설정할 때 실제로 세 가지 작업을 수행했습니다.
- 단일 노드에 클러스터를 생성했습니다.
- 두 번째 노드를 추가했습니다.
- 세 번째 노드를 추가했습니다.
RedisRaft 클러스터 구성은 고정적이지 않으며 클러스터가 생성된 후 활성 상태인 동안 노드를 추가하거나 제거할 수 있습니다.
예를 들어 세 번째 노드를 교체해야 할 수 있습니다. 먼저, 이를 대체할 새 노드에 합류합니다. 전환하는 동안 클러스터와 소중한 데이터가 중복 상태가 저하되는 것을 방지하기 위해 "제거 후 추가" 대신 "추가 후 제거"합니다.
10.0.0.4:6379> RAFT.CLUSTER JOIN 10.0.0.1:6379
OK
다음으로 세 번째 노드에 무작위로 할당된 ID를 찾습니다.
redis-cli -h 10.0.0.1 --raw RAFT.INFO | grep 10.0.0.3
node2:id=1739451728,state=connected,voting=yes,addr=10.0.0.3,port=6379,
last_conn_secs=3537,conn_errors=0,conn_oks=1
그런 다음 제거합니다.
10.0.0.1:6379> RAFT.NODE REMOVE 1739451728
OK
RedisRaft 출시 상태
RedisRaft 개발 작업의 일환으로 Kyle Kingsbury(일명 Aphyr)와 협력하여 분산 시스템의 안전성과 정확성을 테스트하기 위한 잘 알려진 프레임워크인 Jepsen을 사용하여 RedisRaft를 분석하고 테스트했습니다. 이 협업을 통해 지금까지 이 분석 결과를 발표했습니다.
아직 개발 중이지만 대부분의 RedisRaft의 기본 기능은 제자리에 있습니다. 우리는 현재 첫 번째 미리 보기 버전을 위해 노력하고 있으며 몇 달 안에 사용할 수 있을 것으로 예상됩니다. 일반적으로 사용 가능한 경우 RedisRaft는 GNU AGPLv3 또는 Redis RSAL(소스 사용 가능 라이선스) 중 하나의 이중 라이선스로 출시됩니다.