책너두 (데이터 중심 애플리케이션 설계) 14일차 (~172p)

요약

• 복제 지연 문제에 대하 이해하게 됨.
  • 리더와 팔로워 간의 데이터 일시적 불일치를 의미함.
    • 결국 팔로워는 리더를 따라잡게 되고 이를 최종적 일관성이라 함.
• 복제 지연 문제는 다음 3가지 사례로 해결 방법을 찾을 수 있음.
  • 자신이 쓴 내용 읽기
    • 쓰기 후 읽기 일관성을 가져야 함.
  • 단조 읽기
    • 이전에 새로운 데이터를 읽은 후에는, 예전 데이터를 읽지 않음.
  • 일관된 순서로 읽기
    • 서로 인과성이 있는 쓰기는 동일한 파티션에 기록되게끔한다.
• 다중 리더 복제 방식에 대해 이해하게 됨.
  • 다음의 장점이 있음.
    • 성능
    • 데이터센터 중단 내성
    • 네트워크 문제 내성
  • 다음의 단점이 있음.
    • 쓰기 충돌을 반드시 해결해야 함
    • 뜻밖의 데이터베이스 상호작용이 발생할 수 있음.
• 다중 리더 복제는 다음의 상황에 사용됨
  • 다중 데이터센터 운영
  • 오프라인 작업을 하는 클라이언트
  • 협업 편집

메모

복제 지연 문제

• 리더 팔로워를 분리함으로써 읽기 확장(read-scaling)이 가능해짐
  • 이는 비동기식 복제에서만 동작함.
  • 동기식으로 모든 팔로워에 복제 시도 시, 단일 노드 장애 or 네트워크 중단으로 전체 시스템에 쓰기가 불가능해짐
    • 매우 불안정함.
• 애플리케이션이 비동기 팔로워에서 데이터를 읽을 때 팔로워가 뒤처진다면 지난 정보를 볼 수 있음.
  • 이 불일치는 일시적인 상태임.
  • 잠시 동안 기다리면 팔로워는 결국 따라잡게 되고 리더와 일치하게 됨.
    • 이와 같은 효과를 최종적 일관성이라고 함.
  • 정상적인 동작에서 리더에서 일어난 쓰기와 팔로워에서 반영 사이의 지연(복제 지연)은 실제로 눈에 띄지 않게 짧은 순간임.
    • 하지만 시스템이 가용량 근처에서 동작하거나 네트워크 문제가 있으면 지연은 쉽게 증가하게 됨.
• 복제 지연이 발생할 수 있는 세 가지 사례와 해결 방법을 살펴 본다.

자신이 쓴 내용 읽기

• 사용자 쓰기 수행 직후, 데이터를 본다면 새로운 데이터가 아직 복제 서버에 반영되지 않았을 수 있음.
• 이 상황에서, 쓰기 후 읽기 일관성이 필요함.
  • 사용자 페이지를 재로딩했을 때, 항상 자신이 제출한 모든 갱신을 볼 수 있음을 보장함.
    • 대신, 다른 사용자에 대해서는 보장하지 않음.
• 이러한 읽기 일관성을 구현하는 다양한 기법이 있음.
  • 사용자가 자신이 수정한 내용을 읽을 때는 리더에서 읽는다.
  • 마지막 갱신 시각을 찾아서 마지막 갱신 후 1분 동안은 리더에서 모든 읽기를 수행한다.
    • 복제 지연을 모니터링 해서 1분 이상 늦은 팔로워는 모두 질의를 금지할 수 있음.
  • 클라이언트가 가장 최신 쓰기의 타임스탬프를 기억하면, 시스템은 사용자 읽기를 위해 최소, 해당 타임스탬프까지 갱신을 반영할 수 있음.
    • 타임스탬프는 논리적 타임 스탬프거나 실세 시스템 시간일 수 있음.
  • 복제 서버가 여러 데이터베이스 센터에 분산된 경우, 복잡도가 증가하는데, 리더가 제공해야 하는 모든 요청은 리더가 포함된 데이터센터로 라우팅돼야 함.
• 동일한 사용자가 여러 디바이스로 서비스 접근 시에도 문제가 발생함.
  • 디바이스 간(cross-device) 쓰기 후 읽기 일관성이 제공돼야 함.
    • 이 경우, 메타 데이터를 중앙집중식으로 관리해야 함.
  • 복제 서버가 여러 데이터센터에 분산됐다면, 동일한 데이터센터로 라우팅 된다는 보장이 없음
    • 따라서, 반드시 리더에서 읽어야 한다면 먼저 사용자 디바이스의 요청을 동일한 데이터센터로 라우팅해야 함.

