Saga & 2PC

사가패턴(Saga Pattern)

복잡한 트랜잭션 → 서비스 단위로 분산시키기 위해 적합한 패턴

트랜잭션 중 오류 발생 → 보상 트랜잭션 ~> 이전 단계 취소 ⇒ 데이터 일관성 보장

1) 코레오그래피 기반 사가(Choreography-based Saga)

각 서비스가 이벤트 발행하고 구독하여 상호작용

• (+) 중앙 관리 X 분한된 환경에서 빠르게 대응 O
  • 각 서비스가 서로의 상태를 알지 못하는 상황 발생할 수 있음
  • 전체 트랜잭션 상태나 흐름 추적 어려움
  • 워크플로우의 확장과 변경 어려움
    • 새로운 단계 추가 or 기존 워크플로우 변경 → 모든 관련 서비스 수정
• (-) 복잡한 워크플로우 O → 서비스 간 이벤트 흐름 엉킬 위험 있음
  • 다수의 서비스 순차적으로 관여 → 이벤트 여러 단계로 연쇄적으로 전달 ⇒ 이벤트 흐름 복잡
  • 예외 처리 및 데이터 일관성 유지 어려움

---

2) 오케스트레이션 기반 사가(Orchestration-based Saga)

 

중앙에서 오케스트레이터가 전체 워크플로우 관리

오케스트레이터) 각 서비스에 작업 요청, 결과에 따라 다음 단계 결정

/ 각 단계 결과 평가, 조건에 따라 다음 단계로 분기할 수 있음, 다양한 예외 상황에 유연하게 대응할 수 있음

• (+) 중앙 관리로 복잡한 트랜잭션 쉽게 추적할 수 있음
  • 실패 시 어떤 단계로 돌아가야 할지 쉽게 결정, 보상 트랜잭션 명확히 수행할 수 있음
  • 서비스 간 데이터 일관성 유지 쉬움
• (-) 중앙 서비스 과부하 or 장애 발생 → 전체 워크플로우에 영향 줄 수 있음

---

2PC(Two-Phase commit)

• 원자성을 보장하기 위한 분산 트랜잭션 관리 프로토콜
• 여러 노드 상에서의 원자적 트랜잭션 커밋을 이루기 위한 알고리즘(프로토콜)
• 분산된 환경에서 여러 노드(여러 데이터베이스 or 서비스)가 하나의 트랜잭션을 성공적으로 커밋할 때까지
  2 단계에 걸쳐 트랜잭션을 진행하는 프로토콜

일반적인 싱글 노드 트랜잭션에 존재하지 않는 새로운 컴포넌트인 코디네이터(트랜잭션 매니저) 사용

• 코디네이터: 트랜잭션을 요청하는 같은 애플리케이션 프로세스 내 라이브러리에 구현되어 있으나,
  분리된 서비스나 프로세스일 수 있음

애플리케이션) 여러 데이터베이스 노드들에 읽고 쓰면서 시작

• 준비 단계 (Prepare Phase)
  • 애플리케이션이 커밋할 준비 → 코디네이터) phase 1 시작, 각 노드에 prepare 요청
    → 커밋할 수 있는지 질의, 코디네이터) 이후 각 노드(참여자, participant)의 응답 추적
• 커밋 단계 (Commit Phase)
  • 모든 참여자 yes → 코디네티어) phase 2로 넘어가 `commit` 요청 → 커밋 수행되도록 함
  • 어느 하나라도 no → 코디네이터) phase 2로 넘어가 모든 노드들에 `abort` 요청

---

출처

Saga 패턴 - Azure Design Patterns

Two-Phase Commit이란? (2PC)

2PC[Two-Phase-Commit]과 SAGA 패턴