원자성 보장의 어려움
원자성을 보장하는 것은 분산 시스템 뿐만 아니라 일반적으로 어려운 작업이다. 구성요소가 소프트워에의 구성요소인지 하드웨어의 구성요소인지 관계없이 구성요소가 예기치 않게 실패할 수 있기 때문이다.
원자성을 달성하는 일반적인 방법은 저널링(journalling) 또는 미리 쓰기(write-ahead logging) 방법이 있다.
분산 시스템에서의 원자성 문제는 구성요소가 느리고 신뢰할 수 없는 네트워크로 분리되어 있기 때문에 더욱 복작해진다. 분산 시스템에서의 원자성은 작업이 모든 노드에 대하여 적용되거나 적용되지 않아야 함을 의미한다. 이러한 문제를 원자적 커밋(Atomic commit) 이라고 부른다.
2단계 커밋(2PC)
2단계 커밋 프로토콜은 두가지 단계로 구성되며, 아래와 같은 두가지 다른역할이 포함되어 있다.
- 역할
- 코디네이터는 프로토콜의 여러 단계를 조정하는 역할을 담당
- 참가자는 트랜잭션에 참여하는 모든 노드에 해담
- 참가자중 한명이 코디네이터 역할을 맞을 수 있음
투표 단계
이 단계에서 코디네이터는 모든 참가자에게 트랜잭션을 보낸다. 참가자는 커밋해야 하는 지점까지 트랜잭션을 실행한다.
이후 참가자는 태랜잭션 작업이 성공저으로 실행되었는지, 또는 트랜잭션을 커밋할 수 없는 오류 상태인지를 나타내는 투표로 코디네이터에게 응답한다.
커밋 단게
이 단계에서 코디네이터는 참가자로부터 모든 표를 수집한다. 모든 투표가 “예” 이면 코디네이터는 참가자에게 트랜잭션을 커밋하라는 메시지를 다시 보낸다.
그렇지 않고, 적어도 한 표가 “아니오” 이면 코디네이터는 참가자에게 트랜잭션을 중단하도록 지시한다. 마지막으로 참가자는 승인으로 응답하고 이 단계를 끝낸다.
커밋에 만장일치의 긍정적 투표가 필요하다는 사실은 트랜잭션이 모든 참가자에게 커밋되거나 모든 참가자에 대해 중단된다는 것을 의미한다. (원자성)
코디네이터와 참가자는 오류 발생 시 복구할 수 있도록 다양한 단계에서 결정을 유지하는 미리 쓰기 로그(write-ahead logging)를 사용한다.
코디네이터는 첫 번째 단계의 응답을 기다릴 때도 시간 제한을 사용한다. 시간 초과가 만료되면 코디네이터는 이 시간 초과를 투표 없음으로 해석하고 노드가 실패한 것으로 간주한다.
반면에 참가자는 코디네이터의 메시지를 기다리는 동안 시간 초과를 적용하지 않는다. 이는 타이밍 문제로 인해 참가자가 다른 결론에 도달할 수 있기 때문이다.
2단계 커밋 프로토콜의 차단 특성
프로토콜의 차단 특성으로 인해 프로토콜의 특정 단계에서 코디네이터가 실패하면 전체 시스템이 중단될 수 있다. 코디네이터가 준비된 메시지를 참가자에게 보낸 후 실패하면 참가자는 차단되게 된다. 이후 참가자는 코디네이터가 트랜잭션의 결과를 복구하고 알아낼 때까지 기다리며 필요에 따라 트랜잭션을 커밋하거나 중단한다.
이는 코디네이터의 장애로 인해 시스템의 가용성이 크게 저하될 수 있음을 의미한다. 또한 코디네이터가 복구될수 없다면 보류중인 트랜잭션의 결과를 검색할수 없기 때문에 차단된 작업을 해제하기 위해 수동 개입이 필요해 진다.
3단계 커밋(3PC)
2단계 커밋 프로토콜의 주요 병목 현상은 시스템을 차단 상태로 이끄는 코디네이터의 실패이다. 이러한 2단계 커밋 문제는 첫 번째 라운드(투표 단계)를 2개의 하위 라운드로 분할하여 해결할 수 있다.
코디네이터는 먼저 투표 결과를 노드에 전달하고 승인을 기다린 다음 커밋 또는 중단 메시지를 진행한다. 이 경우 참가자는 투표 결과를 알고 코디네이터가 실패할 경우 독립적으로 프로토콜을 완료한다.
이 3PC 프로토콜의 주요 장점은 코디네이터가 단일 실패 지점이 되지 않는다는 점이다. 코디네이터가 실패할 경우 참가자는 프로토콜을 인계받아 완료할 수 있다.
인계받는 참가자는 모든 참가자가 “예”로 투표했음을 알고 커밋 준비를 수신하면 트랜잭션을 커밋할 수 있다. 커밋 준비 메시지를 받지 못한 경우 모든 참가자가 커밋 준비 메시지를 먼저 받지 않고 커밋한 참가자가 없다는 사실을 알고 트랜잭션을 중단할 수 있다.
결과적으로 3PC 프로토콜은 가용성을 높이고 코디네이터가 단일 실패 지점이 되는 것을 방지한다.
Quorum-Based Commit
3PC 프로토콜의 주요 문제는 두 번째 단계가 끝날 때 발생한다. 두 번째 단계에서는 잠재적인 네트워크 분할로 인해 시스템이 일관되지 않은 상태로 이어질 수 있다.
3PC의 위와같은 문제를 해결하기 위해 쿼럼 개념을 활용하여 파티션의 서로 다른 측면이 충돌하는 결과에 도달하지 않도록 한다.
먼저 아래와 같은 기본 개념을 설정한다.
- 총 참가자($V$)
- 중단 정족수($V_a$)
- 커밋 쿼럼($V_c$)
그리고 위와 같은 개념에 대하여 다음 속성이 유지되도록 중단 및 커밋 쿼럼 값을 선택한다.
$V_a + V_c > V$
위 개념을 유지한채로, 쿼럼 기반 커밋 프로토콜은 다양한 경우에 사용되는 세가지 하위 프로토콜들로 구성된다.
- 새로운 트랜잭션이 시작될 때 사용되는 커밋 프로토콜
- 네트워크 파티션이 있을 때 사용되는 종료 프로토콜
- 시스템 이 네트워크 파티션에서 복구될 때 사용되는 병합 프로토콜
커밋 프로토콜
이 프로토콜은 3PC 프로토콜과 매우 유사하다. 유일한 차이점은 코디네이터가 대기한다는 것입니다.
이 단계에서 커밋 쿼럼($V_c$)의 값은 트랜잭션 커밋을 진행하기 위한 세 번째 단계가 끝날 때의 승인 횟수이다.
이 단계에서 네트워크 파티션이 있으면 코디네이터가 트랜잭션을 완료하지 못할 수 있다. 이 경우 파티션 양쪽의 참가자는 다음 프로토콜을 사용하여 트랜잭션을 완료할 수 있는지 여부를 조사한다.
종료 프로토콜
처음에는 리더 선출을 통해 참가자 중에서 대리 코디네이터가 선택된다.
선출된 코디네이터는 파티션의 노드에서 상태를 쿼리한다. 이때 커밋(또는 중단)한 참가자가 적어도 한 명 이상 있으면 코디네이터는 원자성 속성을 유지하면서 트랜잭션을 커밋(또는 중단)한다.
커밋 준비 상태인 참가자가 한 명 이상 있고, 중단 정족수($V_a$)의 값 이상의 투표 결과를 기다리는 참가자가 있으면 코디네이터 는 참가자에게 준비 완료 메시지를 보내고 다음 단계로 진행한다. 또는 커밋 준비 상태에 참가자가 없고, 중단 정족수($V_a$)의 값 이상의 결과 투표를 기다리는 참가자가 있으면 코디네이터는 중단 준비 메시지를 보냅니다.
종료 프로토콜의 마지막 단계는 승인을 기다리고 커밋 프로토콜과 유사한 방식으로 트랜잭션을 완료하려고 시도한다.
병합 프로토콜
여기에는 병합된 두 파티션의 리더 간의 리더 선택과 우리가 설명한 종료 프로토콜의 실행이 포함된다.
참고