TCC가 뭐지???

마이크로서비스를 구현(?) 하는 방법으로 TCC 라는 방법을 사용한 기사가 있어 내용을 소개하고자 한다. 

https://dzone.com/articles/transactions-for-the-rest-of-us

원문은 위에 dzone 사이트에 있다. 

TCC : Try-Confirm/Cancle

예약 시스템이 있다고 가정해보자. 예약은 다음과 같은 경우에 이루어진다. 

비행기와 자동차를 각각의 업체에서 예약을 한다. 바르셀로나로 가는 비행기를 예약을 하고 스페인 남부로 가기 위한 자동차를 예약 한다고 가정해보자. 

비행기 표가 없으면 차를 예약 할 필요가 없고 차가 없으면 비행기를 예약할 필요가 없다. 결론적으로 둘다 예약 가능 해야 예약을 한다. 

TCC에서 정의하는 기본적인 단계

1. 항공사에 HTTP POST 로 비행기를 예약 한다. 항공사는 확정을 하기 위한 URI와 expiration 을 준다. 

2. 렌터카 업체에 HTTP POST 로 자동차를 예약 한다. 마찬가지로 렌탈 업체는 확정을 하기 위한 URI 와 expiration 을 준다. 

3. 각각 받은 URI로 PUT 메소드로 호출을 한다.

Cancel 과 Confirm

항공사와 렌터카는 expiration 기간이 지난 후에는 자체적으로 취소하는게 가능하다. 이것은 위에서 정의한 3번을 실행하기 전에 이미 expiration 기간이 지났음을 의미한다. 

3번이 실행된 이후에 발생하는 각각의 오류에 대해서는 항공사나 렌터카 서로에게 영향을 주지 않는다. 이미 예약은 Confirmed 된 상태이기 때문이다. 

TCC Service / Participant

TCC participants (여기에서는 항공사와 렌터카) 는 "예약" 서비스를 위한 간단한 라이프 사이클 모델을 구현하기 위해 다음과 같은 상태를 따른다.

1. Initial : 아무것도 일어나지 않은 상태이다.

2. Reserved : HTTP POST를 통해서 "Try"를 한 상태이다. participants(항공사 또는 렌터카)는 Confirm 을 할 수 있는 URI와 만료시간을 제공한다. 

3. Final : 예약이 확정된 상태이며 쉽게 취소할수 없다. participants 가 지정된 시간 안에 HTTP PUT 메시지를 받으면 이 상태로 변경된다.

그림으로 표현하면 아래와 같다. 

Post 메소도를 통해서 받은 응답에는 PUT 으로 보낼수 있는 URI(ID 포함) 와 expiration 이 포함되어야 한다. 

보기에는 간단해 보이지만 실제로 구현하려면 중간중간 exception처리가 만만치 않아 보인다. 

각각을 Rest 로 호출을 하면서 각각의 서비스에서 발생한 Exception 에 대한 처리도 고민을 해봐야 하고 Response 에 대한 딜레이를 줄이기 위해 Message Queue 사용에 대한 부분도 확인을 해봐야 한다.