11/26

🔹 Saga 패턴이란?

MSA 환경에서 분산 트랜잭션(Distributed Transaction)을 2PC 없이 해결하기 위한 패턴을 말한다.

즉, 여러 서비스가 하나의 비즈니스 로직을 처리할 때 전체를 하나의 일관된 트랜잭션처럼 보이게 만드는 구조를 말한다.

다만, RDB 내 로컬 트랜잭션과는 다르게 글로벌 락 없이, 각 서비스가 독립적으로 로컬 트랜잭션을 수행한다.

---

🔹 왜 필요한가?

1) MSA는 DB를 공유하지 않는다

• 서비스별로 서로 다른 DB를 갖고 있고
• 하나의 요청이 여러 서비스의 DB 업데이트를 요구할 수 있음
  → 기존의 2PC(분산 트랜잭션)은 락 비용 크고 성능 저하와 장애 전파 위험이 큼.

2) 결국 "성공하면 전체 성공, 실패하면 전체 롤백" 해야 함

Saga는 이를 위해 정상 흐름(Forward Flow)과
보상 트랜잭션(Compensation Transaction)을 정의한다.

---

🔹 Saga 패턴 구성 요소

🔸 Forward Transaction

• 실제 비즈니스 로직
• 예: 결제 → 재고 차감 → 배송 생성

🔸 Compensation Transaction

• 실패 시 되돌리는 작업(보상 단계)
• 예: 배송 생성 실패 → 재고 복구 → 결제 취소

보상 트랜잭션은 반드시 비즈니스적으로 롤백 동작이 존재해야 하고,
데이터베이스 undo가 아니라 “도메인 undo 작업”이다.

---

🔹 Saga 패턴의 두 가지 구현 방식

1️⃣ Choreography (코레오그래피)

각 서비스가 이벤트를 보고 다음 행동을 스스로 결정하는 방식.
▶ 이벤트 기반 아키텍처 중심

🔸 특징

• 중앙 Orchestrator 없음
• 서비스 간 의존도 낮고 확장 용이
• 이벤트 폭발(Event Storm)로 흐름 파악 어려워질 수 있음
• 단순한 워크플로우에 적합

🔸 예시(주문 → 결제 → 재고 → 배송)

1. OrderService → OrderCreatedEvent 발행
2. PaymentService → 결제 시도 후 PaymentCompletedEvent 발행
3. InventoryService → 재고 차감 후 InventoryDeductedEvent 발행
4. ShippingService → 배송 생성

🔸 실패 시 보상 흐름

• Shipping 실패 → ShippingFailedEvent → Inventory → Payment → Order 순으로 보상 이벤트 발생

2️⃣ Orchestration (오케스트레이션)

중앙 Orchestrator가 전체 Saga의 흐름을 지휘.

🔸 특징

• 전체 비즈니스 흐름을 한 곳에서 관리
• 코드 가독성 및 유지보수 용이
• Orchestrator의 책임 집중
• 복잡한 비즈니스 프로세스에 적합

🔸 예시

Orchestrator → Payment → Inventory → Shipping

🔸 실패 시

Orchestrator가 직접 보상 요청

Shipping 실패 → Orchestrator가 Inventory 보상 → Payment 보상 → Order 보상

---

🔹 Saga 패턴이 해결해주는 문제

문제	Saga 해결 방식
분산된 DB 간 트랜잭션 일관성	보상 트랜잭션으로 논리적 Rollback
서비스 장애 전파 위험	느슨한 결합(Choreography) 또는 중앙 제어(Orchestration)
2PC 성능 저하	로컬 트랜잭션만 사용
Eventually Consistency	비동기 이벤트 기반으로 점진적 일관성 확보

---

🔹 Saga 패턴의 한계

🔸 즉시 일관성은 제공하지 못함

→ “Eventually Consistent”만 보장

🔸 보상 단계는 완벽한 롤백이 아니다

→ 보상 트랜잭션이 실패할 수도 있음
→ “보상 실패 처리 전략”까지 고려해야 한다

🔸 설계 복잡도 증가

• 이벤트 순서 꼬임
• 중복 이벤트 처리(Idempotency) 필요
• 메시지 유실 대비 리트라이 필요

---

🔹 Spring 기반 구현 예시(기본 흐름)

🔸 Choreography 예시: Kafka 이벤트 기반

// OrderCreatedEvent 발행
orderEventProducer.send(new OrderCreatedEvent(orderId));

// PaymentConsumer
@KafkaListener(topics = "order-created")
public void handle(OrderCreatedEvent event) {
    paymentService.pay(event.orderId());
}

🔸 Orchestration 예시: Orchestrator 서비스

public void startOrderSaga(UUID orderId) {
    try {
        paymentClient.pay(orderId);
        inventoryClient.deduct(orderId);
        shippingClient.create(orderId);
    } catch (Exception e) {
        compensate(orderId);
    }
}

private void compensate(UUID orderId) {
    shippingClient.cancel(orderId);
    inventoryClient.restore(orderId);
    paymentClient.refund(orderId);
}

---

🔹 실제 MSA 실무에서는?

규모 있는 MSA에서는 대부분

• 복잡한 업무 → Orchestration
• 단순 이벤트 흐름 → Choreography

대규모 전자상거래(예: 쿠팡, 아마존) 같은 곳은
배송/결제/재고 조합이 매우 복잡하기 때문에 오케스트레이터 서비스가 거의 필수.