[분산트랜잭션 맛보기] - 2PC

MSA 전환시 문제점

• 서비스간 데이터정합성을 보장하기 어려움

기존 모놀리식

• 주문, 상품, 포인트 기능이 존재한다고 가정
• 하나의 애플리케이션과 하나의 DB 를 공유하고 있음 → 트랜잭션 기능만으로 데이터 정합성을 맞출 수 있음

MSA 환경

• 각 서비스는 자신만의 DB 를 구성하여 각 서비스간의 호출은 네트워크 통신을 통해 이루어짐

• 트랜잭션은 각 서비스 구간내에서만 보장할 수 있게된다
• 포인트 사용 중 에러가 발생하게 되면 재고는 차감되어있는데 포인트는 사용하지 않은 상태로 데이터 불일치 상태가 발생하게 된다

분산 트랜잭션을 보장하기 위한 방법들

• 2PC
• TCC
• SAGA

---

2PC

• Two-Phase Commit Protocol 의 약자로 분산 시스템에서 트랜잭션의 원자성을 보장하기 위해 사용하는 프로토콜
• 트랜잭션을 두 단계로 나누어 처리한다
  • Prepare 단계 : 트랜잭션 매니저가 참여자에게 작업 준비가 가능한지 묻는다
  • Commit 단계 : Prepare 단게에서 모든 참여자가 작업이 가능하다고 응답하면 실제로 커밋을 수행한다
• 대표적인 구현체로는 XA 트랜잭션이 존재한다 (mysql)

• 위 흐름도는 해피 케이스의 흐름
• 만약 Prepare 단계에서 모두 실패하게 된다면 해당 작업들을 모두 Rollback 해야한다
• 더 문제는 Commit 시점에 실패하게 되는 경우이다
  • 2PC 원칙상 Prepare 단계 이후 참여자(DB) 는 스스로 Rollback 을 하면 안된다 → Coordinator 의 Commit 또는 Rollback 명령을 대기해야한다
  • 만약 1번 Commit 은 성공하고 이후 2번 Commit 은 실패할 경우 이에 대한 대처방안을 생각해야 한다, 그리고 이 시간동안 계속 해당 데이터에 대한 Lock 을 잡고 있는다

2PC 맛보기

• 데이터베이스
  • mysql 환경
  • 2pc1 , 2pc2 두 개의 database 구성
• xa 명령어를 사용해서 2PC 테스트 → mysql 사용

무한대기 문제

xa 명령어로 트랜잭션을 시작하면 xa 트랜잭션이 Lock 을 잡고 있기 때문에 다른 곳에서 해당 데이터에 쿼리를 발생시켜도 무한 대기 상태가 됨

• 이후 prepare 및 commit 실행시 쿼리가 수행됨
  • xa prepare 'product_1' → xa commit 'product_1'
  • xa prepare 'point_1' → xa commit 'point_1'

장점

• 강력한 정합성 보장
• 사용하는 데이터베이스가 XA 를 지원한다면 구현 난이도가 낮다

단점

• XA 를 지원하지 않는다면 구현하기 어렵다
• prepare 단계 이후 commit 이 완료될때까지 lock 을 유지하고 있기 때문에 가용성이 낮다
• 장애복구시 수동으로 개입하여 해결해야 한다
• 실용성이 낮다

일반적으로는 2PC 보다 다른 방법을 사용하여 분산 트랜잭션을 구현한다

• TCC, SAGA