(더이상 무한 트랜잭션을 피할 수 없.ㄷ ㅏ..)
MSA 아키텍처를 구성하기 어려운 이유 중 하나는
“트랜잭션” 때문입니다.
기존 모놀리식 환경에서는 하나의 DB를 사용하였고,
DBMS가 기본적으로 제공해주는 트랜잭션 기능을 사용해서 데이터 일관성을 유지했습니다.
하지만 MSA환경에서는 여러개의 인스턴스마다 데이터베이스가 하나씩 존재해서,
모놀리식처럼 트랜잭션 처리를 하지 못했습니다.
그래서 이 문제를 해결하기 위해서
SAGA 패턴이 등장했습니다.
각 서비스들끼리 이벤트를 주고 받아서 특정 서비스의 작업이 실패하면,
이전 완료된 서비스 들에게 보상 이벤트를 주어서 원자성을 보장하는 패턴을 말합니다.
SAGA 패턴
여기서 우리가 알 수 있는 점은,
모놀리식에서는 트랜잭션의 관리주체가 DBMS에 있었지만,
MSA 환경에서 SAGA 패턴의 핵심은 트랜잭션의 관리주체가 각 서비스 인스턴스에 존재한다는 것입니다.
이를 위해 각 서비스는 API 로 소통하고, 롤백 처리(보상 트랜잭션)은 각 서비스단에서 구현해야 합니다
SAGA 패턴에도 종류가 2가지 존재합니다.
Choreography based SAGA pattern
각 서비스가 독립적으로 이벤트를 발행하고, 이를 구독한 다른 서비스가 반응하며 작업을 진행하는 방식입니다.
이벤트 기반으로 동작하며, 서비스 간 느슨한 결합(Loose Coupling)을 유지합니다.
각 서비스는 이벤트를 수신하여 작업을 진행합니다.
이때 이벤트는 카프카와 같은 메세지 큐를 사용하여 비동기 방식으로 전달할 수 있습니다.
장점
확장성: 중앙 조정자가 없기 때문에 서비스가 추가되고 시스템이 커져서 병목 현상이 발생할 가능성이 적습니다.
단일 실패 지점(SPOF) 없음: 중앙화된 컴포넌트가 없으므로 특정 부분의 실패가 전체 시스템에 영향을 미치지 않습니다.
유연성: 새로운 서비스나 단계를 추가하기 쉬워 비즈니스 요구사항도 유연하게 반영 가능합니다.
단점
복잡한 흐름 추적: 이벤트가 분산되어 발생하므로 전체 워크플로우를 모니터링하거나 디버깅하기 어렵습니다.
에러 처리 복잡: 실패 시 보상 트랜잭션을 각 서비스가 개별적으로 처리해야 해서 에러 핸들링이 분산되고 복잡해질 수 있습니다.
Orchestration based SAGA pattern
오케스트레이션 사가는 중앙 조정자(Orchestrator)가 존재하며,
이 조정자가 각 서비스에 명령을 내려 트랜잭션 단계를 관리하는 방식입니다.
조정자가 전체 워크플로우를 제어합니다.
중앙 조정자를 두어서 전체 트랜잭션 흐름을 관리하고 각 서비스에 트랜잭션을 요청합니다.
중앙에서 트랜잭션을 관리하고 복잡성을 줄여서 일관성을 유지할 수 있습니다.
장점
명확한 로직: 중앙 조정자가 전체 워크플로우를 관리하므로 프로세스 흐름을 이해하고 추적하기 쉽습니다.
간단한 에러 처리: 실패가 발생하면 조정자가 보상 트랜잭션을 호출하므로 에러 복구 로직이 중앙화되어 관리하기 용이합니다.
복잡한 워크플로우에 적합: 단계가 많거나 조건 분기가 필요한 복잡한 비즈니스 프로세스를 처리하기에 적합합니다.
가시성 향상: 중앙에서 상태를 관리하므로 현재 진행 상황을 파악하기 쉽습니다.
단점
단일 실패 지점(SPOF): 조정자가 다운되면 전체 사가 프로세스가 중단될 수 있어 신뢰성에 영향을 미칩니다.
결합도 증가: 서비스가 조정자의 명령에 의존하므로 코레오그래피에 비해 서비스 간 결합도가 높아질 수 있습니다.
유연성 감소: 새로운 단계나 서비스를 추가하려면 조정자 로직을 수정해야 하므로 변경이 다소 번거로울 수 있습니다.
어떤 방식이 적절할까
물론 개발을 하다보면 당연히 알게되는 사실이겠지만,
절대적으로 옳은 방식은 없죠
무엇이든지 개발상황에 적절한 방식을 선택해서 사용하면 됩니다.
그래서 나름대로 어떤 상황에 어떤 방식이 적절할지 생각해보았습니다.
코레오그래피
1. 서비스가 독립적으로 운영된다.
2. 이벤트 기반 통신이다
3. 서비스 확장성이 좋다.
4. 초기 설계가 쉽다
이러한 점들을 종합하자면,
프로젝트 초기 단계에서 빠르게 SAGA패턴을 적용해야 한다면
코레오 그래피 방식이 적절할 것입니다.
오케스트레이션
1. 서비스가 많아지더라도 비지니스 로직을 중앙에서 관리 가능하다
2. 초기 설계가 어렵다
오케스트레이션 방식은
구현하기 어렵고 초기 설계에서 시간을 많이 잡아먹기 때문에
추후 서비스 규모가 커지면 도입하기 적절할 것입니다.
'Back-End' 카테고리의 다른 글
| DI 패턴을 사용하여 IoC 설계 원칙을 구현하고 있다 (0) | 2025.03.31 |
|---|---|
| Kafka를 사용하는 이유 (0) | 2025.03.28 |
| Path Variable과 Request Param 의도는 다르다 (차이점) (0) | 2025.03.19 |
| MSA에서 멀티모듈을 도입하게된 이유 (멀티레포, 모노레포, SpringBoot) (0) | 2025.03.16 |
| 대규모 시스템을 설계하기 전에 고려해봐야 할 것들 (0) | 2025.03.12 |