MicroService Architecture ‐ TCC

MicroService Architecture ‐ TCC

• TCC(Try-Confirm-Cancel)는 분산 시스템에서 데이터 정합성을 보장하기 위해 사용하는 분산 트랜잭션 처리 방식이다.
• 다음과 같이 3단계로 나누어 트랜잭션을 관리한다.
  • Try : 필요한 리소스를 점유할 수 있는지 검사하고 임시로 예약한다.
  • Confirm : 실제 리소스를 확정 처리해 반영한다.
  • Cancel : 문제가 발생한 경우 예약 상태를 취소하여 원복한다.
• Try, Confirm, Cancel 단계는 멱등하게 설계가 되어야 한다.

TCC의 장·단점

• 확장성과 성능에 유리하다. 2PC에 비해 데이터베이스 Lock 점유 시간이 짧고 Long Transaction에 덜 취약하다.
• 장애 복구와 재시도 처리에 유연해서 비즈니스 정책에 따라 전략을 정할 수 있다.
• 기존 시스템에 비해 설계와 구현이 복잡하다. 모든 단계 자체가 멱등하게 설계되어야 하며 네트워크 오류, 재시도 시나리오를 고려한 복잡한 로직 구현이 필요하다.

1. Try(예약)

• 실제 확정이 아니라 "임시 점유"가 핵심이다.
• 재고 100을 바로 차감하는 것이 아니라 가용재고 98 / 예약 2와 같이 예약 상태로 따로 잡아둔다.
• 포인트라면 바로 차감이 아니라 동결. 이렇게 모든 변경을 되돌릴 수 있는 중간 상태로 만들어 두는 게 Try의 역할이다.
• 만약 여기서 중간 상태로 전환할 자원이 부족하면 실패한다.

2. Confirm(확정)

• 모든 서비스의 Try가 성공했을 때만 호출된다. Try에서 잡아둔 예약을 실제로 반영한다.
• 예약 재고를 진짜 차감시키고 포인트 동결을 진짜 차감시킨다.
• 여기서 중요한 부분은 Confirm은 실패하면 안 된다. 이미 Try에서 자원을 확보했기에 실패하면 무한 재시도로 끝까지 성공시키는게 원칙이다.

3. Cancel(보상, 원복)

• Try 중 하나라도 실패하면 이미 성공한 Try들을 되돌린다.
• 예약 재고를 가용으로 다시 반환하고 동결한 포인트를 다시 해제한다.

왜 멱등(Idempotent)이 필수인지?

• 분산 환경에서 네트워크 타임아웃 때문에 Confirm/Cancel이 중복 호출되거나 응답을 못 받아서 재시도되는 일이 항상 있다고 생각해야 한다.
• Confirm이 2번 와도 한 번만 차감해야 하고, Cancel이 2번 와도 한 번만 원복해야 한다.
• 그래서 각 단계는 이미 처리했으면 무시하도록 멱등하게 짜야한다.

상품 주문 및 재고 차감에서의 TCC 시나리오 정리