Replication - 리더 기반 복제에 대해

동기식 복제 vs 비동기식 복제

복제 시스템에서 중요한 사항은 복제가 동기식으로 이루어지는지, 비동기식으로 발생하는지의 여부이다. 

 

그림 1

 

그림 1에서 팔로워 1의 복제는 동기식이다.

리더는 팔로워 1이 쓰기를 수신했는지 확인해 줄 때까지 기다린다.

 

팔로워 2의 복제는 비동기식이다.

리더는 팔로워 2의 응답을 기다리지 않고 다음 작업을 처리한다.

 

 

동기식 복제의 장, 단점

동기의 가장 큰 장점은 팔로워와 리더가 일관성 있게 최신 데이터 복사본을 가지는 것을 보장할 수 있다는 점이다.

 

이는 데이터의 정합성을 우선시할 경우, 동기식 복제가 사용된다. 가령 계좌 이체를 생각해 볼 수 있다.

 

하지만, follower가 어떠한 이유로 response가 어렵다면, 쓰기가 처리될 수 없다.

이러한 경우 ,리더는 모든 쓰기를 차단하고 동기 복제 서버의 failover를 위해 대기해야 한다.

 

비동기식 복제의 장, 단점

비동기의 가장 큰 장점은, 빠른 latency를 보장할 수 있다는 점이다. 사실 현실 세계의 애플리케이션의 경우 대부분 빠른 응답이 요구되므로 대부분 비동기식 처리가 주를 이룬다.

비동기는 많은 팔로워가 있거나, 지리적으로 분산된 경우 유용하다.

 

하지만, 만약 master-slave 구조에서 단일 master일 때 해당 master에 대해 장애가 발생한다면

이는 시스템상의 SPOF 지점이 된다. 이때 팔로워에 아직 복제가 되지 않은 쓰기 작업이 존재할 경우, 이는 모두 유실된다. 

 

따라서 이에 대한 대안으로, 반동기식 처리 방법을 생각할 수 있다.

 

반동기란 하나 이상의 팔로워를 동기식으로 하고, 나머지를 모두 비동기로 처리하는 것을 말한다.

이렇게 될 경우, 적어도 두 노드에 데이터에(리더, 동기식 팔로워)에 데이터의 최신본이 있음을 보장한다.

 

리더 기반 복제에서 HA를 달성하는 방법?

1. 팔로워 노드에서 장애가 발생하는 경우

 

팔로워의 장애 복구는 상대적으로 쉽다. 팔로워는 리더로부터 데이터 변경 로그를 수신받게 되는데, 해당 로그를 통해 장애 발생 직전에 처리한 트랜잭션의 ID를 기준으로 이후 데이터 변경을 모두 요청할 수 있다. 

 

이를 따라잡기라고 한다.

 

2. 리더 노드에서 장애가 발생하는 경우

 

복구 방법을 논의하기 전에 먼저 생각해 볼 것은, 해당 리더 노드가 장애임을 어떻게 파악할 수 있을지이다.

-> 대부분의 시스템은 단순히 타임아웃을 사용해 이를 파악한다.

 

이후, 해당 노드의 failover를 기다리는 것을 현실적으로 어려우므로, 팔로워 노드 내에서 새롭게 리더를 선출해야 한다. 

이때 가장 적합한 후보는, 이전 리더의 최신 데이터 변경사항을 가진 팔로워 노드다.

 

3. 새로운 리더 선정 시, 시스템을 재설정해야 한다.

-> 이전 리더가 failover 되었을 때, 해당 노드가 자신이 여전히 리더라고 믿을 수 있다. 이를 스플릿 브레인이라고 한다. 

 

생각해 볼 문제들

기본적으로 이러한 문제들을 해결하는 것은 쉽지 않고, 실제 일부 운영팀은 자동 failover를 지원하는

시스템이더라도 수동으로 직접 장애 복구 작업을 하기도 한다.

 

단일 master - slave 시스템의 경우, 새롭게 선출된 리더가 반드시 이전 리더의 최신 데이터 변경사항을 지니리라는 보장은 없다는 점도 감안해야 한다.

 

개인적인 생각으로 이러한 맥락에서 정합성을 보다 높이고자 한다면 다중 master를 두어 master 노드의 failover에 따른 데이터 유실 문제를 최대한 방지하는 것도 하나의 방법이 될 수 있을 것 같다.

 

References

- OREILLY - 데이터 중심 어플리케이션 설계 5장. 복제