Saga 패턴의 등장
마이크로 아키텍처(Microserive Architecture)를 구성하면서 가장 신경써야할 부분 중 하나는 트랜잭션(transaction) 관리이다. 데이터베이스 시스템은 각각의 트랜잭션에 대해 원자성(Atomicity), 일관성(Consistency), 독립성(Isolation), 영구성(Durability)을 보장한다.(ACID) 모놀로식 아키텍처(Monolithic Architecture)에서는 DBMS에서 기본적으로 제공하는 트랜잭션(transaction)을 통해 commit, rollback을 통해 데이터 일관성이 관리되지만 Microserive에서는 애플리케이션과 데이터베이스가 분산됨에 따라 트랜잭션을 간의 데이터 일관성을 관리하기 어려워질 수 있다.
이러한 부분을 개선하고자 등장한 것이 Saga 패턴이다.
🤔 트랜잭션(transaction) : 논리 또는 작업의 단일 단위이며 때로는 여러 작업으로 구성됩니다. 트랜잭션 내에서 이벤트는 엔터티에 발생하는 상태 변경이며 명령은 작업을 수행하거나 이후 이벤트를 트리거하는 데 필요한 모든 정보를 캡슐화합
니다.
Saga 패턴이란?
Saga 패턴은 각 서비스의 로컬 트랜잭션을 순차적으로 처리한다.
각 로컬 트랜잭션은 데이터베이스를 업데이트한 다음에 다음 로컬 트랜잭션을 트리거하는 메시지 또는 이벤트를 게시한다. 로컬 트랜잭션 처리가 실패할 경우, 이전 로컬 트랜잭션에 의해 보상 트랜잭션을 진행하여 다른 서비스에서 처리된 트랜잭션을 되돌리게 한다.
일반적인 Saga 패턴 구현방법에는 Choreography와 Orchestration의 두 가지의 방법이 있다.
Choreography
중앙집권방식 없이 각 로컬에서 트랜잭션을 실행하고 Event/Message 발행/수신을 통해 실패, 완료를 확인하는 방식이다. 자세한 로직은 다음과 같다.
- A 마이크로서비스에서 로컬 트랜잭션을 실행하고, 종료하면 완료 Event/Messgae를 발행한다.
- B 마이크로서비스가 해당 Event/Messgae를 수신받고, 다음 작업을 진행합니다.
- 이를 순차적으로 실행하고 트랜잭션 실패가 발생할 경우 실패 결과 Event/Messgae를 발행한다.
- 실패 Event를 A 로컬 트랜잭션에서 수신받고, 트랜잭션 롤백(rollback, 되돌림)을 수행한다.
Choreography 장점
- 구성이 편하다.
- 참가중인 마이크로 서비스가 많이 없고 조정 논리가 필요없는 간단한 워크플로우에서 가능하다.
Choreography 단점
- 새로운 마이크로 서비스가 로직에 추가될 경우 서비스간 연계파악이 매우 중요하다.
- 순환 종속이 일어날 수 있다.
Orchestration
중앙집권으로 Orchestrator가 중앙 집중식 컨트롤러 역할을 하고, 각 서비스에 실행할 트랜잭션을 알려주고, 그 상태를 관리하는 방식이다. 자세한 로직은 다음과 같다.
- A 마이크로서비스에서 로컬 트랜잭션을 실행하고, 종료하면 Orchestrator에게 로컬 트랜잭션이 종료됨을 알린다.
- 만일 정상 완료 되었을 때, Orchestrator는 A 마이크로 서비스의 데이터 변경 사항을 Pending 상태로 갖고 있는다.
- Orchestrator가 B 마이크로서비스에게 다음 로직에 대한 명령을 시도한다.
- 다음 마이크로서비스가 로컬 트랜잭션을 실행하고, 실패하거나 종료하면 Orchestrator에게 로컬 트랜잭션에게 알린다.
- Orchestrator가 실패 여부에 따라 Pending 데이터를 승인하거나 거부한다.
Orchestration 장점
- 새로운 마이크로 서비스가 로직에 추가될 경우 추가하기 간편하다.
- 비교적 많은 서비스가 있는 복잡한 워크플로우에 적합하다.
- 모든 마이크로서비스의 활동을 제어하는 경우 적합하다.
- 모든 마이크로서비스가 Orchestrator에게 의존하기 때문에 순환 종속성은 없다.
Orchestration 단점
- Orchestrator의 관리가 추가될 수 있다.
결론
Saga 패턴이 반드시 좋다고는 볼 수 없으나 마이크로 아키텍처에서 마이크로서비스 간의 트랜잭션 처리를 반드시 지켜야한다면 가장 마이크로 아키텍쳐 사상에 부합하는 패턴이다. 그러나 너무 남발할 경우 트랜잭션 처리를 모니터링하기 매우 어려워질 수 있다. 따라서, 서비스와 시스템이 추구하는 가장 중요한 목표는 무엇이고 이에 부합하는 최적의 방법이 어떤 것인지를 면밀하게 검토한 후 결정해야 한다.
'Tech' 카테고리의 다른 글
[MSA, Kafka] 공통 데이터 셀프컨테이닝? (2) | 2025.04.14 |
---|---|
[MSA, Spring] Multi-Redis? (2) | 2024.11.09 |
[MSA] 이벤트기반 아키텍처(Event-Driven Architecture) (0) | 2024.02.26 |
[MSA] DDD(도메인 주도 설계, Domain Driven Design) (0) | 2024.01.18 |
[MSA] 마이크로서비스 아키텍처(Microservice Architecture) 등장 (0) | 2023.12.19 |