트랜잭션 관리 → MSA에서 데이터 일관성을 보장하는 방법 SAGA (Orchestrator) - 테코톡 1차 자료조사

트랜잭션이란?

트랜잭션(Transaction)은 데이터베이스에서 하나의 작업 단위를 의미하며, 다음의 4가지 특성(ACID)을 만족해야 합니다.

• Atomicity (원자성): 모두 성공하거나 모두 실패해야 함
• Consistency (일관성): 트랜잭션 전후 상태가 데이터베이스 규칙을 위배하지 않음
• Isolation (격리성): 동시에 수행되는 트랜잭션들이 서로 간섭하지 않음
• Durability (지속성): 트랜잭션이 성공하면 그 결과는 영구히 저장됨

---

단일 DB vs 분산 트랜잭션 비교

구분단일 DB 트랜잭션분산 트랜잭션

구조	하나의 DB에 의존	여러 DB, 여러 마이크로서비스
장점	ACID 쉽게 보장 가능	MSA 구조에 적합
단점	서비스 분리 어려움	성능 저하, 복잡성 증가
트랜잭션 방식	DB 자체 트랜잭션	2PC, SAGA, 이벤트 기반 등

---

MSA 설계에서 분산 트랜잭션 시 발생 가능한 문제들

1. 💥 부분 실패 (Partial Failure)

• 하나의 마이크로서비스는 성공하고, 다른 하나는 실패할 수 있음
• 예시 (회원가입):
  • auth-service에서는 사용자 계정 정보가 저장되었지만,
  • user-service에서는 프로필 정보 저장이 실패 → 고아 계정 생성

2. 🌀 트랜잭션 지연 / 성능 저하

• 분산 트랜잭션은 모든 서비스 응답 대기
• 네트워크 지연 또는 병목이 전체 처리 시간에 영향
• 예시: 주문 시 order, payment, inventory 서비스 중 하나가 느리면 전체 UX 저하

3. 🔐 락 과다로 인한 병목

• 각 서비스가 자원을 락한 채 대기 → 데드락 가능성 증가

4. 🧨 롤백 처리 어려움 (보상 트랜잭션 기반)

• 수동 보상이 필요한 경우 복잡한 로직 필요
• 외부 시스템과 동기화 시 어려움 가중
• 예시: 결제 완료 후 재고 차감까지 했는데 배송 등록에서 실패하면?
  • 결제 취소 + 재고 복구 필요 (복구도 실패할 수 있음)

---

회원가입 시 분산 트랜잭션 예시

 

1. Auth Service → 비밀번호 암호화 후 사용자 계정 저장
2. User Service → 프로필 정보 저장
3. 실패 발생 시? → Auth 저장 성공 / User 실패 → 데이터 불일치

해결 방법

• SAGA 보상 트랜잭션: Auth 저장 취소
• 중복 확인 / 중간 상태 저장: 재시도 유도

---

분산 트랜잭션 문제 유형 요약

문제	설명	대표 사례
부분 실패	일부 서비스만 성공	Auth 저장, User 실패
지연	서비스 간 응답 대기	주문 시스템
락 병목	동시에 자원 점유	동시 결제 처리
보상 복잡	롤백 어려움	결제 후 재고 복원

---

 

SAGA (Orchestrator) 패턴 구조

[Saga Orchestrator]
        |
        |--- Step 1. Auth Service - 계정 생성 요청
        |         ↳ 성공 → Proceed
        |
        |--- Step 2. User Service - 프로필 저장 요청
        |         ↳ 성공 → 전체 성공 반환
        |         ↳ 실패 → 보상 트랜잭션 실행
        |
        |<-- Step 3. Auth Service - 계정 삭제 요청 (Rollback)

• 각 서비스는 로컬 트랜잭션 수행
• 실패 시 → 이전 서비스에 보상 트랜잭션(Undo) 호출

 

SAGA 전략 요소

전략 요소	설명
Orchestrator	중앙 컨트롤러 (Auth 내 처리 or 별도 구성)
보상 트랜잭션	이전 단계 취소 로직 (예: 계정 삭제)
메시지 기반 통신	Kafka, RabbitMQ 활용 (Choreography 방식 가능)

 

장점

• 서비스 간의 결합도가 낮아져, 구현 및 테스트가 상대적으로 쉬워진다.
• 트랜잭션 실패 시, 보상 트랜잭션을 통해 이전 상태로 복원할 수 있어 데이터 정합성 유지에 유리하다.

단점

• Orchestrator 서비스가 추가되며, 인프라와 로직 구현이 복잡해질 수 있다.
• 보상 트랜잭션을 설계하고 관리하는 데 추가적인 노력과 고려가 필요하다.

---

Orchestration 적용 회원가입 예시

     +--------------------+
     | Saga Orchestrator  |
     +---------+----------+
               |
 ┌─────────────▼──────────────┐
 │     Auth Service           │
 │ - 계정 저장                │
 └─────────────┬──────────────┘
               |
 ┌─────────────▼──────────────┐
 │     User Service           │
 │ - 프로필 정보 저장         │
 │ - 실패 시 Rollback Trigger│
 └─────────────┬──────────────┘
               |
     +---------▼----------+
     | 보상 트랜잭션 실행 |
     | - Auth 계정 삭제   |
     +--------------------+

