Saga 패턴 편집하기

사가 패턴(영어: Saga Pattern)은 마이크로서비스 아키텍처나 분산 시스템에서 여러 서비스에 걸친 다단계 트랜잭션을 관리하여 데이터 일관성을 확보하기 위한 설계 패턴이다.
==정의==
사가 패턴은 하나의 큰 트랜잭션을 여러 개의 로컬 트랜잭션으로 나누고, 각 로컬 트랜잭션이 자신의 데이터베이스를 업데이트한 뒤 다음 단계를 트리거하는 방식으로 실행된다. 만약 중간 단계에서 실패가 발생하면 이전에 완료된 단계들에 대해 보상 트랜잭션(compensating transaction)을 실행하여 시스템을 일관된 상태로 복구한다.  

“사가(Saga)”라는 이름은 고대 북유럽의 장편 서사문학에서 유래했으며, 하나의 큰 트랜잭션이 여러 단계를 거치며 성공 또는 실패에 따라 보상되거나 계속 이어지는 구조가 '''이야기처럼 흐르는 연속성'''을 지닌다는 점에서 비유적으로 사용되었다. 이 용어는 1987년 Hector Garcia-Molina와 Kenneth Salem이 발표한 논문 「Sagas」에서 처음 제안되었다.
==주요 구성 요소 및 작동 방식==
*로컬 트랜잭션(Local Transaction)
:각 서비스 내에서 ACID 원칙에 따라 실행되는 단위 작업이다.
*보상 트랜잭션(Compensating Transaction)
:로컬 트랜잭션 이후 오류가 발생했을 때 이전 로컬 트랜잭션의 효과를 되돌리기 위한 작업이다.
*트랜잭션 흐름(Transaction Flow)
:로컬 트랜잭션이 성공하면 다음 단계가 실행되며, 실패하면 보상 흐름이 실행된다.
*흐름 조정 방식
**[[오케스트레이션 패턴|오케스트레이션 방식]]: 중앙 실행 조정자(Saga Orchestrator)가 전체 흐름을 제어한다. 
**[[코레오그래피 패턴|코레오그래피 방식]]: 각 서비스가 이벤트를 발행하고 구독하면서 흐름이 자율적으로 진행된다. 
==장점==
*여러 마이크로서비스에 걸친 작업을 단일 트랜잭션처럼 관리하면서도 전통적 2‑단계 커밋(2PC)의 단점(블로킹, 단일 실패 지점 등)을 피할 수 있다. <ref>Baeldung, “Saga Pattern in Microservices”</ref>
*비동기 방식 및 느슨한 결합(loose coupling)을 통해 시스템 확장성과 유연성을 확보할 수 있다.
*실패 시 보상 트랜잭션을 통해 시스템을 일관된 상태로 유지할 수 있다.
==단점 및 고려사항==
*전체 흐름이 복잡해질 수 있으며, 특히 서비스 수가 많아질수록 설계 및 디버깅이 어려워진다. 
*보상 트랜잭션을 설계해야 하며, 이 작업이 누락되거나 잘못 설계되면 데이터 불일치가 발생할 수 있다.
*격리(isolation)가 보장되지 않으므로 결국적 일관성(eventual consistency) 모델을 이해하고 수용해야 한다.
*트랜잭션 흐름이 길어지면 지연(latency)이 증가할 수 있다.
==적용 가능한 상황 및 예시==
===적용에 적합한 경우===
*마이크로서비스 아키텍처에서 여러 서비스가 독립적으로 데이터를 관리하고 있으며, 하나의 작업이 여러 서비스를 거쳐야 하는 경우.
*전통적 분산 트랜잭션(예: 2PC)이 적합하지 않거나 불가능한 환경에서 데이터 일관성을 확보해야 할 때.
*예컨대 주문 처리, 결제, 재고 관리, 배송 등 여러 단계가 연관된 비즈니스 흐름에 적합하다. <ref>Microsoft Azure Architecture Center, “Saga Design Pattern”</ref>
===예시===
온라인 쇼핑몰에서 주문 처리 흐름을 다음과 같이 생각해보자:
#주문 생성(Order Service)
#결제 처리(Payment Service)
#재고 차감(Inventory Service)
만약 결제 단계에서 오류가 발생하면, 결제가 성공한 상태라면 환불 처리하고, 주문 상태를 취소하며, 재고가 이미 차감됐다면 재고를 복구하는 보상 트랜잭션이 실행된다.
==[[오케스트레이션 패턴|오케스트레이션]] vs [[코레오그래피 패턴|코레오그래피]] 방식 비교==
{| class="wikitable"
!방식!!특징!!적합한 상황
|-
|오케스트레이션||중앙 오케스트레이터가 전체 흐름을 제어하고, 각 서비스에 호출 또는 명령을 내림. 흐름이 명확하고 관리가 용이함.||복잡한 워크플로우, 서비스 수가 많거나 제어가 필요할 때
|-
|코레오그래피||각 서비스가 이벤트를 발행하고 구독함으로써 흐름이 분산되어 진행됨. 느슨한 결합, 단일 실패점 없음.||단순한 흐름, 서비스 수가 적고 자율성이 높을 때
|}
==설계 팁 및 주의사항==
*각 로컬 트랜잭션과 그에 대응하는 보상 트랜잭션을 명확히 정의해야 한다.
*각 단계를 가역적(undo 가능) 또는 보상 가능(compensable) 하도록 설계해야 한다. <ref>Microsoft Azure Architecture Center, “Saga Design Pattern”</ref>
*흐름 상태를 추적할 로그 또는 상태 저장소(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.
[[분류:소프트웨어 공학]]