SAGA 패턴
이전에 MSA 관련 포스트를 업로드하면서 MSA를 구축할 때에는 서비스 별로 DB를 구축하는 경우가 많기 때문에 트랜잭션을 어떻게 처리할 것인지에 대한 문제가 존재한다고 언급했었다. 그에 따라 각각의 서비스는 로컬 트랜잭션만을 처리하고 그 결과에 따라 트랜잭션 완료 이벤트 혹은 실패 이벤트를 전달함으로써 데이터의 일관성을 유지하는 SAGA 패턴이 등장하게 되었다. 로컬 트랜잭션이 발생하면 현재 DB를 업데이트한다. 만약 그것이 성공하는 경우 다음 로컬 트랜잭션을 트리거하고 실패하는 경우 보상 이벤트를 통해 이전 로컬 트랜잭션을 롤백한다. 완료 이벤트와 실패 이벤트는 동시 다발적으로 일어나는 것이 아니라 순차적으로 이루어진다. 여기서 트랜잭션의 관리 주체는 DBMS가 아니라 각각의 서비스이다.
SAGA 패턴 종류 (트랜잭션 처리 위치)
(1) Choreography SAGA
앞서 언급한 SAGA 패턴의 방식이 Choreography SAGA 패턴이다. 각각의 서비스는 자신이 보유한 로컬 트랜잭션을 처리하며 그 결과에 따라 완료 혹은 실패 이벤트를 전달한다. 여기서 이벤트는 Kafka와 같은 메시지 큐를 활용해 비동기 방식으로 전달할 수 있다. 해당 패턴은 구현이 쉽다는 장점을 가진다. 그러나 운영자 입장에서 현재 트랜잭션의 상태를 알기가 어렵다.
(2) Orchestrator SAGA
Orchestrator SAGA 패턴에서는 전체 트랜잭션의 처리를 Saga Manager 인스턴스가 처리한다. 트랜잭션의 시작과 함께 생성되는 Saga Manager 인스턴스는 점진적으로 실행되는 트랜잭션의 결과를 모두 전달받는다. 만약 모든 트랜잭션이 성공한다면 해당 Manager 인스턴스는 사라지며 중간에 트랜잭션이 실패할 경우 해당 인스턴스가 롤백 보상 이벤트를 지시한다. 그렇기 때문에 Orchestrator SAGA 패턴은 트랜잭션의 중앙 집중화를 강화할 수 있다. 이는 테스트의 관점, 트랜잭션의 현재 상태를 운영자가 확인할 수 있기 때문에 롤백 처리가 용이하다는 장점과 연결되지만 그만큼 인프라 구현이 복잡해진다는 Orchestartor SAGA 패턴에서는 비동기 형식의 메시지 이벤트를 사용하지 않으며 동기식 API를 활용한다.
'아키텍쳐' 카테고리의 다른 글
| [아키텍쳐] BFF 패턴 (Backend for Frontend) (0) | 2022.04.11 |
|---|