Overview
저번 시간에는 이벤트 주도 아키텍처에 대해 알아보았다.
MSA의 가장 큰 허들 중 하나는 MSA는 polyglot persistence라는 특징을 가지고 있으며 데이터베이스가 1개가 아닌 N개로써 생기는 분산 트랜잭션을 어떻게 잘 처리할 것인가이다.
분산 트랜잭션 처리는 주로 Saga Pattern, Two Phase Commit, TCC 등으로 처리 가능하다고 한다.
오늘은 사가 패턴에 대해 알아보고자 한다.
사가 패턴이란
Saga라는 말은 아이슬란드어로 말해진 것, 말로 전하다를 의미한다. 이 의미에서 사가패턴이 무엇인지를 유추할 수 있다.
Saga Pattern이란 로컬 트랜잭션들이 순차적으로 업데이트를 수행해 나가는 패턴이다.
각각의 마이크로서비스에서 책임지고 트랜잭션을 처리하는데 만약 문제가 발생한다면?? 실패한다면?? 보상 이벤트를 통해 보상 트랜잭션을 발행하여 이전 서비스들에게 롤백을 하도록 하자는 개념이다.
MSA는 물리적으로 데이터베이스가 분리되어 있어 단일 트랜잭션으로 커밋, 롤백 처리가 불가능하다. MSA는 비즈니스 로직으로 커밋, 롤백 등 트랜잭션에 대한 책임을 가지도록 구현해야 한다.
이러한 사가 패턴에는 크게 2가지 방식이 있다.
Orchestration based SAGA pattern
오케스트레이션 방식은 분산 트랜잭션을 책임지는 별도의 중계자(Saga Manager)가 존재하는 방식이다.
중계자(Saga Manager)는 사가 인스턴스를 발급하여 각 작업의 상태를 저장 및 해석하며, 보상 트랜잭션을 사용하여 오류 복구를 처리한다. 그 순서는 다음과 같다.
- 트랜젝션에 관여하는 모든 서비스는 중계자에 의해서 점진적으로 트랜잭션을 수행하며 결과를 중계자에게 전달
- 그렇게 진행하다 마지막 트랜잭션이 끝나게되면 중계자를 종료하면서 전체 트랜잭션 처리를 종료
- 실패 시 보상 트랜잭션 발행
대표적으로 Axon Framework로 구현가능하다.
장점
- 시간이 지남에 따라 많은 참가자가 관여하거나 새 참가자가 추가되는 포함된 복잡한 워크플로에 적합하다.
- 프로세스의 모든 참가자를 제어하고 활동 흐름을 제어할 수 있는 경우에 적합하다.
- 오케스트레이터는 일방적으로 Saga 참가자에 의존하기 때문에 순환 종속성을 도입하지 않는다.
- Saga 참가자는 다른 참가자의 명령에 대해 알 필요가 없다. 문제의 명확한 분리는 비즈니스 논리를 간소화한다.
단점
- 추가 디자인 복잡성을 위해서는 조정 논리를 구현해야 한다.
- 오케스트레이터가 전체 워크플로를 관리하기 때문에 추가 실패 지점이 생긴다.
Choreography based SAGA pattern
분산 트랜잭션을 책임지는 중계자(Saga Manager)가 존재하지 않는 방식이다.
순서는 다음과 같다.
- 로컬 트랜잭션을 처리하고 다음 서비스에게 이벤트 전달
- 성공, 실패를 큐로 응답으로 넣어준다.
- 실패 시 보상 트랜잭션 발행
장점
- 참가자가 거의 없고 조정 논리가 필요하지 않은 간단한 워크플로에 적합하다.
- 추가 서비스 구현 및 유지 관리가 필요하지 않다.
단점
- 어떤 Saga 참가자가 어떤 명령을 수신 대기하는지 추적하기 어렵기 때문에 새 단계를 추가할 때 워크플로가 복잡해질 수 있다.
- 서로의 명령을 소비해야 하기 때문에 Saga 참가자 간에 순환 종속성이 발생할 위험이 있다.
- 트랜잭션을 시뮬레이션하기 위해 모든 서비스를 실행해야 하므로 통합 테스트가 어렵다.
참고자료
https://learn.microsoft.com/ko-kr/azure/architecture/reference-architectures/saga/saga
