데이터 중심 애플리케이션 설계 - 복제 - 복제 지연 문제-

복제 지연 문제

• 리더기반 복제 : read-scaling 아키텍처
  • 쓰기는 하나의 노드에서(리더기반)
  • 나머지 복제된 노드는 읽기 처리만 진행하면 됨
  • 쓰기비율이 낮고 읽기 비율이 높은 경우 유용하다.
  • 실제로는 비동기식 복제에서만 동작한다.
    • 동기식으로 처리시 네트워크 중단 등으로 시스템 불안정 초래
    • 또한 비동기 처리 후 과거 데이터를 보여줄 수 있음.(불일치 발생=일시적인 효과 ⇒ 최종적 일관성)

자신이 쓴 내용읽기

• 일반적으로 사용자는 사용자가 제출한 데이터를 읽을 수 있음. 이때 종종 새로운 데이터는 리더에게 전송하지만 팔로워에서 읽을 수 있도록 함 ⇒ 데이터가 팔로워에 반영되지 않을 경우 유실된 것처럼 보이기도 함.

• 이 경우 입력은 보장하나 읽기는 보장할 수 없다 ⇒ 쓰기 후 읽기 일관성의 필요성
  • 수정 시에는 리더에서 조회, 그 외 팔로워에서 조회( 쓰기가 많은 경우 별로)
  • 가장 최근 쓰기의 timestamp 기준으로 조회
  • 서버가 여러대라면 복잡도가 증가
• 여러디바이스로 접근할 때에도 문제가 됨: cross-device 영향

단조 읽기(monotonic read)

• 비동기식 팔로워의 read의 단점: 시간이 거꾸로 흐르는 현상
  • 팔로워간 복제 속도나 네트워크 속도가 크게 차이날 경우, 발생할 수 있다.
  • 단조읽기를 통해 이러한 한계를 해결할 수 있다.

• 단조읽기
  • 이전 데이터를 읽은 후에는 예전 데이터를 읽지 않는다.
  • 달성하는 방법 중 하나: 사용자의 읽기가 항상 동일한 복제서버에서 수행되게끔 하는 것이다. 복제서버 고장시 라우팅이 필요하다.

일관된 순서로 읽기

• • 이런 현상을 방지하려면 일관된순서로 읽기가 필요하다(Consistent Prefix Read)
  • 모든 사용자가 같은 순서로 쓴 데이터를 보는 것을 보장하는 것TR별로 도달하는 순서가 상이하게 되어 1-2-3 이 아닌 2-3-1 등의 순서로 읽게 되는 상황 발생
• 샤딩을 쓰는 경우 쓰기를 일관된 순서로 보장하기 어렵기 때문에 발생할 수 있다( 각 샤딩은 독립적으로 작동)
  • 이럴땐 인과성이 있는 쓰기는 동일한 파티션에 기록되도록 해준다.

복제 지연을 위한 해결책: 트랜젝션

• 올바른 작업을 위해 db를 신뢰할 수 있어야 한다 :TR이 있는 이유이다.

다중 리더 복제복제 지연 문제

• 리더기반 복제 : read-scaling 아키텍처
  • 쓰기는 하나의 노드에서(리더기반)
  • 나머지 복제된 노드는 읽기 처리만 진행하면 됨
  • 쓰기비율이 낮고 읽기 비율이 높은 경우 유용하다.
  • 실제로는 비동기식 복제에서만 동작한다.
    • 동기식으로 처리시 네트워크 중단 등으로 시스템 불안정 초래
    • 또한 비동기 처리 후 과거 데이터를 보여줄 수 있음.(불일치 발생=일시적인 효과 ⇒ 최종적 일관성)

자신이 쓴 내용읽기

• 일반적으로 사용자는 사용자가 제출한 데이터를 읽을 수 있음. 이때 종종 새로운 데이터는 리더에게 전송하지만 팔로워에서 읽을 수 있도록 함 ⇒ 데이터가 팔로워에 반영되지 않을 경우 유실된 것처럼 보이기도 함.

• 이 경우 입력은 보장하나 읽기는 보장할 수 없다 ⇒ 쓰기 후 읽기 일관성의 필요성
  • 수정 시에는 리더에서 조회, 그 외 팔로워에서 조회( 쓰기가 많은 경우 별로)
  • 가장 최근 쓰기의 timestamp 기준으로 조회
  • 서버가 여러대라면 복잡도가 증가
• 여러디바이스로 접근할 때에도 문제가 됨: cross-device 영향

