SAGA 패턴, 분산 트랜잭션 문제를 해결하는 방법은?
SAGA 패턴은 여러 서비스에 걸쳐 있는 비즈니스 트랜잭션을 관리하기 위한 패턴으로, 분산 트랜잭션(Distributed Transaction) 문제를 해결함
Choreography와 Orchestration 두 가지 방식으로 SAGA를 구현할 수 있으며, 각 방식은 트레이드오프(Trade-offs)를 가짐
데이터 일관성(Data Consistency)을 유지하면서도 2PC(Two-Phase Commit)와 같은 분산 트랜잭션의 단점을 극복할 수 있다는 장점이 있음
자동 롤백(Automatic Rollback) 부재로 인해 개발자가 보상 트랜잭션(Compensating Transaction)을 직접 설계해야 하는 어려움이 존재함
SAGA 패턴의 핵심 원리
SAGA 패턴은 여러 서비스 간의 데이터 일관성을 유지하기 위해 분산 트랜잭션(Distributed Transaction)을 대체하는 방법으로 제시된다. 핵심은 각 서비스를 로컬 트랜잭션으로 분리하고, 각 트랜잭션이 완료된 후 이벤트를 발행하여 다음 단계를 트리거하는 것이다. Choreography 방식은 각 서비스가 이벤트를 직접 발행하고, Orchestration 방식은 오케스트레이터(Orchestrator)가 각 서비스에 명령을 내리는 방식으로 동작한다.
Choreography vs. Orchestration: 구현 방식 비교
SAGA 패턴은 Choreography와 Orchestration 두 가지 주요 구현 방식을 제공한다. Choreography 방식은 각 서비스가 이벤트를 발행하여 다른 서비스의 로컬 트랜잭션을 트리거하는 방식으로, 서비스 간의 결합도가 낮지만, 복잡한 트랜잭션 흐름을 추적하기 어렵다는 단점이 있다. 반면, Orchestration 방식은 오케스트레이터가 전체 트랜잭션 흐름을 제어하므로, 관리가 용이하지만, 오케스트레이터에 대한 의존성이 높아진다.
SAGA 패턴의 장점과 단점
SAGA 패턴은 분산 트랜잭션(Distributed Transaction)의 대안으로, 데이터 격리 아키텍처(Data Isolation Architecture)를 사용하는 마이크로서비스 환경에서 데이터 일관성을 유지하는 데 유용하다. 특히, 2PC(Two-Phase Commit)와 같은 분산 트랜잭션의 성능 저하 문제를 해결할 수 있다. 하지만, 자동 롤백(Automatic Rollback) 기능이 없으므로, 개발자가 보상 트랜잭션(Compensating Transaction)을 직접 설계해야 하는 어려움이 있다.
SAGA 패턴 구현 시 고려 사항
SAGA 패턴을 구현할 때는 데이터 일관성(Data Consistency)을 유지하기 위한 다양한 기술적 고려 사항이 필요하다. 서비스는 원자성(Atomicity)을 보장하기 위해 데이터베이스와 메시지 브로커(Message Broker)를 함께 사용하는 대신, Event Sourcing 또는 Transactional Outbox 패턴을 사용해야 한다. 또한, 비동기 통신(Asynchronous Communication)으로 인해 발생하는 문제(예: 결과 확인)를 해결하기 위해 다양한 전략을 선택해야 한다.
