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

요약

  • 일관성과 합의에 대한 내용을 정리함.
  • 파트 3, 파생 데이터에 대한 내용을 이해함.
    • 데이터 저장 시스템은 크게 두분류로 나뉨.
      • 레코드 시스템
      • 파생 데이터 시스템
    • 위 시스템을 구분하면 시스템 전체 데이터플로가 명확해짐.

메모

정리

  • 일관성과 합의에 관한 주제들을 여러 다양한 각도에서 살펴봄.
  • 인기있는 일관성 모델인 선형성을 깊게 알아봄.
    • 선형성은 이해하기 쉬우므로 매력적이지만 느리다는 단점이 있음.
  • 시스템에 발생한 이벤트에 순서를 부과하는 인과성을 살펴봄.
    • 모든 연산을 하나의 전체 순서가 정해진 타임라인에 넣는 선형성과 달리, 인과성은 더 약한 일관성 모델을 제공함.
    • 인과적 일관성은 선형성의 코디네이션 오버헤드가 없고 네트워크 문제에 훨씬 덜 민감함.
  • 위와 같은 인과적 순서를 담아내더라도 어떤 것들은 이 방법으로 구현할 수 없음.
    • ex) 유일한 사용자명 등록시, 동시 등록을 못하게 거부하는 보장을 해야함.
    • 이를 위해, 한 노드가 등록을 받아들이려면 다른 노드가 동시에 동일한 사용자명을 등록하는 과정에 있지 않다는 것을 어떤 식으로든 알아야함.
    → 이 문제는 우리를 합의로 이끈다.
  • 합의를 달성하는 것은 결정된 것에 모든 노드가 동의하고 결정을 되돌릴 수 없는 방식으로 뭔가를 결정함.
    • 광범위한 문제가 실제로 합의로 환원될 수있고, 이 문제는 서로 동일함.
      • ex) 선형성 레지스터
      • 원자적 트랜잭션 커밋
      • 전체 순서 브로드캐스트
      • 잠금과 임차권
      • 멤버십/코디네이션 서비스
      • 유일성 제약 조건
      • p371 참고
    • 이 모든 것들은 노드가 하나만 있거나 결정하는 능력을 한 노드에만 준다고 하면 간단함.
    • 하지만, 단일 리더가 장애가 나면 이 시스템은 아무것도 하지 못한다.
    • 이 상황을 처리하는 세가지 방법이 있음.
      1. 리더가 복구될 때까지 기다리고 시스템이 그동안 차단되는 것을 받아들인다.
      2. 사람이 새 리더 노드를 선택하고 시스템이 그 노드를 사용하도록 재설정해서 수동으로 장애 복구함.
      3. 자동으로 새 리더를 선택하는 알고리즘을 사용함.
  • 주키퍼 같은 도구는 애플리케이션이 사용할 수 있는 합의, 장애 감지, 멤버십 서비스를 “위탁”하는데 중요한 역할을 수행함.
    • 합의로 환원될 수 있는 문제 중 하나를 원하고, 그것이 내결함성을 지니기를 원한다면 주키퍼 같은 것을 쓰는게 현명함.
  • 그러나, 모든 시스템이 반드시 합의가 필요한 건 아님.
    • ex) 리더 없는 복제 시스템, 다중 리더 복제 시스템 → 전역 합의를 사용하지 않음.
    • 그냥, 선형성 없이 대처하고, 가지치기와 합치기의 버전 기록이 있는 데이터를 잘 처리하는 법을 배울 필요가 있음.

Part 3. 파생 데이터

  • 데이터 시스템은 단일 데이터베이스 보다 종종 더 복잡하다.
    • 큰 애플리케이션에서는 데이터를 접근하고 처리하는 데 다양한 방법이 필요함.
    • 하지만, 동시에 다른 모든 요구사항을 만족하는 하나의 데이터베이스는 없음.
      • 그래서 애플리케이션은 대개 여러 다른 데이터스토어, 색인, 캐시, 분석 시스템 등 몇 가지를 조합해서 사용하고, 한 저장소에서 다른 저장소로 데이터를 이동하는 메커니즘을 구현함.
  • 3부에서는 데이터 모델도 다르고 최적화된 접근 양식도 다른 여러 데이터 시스템을, 일관성 있는 하나의 애플리케이션 아키텍처로 통합하는 문제에 대해 검토한다.
    • 실제로 복잡한 시스템에서 수행해야 하는 가장 중요한 일 중 하나가 서로 다른 시스템을 통합하는 작업임.

레코드 시스템과 파생 데이터 시스템

  • 데이터를 저장하고 처리하는 시스템은 크게 두 분류로 나눌 수 있음.
    • 레코드 시스템
      • 진실의 근원이라고 함.
      • 믿을 수 있는 데이터 버전을 저장함.
      • 사용자 입력과 같은 새로운 데이터가 들어오면 먼저 레코드 시스템에 저장함.
      • 각 사실은 일반적으로 정규화를 거쳐 정확하게 한번 표현됨.
    • 파생 데이터 시스템
      • 다른 시스템에 존재하는 데이터를 가져와 특정 방식으로 변환하고 처리한 결과임.
      • 파생 데이터를 잃더라도 원천 데이터로부터 다시 생성할 수 있음.
      • ex) 캐시 → 필요한 데이터가 캐시에 있다면 캐시에서 제공하고, 그렇지 않다면 기반 데이터베이스를 거쳐 제공할 수 있음.
  • 엄밀히 말하면 파생 데이터는 기존 데이터를 복제한다는 의미에서 중복(redundant) 임.
    • 하지만 파생 데이터는 읽기 질의 성능을 높이는데 종종 필수적임.
    • 파생 데이터는 대개 비정규화 과정을 통해 생성함.
    • 단일 원천 데이터로 여러 데이터셋을 추출해서 각 데이터셋마다 서로 다른 “관점”에서 데이터를 봄.
  • 아키텍처상 모든 시스템이 이 데이터 시스템을 구분하는 건 아니지만, 구분해놓으면 시스템 전체 데이터플로가 명확해짐.
  • 레코드 시스템과 파생 데이터 시스템은 도구에 의해 구분되지 않고 애플리케이션에서 어떻게 사용할지에 따라 결정됨.
    • 데이터베이스는 도구일 뿐임.
  • 시스템 아키텍처를 망치지 않고 명료성을 갖추려면 데이터가 어떤 데이터로부터 파생됐는지를 명확하게 해야함.
    • 3부 전반에 걸쳐 다룰 주제임.

3부 개요

  • 10장
    • 맵리듀스와 같은 일괄 처리 방식 데이터플로 시스템을 살펴본다.
      • 관련 좋은 도구가 어떤 것이 있는지 살펴본다.
      • 대규모 데이터 시스템 구축하기 위한 원리가 무엇인지 알아본다.
  • 11장
    • 10장과 동일한 아이디어를 데이터 스트림에 적용해 본다.
      • 이 방식은 낮은 지연으로 일괄 처리와 동일한 작업을 수행할 수 있음.
  • 12장
    • 책의 결론을 짓는다.
      • 미래에 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션을 구축하기 위해 앞서 언급한 도구들을 어떻게 사용해야 하는지에 대한 아이디어를 모색한다.

댓글

Designed by JB FACTORY