SAGA 패턴

• SAGA 패턴에서는 연속된 개별 로컬 트랜잭션이 이어져, 전체 트랜잭션을 구성한다.
• 각 작업이 독립적으로 커밋되고, 중간에 오류가 발생하면 보상 작업을 통해 롤백하는 과정으로 이루어진다.
  • 이때, 각 트랜잭션이 연속적으로 이루어지기에 무용담(saga)라는 이름이 붙었다고 한다.
• 보상 트랜잭션은 어떠한 서비스에서 트랜잭션 처리에 실패할 경우 이전의 작업을 롤백하여 전체 트랜잭션의 정합성을 보장한다.
• 가장 중요한 점은 보상 트랜잭션 을 발생시키는 주체가 애플리케이션이기에 데이터 일관성을 관리하는 주체가 DBMS가 아니라는 것이다.
  • 보상 트랜잭션이 적용되기 전까지 일시적으로 데이터 정합성이 깨질 수 있으나, 결과적 정합성을 보장하게 된다.

---

Choreography-based Saga

• 간단히 말하자면, 각 로컬 트랜잭션이 다른 서비스의 로컬 트랜잭션을 트리거 하는 방식이다.
  • 중앙 집중된 어떠한 지점이 존재하지 않고 서로 이벤트를 교환하며, 모든 서비스가 메시지 브로커를 통해 Pub/Sub하는 방식이다.
• 각 서비스가 트랜잭션이 완료되면, 완료 이벤트를 발행한다. 그리고 다음 수행해야할 트랜잭션이 있다면, 해당 이벤트를 구독하고 있던 다른 App이 Event를 받고 다음 작업을 실행한다.
  • 보통 이벤트 브로커는 Message Queue를 사용
• 중간에 트랜잭션이 실패하면, 이에 대한 보상 트랜잭션 이벤트를 발생하여 롤백을 시도한다.
  • 이 패턴에서는 각 App 별로 트랜잭션을 관리하는 로직이 존재하기에, 중간에 트랜잭션이 실패한다면 보상 Event를 각 앱에서 발생해서 Rollback을 시도한다.

장점

• 참가자 수가 적고, 복잡하지 않은 워크플로우에 적합하다고 한다. (각각 참여자가 이벤트에 관여하기에 그럴 것 같다.)
• 별도의 중앙 조정자 없기에, 단일 장애 지점이 없다.

단점

• 서비스가 서로 명령을 소비하면서 순환 의존성이 발생할 위험이 있다.

---

Orchestration-based Saga

• Saga Orchestrator가 SAGA에 참여하고 있는 서비스들에게 어떤 트랜잭션을 실행시켜야하는지 알려주는 방식이다.
  • 즉, 어떠한 지점에서 모든 트랜잭션을 처리하고, 필요하다면 보상 트랜잭션을 발생시켜 롤백을 시도한다.
• 각 서비스는 트랜잭션 결과를 Orchestrator에게 전달하고, 마지막 트랜잭션이 끝나면 Orchestrator를 종료해서 전체 트랜잭션 처리를 종료한다.
• 이 패턴은 모든 관리를 Orchestrator가 하기에, 중앙 집중화가 이루어진다는 특징이 존재한다.

장점

• 복잡한 트랜잭션 워크플로우에 적합하며, 많은 참가자가 있는 경우에도 중앙에서 모든 상태를 관리가능
• 중앙에서 순환 의존성을 방지하고 명확한 프로세스 제어가 가능하다.
• 각 서비스는 Orchestrator와만 상호작용 하므로 서비스 간 결합도가 적다.

단점

• Orchestrator로 인한 단일 지점장애

---

예시

• 가장 이런 패턴을 쉽게 설명할 수 있는 방법은 온라인 주문이다. (아래 3가지 단계로 진행되는 주문)
  1. 결제 승인
  2. 제고 차감
  3. 배송 예약
• 이때, 각 작업은 독립적으로 실행되면서, SAGA패턴을 통해 트랜잭션을 관리한다면. 아래와 같이 진행될 것이다.
  1. 결제 승인에 성공하면, 재고 차감 단계로 진행
  2. 재고 차감에 성공하면, 배송 예약 단계로 진행
  3. 만약 배송 예약에 실패하면, 이전 단계들을 취소하는 보상 작업을 수행하여 롤백한다.

🚧 그렇다면 SAGA 패턴을 통한 트랜잭션은 항상 일관성을 보장할까?

각 트랜잭션에서, 이벤트를 발행시키기 전에 데이터베이스에만 트랜잭션을 반영하고 서비스가 오류로 종료된다면 전체적인 트랜잭션 일관성이 깨질 것 같다는 생각이든다.

즉, 메시지 브로커와 데이터베이스는 일관성이 보장이 안되는 문제가 생길 수 있다.
이는 후에 포스팅할 Transactional Outbox 패턴으로 해결 가능하다.