[MSA] 3편 – 분산 트랜잭션과 데이터 일관성: 왜 데이터는 쉽게 깨지는가?

1. 문제 상황

MSA 환경에서는 하나의 비즈니스 로직이 여러 서비스에 걸쳐 실행됩니다.

예를 들어, 주문(Order) 기능을 수행할 때 다음과 같은 흐름이 발생할 수 있습니다.

• Order Service → 주문 생성
• Payment Service → 결제 처리
• Delivery Service → 배송 생성

이 과정에서 하나의 요청이 여러 서비스의 데이터 변경을 포함하게 됩니다.

 

2. 문제의 핵심

이때 가장 큰 문제는 모든 작업이 하나의 트랜잭션으로 묶이지 않는다는 것입니다.

• 주문은 성공했지만
• 결제는 실패하고
• 배송은 생성되지 않는

데이터 불일치(Inconsistency) 문제가 발생할 수 있습니다.

 

3. 왜 이런 문제가 발생하는가?

Monolithic vs MSA

Monolithic

• 하나의 DB
• 하나의 트랜잭션

ACID 보장 가능

 

MSA

• 서비스마다 DB 분리
• 트랜잭션 분산

하나의 트랜잭션으로 묶을 수 없음

 

4. 기존 해결 방식의 한계 (2PC)

과거에는 이를 해결하기 위해 2PC(Two Phase Commit) 방식이 사용되었습니다.

2PC란

1. Prepare 단계 (모든 서비스 준비)
2. Commit 단계 (모두 성공 시 반영)

문제점

• 성능 저하
• 네트워크 의존성 증가
• 장애 발생 시 전체 블로킹

MSA 환경에서는 거의 사용되지 않음

 

5. 현대적인 해결 방법: Saga 패턴

MSA에서는 Saga 패턴을 통해 분산 트랜잭션 문제를 해결합니다.

핵심 개념

“하나의 큰 트랜잭션” 대신 “여러 개의 작은 트랜잭션 + 보상 로직”

 

6. Saga 동작 흐름

정상 흐름

Order 생성 → Payment 성공 → Delivery 생성 → 완료

실패 흐름

Order 생성 → Payment 실패 → Order 취소 (보상 트랜잭션)

 

실패 시 이전 작업을 되돌리는 방식

 

7. Saga 방식 2가지

1) Choreography (이벤트 기반)

• 서비스들이 이벤트를 발행
• 다른 서비스가 구독하여 처리

장점:

• 느슨한 결합

단점:

• 흐름 파악 어려움

2) Orchestration (중앙 제어)

• 하나의 Orchestrator가 전체 흐름 제어

장점:

• 흐름 명확

단점:

• 중앙 의존성 발생

8. 데이터 일관성의 변화

MSA에서는 ACID 대신 다음 개념을 사용합니다.

Eventual Consistency (최종 일관성)

• 즉시 일관성은 보장하지 않음
• 일정 시간이 지나면 일관성 유지

실무에서 가장 많이 사용하는 방식

 

9. 실무에서 반드시 필요한 개념

Outbox Pattern

• DB 트랜잭션과 이벤트 발행을 함께 처리
• 데이터 유실 방지

Idempotency (멱등성)

• 같은 요청을 여러 번 처리해도 결과 동일

중복 처리 방지

 

10. 프로젝트 적용 예시

현재 프로젝트에서도 다음과 같은 상황이 발생할 수 있습니다.

• 주문 생성 성공
• 결제 실패
• 배송 생성 실패

해결 전략

• Saga 패턴 적용
• 이벤트 기반 처리 (Kafka)
• 실패 시 보상 트랜잭션 수행

예를 들어:

• 결제 실패 → 주문 상태 CANCEL 변경
• 배송 실패 → 결제 취소 처리

11. 정리

MSA 환경에서는 하나의 트랜잭션이 여러 서비스에 걸쳐 실행되기 때문에
데이터 일관성이 깨지는 문제는 자연스럽게 발생합니다.

이를 해결하기 위해서는 기존의 강한 일관성 대신
최종 일관성(Eventual Consistency)을 기반으로 설계해야 하며,

Saga 패턴과 같은 구조를 통해
데이터 정합성을 유지하는 것이 중요합니다.