Saga 패턴
사가 패턴(영어: Saga Pattern)은 마이크로서비스 아키텍처나 분산 시스템에서 여러 서비스에 걸친 다단계 트랜잭션을 관리하여 데이터 일관성을 확보하기 위한 설계 패턴이다.
정의[편집 | 원본 편집]
사가 패턴은 하나의 큰 트랜잭션을 여러 개의 로컬 트랜잭션으로 나누고, 각 로컬 트랜잭션이 자신의 데이터베이스를 업데이트한 뒤 다음 단계를 트리거하는 방식으로 실행된다. 만약 중간 단계에서 실패가 발생하면 이전에 완료된 단계들에 대해 보상 트랜잭션(compensating transaction)을 실행하여 시스템을 일관된 상태로 복구한다.
“사가(Saga)”라는 이름은 고대 북유럽의 장편 서사문학에서 유래했으며, 하나의 큰 트랜잭션이 여러 단계를 거치며 성공 또는 실패에 따라 보상되거나 계속 이어지는 구조가 이야기처럼 흐르는 연속성을 지닌다는 점에서 비유적으로 사용되었다. 이 용어는 1987년 Hector Garcia-Molina와 Kenneth Salem이 발표한 논문 「Sagas」에서 처음 제안되었다.
주요 구성 요소 및 작동 방식[편집 | 원본 편집]
- 로컬 트랜잭션(Local Transaction)
- 각 서비스 내에서 ACID 원칙에 따라 실행되는 단위 작업이다.
- 보상 트랜잭션(Compensating Transaction)
- 로컬 트랜잭션 이후 오류가 발생했을 때 이전 로컬 트랜잭션의 효과를 되돌리기 위한 작업이다.
- 트랜잭션 흐름(Transaction Flow)
- 로컬 트랜잭션이 성공하면 다음 단계가 실행되며, 실패하면 보상 흐름이 실행된다.
- 흐름 조정 방식
- 오케스트레이션 방식: 중앙 실행 조정자(Saga Orchestrator)가 전체 흐름을 제어한다.
- 코레오그래피 방식: 각 서비스가 이벤트를 발행하고 구독하면서 흐름이 자율적으로 진행된다.
장점[편집 | 원본 편집]
- 여러 마이크로서비스에 걸친 작업을 단일 트랜잭션처럼 관리하면서도 전통적 2‑단계 커밋(2PC)의 단점(블로킹, 단일 실패 지점 등)을 피할 수 있다. [1]
- 비동기 방식 및 느슨한 결합(loose coupling)을 통해 시스템 확장성과 유연성을 확보할 수 있다.
- 실패 시 보상 트랜잭션을 통해 시스템을 일관된 상태로 유지할 수 있다.
단점 및 고려사항[편집 | 원본 편집]
- 전체 흐름이 복잡해질 수 있으며, 특히 서비스 수가 많아질수록 설계 및 디버깅이 어려워진다.
- 보상 트랜잭션을 설계해야 하며, 이 작업이 누락되거나 잘못 설계되면 데이터 불일치가 발생할 수 있다.
- 격리(isolation)가 보장되지 않으므로 결국적 일관성(eventual consistency) 모델을 이해하고 수용해야 한다.
- 트랜잭션 흐름이 길어지면 지연(latency)이 증가할 수 있다.
적용 가능한 상황 및 예시[편집 | 원본 편집]
적용에 적합한 경우[편집 | 원본 편집]
- 마이크로서비스 아키텍처에서 여러 서비스가 독립적으로 데이터를 관리하고 있으며, 하나의 작업이 여러 서비스를 거쳐야 하는 경우.
- 전통적 분산 트랜잭션(예: 2PC)이 적합하지 않거나 불가능한 환경에서 데이터 일관성을 확보해야 할 때.
- 예컨대 주문 처리, 결제, 재고 관리, 배송 등 여러 단계가 연관된 비즈니스 흐름에 적합하다. [2]
예시[편집 | 원본 편집]
온라인 쇼핑몰에서 주문 처리 흐름을 다음과 같이 생각해보자:
- 주문 생성(Order Service)
- 결제 처리(Payment Service)
- 재고 차감(Inventory Service)
만약 결제 단계에서 오류가 발생하면, 결제가 성공한 상태라면 환불 처리하고, 주문 상태를 취소하며, 재고가 이미 차감됐다면 재고를 복구하는 보상 트랜잭션이 실행된다.
오케스트레이션 vs 코레오그래피 방식 비교[편집 | 원본 편집]
| 방식 | 특징 | 적합한 상황 |
|---|---|---|
| 오케스트레이션 | 중앙 오케스트레이터가 전체 흐름을 제어하고, 각 서비스에 호출 또는 명령을 내림. 흐름이 명확하고 관리가 용이함. | 복잡한 워크플로우, 서비스 수가 많거나 제어가 필요할 때 |
| 코레오그래피 | 각 서비스가 이벤트를 발행하고 구독함으로써 흐름이 분산되어 진행됨. 느슨한 결합, 단일 실패점 없음. | 단순한 흐름, 서비스 수가 적고 자율성이 높을 때 |
설계 팁 및 주의사항[편집 | 원본 편집]
- 각 로컬 트랜잭션과 그에 대응하는 보상 트랜잭션을 명확히 정의해야 한다.
- 각 단계를 가역적(undo 가능) 또는 보상 가능(compensable) 하도록 설계해야 한다. [3]
- 흐름 상태를 추적할 로그 또는 상태 저장소(saga log)를 마련하여 장애 복구 또는 재시도가 가능하도록 해야 한다.
- 아이디엠포턴트(idempotent)한 작업을 설계하여 재시도 시 이상 동작을 막아야 한다.
- 서비스 경계(domain boundary)를 잘 정의하고, 너무 많은 책임이 한 사가에 몰리지 않도록 주의한다.
- 사가의 복잡도가 지나치면 관리 비용이 증가하므로 초기에는 단순한 흐름으로 시작하는 것이 좋다.
결론[편집 | 원본 편집]
사가 패턴은 마이크로서비스 아키텍처에서 분산 트랜잭션 문제를 해결하기 위한 강력한 설계 방식이다. 다단계 작업을 여러 서비스가 협력해 수행하면서도, 실패 시 보상을 통해 일관성을 유지할 수 있다. 다만 설계와 구현이 복잡할 수 있으므로 팀과 시스템의 특성에 맞춰 신중히 적용하는 것이 중요하다.
같이 보기[편집 | 원본 편집]
참고 문헌[편집 | 원본 편집]
- Microsoft Azure Architecture Center. “Saga Design Pattern.”
- Baeldung. “Saga Pattern in Microservices.”
- AWS. “Saga Pattern — AWS Prescriptive Guidance.”
- Garcia-Molina, H., Salem, K. “Sagas.” ACM SIGMOD, 1987.