1. auth-service에서 encodedPassword로 계정 생성
2. user-service로 UserCreateRequestDto 전달
3. user-service에서 실패 시, Orchestrator가 auth-service에 계정 삭제 요청
4. 전체 실패 → 사용자에겐 "회원가입 실패" 메시지 반환 

 

 

주요 장점

• 서비스 간 강한 결합 없이 정합성 보장
• 실패 시 보상으로 전체 롤백 가능
• 일부 실패에도 시스템 복원 가능성 높음

주의사항 & 대응

이슈	대응 방법
보상 트랜잭션 실패	재시도 메커니즘 + DLQ(Dead Letter) 사용
메시지 유실	Kafka 사용 시, 메시지 지속성 설정 필요 (acks=all, replication)
중복 요청	Redis Lock 또는 RequestId로 처리

---

SAGA 패턴이란

SAGA 패턴은 분산 트랜잭션을 서비스 간의 독립적인 로컬 트랜잭션으로 나누고,  순차적으로 처리한다.

각 로컬 트랜잭션은 데이터베이스를 업데이트한 다음에 다음 로컬 트랜잭션을 트리거하는 메시지 또는 이벤트를 게시한다. 트랜잭션의 결과에 따라 롤백이 필요한 경우, 보상 트랜잭션을 진행한다.

각 단계에서 실패가 발생하면 보상 트랜잭션(Compensating Transaction)을 통해 이전 작업을 되돌리는 패턴 

(서비스에서 트랜잭션 처리에 실패할 경우, 그 서비스의 앞선 다른 서비스에서 처리된 트랜잭션을 되돌리게 하는 트랜잭션)

• 각 트랜잭션 후 이벤트 또는 메시지를 발행하여 다음 트랜잭션 트리거
• 실패 시 → 이전 단계로 보상 트랜잭션 수행 (Compensating Transaction)

특징

• 각 서비스는 자신의 DB에만 트랜잭션 수행
• 실패 시 직전 단계부터 역순으로 보상 로직 실행
• 구현 방식
  • Orchestration: 중앙 제어자 존재
  • Choreography: 이벤트 기반, 중앙 제어자 없음

장점 요약

• 예: Auth → User 실패 시 → AuthUser 생성 안됨 → 정합성 유지
• 반대도 마찬가지: Auth 저장 실패 → User는 soft-delete 처리 

 

 

https://joobly.tistory.com/69

[Saga 패턴] 마이크로서비스에서 Saga 패턴이란?

https://velog.io/@xeropise1/%EB%B6%84%EC%82%B0-%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98-Distributed-transaction

분산 트랜잭션 (Distributed transaction)

https://baebalja.tistory.com/622

[대규모 시스템 설계] 6. MSA 분산 트랜잭션 관리

https://docs.aws.amazon.com/ko_kr/prescriptive-guidance/latest/modernization-data-persistence/saga-pattern.html

Saga pattern - AWS 권장 가이드

https://giljae.medium.com/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C-%EC%84%9C%EB%B9%84%EC%8A%A4%EC%97%90%EC%84%9C-%EB%B6%84%EC%82%B0-%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98-347af5136c87

마이크로 서비스에서 분산 트랜잭션

https://velog.io/@youngerjesus/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%ED%8C%A8%ED%84%B4-%EB%B6%84%EC%82%B0-%ED%8A%B8%EB%9E%9C%EC%9E%AD%EC%85%98-%EC%B2%98%EB%A6%AC

마이크로서비스 - 분산 트랜잭션 처리 패턴

 

 

---

MSA 환경에서 발생하는 문제점 

동시성 이슈 / 데이터 정합성 문제 

• 중복 요청으로 인한 중복 저장 

• Race Condition: 순서 문제로 인해 잘못된 상태 저장 

• Rollback 불가 문제: 하나의 마이크로서비스는 성공, 다른 하나는 실패한 경우 

 

데이터 일관성을 보장하기 위한 효율적인 방법

✅ 1. SAGA 패턴 

• 각 서비스가 로컬 트랜잭션을 수행한 후, 다음 서비스에 이벤트를 전달 

• 실패 시 보상 트랜잭션(Undo Logic) 수행 

구현 방식 

• Choreography (분산 이벤트 기반): 이벤트 브로커 사용 (예: Kafka) 

• Orchestration (중앙 통제): Saga Coordinator가 서비스 순서를 제어 

✅ 2. 이벤트 기반 아키텍처 

• Kafka, RabbitMQ 등을 통해 비동기 메시지 처리 

• 서비스 간 Coupling 낮추면서, 장애 시 재시도/보상 가능 

✅ 3. 분산 락 사용 

• Redis 등을 활용한 락으로 중복 요청 방지 

• 예: 회원가입 시 email 기준 Lock 

✅ 4. 중복 요청 방지 로직 

• Redis나 DB에 임시 상태 저장 (Processing, Done) 

• 이미 처리된 요청이라면 무시 

✅ 5. 비즈니스 유효성 검증 추가 

• 각 서비스는 자신만의 도메인 유효성 검사를 필수로 수행 

• 요청 순서와 무관하게 일관된 상태 유지 

 

 

핵심 키워드 

#Transaction #ACID #MSA #SAGA #Choreography #Orchestration #EventDriven #EventualConsistency #DistributedLock #RetryPattern #Rollback #Concurrency