MSA 의 장점 중에는 서비스 별로 필요에 따라 다른 기술 스택을 사용할 수 있다는 점이다. 각 도메인 데이터를 독립적으로 관리해서 서로의 데이터 타입과 스키마에 맞는 DB 를 선택할 수 있다.
수요에 따라 저장소의 크기를 변화시키거나, 다른 서비스의 장애로부터 격리할 수 있다.
하지만 여러 서비스에 걸친 트랜잭션과 여러 서비스 DB 간의 데이터 정합성에 대해 생각해보면 분산 트랜잭션 관리가 중요하다.
주문 서비스, 결제 서비스, 장바구니 서비스, 배송 서비스로 나뉘어진 MSA e-커머스 어플리케이션 예시
ACID 의 유지
격리 수준 유지 : 동시에 여러 트랜잭션이 처리될 때, 한 서비스에서 처리 중인 데이터를 다른 서비스에서 조회하면, 볼 수 있도록 허용할지 말지의 수준을 결정해야 한다.
Two-Phase Commit protocil(2PC), 분산 트랜잭션을 구현할 때 많이 사용하는 패턴으로 Coordinator component 가 각각의 트랜잭션이 수행 가능한지 서비스에 확인하는 Prepare Phase, 1 Phase 에서의 응답에 따라 커밋할지, 응답할지를 결정하는 Commit Phase
로컬 트랜잭션의 순서를 이용해서 트랜잭션을 관리한다. 보상 트랜잭션이 로컬 트랜잭션을 롤백할 수 있다. 사가 패턴의 두 원칙은 보상 트랜잭션이 멱등적이고, 재시도 가능해야한다는 것이다.
Saga 패턴의 두 원리를 보장하는 것이 Saga Execution Coordinator(SEC) 다. Saga flow 를 구현하는 중심 컴포넌트고, 분산 트랜잭션 이벤트 로그를 포함하고있다. 실패가 발생하면 SEC 가 영향 받은 서비스에 보상 트랜잭션이 실행되도록 해야한다.
각 마이크로서비스는 다음 마이크로서비스가 수행할 이벤트를 발생시킨다.
Greenfield 환경(새로 시작하는 프로젝트)에 적합
SEC 는 독립적인 컴포넌트이거나 마이크로서비스에 내장되어있다.
성공적인 Saga flow
실패시의 보상 트랜잭션
- 결제 시스템에 장애가 발생해서 SEC가 보상 트랜잭션을 실행한다.
- 보상 트랜잭션이 실패해도, SEC는 성공할때까지 시도해야 한다.(Saga 의 두가지 원칙)
관련 framework
하나의 Orchestrator 가 모든 트랜잭션 상태 관리를 책임지는 패턴, 트랜잭션중 어떤 마이크로서비스가 실패하면, Orchestartor 가 필요한 보상 트랜잭션을 실행한다.
Brownfield 환경(기존의 레거시가 섞인 프로젝트) 에 적합