워크플로

• 이 장에서는 분산 트랜잭션을 사용하는 것과 관련된 함정을 살펴봄

데이터베이스 트랜잭션

• ACID 트랜잭션
  • 원자성
  • 일관성
  • 격리성
  • 내구성

분산 트랜잭션 - 2단계 커밋

• 2단계 커밋(two-phase commit)알고리즘
  • 줄여서 ‘2PC’라고도 함
• 2PC는 투표(voting) 단계와 커밋(commit) 단계로 나뉨
• 투표 단계에서 중앙 조정자(coordinator)는 트랜잭션에 참가할 모든 워커(worker)를 확인
• 두 가지 요청 존재
  • 상태 확인 요청
    • 필요에 따라 행에 대한 잠금이 필요
  • 동작 수행 요청
    • 하나라도 실패시 롤백 요청을 보내야함
• 2단계 커밋과 관련된 많은 실패 모드가 존재함
  • 워커가 많을 수록, 시스템 지연시간이 길수록 2단계 커밋에 더 많은 문제가 발생

분산 트랜잭션 - 그냥 안 된다고 하라

• 필자는 2단계 커밋 같은 분산 트랜잭션은 피해야한다고 강력히 제안함
• 대안은?
  • 첫 번째 선택지는 데이터를 분리하지 않는것
  • 두 번째 선택지는 사가

사가 패턴

• 2단계 커밋과 달리, 사가는 여러 상태 변경을 조정할 수 있지만 자원을 잠글 필요가 없는 알고리즘으로 설계됨
  • 비즈니스 프로세스를 명시적으로 모델링할 수 있다는 추가적인 이점이 있음, 이는 상당한 혜택
• LLT(Long Lived Transaction)는 몇 분, 몇 시간 또는 며칠이 걸릴수 있는 장기 트랜잭션을 의미
  • 단일 데이터베이스 트랜잭션이 LLT의 전체 수명주기에 걸쳐 진행됨
• 사가는 원래 단일 데이터베이스에 대해 작동하는 LLT를 지원하기 위한 메커니즘으로 구상됐음
• 그러나 여러 서비스에 걸친 변경 사항을 조정할 경우에도 효과적

사가 실패 모드

• 사가를 개별 트랜잭션으로 분해하면, 실패 처리 방법을 고려해둬야함
• 역방향 복구
  • 이전 커밋된 트랜잭션을 취소
• 순방향 복구
  • 실패 발생 지점에서 데이터를 가져와 계속 처리

사가 패턴 구현

• 오케스트레이션형 사가(orchestrated saga)
• 코레오그래피형 사가(choreographed saga)

사가와 분산 트랜잭션 비교

요약