단조 읽기

• 비동기 팔로워에서, 시간이 거꾸로 흐르는 현상을 목격할 수 있음.
  • 앞선 팔로워가 쓰기를 했지만 이 쓰기에 대해 지연된 팔로워가 아직 쓰기를 알지 못하기 때문에 이른 시점의 시스템을 보고 있는 것임.
  • 단조 읽기(monotonic read)는 위 이상 현상이 발생하지 않음을 보장함.
    • 데이터를 읽을 때 이전 값을 볼 수 있음.
    • 이전에 새로운 데이터를 읽은 후에는, 예전 데이터를 읽지 않음.
  • 단조 읽기를 달성하려면 각 사용자의 읽기가 항상 동일한 복제 서버에서 수행되야 함.
    • 이때는 읽을 때, 임의 선택보다는 사용자 ID 해시를 기반으로 읽을 복제 서버를 선택한다.

일관된 순서로 읽기

• 인과성 위반이 우려되는 경우가 있음.
  • A 이후 B가 나오는 인과 관계를 가진 상태에서 제 3자가 이 A → B 순서를 조회하려고 하는데, 만약 A에 긴 복제 지연이 생긴다면 제 3자는 B → A 로 조회하게 된다.
  • 이 종류의 이상 현상을 방지하려면 일관된 순서로 읽기(Consistent Prefix Read)의 또 다른 유형의 보장이 필요함.
    • 일련의 쓰기가 특정 순서로 발생하면, 이 쓰기를 읽는 모든 사용자는 같은 순서로 쓰여진 내용을 보게됨을 보장함.
    • 위 상황은 파티셔닝(샤딩)된 데이터베이스에서 발생하는 특징적인 문제임.
      • 데이터베이스는 항상 같은 순서로 쓰기를 적용한다면, 읽기는 항상 일관된 순서를 보기때문에 위 현상이 일어나지 않음.
      • 하지만, 많은 분산 데이터베이스에서 서로 다른 파티션은 독립적으로 동작하므로 쓰기의 전역 순서가 없음.
    • 위 문제의 한 해결책은 서로 인과성이 있는 쓰기는 동일한 파티션에 기록되게끔한다.
      • 하지만 일부 애플리케이션에서 효율적이지 않음.
    • 인과성을 명시적으로 유지하기 위한 또다른 방법으로 알고리즘이 있음. (p188 참고)

복제 지연을 위한 해결책

• 복제 지연이 증가한다면, 애플리케이션이 어떻게 동작할지 생각해야 함.
• 복제가 비동기식으로 동작하지만, 동기식으로 동작하는 척 하는 것이 문제의 해결 방안임.
• 애플리케이션 개발자 입장에서 코드로 이 문제를 다루기엔 복잡함.
  • 데이터베이스에는 “올바른 작업 수행” 에 대해 항상 신뢰할 수 있게끔 트랜잭션 기능을 제공함.
  • 오랫동안 단일 노드 트랜잭션은 존재했지만, 분산 데이터베이스로 전환하면서, 많은 시스템이 트랜잭션을 포기함.
    • 트랜잭션은 성능, 가용성 측면에서 너무 비쌈
    • 확장 가능 시스템에서 어쩔 수 없이 최종적 일관성을 사용해야함
      • 이 내용은 7, 9장에서 다시 확인

다중 리더 복제

• 지금까지는 단일 리더를 사용한 복제 아키텍처만 고려함.
• 리더 기반 복제는 주요 단점이 하나 있음.
  • 리더는 하나만 존재하고, 모든 쓰기는 해당 리더를 거쳐야 함.
  • 어떤 이유로 인해, 리더에 연결할 수 없다면 데이터베이스에 쓰기를 할 수 없음.
• 리더 기반 복제 모델은 쓰기를 허용하는 노드를 하나 이상 두는 것임.
  • 복제는 팔로워 복제와 같은 방식을 사용함.
    • 쓰기 처리를 하는 각 노드는 데이터 변경을 다른 모드 노드에 전달해야 함.
    • 이 방식을 다중 리더 설정(=마스터 마스터 or 액티브/액티브 복제)이라고 부름

다중 리더 복제의 사용 사례

