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

요약

• 분산 트랜잭션과 합의에 대한 내용을 이해함.
  • 분산 컴퓨팅에서 가장 중요하고 근본적인 문제임.
  • 노드간의 동의를 만드는 것임.
• 원자적 커밋과 2단계 커밋에 대한 내용을 이해함.
  • 단일 노드에서 원자적 커밋은 저장소 엔진에서 구현됨.
  • 다중 노드에서는 위 내용만으로 분산 트랜잭션을 안전하게 구현할 수 없음.
    • 2단계 커밋을 이용한다.
      • 모든 노드가 커밋되거나모든 노드가 어보트되도록 보장하는 알고리즘임.
      • 단점은 코디네이터가 죽으면, 복구될 때까지 기다려야함.
      • 블로킹 원자적 커밋 프로토콜이라고도 부름.
    • 3PC를 대안으로 제시하기도 하지만 신뢰성 있는 장애 감지기 역할을 하지 못함. (네트워크 지연, 프로세스 중단에 대한 제한이 깔려있기 때문)

메모

분산 트랜잭션과 합의

• 합의는 분산 컴퓨팅에서 가장 중요하고 근본적인 문제 중 하나임.
  • 비공식적으로, 합의의 목적은 여러 노드들이 뭔가에 동의하게 만드는 것임.
• 합의를 얘기하려면, 복제, 트랜잭션, 시스템 모델, 선형성과 전체 순서 브로드 캐스트에 대한 선행 지식이 필요함.
  • 이미 앞에서 다 다뤘다.
• 노드가 동의하는 것이 중요한 상황은 다음과 같다.
  • 리더 선출
  • 원자적 커밋
• 원자적 커밋을 해결하는 가장 흔한 방법은
  • 다양한 데이터베이스, 메시징 시스템, 애플리케이션 서버에서 구현된 2단계 커밋(2PC) 알고리즘을 다룸.

원자적 커밋과 2단계 커밋(2PC)

• 원자성은 실패한 트랜잭션이 절반만 완료된 결과나 절반만 갱신된 상태로 데이터베이스를 어지럽히는 것을 막아줌.
  • 다중 객체 트랜잭션과 보조 색인을 유지하는 데이터베이스에서 특히 중요함.
  • 개별 보조 색인은 주 데이터와 분리된 자료구조임.
    • 따라서 데이터를 변경하면 그에 해당하는 변경은 보조 색인에도 반영돼야 함.
    • 원자성은 보조 색인이 주 데이터와 일관성을 유지하도록 보장함.

단일 노드에서 분산 원자적 커밋으로

• 단일 데이터베이스 노드에서 실행되는 트랜잭션에게 원자성은 흔히 저장소 엔진에서 구현됨.
  • 클라이언트가 데이터베이스 노드에게 트랜잭션을 커밋하라고 요청할 때
    • 데이터베이스는 트랜잭션의 쓰기가 지속성 있게 하고
    • 그 후 디스크에 있는 로그에 커밋 레코드를 추가함.
      • 따라서 단일 노드에서 트랜잭션 커밋은 데이터가 디스크에 지속성 있게 쓰여지는 순서에 결정적으로 의존함.
        • 데이터가 먼저고 커밋 레코드는 그 다음임.
      • 트랜잭션이 커밋되거나 어보트되는지 결정하는 핵심적인 시점은 디스크가 커밋 레코드 쓰기를 마치는 시점임.
        • 이 시점 전에는 아직 어보트될 가능성이 있지만, 이 시점 후에는 트랜잭션이 커밋된 상태임.
      • 커밋을 원자적으로 만들어주는 것은 단일 장치임.
        • 특정한 하나의 노드에 부착된 하나의 특정 디스크 드라이브 컨트롤러로 볼 수 있음.
• 만약 트랜잭션 여러 노드가 관여한다면?
  • 대부분의 NoSQL 분산 데이터스토어는 이런 분산 트랜잭션을 지원하지 않지만, 다양한 클러스터 관계형 시스템은 지원함.
  • 이 경우, 단지 모든 노드에 커밋 요청을 보내고 각 노드에 독립적으로 트랜잭션을 커밋하는 것으로는 충분치 않음.
    • 어떤 노드에서는 커밋이 성공하고 다른 노드에서는 실패해서 원자성 보장을 위반하기 쉬움.
    • 노드는 트랜잭션에 참여하는 다른 모든 노드도 커밋될 것이라고 확신할 때만 커밋돼야 함.
  • 트랜잭션 커밋은 되돌릴 수 없어야 함.
    • 데이터가 커밋되면 다른 트랜잭션에게 보이게 되고, 다른 클라이언트들은 그 데이터에 의존하기 시작함.

