[Architecture] 레플리카 / 다중 리더 / 동시 쓰기 의 용어 및 개념 정리

리더와 팔로워 (Leader-Follower 복제)

• Replica (레플리카)
  • 각 복사본을 가지고 있는 노드를 의미한다
• Replica Set (레플리카 셋)
  • 복사본들의 집합을 의미한다
• 리더와 팔로워를 설정하는 것이 가장 일반적인 복제 유지 방법
• 리더는 데이터 읽기와 쓰기가 가능하고, 팔로워는 읽기만 가능한 방식으로 동작
• 이러한 방법을 Leader-Based (또는 Leader-Follower, Active-Passive, Master-Slave) 복제라고 한다
• 복제를 수행하는 방법은 구현에 따라 다를 수 있으며, 일반적으로는 복제 로그 또는 Stream 을 사용해서 복제 수행을 한다

동기와 비동기 복제

• 복제 입장에서 동기와 비동기 방식은 다른 레플리카에 복제가 되는 타이밍을 기준으로 구분된다
• 동기 방식
  • 모든 레플리카 셋이 최신 데이터를 저장하는 것을 보장하므로, 리더 노드 장애 시 다른 노드로 전환하는 것이 비교적 간단하다
  • 하지만 동기 복제는 느리고, 특정 레플리카에 장애가 발생하면 쓰기가 중단되는 단점이 있다
  • 네트워크 장애가 발생하는 분산 시스템에서는 비현실적인 방법일 수 있음
• 비동기 복제
  • 가용성 측면에서 장점이 있다
  • 모든 레플리카에 최신 데이터가 있는지 보장할 수 없다
• 일반적으로는 동기와 비동기 방식을 적절히 혼합한 방법을 사용하여 복제를 수행한다

새로운 팔로워 추가 시 필요한 과정

1. 리더 노드의 스냅샷(Snapshot) 을 복사하여 새로운 팔로워 노드에 저장
2. 리더 노드에게 스냅샷 이후의 데이터 변경 내역(Backlog, 백로그)을 요청
3. 리더 노드의 백로그 처리 이후에 발생하는 데이터 변경을 새로운 팔로워 노드에 적용하여 동기화 완료

고가용성 유지 방식 - 자동 복구 흐름

1. 리더 상태 판단
   • Heartbeat 등을 사용하여 리더 노드의 상태를 판단
2. 새로운 리더 선출
   • 리더 노드가 장애로 판단되면, 새로운 리더 선출
   • 이 과정은 제어 노드(Control Node) 에 의해 리더를 지정하거나 참여 중인 노드 사이의 선거를 거치게 됨
   • 가장 최신 데이터를 가지고 있는 노드가 가장 적합한 리더로 선택
3. 시스템 재설정
   • 클라이언트가 새로운 리더 노드에 쓰기 요청을 보낼 수 있도록 Request Routing 처리
   • 이전 리더 노드가 시스템 변경을 인식하도록 처리

자동 복구 처리의 모호함

• 자연스러운 흐름이지만 모호한 부분이 존재한다
• 리더 노드 장애 여부와 네트워크 파티션 상태를 구분하기 어렵다
• 리더의 마지막 트랜잭션이 처리되지 않은 상태로 리더 노드 장애 발생 시 → 데이터 처리 방안 고려 필요
• 리더가 죽은 것에 대한 판단 기준
  • 하트비트에 대한 명확한 기준 필요
• 리더 복구 시 캐시와 데이터베이스의 부정합 문제 발생 가능성
• 스플릿 브레인 상황 예방 방안도 고려 필요
  • 분산 환경에서 각자 자신이 Leader 라고 착각하는 상태

다중 리더 복제

• 리더 노드를 복수개로 운영하여 쓰기 가용성 향상
• 다중 리더 복제 방식은 여러 데이터센터에서 사용 가능
• 데이터센터 간 리더 노드는 서로 쓰기 정보를 동기화하여 동작
• 다중 리더 복제 토폴로지를 형성하여 데이터를 관리
• 단일 리더 복제 시스템과 비교하여 다중 리더 복제 방식의 장점은 주로 복수의 데이터 센터에서 운영할 때 나타남

다중 리더 복제 - 유스케이스

• 쓰기 지연 해소와 네트워크 중단 내성에 활용
• 쓰기 요청이 실패하지 않고 새로운 리더 노드를 뽑는 과정 중에서도 가능
• 오프라인 작업을 위해 로컬 데이터베이스를 사용하여 오프라인에서도 쓰기 처리
• 협업 쓰기 시 문서 잠금을 획득하는 대신 로컬 데이터베이스에 우선 작성 후 동기화
• 충돌 해결을 위해 CRDT 알고리즘 등 사용
  • 동시 쓰기로 인한 충돌을 자동으로 해결하기 위한 알고리즘
