MSA Transaction 전략 (LLTs) - SAGA 패턴

MSA의 Transaction 이란

MSA(Microsoft System Architecture) 컨텍스트에서 트랜잭션은 단일 작업 단위로 취급되는 작업 시퀀스를 말함
MSA에서 트랜잭션은 분산 시스템 전체에서 데이터 일관성과 무결성을 보장하는 데 사용된다.

예를 들어 거래에 한 은행 계좌에서 다른 은행 계좌로 돈이 이체되는 경우 거래가 올바르게 완료되고 돈이 이체되는지 확인되어야 함. 트랜잭션 중에 네트워크 오류 또는 데이터베이스 오류와 같은 오류가 발생하면 트랜잭션을 원래 상태로 롤백하여 데이터가 일관되고 정확하게 유지되도록 해야 함. 이는 오류를 견디고 데이터 일관성과 무결성을 보장할 수 있는 안정적이고 강력한 분산 시스템을 구축해야 한다는 말

 

---

SAGA 패턴이란

1987년 발간된 SAGAS라는 제목의 논문에서 LLTs(Long Lived Transactions)를 표현하기 위해 사용된 말
event가 진행되는 과정을 SAGA라고 표현 함

---

Choreography Saga 패턴

 

전체적인 프로세스에서 실패가 난 지점으로부터 event의 프로세싱 파이프라인을 거슬러 올라가면서 롤백처리하는 패턴

단점:
간단한 MSA 구조에서는 사용할 만 하지만, 확장성에서 불리함을 갖는다.
파이프라인이 길어지면, 롤백에 대한 프로세싱이 수평적으로 길어진다.
프로세스가 추가될 때마다 관리 포인트가 배로 늘어나는 구조
scale out 구조에서 롤백해야 할 저장소/서버에 대한 관리가 추가적으로 관리되어야 한다.

---

Orchestration SAGA Pattern

transaction이 필요한 서버 중간에 orchestration Server가 위치한다.
해당 서버는 transaction에 대한 정보를 가지고 있으며, 순서대로 프로세싱이 일어날 수 있도록 관리를 한다.
또한 도중 실패 응답에 대해서 보상 이벤트를 발행하는 주체가 된다.

 

---

SAGA 패턴 적용 예제

ibm cloud architecture with SAGA Pattern

 

1. 주문 생성 요청 → OrderServiceSaga에서 OrderCreatedEvent 생성 후 publish
2. event 생성 성공 후 orderId 생성 후 응답
3. 항해 예약 cmd 생성 및 publish
4. Voyage Service에서 ReserveVoyageCmd를 subscribe 하여 처리
5. Voyage Service에서 VoyageAllocatedEvent publish
6. saga에서 VoyageAllocatedEvent subscribe
7. 냉동선 예약 cmd publish
8. Container Service에서 ReserveReeferCmd를 subscribe 하여 처리
9. Container Service에서 ReeferReserved Event publish
10. saga에서 ReeferReservedEvent를 subscribe
11. 모든 과정이 처리 완료되어 OrderAssignedEvent publish

1 ~ 8 동일
9. Container Service에서 오류 발생, ReservationFailedEvent publish
10. saga에서 reservationFalledEvent를 subscribe 및 롤백 프로세스 시작 이벤트 4 ~ 1 순으로 rollback 진행
11. ReleaseReeferCmd publish
12. container service에서 releaseReeferCmd를 subscribe 하여 8에서 들어온 reserveReeferCmd의 상태를 release로 변경 및 데이터 처리
13~14. container service에서 ReeferReleasedEvent를 publish 하고 saga에서 subscribe 하여 처리
15. saga에서 deallocVoyageCmd를 publish
16. voyage service에서 deallocVoyageCmd를 subscribe하여 상태 업데이트 및 데이터 롤백
17~18. VoyageDeallocatedEvent를 발행 및 구독하여 처리
19. 주문 취소 이벤트를 publish

---

Coachbase 예제

전체적인 프로세스는 위 IBM 예제와 같다.
다만 event가 아닌 channel 관점에서 플로우를 표현했다.

 

 

---

고려사항

Transaction Id

최초 요청 / 최초 프로세싱 과정의 결과물로 unique 한 id를 생성하야 한다.
해당 id를 바탕으로 롤백 및 처리 결과, 처리 현황등을 조회할 수 있다.

Reply Address

orchestrator 또는 각 서비스에서 message를 발행할 때 자신의 주소에 대한 정보를 실어서 publish 해야 한다.
그래야 scale out 시 일관된 서버/위치로 메시지를 응답할 수 있다.

Idempotent

cmd / event의 처리는 idempotent 해야한다.
상태를 가지거나 순서에 영향을 받는 식으로 구현된다면, 메시지가 2번 처리되거나 하는 상황에서 시스템적인 꼬임이 발생할 수 있다.

Asynchronous Communication

SAGA 패턴은 비동기식 프로세스를 지향하는 구조이다.
비동기식으로 진행되기 위하여, orchestrator는 충분한 정보를 메시지에 넣어주어야 한다.

 

---

REFERENCE

• https://ibm-cloud-architecture.github.io/eda-saga-orchestration/ 
• https://www.couchbase.com/blog/saga-pattern-implement-business-transactions-using-microservices-part-2/