MSA 환경에서의 분산 트랜잭션

Two Phase Commit Protocol (2PC)

• 분산 트랜잭션을 다루는데 유명한 알고리즘. 트랜잭션을 제어하고 트랜잭션 로직을 포함하는 코디네이터가 있고, 로컬 트랜잭션을 수행하는 노드가 존재한다.
• Phase 1에서는 코디네이터가 각각의 노드에게 커밋 준비가 되었냐고 묻고 응답을 기다린다.
• Phase 2에서 모든 노드가 예로 응답하면 코디네이터는 모든 노드에 커밋하도록 지시하고, 그렇지 않으면 코디네이터는 모든 노드에 롤백하도록 지시한다.

단점

• 코디네이터에 이슈가 생기면 전체 서비스에 영향이 간다. -> single point of failure
• 가장 느린 서비스에 의해 전체 성능이 결정이 된다. 모든 서비스가 코디네이터에 응답을 보낼 때 까지 트랜잭션은 커밋될 수 없기 때문이다.
• NoSQL 환경에서 사용 불가능

Saga Architecture Pattern

• 로컬 트랜잭션을 통해 서비스 전체 트랜잭션을 관리하며, 이전 단계를 성공적으로 완료가 되면 다음 단계를 요청한다.
• 이 패턴를 구성하는 node의 작업은 로컬 트랜잭션으로 표현되고, 사가의 모든 작업은 보상 트랜잭션(Compensatory Transaction)에 의해 롤백될 수 있다.
• choreography, orchestration 2가지 방법으로 구현 가능

1. Saga Orchestration Pattern

• 마이크로 서비스의 트랜잭션이 Orchestrator에 의해 제어가 됨. Orchestrator가 모든 서비스의 이벤트를 청취하고 엔드포인트를 실행할 책임을 가지고 있음. 각각의 마이크로서비스는 이 Orchestrator에 의존한다.

Pros and Cons

• 장점
  • 트랜잭션 시라니오에 변화가 생겨도 Orchestrator만 변경하면 되기 때문에 유지보수에 용이하다.
  • Orchestrator가 모든 서비스와 통신하기 때문에 서비스 간의 순환 참조를 피할 수 있다.
• 단점
  • 어려운 구현
    • Orchestrator에 single point of failure을 생성해야 한다.
    • 또한 각각의 서비스에 대한 트랜잭션 로직을 구현하고 관리해야 한다.
  • Orchestrator가 추가되기 때문에 인프라 복잡성이 증가가 된다.

2. Saga Choreography Pattern

• 각각의 서비스에서 자신의 로컬 트랜잭션을 관리하며, 트랜잭션이 완료가 되었으면 완료 이벤트를 발생시켜 이를 다음 서비스에 전달시켜 트랜잭션을 처리하는 방식으로 구현.

Pros and Cons

• 장점
  • Orchestration-based 보다 성능상 이점이 있다.
  • 구현하기 쉽다.
  • 개념에 대해 이해하기 쉽다.
• 단점
  • 트랜잭션 시나리오가 점점 많아질 수록 관리가 힘들다.
  • 어떤 서비스가 어떤 이벤트를 수신하는지 확인하기 어려움. 또한 모든 서비스는 호출되는 각 서비스의 이벤트를 가지고 있어야 한다.

Reference

https://medium.com/codex/how-to-use-saga-pattern-with-spring-boot-67c3428810f1