Recommanded Free YOUTUBE Lecture: <% selectedImage[1] %>

Contents

2단계 커밋 프로토콜

트랜잭션 처리와, 데이터베이스 컴퓨터 네트워킹에서 정보가 성공적으로 수정되었음을 확인하기 위해서 사용하는 ACP(원자적 커밋 프로토콜)이다. 트랜잭션 성공과 실패(롤백)을 확인하고, 이러한 작업들이 원자적으로 이루어질 수 있도록 조정하는 분산 알고리즘을 제공한다.

개요

프로토콜의 작동방식은 다음과 같다. 먼저 네트워크 상에서 하나의 노드가 코디네이터(coordinator, 이하 트랜젹선 관리자)로 지명되고, 나머지 노드들은 cohorts로 지정된다.

트랜잭션 관리자는 모든 cohorts에 대해서 작업 준비(prepare)가 됐는지 확인한다. 모든 cohorts의 작업준비가 끝났다면, 작업을 반영(commit)한다. 하나의 cohorts라도 작업준비가 끝나지 않았다면, 작업은 실패한다. All or nothing 인 셈이다.

작업 요청 단계와 반영 단계 2단계로 구분되기 때문에, 2단계 커밋 프로토콜이라고 한다.

Commit request phase

  1. 트랜잭션 관리자는 모든 cohorts에게 query to commit 메시지를 전송하고, 응답이 끝나기를 기다린다.
  2. Cohorts는 트랜잭션을 지점을 설정하고 commit 준비를 한다. 실패하는 cohorts가 발생할 경우 실행취소를 해야 하기 때문에, redo log와 undo log를 준비한다.
  3. 각 cohort들은 agreement메시지를 전송한다. 작업준비를 성공했다면 Yes를 실패했다면 No를 전송한다.

Commit phase

성공

모든 cohorts로 부터 agreement메시지를 받았다면
  1. 트랜잭션 관리자는 모든 cohorts에 commit 메시지를 전송한다.
  2. 각 cohort는 그들의 작업을 마무리 하고, 리소스에 대한 잠금을 푼다.
  3. 각 cohort는 트랜잭션 관리자에게 acknowledgment를 전송한다.
  4. 모든 cohort로 부터 acknowledgment 메시지를 받으면, 작업을 완료한다.

실패

Commit request phase단계에서 하나 이상의 cohort가 No를 응답하거나, 응답시간을 초과할 경우
  1. 트랜잭선 관리자는 모든 cohort들에게 rollback메시지를 전송한다.
  2. 각 cohort는 undo log를 이용해서 원래 상태로 복구한다. 잠근 자원이 있다면, 해제한다.
  3. 각 cohort는 트랜잭션 관리자에게 acknowledgement를 전송한다.
  4. 모든 cohort로 부터 acknowledgement 메시지를 받으면 트랜잭션을 복구한다.

단점

2단계 커밋 프로토콜의 가장 큰 단점은 블럭킹(blocking) 프로토콜이라는 점이다. 만약 트랜잭션 관리자가 영구적으로 실패하면, 트랜잭션을 영원히 해결하지 못하는 cohort들이 생길 수 있다.

구현

일반적인 아키텍처

2PC 프로토콜은 분산 컴퓨터 네트워크 시스템에서 주로 사용한다. 보통은 트랜잭션의 과정을 모니터링 하는 트랜잭션 메니저(Tranasction manager)라는 별도의 컴퓨터 시스템을 구성한다.

실례

은행 간 이체

철수가 우리은행 계좌에서, 영희의 너희은행 계좌로 100원을 이체하려고 한다. 이체는 하나 이상의 작업으로 진행된다.
  1. 철수가 우리은행 계좌에서 100원을 인출한다.
  2. 인출한 돈을 너희은행의 영희 계좌로 입금한다.
이들 작업은 서로에 독립적이다. 예를들어 철수가 100원을 인출하는 걸 생공했다고 해도, 영희 계좌로의 입금이 성공하리라는 건 예상 할 수 없다. 영희 계좌가 사라졌을 수도 있고, 계좌 번호를 잘못 입력했을 수도 있다. 너희은행의 전산시스템에 장애가 발생 할 수도 있다.

두번째 작업이 실패할 경우 최초의 상태로 되돌려야 하는 번거로운 작업을 해야 한다. 이 경우 인출한 돈을 다시 원래 계좌로 입금을 해야 한다.

그렇다면 실제 인출/입금 작업을 하기 전에, 우리은행 계좌와 너희은행의 영희계좌가 준비된 걸 먼저 확인 한후 이체를 프로세스를 타게하면, 문제를 쉽게 해결 할 수 있을 것이다. 만약 하나라도 준비가 돼 있지 않다면, 아예 인출이 되지 않으니 상태 복구와 같은 번거로운 작업이 필요없다.

항상 2단계 커밋이 필요한 건 아니다

2단계 커밋 프로토콜이 필요한 이유는 "일단 정보가 반영되고 나면 되돌리기가 어렵기 때문"이다. 신용이 중요한 은행같은 경우에는 반드시 필요한 프로토콜이라고 할 수 있다.

하지만 모든 경우에 필요한 프로토콜은 아니다. 기기를 제어하는 메시징 서비스가 있다고 가정해보자.(IoT 서비스 쯤이 되겠다.) 2단계 커밋을 사용한다면,
  1. 메시지를 보낼 준비가 됐는지
  2. 목적지에 있는 기기가 메시지를 받을 준비가 됐는지
를 확인 한 후 메시지를 전송해야 한다. 이는 시스템의 구성을 굉장히 복잡하게 한다. 아마도 아래의 과정을 거쳐야 할 것이다.
  1. 메시지를 수신할 디바이스를 식별 한다.
  2. 디바이스가 연결상태인지 서버에 묻는다.
  3. 디바이스가 연결 상태라면, 응답가능 한 상태인지 PING 메시지를 전송한다.
  4. PING 메시지를 수신하면, 메시지를 전송한다.
이 경우에는 그냥 메시지를 보내고, 실패하면 실패 응답 메시지를 받는 식으로 구성하는게 훨씬 깔끔하고 효율적이다. 복구는 클라이언트에 맡기면 된다.

이와 관련된 내용은 스타벅스는 2단계 커밋을 사용하지 않는다 문서를 참고하자.

참고