📌 개요
MSA(Microservice Architecture) 환경에서는 하나의 요청이 여러 서비스와 DB를 거치게 된다.
이때 데이터 정합성을 유지하는 것이 매우 중요하며, 이를 해결하기 위한 대표적인 방법이 다음 두 가지이다.
- 2PC (Two-Phase Commit)
- Saga Pattern
1️⃣ 2PC (Two-Phase Commit)
✅ 정의
여러 서비스(또는 DB)의 트랜잭션을 하나처럼 묶어서 전부 성공하거나 전부 실패하도록 보장하는 방식
🔄 동작 방식
1. Prepare 단계
각 서비스에 commit 가능 여부를 확인
Coordinator → Payment: 준비됐어?
Coordinator → Lecture: 준비됐어?
Payment → OK
Lecture → OK2. Commit 단계
모든 서비스가 OK면 commit
Coordinator → Payment: commit
Coordinator → Lecture: commit❌ 하나라도 실패 시
Coordinator → ALL: rollback💡 특징
- 강한 일관성 보장 (Strong Consistency)
- 모든 서비스가 동시에 성공/실패
❗ 단점
1. 성능 문제
- 모든 서비스가 응답할 때까지 대기
- 락(Lock) 유지 → 병목 발생
2. 결합도 증가
- 서비스 간 강하게 연결됨
3. 장애 전파
- 하나의 서비스 장애 → 전체 실패
4. MSA에 부적합
- 독립적인 서비스 구조와 충돌
2️⃣ Saga 패턴
✅ 정의
각 서비스가 독립적으로 트랜잭션을 처리하고,
문제가 발생하면 보상 트랜잭션(rollback)으로 정합성을 맞추는 방식
🔄 동작 방식
정상 흐름
1. 결제 성공
2. 수강 등록
3. 알림 전송실패 흐름 (보상 트랜잭션)
1. 결제 성공
2. 수강 등록 실패 ❌
3. 결제 취소 (보상)💡 특징
- 이벤트 기반 처리 (Kafka 등)
- 느슨한 결합 (Loose Coupling)
- 높은 확장성
❗ 단점
1. 구현 복잡도 증가
- 보상 로직 설계 필요
2. 일시적 데이터 불일치 가능
- 최종 일관성(Eventual Consistency)
3️⃣ Saga 패턴 방식 2가지
1. Choreography (분산 방식)
- 각 서비스가 이벤트를 구독하여 다음 작업 수행
Payment → 이벤트 발행
Lecture → 이벤트 수신 후 처리
Notification → 이벤트 수신 후 처리장점
- 단순
- 중앙 제어 없음
단점
- 흐름 파악 어려움
- 서비스 간 의존 증가
2. Orchestration (중앙 제어 방식)
- 하나의 오케스트레이터가 전체 흐름 제어
Orchestrator → Payment
Orchestrator → Lecture
Orchestrator → Notification장점
- 흐름 명확
- 관리 용이
단점
- 중앙 서비스 의존
4️⃣ 2PC vs Saga 비교
| 항목 | 2PC | Saga |
|---|---|---|
| 일관성 | 강한 일관성 | 최종 일관성 |
| 성능 | 느림 | 빠름 |
| 결합도 | 높음 | 낮음 |
| 장애 영향 | 전체 영향 | 부분 영향 |
| MSA 적합성 | ❌ | ✅ |
5️⃣ 실제 프로젝트 적용 예시 (교육 플랫폼)
🎯 결제 흐름
Saga 적용
1. 결제 요청
2. Payment Service → 결제 성공
3. Kafka 이벤트 발행
4. Lecture Service → 수강 등록
5. Notification Service → 알림 발송
❌ 실패 시
→ Payment Service → 결제 취소6️⃣ 왜 Saga를 선택했는가?
- MSA 환경에서는 서비스 간 독립성이 중요
- 2PC는 성능 저하와 결합도 문제 발생
- Saga는 이벤트 기반으로 확장성과 유연성을 제공
🚀 결론
- 2PC는 강한 일관성을 제공하지만 MSA 환경에서는 비효율적
- Saga는 복잡하지만 확장성과 성능 면에서 더 적합
- 실무에서는 대부분 Saga 패턴을 사용
📌 한 줄 정리
2PC는 “모두 함께 성공하거나 실패”,
Saga는 “각자 처리하고 문제 생기면 되돌린다”
안 되면 될 때까지