콘텐츠로 바로가기
HY_TECH_BASE

Distributed Transactions & Saga Dynamics

여러 서비스에 걸친 원자적 연산을 보장하는 2단계 커밋과, 긴 실행 시간의 비즈니스 정합성을 관리하는 사가(Saga) 패턴의 물리 메커니즘을 다루는 학습 노드입니다.

sys.entry
M

Me

hyunyoun's Blog

posts6 min read

1. Overview

분산 트랜잭션 및 사가 역학(Distributed Transactions & Saga Dynamics, DTS)은 데이터가 여러 서버에 흩어져 있는 환경에서 "전부 성공하거나, 아니면 전부 실패해야 한다"는 원자성(Atomicity)의 철칙을 어떻게 물리적으로 관철할 것인지 다루는 데이터 전술론입니다.

학습자는 단일 DB의 트랜잭션을 넘어 여러 자원(DB, MQ 등)을 하나로 묶는 **2단계 커밋(2-Phase Commit, 2PC)**의 수리적 흐름과 그로 인한 하드웨어 잠금 병목을 배웁니다. 특히, 현대 MSA 환경에서 2PC의 한계를 극복하기 위해 제안된 사가(Saga) 패턴의 보상 트랜잭션 물리학을 익힙니다. 이를 통해 서비스 간 호출이 얽힌 복잡한 비즈니스 시나리오에서도 데이터가 미아가 되지 않도록 보정하는 하이엔드 정합성 설계 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

  • 2-Phase Commit (2PC) Anatomy: 준비(Prepare)와 확정(Commit)의 물리적 단계와 조정자(Coordinator)의 역할
  • 3-Phase Commit (3PC): 2PC의 블로킹 문제를 해결하기 위한 수리적 대안
  • Saga Pattern (Choreography & Orchestration): 비동기 메시징 기반의 단계적 정합성 물리
  • Compensating Transactions: 실패 시 수리적으로 이전 상태를 되돌리는 보상 로직 설계
  • TCC (Try-Confirm-Cancel): 애플리케이션 레벨에서 구현하는 분산 예약 물리학

Out-of-Scope

  • 단일 데이터베이스 내부의 ACID 트랜잭션 상세 (06-01-03 영역에서 분담)
  • 분산 합의 알고리즘(Paxos/Raft)의 내부 리더 선출 상세 (07-02-02 영역에서 분담)

Boundaries

  • DTS vs. Consensus: 합의(07-02-02)가 '로그의 일치'에 집중한다면, DTS는 '서로 다른 데이터 저장소들 간의 비즈니스적 상태 일치'에 집중하여 구분합니다.

3. Counterexample

  • 단순히 "트랜잭션 어노테이션(@Transactional) 쓰기"라 설명하는 것은 DTS 학습이 아닙니다. 왜 2단계 커밋에서 조정자가 죽었을 때 참여자들이 하드웨어 리소스를 잡고 '무한 대기'에 빠지는 물리적 공포를 수리적으로 증명할 수 있어야 하며, 사가 패턴이 ACID 중 'I(Isolation, 격리성)'를 물리적으로 포기함으로써 발생하는 '더티 리드(Dirty Read)'의 위협을 논증하지 못한다면 DTS의 위험성을 이해하지 못한 것입니다.

4. Prerequisites

  • Transaction & Logging Mechanics (Basic): 로컬 ACID 트랜잭션 이해가 필수입니다. (06-01-03 TLM)
  • Theorems & Consistency Dynamics (Recommended): CAP 정리와 결과적 일관성 이해가 권장됩니다. (07-02-01 TCD)

5. Learning Map

  1. The Distributed Gap: 물리적으로 떨어진 두 DB가 어떻게 동시에 '커밋'될 수 있는지 고민합니다.
  2. Atomic Chain: 2단계 절차를 통해 모든 노드의 준비 상태를 확인하고 동시에 발사(Commit)합니다.
  3. Decoupled Reconciliation: '한꺼번에'를 포기하고, '순차적으로' 처리하되 실패 시 되돌리는 시나리오를 짭니다.
  4. Resilient Integrity: 비동기 세계에서 데이터가 최종적으로 일치되게 만드는 수리적 화해(Reconciliation) 기법을 완성합니다.

6. Learning Topics

Basic

Core: 2단계 커밋의 물리 구조 (2-Phase Commit)

  • Why to Learn: 가장 전통적이고 강력한 분산 원자성 보장 도구의 작동 원리를 알기 위해서입니다.
  • What to Learn:
    • Phase 1 (Prepare): 참여할 수 있는지 물리적 의사를 묻고 리소스를 잠그는 단계
    • Phase 2 (Commit/Rollback): 조정자의 최후 명령에 따른 하드웨어 상태 확정
    • Blocking Problem: 조정자 장애 시 모든 참여자가 락(Lock)을 쥔 채 멈추는 물리적 재난
  • How to Learn:
    • 두 대의 DB에 분산 트랜잭션을 걸고, Prepare 단계 이후 네트워크를 끊어 DB 락이 풀리지 않는 현상을 재현 실습
    • 2PC가 네트워크 메시지 왕복 횟수를 얼마나 물리적으로 요구하는지 산출
  • Implement: 조정자 기능을 수행하며 하위 노드들의 투표를 받아 결과를 전송하는 기초 XA_Coordinator

