[Legacy to Microservices] 설계의 변경

분산 트랜잭션을 구현하는 과정에서 스케줄러 서버를 사용하지 않는 형태로 설계를 변경하기로 결정했다. 또, 팀원과 어떻게 협업하고 있는지를 조금 남겨보려고 한다.

 

[Legacy to Microservices] 설계의 변경

 

 

블로그 목차

 

1. 설계의 변경

2. 협업 과정

 

 

설계의 변경

 

- 아마 저번 게시글까지 읽었다면, 분산 트랜잭션 과정에서 상대 서버가 죽은 경우 재확인 검증을 위해 스케줄링을 하도록 구현했다는 것을 알 수 있을 것이다.

- 하지만, 이것이 현재 내가 독립적으로 개발한 프로토 타입이었다. 즉, 실제로 구현해야 하는 것은 팀원이었는데 내 설계가 맞는지 틀린지를 검증하기 위해서 간단하게 개발한 것이었다.

- 같이 하는 팀원도 힘들었지만 나도 이 설계를 설명하는 것이 굉장히 어려웠기 때문에 대화를 아주 많이 나눴다.

 

* 구현 과정에서의 궁금점

- 모든 것이 이해가 되었지만, 팀원과 대화를 하면서 이해가 되지 않는 부분이 있었다.

- 주문 서버에서 응답을 지연시키고 스케줄러 서버에 내 작업을 등록해서 해당 작업이 n초 이후에 일어나도록 미루는데, 이 과정을 왜 주문 서버에서 처리하지 않는지가 궁금했다.

- 나는 아무래도 시스템이 대규모로 확장되면서 여러 서비스에서 스케줄링이라는 기능이 필요했는데, 그 기능을 하나의 서비스로 떼어낸 것이 아닐까라고 추측했다.

- 두 번째로는 현재 설계대로라면, 응답을 미루고 스케줄러 서버로부터 다시 요청이 날라올 때까지 사용자에게 응답을 미뤘기 때문에 사용자도 같이 대기를 하고 있는 상태이다.

- 하지만, 그렇게 되면 계속되는 재실패를 겪으면서 계속 지연이 일어나게 되면 계속 대기해야 하는 문제가 있다.

- 그렇지만 SLASH 24에서 이것에 대한 언급은 전혀 없었기 때문에 알아내기 위해서는 단 한가지의 방법만 존재했다.

 

* SLASH 24에 연락

- 그 질문에 대해서 대답해줄 수 있는 사람은 발표자 한 사람밖에 없었다.

- 현직에 있는 친구들 중에 백엔드를 이렇게 MSA 환경에서 다루고 있는 사람도 없어서 조언을 구할 곳이 마땅치 않았다.

- 그래서 직접 SLASH 24에 적힌 메일로 연락을 보냈다.

- 하지만, 답변을 받지는 못했다. 답변을 받을 것이라고도 기대는 많이 하지 않았다. 아마 바쁘신 분들이기에 백그라운드 없이 던진 질문에 깊게 답변을 하는 것이 힘들 것이라고 생각했다.

 

* 설계의 변경

- 그래서 결국에는 설계를 변경하게 되었다.

- 기존에는 재요청을 스케줄러를 통해 끊임없이 자동으로 하도록 했었다면, 이제는 사용자에게 재시도 요청을 하도록 위임하는 것이다.

- 즉, 첫 번째 재고 감소 요청이 Timeout이 나고, 그 이후 바로 재고 감소 요청이 이루어졌는지를 확인하는데 이 요청마저 Timeout이 난다면, 다시 주문 페이지로 돌아가서 사용자가 재시도를 하도록 하는 것이다.

- 그리고 이 과정에서 본 주문은 Unknown 상태로 기록해둔다.

- 이외에도 Success와 Fail 상태가 존재하는데, Success의 경우 주문이 삽입되었기 때문에 주문 확인 페이지로 진행하게 되고, Fail 상태에서 사용자가 재시도를 하는 경우 보상 트랜잭션까지 이루어지기 때문에 아예 재고 감소부터 다시 시작하게 된다.

- Unknown 상태에서 사용자가 재시도를 하게 되면, 재고 감소가 제대로 일어났는지 확인한 후에 주문 처리를 하도록 한다.

- 이때, 중요한 것은 사용자가 재시도 요청을 하도록 했기 때문에 알게 모르게 동일한 요청이 여러 번 전달될 수 있는데, 그럴 때마다 주문이 수행되거나 재고 감소가 일어나면 안된다.

- 따라서 카카오페이의 분산 트랜잭션에서는 멱등성을 보장하는 API가 필요하다고 강조하고 있다.

- 즉, 고유한 값인 특정 orderId로 한 번이라도 재고가 변경되거나 주문이 삽입되어 Success 응답을 받았다면, 그 뒤에 요청들은 재고를 변경하거나 주문을 삽입하지 않게 하면서 Success 응답을 전달해야 한다.

- 그래야지만 재시도 과정에서 여러번 발생할 수 있는 요청에 대해서 일관된 처리를 하도록 보장할 수 있다.

- 이 설계에 대한 내용은 다음 실제 구현 게시글에서 그림을 가지고 설명하게 될 것 같다.

협업 과정

 

- 현재 협업 과정을 간략하게 나타내면 다음과 같다.

- 각자 Orginization에 있는 레포지토리를 Fork로 자신의 레포지토리로 가져간다.

- 자신의 레포지토리에 변경 기록을 업로드 하고, 검토가 완료되었을 때 Orginization으로 풀리퀘를 날린다.

- 리뷰어로 상대방을 등록하고 기다린다.

- 리뷰어는 상대방의 변경 사항들을 보면서 리뷰를 본다.

- 리뷰에 대한 확인이 다 된 상태에서 풀리퀘를 머지하게 된다.

- 아래는 예시이다.

- 이런 식으로 여러 줄 혹은 한 줄에 대한 코멘트를 남길 수 있어서 좋은 것 같다.

- 이렇게 협업해본 적이 없어서 또 경험을 많이 쌓을 수 있을 것 같다.

- 아무래도 이번 프로젝트를 진행하면서 많은 경험들을 쌓아가고 있는데 그러다보니 부트캠프로 향하는 길이 맞는지 아닌지 자꾸 고민하게 되는 것 같다.