금융IT와 MSA - 2. SAGA 패턴

1편 MSA의 필요성 : https://subbak2.tistory.com/46

금융IT와 MSA - 1. 왜 필요한가?

 

금융업 특성상 데이터 결합도가 높고 대외기관 과의 트랜잭션도 많은 편이다. 

MSA를 금융IT에 도입할 경우 아래와 같은 문제가 발생할 수 있다.

 

아래 그림처럼

1) A에서 시작한 트랜잭션이

2) B 서버를 거쳐

3) 대외기관까지 갔다가 

4) 다시 B서버에 도착한 상황에서 

A서버의 WAS가 DOWN 되는 장애가 발생했다면

 

상상하기 싫은 상황이다. 하지만 충분히 발생할 수 있다.

 

Monolithic한 구조였다면 1개 서버에서의 failover를 고민하면 됐지만, 

MSA 구조에서는 다른 서버와의 연계를 반드시 고려해야한다.

 

위와 같은 상황에서 아래와 같은 방법으로 해결할 수 있다.

 

1. WAS를 단순 재가동하는 상황

즉, 장애가 발생해 갑자기 WAS가 중단되는 상황이 아니라, 운영자가 WAS 재가동을 하는 상황이다.

이 경우에는 비교적 단순한 방법으로 해결할 수 있다.

 

2개 이상의 WAS를 순차 재가동한다고 했을때,

1) WAS를 서스펜드 모드(신규 거래 유입 차단)로 바꾸고, 

2) 기존 온라인 트랜잭션이 모두 처리될때까지 대기

3) 일정 시간이 지나도 안끝나는 스레드가 있다면 강제 shut down

4) WAS Graceful Shutdown 수행

 참고 : https://stackoverflow.com/questions/56040542/spring-boot-graceful-shutdown

 

 

2. 장애가 발생해서 WAS가 비정상 SHUTDOWN 되는 상황

어떤 일이 생길지 모르니 MSA에서는 1번 상황이 아닌 이 상황을 반드시 고려해야한다.

즉, 보상거래가 이뤄져야 하는데 자주 쓰는 디자인 패턴이 SAGA패턴이다.

( TMI : SAGA는 약자가 아니며 Long Lived Transactions 을 의미하는 단어이다)

https://stackoverflow.com/questions/63319018/why-the-pattern-for-microservices-distributed-transactions-named-as-saga

 

SAGA 패턴에는 2가지 종류가 있다.

 

1) 코레오그래피 (Choreography-Based Saga)

2) 오케스트레이션 (Orchestration-Based Saga)

 

2가지의 장단점이 명확해 서버 성격에 맞게 패턴을 적용해야한다.

 

 

1) 코레오그래피 (Choreography-Based Saga)

- 각각의 로컬 트랜잭션이 다른 Micro 서비스를 이벤트로 소싱하는 방식

- 특징 : Kafka와 같은 별도의 메시지 브로커 필요

- 장점 : 도메인간 종속성 낮아짐

- 단점 : 트랜잭션이 많은 서비스의 경우 문제상황 발생시 거래 추적이 어려움

 

 

 

 

 

2) 오케스트레이션 (Orchestration-Based Saga)

- Orchestrator가 중앙에서 여러 로컬 트랜잭션을 관리

- 장점 : 롤백 관리가 쉬움

- 단점 : 중앙집중적 형태이므로 도메인 커플링이 높아짐

          모든 트랜잭션을 Orchestrator가 관리하기 때문에 로직이 복잡해짐

 

- 오케스트라를 생각하면 이해하기 쉽다.

  지휘자에 지휘에 맞춰 일사불란하게 움직이는 관현악단처럼,

분산 트랜잭션을 관리하는 Orchestrator가 중앙에서 여러 로컬 트랜잭션을 관리하는 형태이다.

 

 

참고 : https://microservices.io/patterns/data/saga.html