Core: 사가 패턴과 오케스트레이션 (Saga Mechanics)

  • Why to Learn: 락(Lock) 없는 고성능 분산 처리를 위해 ACID를 포기하고 정합성을 잡기 위함입니다.
  • What to Learn:
    • Choreography Saga: 메시지 브로커를 통해 서비스들이 자율적으로 반응하는 물리 방식
    • Orchestration Saga: 중앙 제어기가 전체 실행 순서를 관리하는 수리 모델
    • Forward vs Backward Recovery: 실패 시 앞으로 갈지 뒤로 갈지의 물리적 선택
  • How to Learn:
    • 주문-결제-배송 흐름을 사가 패턴으로 설계하고, 결제 실패 시 주문을 취소하는 보상 트랜잭션의 물리 흐름도 작성 실습
    • 사가 패턴에서 '격리성' 부족으로 인해 발생할 수 있는 데이터 꼬임 사례 분석
  • Implement: 오케스트레이터가 메시지를 발행하며 각 단계의 성공/실패를 기록하는 SagaManager

Practical

Core: 보상 트랜잭션과 TCC 디자인 (Reconciliation Patterns)

  • Why to Learn: 이미 커밋된 물리적 결과를 취소할 수 없는 환경에서 '반대 작업'을 수행하기 위해서입니다.
  • What to Learn:
    • Compensating Transaction: INSERT에 대한 DELETE, 금액 차감에 대한 충전과 같은 수리적 반전
    • TCC (Try-Confirm-Cancel): 리소스를 미리 예약(Try)하고 확정(Confirm)하거나 취소(Cancel)하는 3단계 전술
    • Idempotency: 보상 트랜잭션이 중복 실행되어도 안전한 하드웨어 물리 상태 유지
  • How to Learn:
    • 보상 트랜잭션 자체가 실패했을 때의 '무한 재시도' 혹은 '수동 개입' 물리 비용 산출 실습
    • TCC 패턴을 통해 송금 시스템의 안전성을 수리적으로 증명
  • Implement: 중복 요청에도 결과가 변하지 않는 멱등성(Idempotency) 로직이 적용된 MoneyTransferService

Advanced

Core: 혼합적 일관성과 신뢰 가능한 정합성 (High-end Integrity)

  • Why to Learn: 2PC의 안전성과 사가의 유연성을 적재적소에 배치하여 최적의 부하 분산을 달성하기 위함입니다.
  • What to Learn:
    • Outbox Pattern: DB 트랜잭션과 메시지 발행을 물리적으로 하나로 묶는 기법
    • Transactional Messaging: 메시지 전송과 상태 변경의 원자적 수리 결합
    • Formal Verification of Sagas: 복잡한 사가 흐름의 데드락이나 유실 가능성을 수리적으로 검증
  • How to Learn:
    • 아웃박스 패턴을 적용하여 DB 저장 후 메시지 전송이 누락되지 않음을 물리적으로 증명 실습
    • 대규모 분산 시스템의 트랜잭션 신뢰도를 수치(99.99%)로 모델링하는 실습
  • Implement: 데이터베이스 변경분을 관찰하다가 이벤트를 발행하는 OutboxRelay 서비스

7. Terminology

Term (EN / ko, abbr) 1문장 정의 단계(기본/권장/실무/심화) 역할/맥락 관련 개념 유사/대비/함께 사용 오해 포인트 Evidence(Primary/Secondary/Industry) Flags(core)
2PC 분산된 자원들의 원자적 커밋을 위해 준비와 확정의 두 단계로 나누어 제어하는 프로토콜입니다. 기본 원자성 보장 Commit / Coordinator Saga 블로킹이 치명적 P1:CS2023 core
Saga Pattern 로컬 트랜잭션들을 일련의 순서로 실행하고 실패 시 보상 작업을 수행하는 분산 패턴입니다. 추천 유연한 정합성 Event / Compensate 2PC 락을 걸지 않음 Industry core
Compensating Job 이미 완료된 작업을 논리적으로 되돌리기 위해 실행되는 정반대의 비즈니스 물리 연산입니다. 실무 오류 복구 Rollback / Undo TCC 물리적 Undo와 다름 Industry core
Idempotency 연산을 여러 번 실행해도 결과가 처음 한 번 실행했을 때와 물리적으로 동일한 성질입니다. 추천 중복 방지 Atomic / Retry Reliability 분산 시스템 필수 P2:SWEBOK core

8. References

Primary

Secondary

  • [Designing Data-Intensive Applications (DDIA)] Martin Kleppmann — Chapter on Atomic Commit and Two-Phase Commit.
  • [Sagas] Hector Garcia-Molina et al. — Original Saga paper.

Industry

  • [Microsoft: Saga Distributed Transactions Pattern] — Cloud architecture practice.
  • [AWS: Ensuring Data Consistency in Microservices] — Practical Saga implementation.

9. Final Checklist

Primary

  • '2단계 커밋(2PC)'이 왜 '단일 조정자(Coordinator)' 장애 시 시스템 전체를 물리적 마비(Blocking)로 몰아넣는지 설명 가능한가? (P1)
  • '분산 트랜잭션'의 ACDI 속성 중 'Saga 패턴'에서 가장 물리적으로 타협받는 항목이 무엇인지 기술할 수 있는 가? (P1)

Secondary

  • '코레오그래피(Choreography)'와 '오케스트레이션(Orchestration)'의 물리적 통제 방식 차이를 서비스 결합도 관점에서 소통 가능한가?
  • **멱등성(Idempotency)**이 확보되지 않은 환경에서 보상 트랜잭션 재시도가 발생했을 때의 물리적 위험성을 논증 가능한가?

Industry

  • 결제 시스템 설계 시, '주문 차감'을 위해 '2PC'를 쓸 것인지 '사가 패턴'을 쓸 것인지 하드웨어 리소스 효율면에서 제안할 수 있는 가? (SFIA)
  • '아웃박스(Outbox) 패턴'이 메시지 중복 발행을 방지하기 위해 어떤 물리적 저장 기법을 사용하는지 분석할 수 있는 가?

Concepts & Tags

#distributed-transactions#2pc#3pc#saga-pattern#compensating-transactions#atomicity