분산 트랜잭션 MSA - SAGA

[skarltjr]

문제 :

• MSA 아키텍처를 구성하기 어려운 이유 중 하나는 트랜적션의 문제
• 기존의 Monolithic 환경에서는 DBMS가 기본적으로 제공해주는 트랜잭선 기능을 통해서 데이터 commit이나 rollback을 통해서 일관성있게 관리.
• 그러나 Application 과 DB가 분산되면서 해당 트랜잭션 처리를 단일 DBMS에서 제공하는 기능으로는 해결할 수 없다.

대안 1: Two-Phase Commit

예를들어 분리된 각각의 A service / B service가 존재한다고 생각해보자
b에서 발생한 실패로 a도 롤백을 해야하는 상황

• 2 phase commit의 경우 중앙에서 트랜잭션을 통제하는 글로벌 트랜잭션 매니저인 코디네이터가 존재한다.
• 동작 과정 1 : 각 서비스에게 커밋 준비가 완료된 상태인지 묻고 응답을 전달받는다.
• 
• 동작 과정 2. 하나라도 실패가 발생한 경우 각 서비스에게 롤백 요청을 전달한다.
• 만약 둘 다 커밋 준비가 완료되었다면 커밋을 수행하도록 요청을 전달하고 응답을 받는다.
• 

그러나 이 방식에는 치명적인 문제점이 존재한다.

1. 단일 장애 지점
- 만약 코디네이터가 망가지면 양 서비스 모두 장애가 전파된다.
- 이게 MSA의 철학과 일치하는것인가? 아니라고 생각한다.

2. 너무 많은 통신으로 인해 성능 저하 
3. 확장성이 떨어진다. 2개 이상의 서비스가 묶여있다면..

[skarltjr]

대안 2 : SAGA패턴

• Two-Phase Commit의 단점을 보완
• 마이크로서비스들끼리 이벤트를 주고 받아 특정 마이크로서비스에서의 작업이 실패하면 이전까지의 작업이 완료된 마이크서비스들에게 보상 (complemetary) 이벤트를 소싱함으로써 분산 환경에서 원자성(atomicity)을 보장하는 패턴

  즉 한 번에 모든 트랜잭션을 관리할 수 없다.
  최종적인 일관성을 맞추겠다.

• saga pattern 종류

  
  saga pattern에는 크게 두 종류가 있다.

Choreography & Orchestration

- Orchestration방식

Orchestration 방식은 중앙 집중식 방식이라는것으로부터 장점,단점이 존재한다. 장점 :

• 트랜잭션 상태(흐름)을 파악하기 용이
• 중앙에서 설정등 관리 용이

단점 :

• 단일 장애 지점
• 서비스들간 강한 결합

작은 서비스에선 간편하게 사용할 수 있지만 결국 확장과 단일 장애지점이라는 한계가 명확

- Choreography 방식

각각 서비스끼리 이벤트에 기반한 통신 보상 트랜잭션을 통한 최종 일관성

장점 :

• 서비스간 느스한 결합
• 각 서비스마다 자신의 책임이 있기 때문에 수정에 용이하고 확장성 증가

단점 :

• 트랜잭션 상태 파악 어려움
• 복잡성

[skarltjr]

Choreography

- Choreography 방식은 서비스끼리 직접적으로 통신하지 않고, 이벤트 Pub/Sub을 활용해서 통신하는 방식
- 프로세스를 진행하다가 여러 서비스를 거쳐 서비스에서 실패가 난다면 보상 트랜잭션 이벤트를 발행

• 
• 

Orchestration

- 중앙 집중식으로 오케스트레이터라는 관리자가 존재
- 실패 이벤트 발생시 관리자에게 이벤트를 전달
- 관리자가 모두에게 롤백 이벤트 전달

•