분산 시스템에서 2PC ( 2-Phase-Commit) 해결책과 한계

분산 시스템에서 2PC와 일관성 보장: 해결책과 한계

 

분산 시스템에서는 여러 노드가 협력하여 작업을 수행한다. 이러한 시스템에서 트랜잭션의 일관성을 보장하는 것은 매우 중요하다. 이를 위해 다양한 방법이 사용되는데, 그 중 하나가 2PC(2-Phase Commit) 프로토콜이다. 2PC는 분산 트랜잭션의 일관성을 보장하지만, 단점도 존재한다. 

 

2PC(2-Phase Commit) 프로토콜

2PC의 원리

2PC는 두 단계로 구성된다: 준비 단계(Prepare Phase)와 커밋 단계(Commit Phase)이다.

1. 준비 단계 (Prepare Phase): 코디네이터는 모든 참가자에게 트랜잭션을 준비할 수 있는지 요청한다. 각 참가자는 준비가 되었는지 여부를 코디네이터에게 응답한다. 모든 참가자가 준비 상태임을 응답하면 다음 단계로 넘어간다.
2. 커밋 단계 (Commit Phase): 모든 참가자가 준비되었다고 응답하면, 코디네이터는 각 참가자에게 트랜잭션을 커밋하도록 지시한다. 만약 어떤 참가자가 준비되지 않았다고 응답하면, 코디네이터는 트랜잭션을 중단하고 모든 참가자에게 롤백을 지시한다.

2PC의 문제점

2PC는 트랜잭션의 일관성을 보장하지만, 몇 가지 단점이 있다:

• 코디네이터 장애: 코디네이터가 장애가 발생하면 트랜잭션 전체가 중단될 수 있다.
• 지연: 각 단계에서 모든 참가자의 응답을 기다려야 하므로 지연이 발생할 수 있다.
• 복잡성: 트랜잭션이 중단될 경우 이를 복구하는 과정이 복잡하다.

2PC 문제 해결책

2PC의 문제를 해결하기 위해 두 가지 주요 접근 방식이 있다: 로그 기반 복구와 분산 코디네이터를 사용하는 방식이다.

로그 기반 복구

로그 기반 복구는 코디네이터가 트랜잭션의 각 단계마다 로그를 기록하여, 장애 발생 시 이를 기반으로 복구하는 방법이다.

1. 로그 기록: 코디네이터는 Prepare 요청, Prepared 상태, Commit 요청, Commit/Abort 상태를 로그에 기록한다.
2. 장애 복구: 코디네이터가 다시 시작되면, 마지막으로 기록된 로그 상태를 확인하고 그에 따라 복구를 진행한다.

이 방법은 상대적으로 간단하지만, 로그가 손상되거나 일관성이 깨질 경우 복구가 어려울 수 있다. 또한, 복구 시간 동안 트랜잭션이 지연될 수 있다.

분산 코디네이터

분산 코디네이터는 여러 코디네이터를 두어 하나의 코디네이터에 장애가 발생하더라도 다른 코디네이터가 이어서 작업을 수행할 수 있게 하는 방법이다.

1. 상태 동기화: 각 코디네이터는 주기적으로 서로의 상태를 공유하고 동기화한다.
2. 리더 선출: 장애가 발생했을 때 새로운 코디네이터가 주도권을 잡고 트랜잭션을 이어받는다.
3. 상태 복구: 새로운 코디네이터가 이전 코디네이터의 상태를 기반으로 트랜잭션을 이어받아 처리한다.

이 방법은 시스템의 신뢰성을 높일 수 있지만, 상태 동기화와 리더 선출 과정에서 추가적인 복잡성과 오버헤드가 발생할 수 있다.

해결책의 한계

두 가지 해결책 모두 완벽하지 않은 이유는 다음과 같다:

로그 기반 복구의 한계

• 복구 시간: 코디네이터가 장애에서 복구되기까지 시간이 걸릴 수 있다.
• 로그 손상: 로그 파일이 손상되거나 일관성이 깨지면 복구가 어려울 수 있다.
• 부분 실패 처리: 모든 노드가 일관되게 준비 상태를 유지하지 않으면 복구가 어려울 수 있다.

분산 코디네이터의 한계

• 상태 동기화: 여러 코디네이터 간의 상태를 동기화하는 것은 복잡하고, 네트워크 지연이나 통신 오류가 발생할 수 있다.
• 리더 선출: 새로운 리더를 선출하는 과정에서 경쟁 상태나 추가적인 지연이 발생할 수 있다.
• 추가 오버헤드: 상태 동기화와 리더 선출 등 추가적인 로직이 시스템에 오버헤드를 초래할 수 있다.

 

분산 시스템에서 트랜잭션의 일관성을 보장하기 위한 2PC 프로토콜은 강력한 도구이지만, 코디네이터 장애와 같은 단점을 가지고 있다. 이를 보완하기 위해 로그 기반 복구와 분산 코디네이터 같은 해결책이 존재하지만, 이들 역시 완벽하지 않다. 분산 시스템 설계는 항상 일관성, 가용성, 성능 간의 균형을 맞추는 과정이다. 각 시스템의 요구사항과 환경에 맞는 최적의 해결책을 찾는 것이 중요하다.

 

 

3PC?

3PC는 다음과 같은 개선점을 제공:

1. PreCommit 단계: 이 단계는 트랜잭션을 실제로 커밋하기 전에 참가자들이 준비 상태로 전환되게 한다. 이를 통해 참가자들이 트랜잭션을 커밋할 준비가 되었는지 확실히 확인할 수 있다.
2. 타임아웃 설정: 각 단계에서 타임아웃을 설정하여, 코디네이터가 응답하지 않으면 참가자들이 독립적으로 롤백을 수행할 수 있게 한다. 이는 코디네이터 장애 상황에서도 시스템이 중단되지 않도록 도와준다.
3. 네트워크 분할 대응: 네트워크 분할 상황에서도 참가자들이 커밋 또는 롤백 결정을 독립적으로 내릴 수 있게 설계되어 있다. 이는 2PC에 비해 더 높은 신뢰성을 제공한다.

여전히 남아있는 문제

3PC가 여러 가지 개선을 제공하지만, 몇 가지 한계가 있다.

1. 코디네이터 장애: 코디네이터가 장애가 발생하면 여전히 문제가 발생할 수 있. PreCommit 단계에서 타임아웃을 통해 일부 해결되지만, 코디네이터의 복구 과정이 복잡할 수 있다.
2. 네트워크 문제: 네트워크 분할 상황에서도 모든 노드가 동기화되지 않으면 여전히 일관성 문제가 발생할 수 있. 특히 네트워크가 완전히 분할되는 극단적인 상황에서는 완벽한 해결이 어려울 수 있다.
3. 복잡성 증가: 3PC는 추가적인 단계를 포함하여 구현과 관리의 복잡성이 증가한다. 이는 시스템의 오버헤드를 증가시킬 수 있다.

 

참고:

책: 데이터 중심 어플리케이션 설계