Saga 패턴은 언제 필요할까?

마이크로서비스에서 트랜잭션을 처리하는 방법

모놀리식 시스템에서는 데이터베이스 트랜잭션을 사용하는 것이 일반적이다.

예를 들어 주문 시스템을 생각해 보자.

 

주문 생성
→ 결제 처리
→ 재고 차감

 

이 과정은 보통 하나의 트랜잭션으로 처리된다.

 

BEGIN
INSERT ORDER
UPDATE PAYMENT
UPDATE INVENTORY
COMMIT

 

만약 중간에 문제가 발생하면

 

ROLLBACK

 

으로 전체 작업을 취소할 수 있다.

이것이 ACID 트랜잭션이다.

하지만 마이크로서비스 아키텍처(MSA)에서는 상황이 달라진다.

서비스가 여러 개로 나뉘기 때문이다.

---

MSA에서 발생하는 트랜잭션 문제

MSA 환경에서는 각 서비스가 자신의 데이터베이스를 가진다.

예를 들어 다음 구조를 생각해 보자.

 

Order Service
→ orders DB

Payment Service
→ payments DB

Inventory Service
→ inventory DB

 

주문 생성 과정은 다음과 같이 진행된다.

 

1. Order Service → 주문 생성
2. Payment Service → 결제 처리
3. Inventory Service → 재고 차감

 

문제는 이 과정이 하나의 트랜잭션으로 묶일 수 없다는 것이다.

예를 들어 다음 상황을 생각해 보자.

 

Order 생성 성공
Payment 성공
Inventory 실패

 

이 경우 주문과 결제는 성공했지만
재고 차감이 실패했다.

모놀리식 시스템이라면 롤백이 가능하지만
MSA에서는 서비스가 분리되어 있기 때문에 쉽지 않다.

이 문제를 해결하기 위해 등장한 패턴이 바로
Saga 패턴이다.

---

Saga 패턴이란 무엇인가

Saga 패턴은 여러 서비스에 걸친 트랜잭션을 단계별로 처리하는 방식이다.

각 서비스는 자신의 로컬 트랜잭션을 수행한다.

만약 중간에 실패하면
이전에 수행한 작업을 보상 트랜잭션(Compensation Transaction)으로 취소한다.

예를 들어 주문 처리 과정은 다음과 같이 구성된다.

 

1. Order 생성
2. Payment 처리
3. Inventory 차감

 

만약 재고 차감이 실패하면

 

Payment 취소
Order 취소

 

와 같은 보상 작업이 실행된다.

 

즉 Saga 패턴은

 

실패 시 Rollback

 

대신

 

실패 시 Compensation

 

을 사용하는 구조다.

---

Saga 패턴의 두 가지 방식

Saga 패턴은 보통 두 가지 방식으로 구현된다.

---

1. Choreography 방식

Choreography 방식에서는
서비스들이 이벤트 기반으로 서로 통신한다.

예를 들어 주문 생성 이벤트가 발생하면

 

OrderCreated 이벤트

 

이 이벤트를 다른 서비스들이 처리한다.

 

Order Service
→ OrderCreated 이벤트 발행

Payment Service
→ 결제 처리
→ PaymentCompleted 이벤트 발행

Inventory Service
→ 재고 차감

 

만약 재고 차감이 실패하면

 

PaymentCancel 이벤트

 

같은 보상 이벤트를 발행한다.

이 방식의 장점은 중앙 컨트롤러가 없다는 것이다.

하지만 서비스 간 흐름이 복잡해질 수 있다.

---

2. Orchestration 방식

Orchestration 방식에서는
중앙 Saga Coordinator가 흐름을 관리한다.

예를 들어 다음과 같은 구조다.

 

Saga Orchestrator
→ Order Service 호출
→ Payment Service 호출
→ Inventory Service 호출

 

만약 실패하면

 

Saga Orchestrator
→ Payment 취소
→ Order 취소

 

와 같이 보상 작업을 실행한다.

이 방식은 흐름 관리가 명확하지만
중앙 컨트롤러에 의존하게 된다.

---

Saga 패턴이 필요한 상황

Saga 패턴은 다음과 같은 상황에서 필요하다.

---

1. 여러 서비스에 걸친 트랜잭션

예를 들어 다음 작업이 있다.

• 주문 생성
• 결제 처리
• 재고 차감
• 배송 준비

각 서비스가 서로 다른 데이터베이스를 사용할 경우
Saga 패턴이 필요하다.

---

2. 이벤트 기반 시스템

Event Driven Architecture를 사용하는 경우
Saga 패턴은 자연스럽게 등장한다.

예를 들어 다음 이벤트 흐름이 있다.

 

즉 Saga 패턴은

 

실패 시 Rollback

 

대신

 

실패 시 Compensation

 

을 사용하는 구조다.

---

Saga 패턴의 두 가지 방식

Saga 패턴은 보통 두 가지 방식으로 구현된다.

---

1. Choreography 방식

Choreography 방식에서는
서비스들이 이벤트 기반으로 서로 통신한다.

예를 들어 주문 생성 이벤트가 발생하면

 

OrderCreated 이벤트

 

이 이벤트를 다른 서비스들이 처리한다.

 

Order Service
→ OrderCreated 이벤트 발행

Payment Service
→ 결제 처리
→ PaymentCompleted 이벤트 발행

Inventory Service
→ 재고 차감

 

만약 재고 차감이 실패하면

 

PaymentCancel 이벤트

 

같은 보상 이벤트를 발행한다.

이 방식의 장점은 중앙 컨트롤러가 없다는 것이다.

하지만 서비스 간 흐름이 복잡해질 수 있다.

---

2. Orchestration 방식

Orchestration 방식에서는
중앙 Saga Coordinator가 흐름을 관리한다.

예를 들어 다음과 같은 구조다.

 

Saga Orchestrator
→ Order Service 호출
→ Payment Service 호출
→ Inventory Service 호출

 

만약 실패하면

 

Saga Orchestrator
→ Payment 취소
→ Order 취소

 

와 같이 보상 작업을 실행한다.

이 방식은 흐름 관리가 명확하지만
중앙 컨트롤러에 의존하게 된다.

---

Saga 패턴이 필요한 상황

Saga 패턴은 다음과 같은 상황에서 필요하다.

---

1. 여러 서비스에 걸친 트랜잭션

예를 들어 다음 작업이 있다.

• 주문 생성
• 결제 처리
• 재고 차감
• 배송 준비

각 서비스가 서로 다른 데이터베이스를 사용할 경우
Saga 패턴이 필요하다.

---

2. 이벤트 기반 시스템

Event Driven Architecture를 사용하는 경우
Saga 패턴은 자연스럽게 등장한다.

예를 들어 다음 이벤트 흐름이 있다.