분산 트랜잭션
2PC 패턴
분산 트랜잭션을 관리하는 주체인 코디네이터를 두고, 준비(prepare), 커밋(commit)의 2단계를 거치는 패턴이다.
준비(prepare)
분산 트랜잭션에 참여하는 각 참여자(멤버 트랜잭션)에게 커밋할 준비가 되었는지 확인하는 단계다. 이 시점에 멤버 트랜잭션이 관여하는 행이나 테이블에 락이 걸린다.
각 멤버 트랜잭션은 커밋할 수 없는 상태인 경우 커밋할 수 없다는 응답(abort)을 코디네이터에게 응답하고, 커밋이 가능한 경우 가능하다는 응답(prepared)을 한다.
중요한 점은 멤버 트랜잭션의 커밋 가능 여부를 응답하는 것이지, 이 시점에 커밋이나 롤백이 진행되지 않는다는 것이다.
커밋(commit)
코디네이터가 모든 참여자에게 응답을 받았다면, 그 결과에 따라 커밋이나 롤백을 결정한다. 멤버 트랜잭션 중 하나라도 abort 응답을 했다면 롤백을 진행한다.
각 멤버 트랜잭션이 동시에 커밋이나 롤백이 되는 것이 아니라 시간 차이가 존재하게 된다. 그리고, 각 멤버 트랜잭션은 그 결과가 결정될 때 까지 락을 보유하고 있다.
한번 분산 트랜잭션의 커밋 여부가 결정된다면, 이는 그 어떤 경우에도 번복되지 않는다. 만약, 각 노드가 응답이 없다면 응답 할 때 까지 재요청을 무한히 수행한다.
단점
1.
각 멤버 트랜잭션이 오랫동안 락을 보유한다. ⇒ 지연 시간이 증가할 수 있다.
2.
NoSQL 등은 2PC 패턴을 지원하지 않는다.
Saga 패턴
모든 멤버 트랜잭션을 관리하는 것 대신, 순차적으로 멤버 트랜잭션을 처리하는 방법이다. 만약, 롤백이 필요한 경우 롤백한 것과 동일한 효능을 가지는 보상 트랜잭션을 수행하는 방법이다.
보상 트랜잭션을 쉽게 설명하면, 게시글 생성의 보상 트랜잭션은 게시글 삭제이고, 결제의 보상 트랜잭션은 환불이다.
Saga 패턴은 마이크로 서비스들이 이벤트 기반 통신을 할 때 적절한 방법이다. 중간에 관리자를 두는지 여부에 따라 Choreographed Saga와 Orchestrated Saga로 나뉜다.
Saga 패턴은 ACID 속성 중 Isolation(격리성)을 보장하지 않는다. 각 로컬 트랜잭션이 실제 데이터베이스에 반영되었다가 이후에 보상 트랜잭션에 의해 롤백될 수 있기 때문이다. 따라서, 이를 위한 추가 설계가 필요하다.
Choreographed Saga
각 마이크로 서비스가 직접 보상 트랜잭션을 관리하는 구현
두개의 마이크로 서비스를 순차적으로 한번씩 사용하는 요청을 처리하는 상황을 생각해 보자. 두 마이크로 서비스는 아래와 같이 동작한다.
첫 번째 마이크로 서비스:
•
발급 이벤트: 작업 성공 시 성공 이벤트 발급
•
구독 이벤트: 롤백 이벤트
•
이벤트 인식 후 동작: 롤백 이벤트 인식 시 보상 트랜잭션 수행하여 상태를 원래대로 복원
두 번째 마이크로 서비스:
•
발급 이벤트: 롤백 발생 시 롤백 이벤트 발급
•
구독 이벤트: 첫 번째 마이크로 서비스의 성공 이벤트
•
이벤트 인식 후 동작: 첫 번째 마이크로 서비스의 성공 이벤트 인식 시 작업 수행
이러한 방식으로 마이크로 서비스들은 서로 이벤트를 주고받으며 분산 트랜잭션을 순차적으로 처리하고, 필요 시 롤백을 수행한다.
이 방식은 각 마이크로 서비스가 다른 서비스가 발급하는 이벤트를 직접 구독하고 있어야 한다. 즉, 마이크로 서비스 사이에 의존성이 발생한다. 참가자가 많아질 경우 구조가 복잡해질 수 있다.
Orchestrated Saga
중앙의 오케스트레이터가 전체 트랜잭션 흐름을 조정하는 구현
오케스트레이터와 두 개의 마이크로 서비스가 상호작용하는 상황을 살펴보자. 각 구성요소는 다음과 같이 동작한다.
오케스트레이터:
•
전체 트랜잭션 흐름 관리 및 각 마이크로 서비스에 명령 전달
•
각 단계의 성공/실패 여부 추적
•
실패 시 보상 트랜잭션 명령 발행
마이크로 서비스 (공통):
•
수신 이벤트: 오케스트레이터로부터의 작업 수행 명령
•
발급 이벤트: 작업 성공/실패 결과
•
이벤트 인식 후 동작: 오케스트레이터의 보상 트랜잭션 명령 수신 시 롤백 수행
이 방식에서는 오케스트레이터가 중앙에서 전체 트랜잭션의 상태를 관리하고, 각 마이크로 서비스는 자신의 작업만 수행하며 결과를 보고한다. 오케스트레이터는 이를 바탕으로 전체 트랜잭션의 성공 여부를 판단하고 필요시 롤백을 지시한다.
이 방식은 각 마이크로 서비스 사이의 의존성이 없고, 마이크로 서비스가 많아지더라도 트랜잭션 흐름이 복잡해지지 않는 장점이 있다. 하지만, 오케스트레이터가 중앙 집중적으로 처리하는 구조인 만큼 오케스트레이터가 SPOF가 될 수 있다.
