SAGA 패턴은 뭘까?
msa 환경에서 분산 트랜잭션을 관리하기 위한 패턴이다. 모놀리식 앱에서는 하나의 트랜잭션으로 여러 작업을 처리할 수 있었지만 msa 환경에서는 각 서비스가 자신의 데이터베이스를 갖고 있기에 분산 트랜잭션을 동일한 방식으로 처리하기가 힘들다.
그래서 saga가 등장했다.
SAGA stands for?
saga는 줄임말이 아니다. 노르드 신화나 중세 북유럽의 서사시(Saga)라는 뜻에서 유래된 말이다.
- saga는 여러 개의 로컬 트랜잭션의 집합
- 각 서비스는 자신의 데이터베이스에 로컬 트랜잭션을 수행하고, 다음 서비스로 이벤트를 전달
- 중간에 오류가 발생하면, 보상 트랜잭션을 실행해서 이전 상태로 롤백
SAGA의 두 가지 방식
1. Choreography
중앙화 된 컨트롤러 없이 서비스들이 서로의 이벤트들을 교환하며 처리하는 방식을 말한다. 즉 실제 환경에 빗대어 보자면 client request 이후 특정 서비스가 전달 받아 처리를 관장하는 것이 아닌 event hub 또는 kafka 와 같은 event 관련된 리소스를 통해 처리하는 것이라고 보면 된다.
| Benefits | Drawbacks |
|---|---|
| 적은 서비스들을 가진 간단한 구조에 탁월함 | 새로운 단계나 서비스를 추가할 때 어느 부분에 적용해야 할지 파악이 어려워진다. |
| coordination에 특정 서비스가 필요 없다. | saga component들 간 상호 의존성이 있는 부분이 위험할 수 있다. |
| 하나의 장애가 전체의 장애가 되진 않는다. | integration test가 힘들다. 모든 서비스가 돌아야 할 수도 있다. |
2. Orchestration
중앙화 된 컨트롤러가 각 서비스들 사이의 모든 transaction을 관리하는 방식을 말한다. 컨트롤러는 각 요청들의 trasaction 상태를 분석하여 서비스에 연계하거나 보상 transaction과 같은 처리가 필요한 경우 실행할 수 있게 관리하는 역할을 한다.
| Benefits | Drawbacks |
|---|---|
| 복잡한 workflow나 새로운 서비스를 도입하는데 이점이 있음 | 중앙 컨트롤하는 로직 설계가 복잡함 |
| 상호 의존성이 적음. 컨트롤하는 주체가 있기 때문. | 컨트롤러에 장애가 생기면 전체 장애로 커짐 |
어떤 방식이 좋을까?
상황에 맞게 사용하는 것이 중요하다.
Choreograhy가 좋은 상황
- 마이크로서비스의 수가 적고 간단한 트랜잭션으로 구성이 가능할 때
- 서비스 간 결합도를 낮추고 싶을 때
- 이벤트 기반 아키텍처가 기본일 때 - 예: 주문 생성 -> 결제 요청 -> 배송 예약 등에서 각 서비스가 이벤트만 받아 처리할 때
Orchestration이 적합한 상황
- 서비스가 많고 transaction 순서가 명확하게 컨트롤 되어야 할 때
- 롤백 / 보상 로직이 복잡한 경우 - 비즈니스 흐름을 하나의 코드 / 시각화된 흐름으로 보고 싶을 때
- 예: 보험 청구, 여행 예약 (항공 + 호텔 + 렌터카) 같은 복잡한 흐름
결론
단순하거나 이벤트 기반일 경우 -> Choreography
복잡하거나 transaction 흐름 제어가 중요한 경우 -> Orchestration
마치며
saga는 보상 transaction이 중요한 경우에 사용을 하자. 언제나 그렇듯 saga, cqrs 둘 다 좋으나 simple is the best. 간단하게 구성이 끝날 수 있다면 그게 가장 좋은 아키텍처다.
n년차 눕눕