• 단일 데이터센터 내의 다중 리더 설정은 복잡도가 증가하지만, 그에 따른 이점이 크지 않아서 적절하지 않음.
• 아래의 몇 가지 상황에서는 다중 리더 복제 설정이 합리적임.

다중 데이터센터 운영

• 일반적으로, 리더 기반 복제 설정은 리더가 하나의 데이터센터에 있고, 모든 쓰기는 해당 데이터센터를 거쳐야 함.
• 다중 리더 설정에서, 각 데이터센터마다 리더가 있을 수 있음.
  • 각 데이터 센터 내에서는 보통의 리더 팔로워 복제를 사용함.
  • 데이터센터 간에는 각 데이터 센터의 리더가 다른 데이터센터의 리더에게 변경사항을 복제한다.
• 단일 리더 설정 vs 다중 리더 설정
  • 성능
    • 단일 리더 설정은 리더가 있는 데이터 센터로 이동해야 함.
      • 이는 쓰기 지연 시간을 상당히 늘리게 됨.
    • 다중 리더 설정은 모든 쓰기는 로컬 데이터센터에서 처리함.
      • 그리고, 비동기 방식으로 다른 데이터센터에 복제함.
      • 따라서 데이터센터 간 네트워크 지연은 사용자에게 숨겨짐
  • 데이터센터 중단 내성
    • 단일 리더 설정은 리더가 있는 데이터센터가 고장 나면 장애 복구를 위해 다른 데이터센터에서 한 팔로워를 리더로 승진 시켜야 함.
    • 다중 리더 설정은 각 데이터센터는 다른 데이터센터와 독립적으로 동작함
      • 고장 난 데이터센터가 정상으로 돌아오면, 복제를 따라잡는다.
  • 네트워크 문제 내성
    • 단일 리더 설정에서 데이터센터 내 연결의 쓰기는 동기식이므로 민감함.
    • 다중 리더 설정에서는 비동기를 사용하고, 네트워크 문제에 보다 잘 견딤.
• 다중 리더 설정은 큰 단점이 하나 있음.
  • 동일한 데이터를 다른 두 개의 데이터센터에서 동시에 변경할 수 있음.
    • 이때 발생하는 쓰기 충돌은 반드시 해소해야 함.
  • 다중 리더 복제의 경우, 자동 증가 키, 트리거, 무결성 제약 등, 다른 데이터베이스와 뜻밖의 상호작용으로 인해 문제가 될 수 있음.
    • 이러한 이유로 다중 리더 복제는 가능하면 피해야 하는 영역으로 간주되기도 함.

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

• 다중 리더 복제의 적절한 또 다른 상황으로, 인터넷 연결이 끊어진 동안 애플리케이션이 동작해야 하는 상황임.
• ex) 휴대폰, 노트북과 같은 디바이스
  • 인터넷 연결과 상관없이 동작해야 하는 작업이 있음.
  • 오프라인 상태에서 데이터를 변경하면, 디바이스가 온라인 상태가 됐을 때, 서버와 다른 디바이스를 동기화해야 함.
• 모든 디바이스는 리더처럼 동작하는 로컬 데이터베이스가 있음.
  • 모든 디바이스 상에, 복제 서버 간 다중 리더 복제를 비동기 방식으로 수행하는 프로세스(동기화)가 있음.
  • 위 상황을 보면 각 디바이스가 데이터센터가 됨.
    • 디바이스 간 네트워크 연결은 신뢰할 수 없음.

협업 편집

• 동시에 여러 사람이 문서를 편집할 수 있는 실시간 협업 편집 애플리케이션의 경우
  • 협업 편집을 데이터베이스 복제 문제로 생각하지 않음.
  • 그러나 협업 편집은 오프라인 편집 사용 사례와 공통점이 많음.
    • 한 사용자가 문서를 편집할 때, 변경 내용을 즉시 로컬 복제 서버에 적용하고 나서 동일한 문서를 편집하는 다른 사용자와 서버에 비동기 방식으로 복제한다.
• 편집 충돌이 없으려면 사용자가 편집하기 전에 문서의 잠금을 얻어야 함.
  • 더 빠른 협업을 위해 변경 단위를 매우 작게해서 잠금을 피할 수 있음.
    • 이 방식을 통해 여러 사용자가 동시 편집을 할 수 있지만 충돌 해소가 필요한 경우를 포함해서 다중 리더 복제에서 발생하는 모든 문제를 야기함.