커밋된 트랜잭션의 효과를 나중에 다른 보상 트랜잭션이 취소하는 것은 가능함. 그러나 데이터베이스 관점에서 이는 분리된 트랜잭션이므로 트랜잭션 사이에 걸친 정확성 요구사항은 애플리케이션의 문제임.

2단계 커밋 소개

• 2단계 커밋은 여러 노드에 걸친 원자적 트랜잭션 커밋을 달성하는, 즉 모든 노드가 커밋되거나모든 노드가 어보트되도록 보장하는 알고리즘임.
• 2PC 커밋/어보트 과정은 두 단계로 나뉨.
  • p353 참고
• 2PC는 단일 노드 트랜잭션에서는 보통 존재하지 않는 새로운 컴포넌트인 코디네이터(= coordinator, 트랜잭션 관리자라고도 함)를 사용함.
• 2PC 트랜잭션은 평상시처럼 애플리케이션이 여러 데이터베이스 노드에서 데이터를 읽고 쓰면서 시작함.
  • 이런 데이터베이스 노드를 트랜잭션의 참여자라고 부름
  • 애플리케이션이 커밋할 준비가 되면 코디네이터가 1단계를 시작함.
  • 각 노드에 준비 요청을 보내서 커밋할 수 있는지 물어봄.
  • 그 후 코디네이터는 참여자들의 응답을 추적함.
    • 모든 참여자가 커밋할 준비가 됐다는 뜻으로 “네”를 응답하면 코디네이터는 2단계에서 커밋 요청을 보내고, 실제로 커밋이 일어남.
    • 참여자 중 누구라도 “아니로”를 응답하면 코디네이터는 2단계에서 모든 노드에 어보트 요청을 보냄.

약속에 관한 시스템

• 2PC는 두 개의 중대한 “돌아갈 수 없는 지점”이 있음.
  • 참여자가 “네”에 투표할 때 나중에 분명히 커밋할 수 있을 거라고 약속함.
  • 코디네이터가 한 번 결정하면 그 결정을 변경할 수 없음.
    • 이러한 약속이 2PC의 원자성을 보장함.

코디네이터 장애

• 코디네이터가 죽으면 어떻게 되는가?
  • 코디네이터가 죽거나 이 시점에 네트워크에 장애가 나면 참여자는 기다릴 수밖에 없음.
  • 이 상태에 있는 참여자의 트랜잭션을 의심스럽다, 또는 불확실하다고 함.
    • 코디네이터에게 듣지 않고 참여자는 커밋할지 어보트할지 알 방법이 없음.
    • 이론상으로 참여자들끼리 통신해서 각 참여자가 어떻게 투표했는지 알아내서 어떤 것에 동의할 수 있음.
      • 하지만 이는 2PC의 프로토콜 일부가 아님.
    • 2PC가 완료할 수 있는 유일한 방법은 코디네이터가 복구되기를 기다리는 것 뿐임.

3단계 커밋

• 2단계 커밋은 2PC 가 코디네이터가 복구하기를 기다리느라 멈출 수 있다는 사실 때문에 블로킹 원자적 커밋 프로토콜이라고 불림.
• 2PC 대안으로 3단계 커밋(3PC) 알고리즘이 제안됨.
  • 하지만 이는 지연에 제한이 있는 네트워크 응답과 응답 시간에 제한이 있는 노드를 가정함.
  • 이렇게 기약 없는 네트워크 지연과 프로세스 중단이 있는 대부분의 실용적 시스템에서 3PC는 원자성을 보장하지 못함.
• 일반적으로 논블로킹 원자적 커밋은 완벽한 장애 감지기(perfect failure detector), 즉 노드가 죽었는지 아닌지 구별할 수 있는 신뢰성 있는 메커니즘이 필요함.
  • 그런데, 기약 없는 지연이 있는 네트워크에서 타임아웃은 신뢰성 있는 장애 감지기가 아님.
  • 따라서 코디네이터 장애와 관련된 알려진 문제가 있더라도 2PC가 계속 쓰임.