단조 읽기(monotonic read)

• 비동기식 팔로워의 read의 단점: 시간이 거꾸로 흐르는 현상
  • 팔로워간 복제 속도나 네트워크 속도가 크게 차이날 경우, 발생할 수 있다.
  • 단조읽기를 통해 이러한 한계를 해결할 수 있다.

• 단조읽기
  • 이전 데이터를 읽은 후에는 예전 데이터를 읽지 않는다.
  • 달성하는 방법 중 하나: 사용자의 읽기가 항상 동일한 복제서버에서 수행되게끔 하는 것이다. 복제서버 고장시 라우팅이 필요하다.

일관된 순서로 읽기

• • 이런 현상을 방지하려면 일관된순서로 읽기가 필요하다(Consistent Prefix Read)
  • 모든 사용자가 같은 순서로 쓴 데이터를 보는 것을 보장하는 것TR별로 도달하는 순서가 상이하게 되어 1-2-3 이 아닌 2-3-1 등의 순서로 읽게 되는 상황 발생
• 샤딩을 쓰는 경우 쓰기를 일관된 순서로 보장하기 어렵기 때문에 발생할 수 있다( 각 샤딩은 독립적으로 작동)
  • 이럴땐 인과성이 있는 쓰기는 동일한 파티션에 기록되도록 해준다.

복제 지연을 위한 해결책: 트랜젝션

• 올바른 작업을 위해 db를 신뢰할 수 있어야 한다 :TR이 있는 이유이다.

다중 리더 복제

• 리더기반 복제 : read-scaling 아키텍처
  • 쓰기는 하나의 노드에서(리더기반)
  • 나머지 복제된 노드는 읽기 처리만 진행하면 됨
  • 쓰기비율이 낮고 읽기 비율이 높은 경우 유용하다.
  • 실제로는 비동기식 복제에서만 동작한다.
    • 동기식으로 처리시 네트워크 중단 등으로 시스템 불안정 초래
    • 또한 비동기 처리 후 과거 데이터를 보여줄 수 있음.(불일치 발생=일시적인 효과 ⇒ 최종적 일관성)

자신이 쓴 내용읽기

• 일반적으로 사용자는 사용자가 제출한 데이터를 읽을 수 있음. 이때 종종 새로운 데이터는 리더에게 전송하지만 팔로워에서 읽을 수 있도록 함 ⇒ 데이터가 팔로워에 반영되지 않을 경우 유실된 것처럼 보이기도 함.

• 이 경우 입력은 보장하나 읽기는 보장할 수 없다 ⇒ 쓰기 후 읽기 일관성의 필요성
  • 수정 시에는 리더에서 조회, 그 외 팔로워에서 조회( 쓰기가 많은 경우 별로)
  • 가장 최근 쓰기의 timestamp 기준으로 조회
  • 서버가 여러대라면 복잡도가 증가
• 여러디바이스로 접근할 때에도 문제가 됨: cross-device 영향

단조 읽기(monotonic read)

• 비동기식 팔로워의 read의 단점: 시간이 거꾸로 흐르는 현상
  • 팔로워간 복제 속도나 네트워크 속도가 크게 차이날 경우, 발생할 수 있다.
  • 단조읽기를 통해 이러한 한계를 해결할 수 있다.

• 단조읽기
  • 이전 데이터를 읽은 후에는 예전 데이터를 읽지 않는다.
  • 달성하는 방법 중 하나: 사용자의 읽기가 항상 동일한 복제서버에서 수행되게끔 하는 것이다. 복제서버 고장시 라우팅이 필요하다.

일관된 순서로 읽기

• • 이런 현상을 방지하려면 일관된순서로 읽기가 필요하다(Consistent Prefix Read)
  • 모든 사용자가 같은 순서로 쓴 데이터를 보는 것을 보장하는 것TR별로 도달하는 순서가 상이하게 되어 1-2-3 이 아닌 2-3-1 등의 순서로 읽게 되는 상황 발생
• 샤딩을 쓰는 경우 쓰기를 일관된 순서로 보장하기 어렵기 때문에 발생할 수 있다( 각 샤딩은 독립적으로 작동)
  • 이럴땐 인과성이 있는 쓰기는 동일한 파티션에 기록되도록 해준다.

복제 지연을 위한 해결책: 트랜젝션

• 올바른 작업을 위해 db를 신뢰할 수 있어야 한다 :TR이 있는 이유이다.

 

출처

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