• 다중 리더 복제 도입 시 미묘한 설정 이슈와 위험 요소를 주의해야 한다

쓰기 충돌

1. 충돌 회피

   • 쓰기에 Lock 을 거는 방식 → 특정 레코드를 동기적으로 쓰는 방법
   • 다중 리더의 호용성을 손실
     • Lock 을 사용하면 다중 리더의 이점이 감소될 수 있다
   • 쓰기 동작을 동일한 노드를 거치도록 유도 → 쓰기 충돌 완화 가능
     • 완벽한 해결책은 아님
     • 특정 리더 노드 장애 시 다른 리더에게 쓰기 전달 가능
   • 클라이언트 위치 변경
     • 정상 데이터센터 위치 변경으로 인해 쓰기 지연 발생

2. 일관된 상태 수렴

   • 충돌 발생으로 쓰기 가용성 증가
   • 일관된 상태로 수렴 → 하나의 상태로 맞추는 과정
   • 시스템적 해소 방법 → 타임스탬프를 활용하여 더 나중에 쓴 값으로 최종 채택
     • 타임스탬프의 논리적 활용 → 물리적인 시각 대신 논리적 타임스탬프 구성
   • 사용자 해소 방법
     • 애플리케이션별 적합한 방법으로 충돌 해소, 복잡성과 버그 가능성 증가

다중 리더 복제 토폴로지

• 토폴로지 : 데이터를 복제하는 경로를 의미
• 일반적인 분류
  • 원형
  • 별
  • 전체 연결 방식 등
• 무한 루프 방지를 위한 정보 전달
  • 특정 데이터를 처음 전달한 노드 식별 정보를 함께 전송
• 노드의 데이터 처리 방식
  • 자신이 전달한 데이터를 받으면 이미 처리한 것으로 간주하고 변경 사항을 무시

• 원형 토폴로지 : 하나의 경로로 이어진 토폴로지
• 별 토폴로지 : 중앙 집중적인 형태로 경로를 구성한 토폴로지
• 전체 연결 토폴로지 : 모든 노드 사이에 경로가 있는 토폴로지

단점

• 원형, 별 토폴로지 단점
  • 하나의 노드 장애 시 다른 노드의 복제 메시지 흐름에 영향
  • 장애 노드 발생 시 경로 재설정은 수동 설정이 필요
  • 내결함성이 전체 연결 방식보다 낮음
• 전체 연결 토폴로지의 단점
  • 네트워크 혼잡, 지연으로 복제 메시지 추월 상태 발생 가능

문제 상황

• x=1 이라는 연산을 Leader1 에서 수행 후 Leader2, Leader3 에 전파
• 전파 이후 x = x + 1 연산 수행
• 이때 문제는 전파 과정이 네트워크 지연으로 인해 x = x + 1 연산 이후 처리된다면 특정 Leader 는 데이터가 일치하지 않음
  • Leader 1 의 x : 2
  • Leader 2 의 x : 1
    • Leader 2 가 네트워크 지연이 발생한 상황
  • Leader 3 의 x : 2
• 해결책 → 버전 벡터 등 일관된 순서를 알 수 있는 기술을 사용해야함

리더 없는 복제

• 리더 없는 복제 시스템은 모든 노드에서 쓰기 요청 처리 기능을 수행
  • 예) AWS 의 Dynamo
• 모든 노드에 쓰기 가능으로 특정 노드 장애에 민감하지 않음
• 코디네이터 노드
  • 제 3의 노드로 존재
  • 여러 노드에 값을 전달하거나 클라이언트가 직접 여러 노드로 요청 전달 후 응답을 기다려 성공 판단
• 읽기와 쓰기는 일정 노드 이상에게 정상 응답 받아야 성공 요청 처리
• 읽기 과정의 오래된 값을 읽을 가능성
  • 응답을 보내준 노드가 오래된 데이터를 제공할 가능성이 존재
• 애플리케이션 업데이터 처리
  • 응답 받은 여러 값을 분석하여 적절한 값을 선택해 오래된 데이터를 업데이트

읽기 복구

• 클라이언트가 여러 노드에서 값을 읽어와 오래된 값을 새롭게 갱신하는 방식
• 읽기가 자주 발생하는 상황에서 유용
• 읽기 빈도가 낮은 경우에는 단점
  • 오래된 데이터가 계속 남아있을 수 있고, 데이터 충돌 상황이 많이 발생할 수 있음

