알고리즘 2️⃣: 다중 리더 복제

지난번에는 단일리더 복제에 대해서 알아봤습니다. 이번에는 데이터센터 마다 리더가 있는 다중리더 복제 알고리즘에 대해서 정리했습니다. 단일리더와 다르게 쓰기충돌이라는 새로운 문제점이 발생합니다.

단일 리더 복제는 리더가 장애를 일으키면 쓰기를 할 수 없다. 다중 리더는 쓰기를 허용하는 노드를 하나 이상 두는 것으로 확장ㅎ나다.

쓰기 작업이 분산되므로 사용자가 인지하는 성능은 더 좋다.
데이터센터 중단 내성
네트워크 문제 내성
동일한 데이터를다른 두개의 데이터 센터에서 동시에 변경하면 쓰기 충돌이 일어난다
오프라인 작업을 하는 클라이언트에 적합
- 예를들어 휴대전화, 노트북, 태블릿에 연동된 캘린더 앱에서 사용. 디바이스가 현재 인터넷에 연결되어있지 않더라도 언제든지 일정을 볼 수 있어야 하고(읽기 요청) 언제라도 새로운 일정을 등록할 수 있어야 한다.(쓰기요청) 오프라인 상태에서 데이터를 변경하면 디바이스가 다음에 온라인 상태가 됐을 때 서버와 다른 디바이스를 동기화 한다.
- 이 경우 디바이스 마다 리더처럼 동작하는 로컬 데이터베이스가 있는 것이고 온라인이 되는 순간

쓰기 충돌 다루기

다중 리더 복제에서 가장 큰 문제점.

위 그림과 같이 위키 페이지를 동시에 편집한다고 가정. 페이지의 제목을 한 사용자는 A→B로 변경. 다른 사용자는 A → C 로 변경하면 각 사용자의 로컬 리더에서는 성공적으로 동작한다. But 변경을 다른 리더끼리 비동기로 공유할 때 충돌을 감지한다.

동기식으로 충돌을 감지한다고 하면 리더1의 변경사항을 다른 리더들에게 알리고 충돌이 없다는 응답을 받을 때 까지 기다린다. 이렇게 되면 다중리더복제 방식의 장점인 각각의 복제서버가 독립적으로 쓰기를 할 수 있다는 점이 사라진다.

다중 리더 복제서버에서 쓰기는 순서가 정해지지 않아 최종 값이 무엇인지 명확하지 않다.
- 예를들어 위에 있던 그림처럼 A→B, A→C 로 변했을 때 각각 최종 값이 달라지게 된다.
모든 복제 서버가 최종적으로 동일하다는 사실을 보장해야한다. 따라서 데이터베이스는 수렴(convergent) 방식으로 충돌을 해소해야 한다.
수렴의 다양한 방식
- 각 쓰기에 타임스탬프를 부여해 가장 나중에 수정된 쓰기가 이긴다. 이를 LWW(last write wins)방식이라고 한다. 이는 대중적이지만 데이터 유실 위험이 있다.
- 어떻게든 병합한다.
- 충돌을 기록해 모든 정보를 보존한다. 나중에 충돌을 해소하는 애플리케이션 코드를 작성한다.

원형과 별 토폴로지는 하나의 노드에 장애가 발생하면 전체 시스템에 영향을 미친다. 반면에 전체 연결 토폴로지는 일부 네트워크 연결이 지연되면 복제 메시지가 다른 메시지를 추월할 수도 있다.(그림 참고)