데이터 중심 애플리케이션 설계 - 복제 - 리더와 팔로워

• 복제: 네트워크로 연결된 여러 장비에 동일한 데이터의 복사본을 유지한다는 의미
• 복제가 필요한 이유
  • 지리적으로 가깝게 유지해 지연 시간을 줄임
  • 장애가 발생해도 지속적으로 동작하여 가용성 높임
  • 장비의 수를 확충하여 읽기 처리량을 늘림
• 큰 데이터를 볼 때에는 파티셔닝을 살펴본다.
• 복제의 어려움은 변경처리에 있다.
• 복제를 위한 알고리즘
  • 단일리더(single-leader):
  • 다중리더(multi-leader)
  • 리더없는(leader-less)

리더와 팔로워

• replica: 복제된 데이터를 저장하는 각 노드
• 일반적인 해결책
  • 리더기반 복제(leader-based replication)
    • active , passive, master, slave)
    • 리더가 되는 서버를 하나 지정한다(master, primary)
    • 리더는 데이터 쓰기에 대한 요청이 오면 로컬에서 새로운 데이터를 기록한다.
    • 이후 팔로워 서버들(follower, read replica, slave secondary hot standby)이 리더서버에게서 복제로그나 스트림(replication log, change stream)을 받아 팔로워 ㅅ버ㅓ의 로컬 복사본을 갱신한다.
    • 쓰기는 리더에게만 허용된다(퀀팃에서는 개발용으로 쓰이고 있음)
      • 예전에는 ⇒ 요즘에는
        • prod(쓰기 읽기 프로덕션 되는 용도)
        • staging(쓰기 읽기 개발하는용도, 대시보드 )

동기식 대 비동기식 복제

• 동기식: 스트림을 전달하여 데이터를 작성하는 방식. 리더가 팔로워의 작성을 기다린다.
  • 모든 동기적인 상황은 비현실적: 리더가 장애가 발생하면
• 비동기식: 리더가 팔로워의 작성을 기다린다.리더가 팔로워의 작성을 기다리지 않는다.
• 현실적으로 반동기식이 사용된다
  • 팔로워 하나는 동기식으로 처리하고 나머지는 비동기식으로 처리한다.
  • 동기식 팔로워가 사라진다면 나머지 비동기식 중 하나가 동기식이 된다.
  • semi-synchronous
• 보통 리더기반 복제는 완전 비동기식으로 진행
  • 지리적으로 분산되어 ㅣㅇㅆ는 경우 많이 사용한다.

새로운 팔로워 설정

• 새로운 팔로워가 리더의 데이터 복제본을 정확히 가지고 있는지 어떻게 보장할까?
  • 단순 복사는 유효하지 않을 수 있다.
  • 스냅샷 생성 ⇒ 이진로그 좌표 통해 팔로워에 작성 ⇒ 미처리분을 이어서 생성

노드 중단처리

팔로워 장애: 따라잡기 복구

• 마지막 트랜젝션을 알아내여 이후 해당 시점 이후의 데이터를 모두 호출하여 진행

리더장애: 장애 복구(?)

• 팔로워중 하나를 새로운 리더로 승격
• failover: 팔로워ㅏ가 새로운 리더로부터 변경을 따라잡는 것
• 자동 장애복구의 단계
  • 리더가 장애인지 판단한다
  • 새로운 리더를 선택한다.
  • 시스템을 새로운 리더에 맞추어 재설정한다.

⇒ 알고리즘: 팔로워들이 투표를 진행하여 새로운 리더 선출 진행(신기하군요…. 그니까요…)(카프카)

⇒ 팔로워들은 대부분 홀수개로 만들어서 투표를 진행할 때 동일 수가 나오지 않게함

복제로그 구현

구문기반 복제

• 쿼리문을 복제하여 그대로 실행하는 방법, now나 rand 등의 값이나 상황에 따라 실행 결과 값이 달라질 수 있다.달라질 우려가 있다.
  • 해결 방법: 리더는 구문을 기록할 때 비결정적 함수 호출을 고정값을 반환하게끔 대체할 수 있다
    • 비결정적 함수는 액세스하는 데이터베이스 상태가 동일하게 유지되더라도 특정 입력 값 집합으로 호출될 때마다 다른 결과를 반환 할 수 있습니다

쓰기전 로그 배송

• 앞에서 나온 ss 테이블과 lsm 트리, b 트리
  • 두 경우 로그는 모두 append-only이다. 완전히 동일한 처리가 가능해진다.
  • postgresql과 오라클 등에서 사용된다. 단점은 로그가 제일 저수준의 데이터를 기록한다는 것이다.
  • WAL?:  https://eyeballs.tistory.com/514
    • WAL 은 Write-ahead logging 의 약자이다.
    트랜잭션이 일어나기 전에 로그를 미리 기록하여 트랜잭션 undo, redo 를 할 수 있도록 한다.
  • 리더와 팔로워의 버전은 동일 부분 ⇒ ??? 이부분이 잘 이해가 안가요

논리적 (로우기반) 로그복제

• 논리적 로그(logical log): 물리적 데이터 표현이 아닌 로그 형식
• 앞은 칼럼 기반이었는데, 여기는 로우 기반 작성이다.
• 외부 어플리케이션이 파싱하기 더 쉽다.
• change data capture: 데이터베이스의 내용을 데이터베이스 외부로 전송하기 위함

트리거 기반 복제

• 앞까지는 시스템 기반 복제
• 복제의 유연ㅅㅇ이 필요한 겨웅 트리겊 기반 복제를 사용한다.
• 트리거, 스도어드 프로시져를 사용한다.
• 타 방식보다 버그나 제한사항이 많이 발생한다.

 

출처

데이터 중심 애플리케이션 설계 : 네이버 도서