Replication Layer

Overview

고가용성을 위해서 데이터베이스가 애플레키에션에 대한 서비스를 중단하지 않고 노드가 오프라인 상태가 되는 것을 견딜 수 있어야 한다. 즉, 노드 간에 데이터를 복제해 데이터에 계속 액세스할 수 있도록 해야 한다.

Cockroach DB는 이 과제를 달성하기 위해 합의 알고리즘에 의존해 범위의 번경이 커밋되기 전에 복제본의 쿼럼이 변경에 동의하도록 요구한다. 3은 쿼럼을 달성할 수 있는 최소 수 이므로 Cockroach DB의 고가용성을 위해서는 3개의 노드가 필요하다.

허용 가능한 장애 수는 (Replication factor - 1)/2 다. 장애가 발생하면 자동으로 노드의 응답이 중지되었음을 인식하고 데이터를 재분배해 생존 가능성을 극대화하기 위해 노력한다. 새 노드가 클러스터에 가입하면 데이터가 자동으로 클러스터로 재조정되어 부하가 고르게 분산되도록 한다.

Interactions with other layers

• Destribution layer로 부터 요청을 수신하고 응답을 전송한다.
• 수락된 요청을 Storage layer에 쓴다.

Technical details and components

Raft

Raft는 합의 프로토콜로, 데이터를 여러 컴퓨터에 안전히 저장하고 일부 컴퓨터의 연결이 일시적으로 끊어지더라도 해당 컴퓨터가 현재 상태에 대해 동의하도록 하는 알고리즘이다.

Raft는 특정 범위의 복제본을 포함하는 모든 노드를 하나의 그룹으로 구성하는데, 이를 Raft 그룹이라 부른다. Raft 그룹의 각 레플리카는 리더 또는 팔로워다. Raft에 의해 선출되고 오래 살아남는 리더는 Raft 그룹에 대한 모든 쓰기를 조정한다. 리더는 팔로워들에게 주기적으로 하트비트를 보내고 로그를 복제한다. 하트비트가 없는 경우, 팔로워들은 무작위 선거 타임아웃 후 후보가 되어 새로운 리더 선거를 진행한다.

3번째 복제본 유형인 “non-voting” 복제본은 Raft 선거에 참여하지 않지만, 지연 시간이 짧은 다중 지역 읽기가 필요한 사용 사례를 지원하는데 유용하다. 노드가 포함된 범위에 대한 BatchRequest를 받으면 해당 KV 작업을 Raft 명령으로 변환한다. 이런 명령은 Raft 그룹 리더에게 제안되며 Raft log에 기록된다.

Raft logs

쓰기가 정족수를 충족하고 Raft 그룹 리더에 의해 커밋되면 Raft 로그에 추가된다. 이것은 복제본이 동의한 명령의 정렬된 집합을 제공하며, 본질적으로 일관된 복제를 위한 진실 소스가 된다.

이 로그는 직렬화 가능한 것으로 취급되기 때문에 노드를 과거 상태에서 현재 상태로 되돌리기 위해 재생할 수 있다. 또한 이 로그를 사용하면 일시적으로 오프라인 상태가 된 노드를 스냅샷 형태로 기존 데이터의 사본을 받을 필요 없이 현재 상태로 따라잡을 수 있다.

Non-voting replicas

Raft 합의 프로토콜에서 투표자로만 구성된 복제본들은 모든 합의 알고리즘에 복제본이 참여해야 하기 때문에 복제 계수를 늘리면 Raft 쿼럼이 증가해 추가 쓰기 지연이 발생했다. 다중 지역 클러스터에 대한 개선을 위해 비투표 복제본이라는 개념이 도입된다. 비투표 복제본은 Raft log를 따르지만 쿼럼에는 참여하지 않는, 쓰기 지연 시간 개선을 위한 읽기 전용 복제본인 셈이다.

Per-replica circuit breakers

개별 범위를 일시적으로 사용할 수 없게 되면 해당 범위에 대한 요청은 무한정 중단되는 대신 복제본별 circuit breaker 메커니즘에 의해 거부된다.

사용자 관점에서는 일시적으로 사용할 수 없는 범위에 액세스해 SQL 쿼리가 궁극적으로 실패할 경우 해당 범위에 있는 복제본이 서킷 브레이커를 작동 시키고 시스템을 통해 오류를 전파시킨다. 또한 범위의 가용성을 비동기적으로 계속 조사해 복제본을 다시 사용할 수 있게 되면 차단기가 재설정되어 정상적으로 요청을 다시 처리할 수 있다. 이런 기능은 일시적 오류에 대한 견고성을 갖추게해 클러스터 가용성을 더욱 높힌다.