데이터 중심 애플리케이션 설계 - 복제 - 다중 리더 복제

다중 리더 복제

• 리더에 대한 의존성이 높다.
• 리더가 여러개: 다중리더설정, 마스터미스터 액티브/액티브 복제

다중 리더 복제의 사용사례

다중 데이터센터 운영

• 데이터 센터마다 리더를 두고 복제를 진행

오프라인 작업을 하는 클라이언트

• 인터넷이 끊어진 동안 앱이 계속 동작해야하는 경우
• 이 경우 로컬 데이터베이스가 있다. 아키텍처 관점에서 보면 근본적으로 다중 리더복제와 동일하다.(구글 캘린더?)

협업 편집

• 실시간 협업 편집 애플리케이션: ex 구글독스
• 오프라인 사용 사례와 공통점이 많다. 로컬에 적용하고 이후 비동기방식으로 타 사용자의 db와 연동한다.
• 충돌이 없으려면 편집전 문서의 lock을 얻어야한다.

[펌] 파일락(File Lock)

쓰기 충돌 다루기

동기 대 비동기 충돌감지

• 단일 리더: 들어온 순서대로 차근차근 처리함
• 다중 리더: 리더들의 쓰기는 모두 성공하며 충돌은 이후 특정시점에서 비동기로 감지
  • 동기도 가능하지만 그러면 속도 향상인 장점을 잃어버리게 됨.

충돌 회피

• 하나의 레코드 내에서 일어나는 모든 쓰기 액션을 같은 리더 안에서 진행하도록 하는 것

일관된 상태 수렴

• 단일에서는 마지막에 작성된 값을 최종값으로 정하기 쉬운데, 다중리더설정에서는 그렇제 않다. ⇒ db가 일관성을 잃어버릴 수 있음
• 이를 해소하기 위해 convergent 방식으로 충돌을 해소한다 ⇒ 모든 db는 동일한 최종값을 가진다.
• 쓰기별로 id를 부여한다.(unix timestamp 등.) ⇒ 최종 쓰기 승리
• 복제서버에 id를 저장하고 가장 높은 id를 마지막 값으로 따라가도록 한다.
• 어떻게든 값을 병합한다 b+c
• 명시적으로으로 충돌 관리 코드를 작성

사용자 정의 충돌 해소 로직

• 충돌은 일반적으로 로우나 문서 수준에서 적용된다.
• 자동 충돌 해소: conflict-free replicated datatype, mergeable persistent data structure, operational transformation

충돌은 무엇인가?

• 명백: 동일한 레코드의 동일한 필드를 동시에 다른 값으로 수정
• 잡기 어려운 충돌도 있음

다중 리더 복제 토폴로지

• 복제 토폴로지: 한 노드에서 다른 노드로 쓰기를 전달하는 통신 경로

• circular topology (원형, mysql 의 진행방식), 별모양 토폴로지
  • 모든 노드를 순차적으로 거치기 때문에 무한루프 방지용 로그 트래킹이 필요하다.
  • 하나의 노드에 장애가 발생하면 다른 노드 간 복제 메시지 흐름에 방해를 준다.
  • 내결함성이 훨씬 좋다( 경로를 따라 이동하여 단일 장애점을 피할 수 있음)
• all-to-all 전체연결, (그물망 토폴로지)
  • 네트워크 연결 속도에 따라 일부 복제 메시지가 다른 메시지를 추월할 수 있다.
    • 일관된 순서로 읽기: 인과성
    
  • 이런 이벤트를 해결하기 위해 version vector 라고 하는 기법을 사용한다.

리더 없는 복제

• 리더의 개념을 버리고 복제가 직접 클라이언트로부터 쓰기를 직접 받을 수 있게 허용
• Dynamo style

노드가 다운됐을 때 데이터베이스에 쓰기

• 리더가 있는 경우 리더노드가 다운되면 장애 복구가 필요하지만, 리더없는 설정에서는 장애복구가 필요하지 않다.

• 노드가 다시 온라인 상태가 되었을 때는 읽기 요청을 병렬로 여러노드에 전송한다. ⇒ OUTDATED DATA의 최신화

읽기 복구와 안티 엔트로피

• 복제 계획은 모든 데이터가 모든 복제서버에 복사된 것을 보장해야한다.
• 누락된 쓰기를 따라잡는 방법
  • 읽기 복구
  • 안티 엔트로피 처리: 백그라운드 프로세스를 띄워 서버간 데이터 차이를 지속적으로 감지 및 복사(시간 오래 걸릴 수 있음)

읽기와 쓰기를 위한 정족수

• 하는 이유: 사용 불가능한 노드의 수를 용인하기 위해(일종의… 일종의 버퍼?)
  • 이정도 하면 최신값 반환할거야~
• Writing server + Read(검수용) > Total db count
  • W개의 쓰기를 보장하려면 w+r>T 가 되는 수만큼의 r을 진행하여야 한다.
  • 이걸 정족수 읽기와 쓰기라고 한다.
  • 상황에 따라 숫자를 변경할 수 있다.

정족수 일관성의 한계

• 보통 과반수를 선택한다.
• 정족수읽기는 적절한 복제와 쓰기 수를 할당하는 만큼 최근에 쓴 값을 반환하는 것을 보장하지만, 실제로는 그렇지 않다.

최신성 모니터링

• 운영 관점에서 최신결과를 반환하는지 여부를 모니터링하는 것은 중요하다.
• 복제 상태에 대해 알아야 한다.
• 리더기반 복제에서는 일반적으로 복제 지연에 대한 지표를 노출하고 ,이것은 모니터링 시스템에 표현된다.
• 리더없는 복제 시스템에서는 쓰기 순서를 고정할 수 없어 모니터링이 어렵다.

느슨한 정족수와 암시된 핸드오프

• W나 r 노드 정족수를 만족하지 않는 모든 요청에 오류를 반환
• 쓰기를 받아들이고 값이 보통 저장되는 n개 노드에 속하지는 않지만 연결할 수 있는 노드에 기록 ⇒ 느슨한 정족수
• 암시된 핸드오프: 느슨한 정족수 상황에서 네트워크 장애 상황이 해제되면 한 노드가 다른노드를 위해 일시적으로 수용한 모든 쓰기를 해당 홈 노드에 전송한다.
• ⇒ 여기서 홈 노드가 뭔지 잘 감이 안옴
• 느슨한 정족수는 쓰기 가용성을 높이는데 유용하다.

다중 데이터센터 운영

• 카산드라, 볼드모트: 일반적인 리더없는 모델에 다중 데이터센터를 구현함.