트랜잭션에 대한 고민

상황

업무를 맡고있는 서비스가 msa구조로 가려고 했던것 같음.

'했던것 같다'는 이유는 내가 알고있는 얕은 지식으로는 서비스(api)하나 당 db가 1~2개 붙어 있어야 함.(하나의 서비스 트랜잭션을 하나의 api가 담당하기 위해서이지 꼭 1~2개라는 뜻은 아님)

 

하지만 api를 아주 세부적인 함수단위로 나눠놓고 여러 api가 여러 db를 조회하는 신기한 구조.

문서 하나를 작성하기위해 db는 3개를 갱신하고(table은 더 있음), api도 4개를 요청해서 2개의 디비를 갱신해주어야 함(2개는 조회).

-> 예로 문서의 unique id를 구하고 별도로 관리하는 테이블 및 api가 존재, 해당 문서의 서명 정합성 검증 api, 문서저장 api, 발급api, ems요청 api 등등 

 

문서를 작성하는 하나의 액션이 여러군데 나눠진 데이터베이스의 테이블을 갱신하고 api를 요청하며, 그api들 또한 앞서 갱신된 table을 조회및 갱신하는 괴랄한 형태(내 생각)

 

처음 볼떄 msa가 원래 이런건가? 내가 잘 모르니 이게 맞는건가? 싶지만 찾아볼수록 이상함이 느껴지고 개발할수록 유지보수가 힘들어짐

면접때 msa를 해봤다고 말하기위한 msa느낌? 

 

디자인 패턴으로 유명한 마틴 파울러는 “Don't even consider microservices unless you have a system that's too complex to manage as a monolith.”라고 말했다. 즉, "모놀리식으로 관리하기에 특별히 복잡한 시스템을 운영할 상황이 아니면 마이크로서비스는 고려할 필요조차 없다"고 피력한 것임

 

하지만 이미 개발된 아키텍쳐 전체를 뜯어고칠수는 없고 업무 일정에 맞게 구현하는게 우선이라 현재 설계된 아키텍쳐에 맞춰 개발을 진행하고 불편했던점은 따로 정리했다가 나중에 전체 설계를 다시 진행해야겠다.

 

지금 당장 필요한 처리는 하나의 액션에 대한 여러 api및 다양한 database에 대한 트랜잭션처리 및 예외처리였다.

 

 

처리방안

기초적인 구조는 facade패턴과 보상트랜잭션을 사용했다.

내용은 기본적인 스프링의 트랜잭션개념과 위 디자인패턴을 찾아보면 쉽게 이해할 수 있을것이다,

하나의 요청액션에서 3개의 데이터베이스를 갱신해주어야하고, 이를 트랜잭션으로 묶기위해 요청서비스와 요청퍼사드서비스를 구분하였다.

요청퍼사드서비스에서 요청서비스를 호출하며 db트랜잭션을 처리하였고 서비스개념의 트랜잭션은 보상트랜잭션으로 처리하였다.

 

 

해결할 점

db뿐 아니라 api요청시 타임아웃등 알수없는 에러에 대한 처리.

무조건적인 롤백보다는 멱등성있는 api를 사용하여 처리하면 좋을것같고, 그러기 위해선 멱등키를 테이블에 추가로 저장하는 방향

msa 구조에 맞게 api와 데이터베이스가 구분되어 트랜잭션 처리를 원만하게 database분리....(전체코드수정, 마이그레이션...)