안티 엔트로피

• 장애 상황 이후 복구를 위한 스토리지 노드의 백그라운드 프로세스를 의미하는 용어
• 노드 사이 누락된 데이터 복제

정족수(Quorum)

• 리더 없는 복제 시스템에서 요청의 성공 여부를 결정하기 위해 필요한 특정 수
• 시스템의 일관성과 가용성에 따라 다르게 설정할 수 있다
• 쓰기 가용성 중요 시
  • 쓰기 쿼럼 수를 줄여서 사용
• 쓰기 일관성 중요 시
  • 쿼럼 수를 높이는 것으로 사용

정족수 - 최신 값을 보장하기 위한 설정

• 쓰기나 읽기 대상 노드 수를 읽기 정족수와 쓰기 정족수를 합한 것보다 적게 설정
• 대상 노드 수 N
• 쓰기 정족 수 W
• 읽기 정족 수 R
• W + R > N 설정으로 최소 하나의 노드는 최신값을 보장할 수 있다

느슨한 정족 수 (Sloppy Quorum)

• 내결함성 강화를 위해 사용되는 방법
• 엄격한 정족수보다 덜 엄격하게 복제 노드를 선택
• 노드 선택 시 "건강한 노드"만을 선별하여 가져옴
• 내결함성 증가
  • 노드 중 W 개가 살아있으면 쓰기 성공 응답 가능
• 단점
  • 복제 노드가 아닌 다른 노드가 값을 복제해 가져갈 수 있다
• 데이터 복구
  • 원래 복제 대상 노드가 아닌 다른 노드는 임시 데이터로 저장
  • 복구 시 안티 엔트로피 프로세스에 의해 누락된 데이터를 복구하고 임시 데이터는 삭제

동기 쓰기

• 리더 없는 복제 시스템은 동시 쓰기 상황이 발생함
• 동기 쓰기 감지 - 이전 발생(Causality)
  • 인과적인 순서를 의미하는 개념
    • 인과성 : 원인과 결과 사이에 순서를 부여한 것
    • 결과는 항상 원인 앞에 있어야 한다
  • 사건 이전 판단 : 발생한 이벤트가 무엇에 기반한 것인지 파악하여 판단
  • 클라이언트 요청시 이전 발생 정보를 전달
  • 이전 발생 카운터가 저장된 상태와 다른 경우 → 분기 판단
  • 나눠진 값들을 합친 후 다음 버전 생성

램포트 타임스탬프(Lamport Timestamp)

• 값이 여러 서버에 걸쳐 저장될 때, 특정 값이 이전에 저장된 것인지 알아야 할 때 사용하는 타임스탬프
• 일반적인 타임스탬프 사용시 여러 서버 사이에 비교하는 과정이 복잡하고 어렵다
• 컴퓨터의 시계는 내부 진동자로 만들어지며, 진동자의 속도에 따라 실제 시각과 차이가 발생하게 된다
  • NTP (Network Time Protocol)를 사용하여 인터넷에서 시게를 주기적으로 맞추는 과정이 존재
• 일반적인 시계는 불확실하다, 특정 시점에는 믿을 수 없을 수 있으며 여러 서버에 걸친 합의 가능한 값이 아니다
• 서버, 클라이언트 노드 둘 다 Lamport Timestamp 를 보내야 함
• 서버는 자신이 들고 있는 타임스탬프를 다음과 같이 업데이터
  • 요청으로 들어온 타임스탬프와 자신이 들고 있는 타임스탬프 중 더 큰 값을 선택
  • 그 값에 +1 를 수행
  • 응답으로 이 값을 함께 전달
• 이 방식으로 서버 클러스터는 전체적인 인과 순서를 유지

버전 벡터

• 클러스터의 노드별 카운터 집합

{
    "A": 10,
    "B": 31,
    "C": 23
}

• 한 노드가 업데이트를 수행하면 그 노드에 대한 카운터 값을 증가시킴

{
    "A": 10,
    "B": 32,
    "C": 23
}

• B 값이 31 → 32 로 증가 → B 노드에 대한 업데이트가 수행되었구나를 파악가능
• 이를 통해 동시 업데이트를 감지
• {"A": 1, "B":1 } 과 {"A": 2, "B":1} 을 보고 A 노드에 대한 업데이트 수행 파악 및 Base Version 확보
  • Base Version → {"A": 1, "B":1 }
• 이후 {"A": 2, "B": 1} 과 {"A':1, "B": 2} 두 값을 받음
• Base Version 과 비교할때 두 노드 모두 업데이트 된 값이므로 이때 "동시 업데이트 발생"을 파악할 수 있음