분산 트랜잭션의 도전 과제
마이크로서비스 아키텍처에서 여러 서비스에 걸친 데이터 일관성 유지는 핵심 과제입니다. 정보처리기사 시험에서는 Saga 패턴, 이벤트 소싱, CQRS, 2PC와 같은 분산 트랜잭션 패턴이 주요 출제 범위입니다.
Saga 패턴
분산 트랜잭션을 로컬 트랜잭션의 연속으로 분해하고, 실패 시 보상 트랜잭션(Compensating Transaction)으로 롤백하는 패턴입니다.
- 코레오그래피(Choreography) Saga: 각 서비스가 이벤트를 발행하고 다른 서비스가 구독. 중앙 조정자 없음. 느슨한 결합, 디버깅 어려움
- 오케스트레이션(Orchestration) Saga: 중앙 오케스트레이터가 각 서비스 호출 순서 조정. 복잡한 흐름 관리 용이, 중앙 집중화
주문 처리 Saga 예시: 결제 → 재고 차감 → 배송 예약. 배송 실패 시 재고 보상 → 결제 환불 순으로 보상 트랜잭션 실행
이벤트 소싱(Event Sourcing)
상태를 직접 저장하는 대신 상태 변경을 일으킨 이벤트의 시퀀스를 저장합니다. 현재 상태는 이벤트를 재생(Replay)해 도출합니다.
- 장점: 완전한 감사 로그, 임의 시점의 상태 재현, 이벤트 기반 통합 용이
- 단점: 쿼리 복잡성, 이벤트 스키마 변경 어려움, 이벤트 저장소 증가
- 스냅샷(Snapshot): 이벤트 수가 많을 때 특정 시점 상태를 저장해 Replay 최적화
CQRS(Command Query Responsibility Segregation)
읽기(Query)와 쓰기(Command) 모델을 분리하는 패턴입니다. 이벤트 소싱과 자주 함께 사용됩니다.
- Command Side: 쓰기 최적화 모델. 도메인 로직 검증, 이벤트 발행
- Query Side: 읽기 최적화 모델(Read Model/View). 비정규화된 데이터, 빠른 조회
- 최종 일관성(Eventual Consistency): Command 처리 후 이벤트 전파로 Query 모델이 비동기적으로 업데이트
2PC와 3PC, TCC
- 2PC(2-Phase Commit): 준비 단계(Prepare) + 커밋 단계(Commit). 코디네이터 단일 장애점, 차단 프로토콜 문제
- 3PC(3-Phase Commit): 준비 + 사전 커밋 + 커밋. 블로킹 문제 완화, 네트워크 분할 취약
- TCC(Try-Confirm-Cancel): 애플리케이션 수준 2PC. Try(자원 예약) → Confirm(확정) or Cancel(취소). 비즈니스 트랜잭션에 적합
정보처리기사 기출 핵심 정리
- Saga 패턴 = 보상 트랜잭션으로 분산 롤백, 코레오그래피 vs 오케스트레이션
- 이벤트 소싱 = 상태 변경 이벤트를 저장, Replay로 현재 상태 도출
- CQRS = Command(쓰기)와 Query(읽기) 모델 분리
- 2PC = 코디네이터 중심, 단일 장애점 문제
- TCC = 애플리케이션 수준 보상 트랜잭션