SAGA 패턴이란?
분산 트랜잭션을 우아하게 처리하는 방법을 말한다.
MSA 아키텍처가 보편화 되면서, 여러 서비스에 걸친 트랙잭션을 어떻게 처리할 것인가?에 대한 해답 중 하나이다.
목차
1. 분산 환경에서의 트랜잭션 문제
2. 기존 해결책: 2PC (Two-Phase Commit)
3. SAGA 패턴 등장 배경
4. SAGA 패턴이란?
5. SAGA의 핵심 개념 (보상 트랜잭션)
6. SAGA 구현 방식
6-1. Choreography 방식
6-2. Orchestration 방식
7. 간단한 예제로 이해하는 SAGA
8. SAGA 패턴의 장점과 단점
9. 언제 SAGA 패턴을 써야 할까?
10. 정리
1. 분산 환경에서의 트랜잭션 문제.
MSA 환경에서는 일반적인 트랜잭션이 어렵습니다.
주문 / 결제 / 배송 서비스가 개별적으로 존재한다면 서로 다른 DB서버를 사용하게 되고,
이는 서로 다른 트랜잭션으로 묶이게 된다는 의미를 뜻합니다.
서로 다른 서버들이기 때문에 하나의 DB 트랜잭션으로 묶을 수 없다는 큰 문제가 생기게 됩니다.
2. 기존 해결책 : 2PC (Two-Phase Commit)
이런 문제를 해결하기 위해서 중앙 코디네이터가 모든 서비스에게 커밋에 대한 신호를 보내고 받는 형식을 사용했다.
하지만 이런 방식에도 문제점이 존재했는데 하나라도 응답이 잘 안되면 전체가 멈추는 문제와 네트워크 지연에 취약하다는 문제였다. 또한 확장성이 낮아 MSA 아키텍처와 잘 호환되지 않는 방식이었다.
3. SAGA 패턴의 등장 배경
이처럼 완벽한 롤백/커밋이 어렵다면 개별 트랜잭션에서 실패했을 때 되돌리는 작업을 만들자라는의견이 나왔고,
이것이 바로 SAGA 패턴의 등장이다.
SAGA는 강한 일관성 대신에 최종 일관성을 유지할 수 있도록 만든 방법이었다.
4. SAGA 패턴이란?
SAGA패턴은 하나의 큰 트랜잭션을 여러개의 로컬 트랜잭션으로 나누고 실패에 대한 보상 트랜잭션으로 되돌리는 패턴을 의미한다.
5. SAGA 패턴의 핵심 : 보상 트랜잭션
SAGA에서 말한 보상 트랜잭션은 Rollback이 아닌 되돌리는 동작을 직접 구현하는 것이다.
예를 들어 주문과 결제 서비스가 이루어 질 때 주문은 잘 생성되었지만 결제가 실패했을 때 이전에 주문에 대한 동작을 취소하는 동작을 구현해 실행되도록 만든 패턴을 말한다.
6. SAGA의 구현 방식
6-1. Choreography 방식 (이벤트 기반)
특징 : 중앙 제어자가 없고 서비스들끼리 이벤트를 주고 받으면 동작하도록 만들었다.
흐름 :
- 주문 생성 → OrderCreated 이벤트 발행
- 결제 서비스가 이벤트 수신 → 결제
- 결제 성공 → PaymentCompleted 이벤트
- 배송 서비스 처리
장점 : 서비스간의 결합이 낮고 확장성이 높다
단점 : 하지만 이벤트 기반으로 흐름 파악이 어렵고 디버깅 난이도가 증가한다는 단점이 있다.
6-2. Orchestration 방식 (중앙 제어)
특징 : 중앙의 조정자( Saga Orchestrator)가 흐름을 제어하는 방식이다.
흐름 :
- Orchestrator → 주문 생성
- Orchestrator → 결제 요청
- 실패 시 → 결제 취소 / 주문 취소 지시
장점 : 로직 흐름이 명확해 관리와 디버깅이 쉽다.
단점 : 하지만 Orchestrator에 집중된 로직으로 단일 장애 지점 가능성이 있다는 단점이 있다.
7. SAGA의 보상 트랜잭션 처리 방법
7-1. SAGA Backward Recovery
Backward Recovery는 Saga 실행 중 오류가 발생했을 때, 이미 성공한 트랜잭션을 보상 트랜잭션으로 되돌리는 방식이다.
즉, 전통적인 트랜잭션의 rollback 개념을 Saga 환경에 맞게 명시적인 보상 로직으로 구현한 것이다.
동작 시나리오 예시 : 다음과 같은 Saga 흐름이 있다고 가정해보자.
: T1 → T2 → T3
실패 상황 :
- T1, T2는 성공
- T3 실행 중 오류 발생
동작 흐름 :
- abort-saga 명령이 실행된다.
- 현재 진행 중인 T3 트랜잭션을 중지한다.
- T3에 대한 보상 트랜잭션을 실행한다.
- 이후 T2, T1 순서로 역순 보상 트랜잭션을 실행한다.
- 각 보상 트랜잭션의 시작/종료 로그를 기록한다.
- Saga 전체가 종료된다.
장점 : 데이터 정합성을 다시 맞추는 데 적합하고 비즈니스적으로 “원래 상태로 돌아가야 하는 경우”에 적합
단점 : 보상 트랜잭션 설계 비용이 크며, 이미 외부에 노출된 상태(알림, 배송 등)는 되돌리기 어렵다.
7-2. SAGA Forward Recovery
Forward Recovery는 실패가 발생했다고 해서 Saga를 즉시 중단하지 않고,
가능한 지점부터 다시 진행하거나 보완하는 방식이다.
즉, 실패했지만, 굳이 되돌릴 필요는 없는 경우에 선택하는 전략이다.
동작 시나리오 예시 : 다음과 같은 Saga 흐름이 있다고 가정해보자.
: T1 → T2 → save-point → T3 → T4
실패 상황 :
- T4 실행 중 오류 발생
동작 흐름 :
- 시스템은 save-point 지점을 기준으로 복구를 판단한다.
- 필요하다면 save-point까지 역방향 복구를 수행한다.
- T3, T4의 코드가 재실행 가능하다면:
- 해당 단계부터 트랜잭션을 재시작한다.
- Saga를 계속 진행한다.
장점 : 사용자 경험을 유지에 좋으며 전체 롤백이 불필요한 경우 효율이고 대규모 시스템에서 자주 사용된다.
단점 : 하지만 설계 난이도가 높고 상태 관리가 복잡해질 수 있다는 단점이 있다.
다음과 같은 상황에서는 Backward Recovery가 오히려 비효율적일 수 있다.
- 실패가 치명적이지 않은 경우
- 실패 시 즉각적인 복구가 필요 없는 서비스
- 보상 트랜잭션 없이도 알림, 재시도로 처리 가능한 경우
- 이미 성공한 단계의 비즈니스 가치가 매우 큰 경우
8. SAGA의 장단점
장점 :
- MSA에 적합
- 확장성 뛰어남
- 서비스 독립성 유지
단점 :
- 구현 복잡도 증가
- 보상 로직 직접 설계 필요
- 데이터가 잠깐 불일치할 수 있음
9. 언제 SAGA 패턴이 적절할까?
추천
- 마이크로서비스 아키텍처
- 서비스별 독립 DB
- 주문/결제/배송 같은 비즈니스 흐름
비추천
- 단일 DB
- 강한 즉시 일관성이 반드시 필요한 경우
Saga Pattern은 분산 트랜잭션 환경에서 서비스 간 결합도를 낮추고 보상 트랜잭션을 실행하도록 설계하는 패턴 중 하나이다. 데이터의 일관성을 보장하고, 보상 트랜잭션 구현을 위해 고려해야 한다. 보상 트랜잭션은 서비스와 서비스 간의 비즈니스 흐름을 고려하여 최소화하는 것이 바람직하다.
Saga Pattern을 구현하는 방안 선택의 기준은 명확히 제시된 것은 없지만, 일반적으로 프로젝트의 규모를 고려할 수 있다. 단순하게 Loosley Coupled 지향의 Choreographed Saga는 대규모 프로젝트에서 각 팀 간의 결합도를 낮추고 개발에 영향을 최소화하기 위해 선택하기 용이하다. 반면에 Orchestrated Saga는 단일팀 내에서 개발 가능한 경우 중앙 관리 방식으로 개발하는 것이 효과적일 수 있다. 또한 Tightly Coupled 지향의 트랜잭션 처리, Cyclic Dependency 발생이 있는 워크플로우에서 Saga Pattern 설계는 적합하지 않을 수도 있다.