비즈니스 성공을 위한 Java/Spring 기반 서비스 개발과 MSA 구축 #4 (선물하기 프로젝트 개발)
0
아래 내용은 비즈니스 성공을 위한 Java/Spring 기반 서비스 개발과 MSA 구축 강의를 기반으로 하여 정리한 내용입니다. 자세한 내용 및 코드가 궁금하면 위에 강의를 참고해주세요.
이번 강의도 라이브 코딩이 대부분이라 개인적으로 개발하면서 유념하면 좋을 만한 내용들 위주로 정리하였습니다.
MSA환경에서 새로운 기능 및 서비스 개발시 검토 방안
- 새로운 기능에 대한 분석.
- 분석된 내용 기반으로 이미 존재하는 서비스에 위임할 수 있는 부분이 있는지 확인.
- 신규 서비스 작업과 기존 서비스에 맡길 작업 분리.
- 기존 서비스와 통신을 위한 메시지 형태 정리.
- 신규 서비스와 기존 서비스간의 메시지 흐름 과정 도식화 해보기.
선물하기 기능을 위에 방식대로 적용하면 아래와 같다.
- 선물하기 주문 정보등록, 선물하기 주문 정보 생성, 결제, 선물지급.
- 주문정보 생성, 결제는 기존 주문서비스에 위임가능.
- 나머지 작업은 신규 선물하기 서비스에 처리.
- 기존 주문 생성 api를 그대로 사용할 수 없어 신규 선물하기용 주문생성 api를 구축하고 메세지 정리.
- 이렇게 기존 api를 그대로 활용할 수 없는 상황에서는 3가지 방법이 있다.
- 기존 api의 변경 한다. (배송지 필수 validation 제거)
- 단점은 기존 배송지 validation 약해져 잘못된 데이터가 들어갈 수 있음. 그리고 배송지가 없어도 된다는 로직은 선물하기 서비스의 비지니스 로직일 수 있는데 이게 주문 쪽으로 포함 되는것이다.
- 호출하는 곳에 맞게 신규 api를 생성해서 사용한다. (현재 방법)
- 단점은 호출하는 서비스마다 다른부분이 생긴다면 신규 서비스용 api들이 계속 늘어날 수 있다.
- 신규 api쪽에서 기존 api에 맞춰서 호출한다. (선물하기에서 배송지정보를 임의의 값으로 채워 넣는다.)
각자 장단점이 있음으로 상황에 맞춰 쓰자.
- 유저 -> 선물하기 서비스 -> 주문 서비스
서버간의 호출 flow
- 서비스 간에도 위상 관계가 있다.
- 하위 서비스에 상위 서비스의 로직이 포함되지 않도록 해야 확장성이 유지된다.
- 의존관계는 상위 서비스에서 하위 서비스로 단뱡항으로 유지해야 도메인 분석도 쉽고 계층에 맞게 서비스가 유지가 된다.
- 서버간의 강결합의 또는 양방향 의존관계를 끊기 위해 비동기 메시징 구조를 가져갈 수 있다. 단방향을 유지함으로써 하위 서비스가 최대한 보편적이고 중립적으로 구현되어 확정성이 높아진다.
보상 트랜색션
- MSA에서 분산 트랙잭션 구조에서 rollback을 위한 개념이다.
- 데이터 베이스 롤백과 완전히 일치하지는 않는다. 작업을 회수하는 개념이 아니라 추가적인 작업을 통해 기존 작업을 보완하는 방식이다.
- 상황에 따라 보상 트랙잭션 발생 횟수를 줄일 수 있다.
- 예외 발생 높은 프로세스 먼저 실행 (외부 api 호출)- 데이터 베이스 롤백이 쉬운 프로세스 부터 실행
- 프로세스 실행 순서를 바꿀수 없다면 자주 발생하는 특정 예외 확인 로직을 중복으로 프로세스에 포함시켜 줄일 수 있다.
- 데이터 베이스 롤백이 쉬운 프로세스 부터 실행
메시지 발행과 비즈니스 로직 정합성
- 정합성이 완전히 일치해야 하는 상황
- 메세지 발행 부분을 try catch로 잡아 rollback 및 보상 트랜잭션 처리
- Transactional Outbox 패턴 (한 transaction에서 비지니스 로직과 Outbox 라는 테이블에 보낼 메시지를 기록하는 방식)
- Outbox 테이블를 기준으로 풀링해서 메시지 발행(풀링하는 구조는 데이터베이스 지속적으로 조회를 해야 하기 때문에 성능에 영향을 줄수 있음)
- Outbox 테이블에 쌓이는 데이터베이스의 트랜잭션 로그를 읽어 변경분을 메시지 발행 (데이터베이스 성능에 영향x)
- 정합성이 느슨하게 일치해도 되는 상황
- 메세지 발행에 대한 에러를 로그로 수집한 후 이슈가 사라진 시점에 메시지를 재발행 한다.
질문
- 데이터 베이스 롤백이 쉬운 프로세스 부터 실행하면 왜 보상트랜잭션 발생 횟수가 줄어드는가?
