현실에서 마이크로 서비스 관련 설계를 진행하다 보면, 적합하지 않은 상황이 발생하곤 한다. 이런 상황에 대해서 언급하는 글(https://dzone.com/articles/chopping-the-monolith-the-demo)을 발견해서 내용을 작성한다. 저자는 전자 상거래 영역에서 몇 년간 일을 했다고 한다. 전자 상거래의 상당 부분이 가격 책정에 전념하고 있고 가격 책정 규칙은 매우 자주 변경된다고 한다.
- 특정 제품의 재고가 너무 많음
- 시즌 종료: 새 상품에 대한 물류 센터 공간을 확보해야 하기에, 가격을 낮춰서 판매한다.
- 연구에 따르면 마진을 낮추면 제품 판매가 증가하여 전반적으로 더 많은 수익이 발생한다고 한다.
- 마케팅 목적
저자는 관련해서 예제로 코드를 만들었다. 아래는 전자 상거래 예시 화면이다.
장바구니에 항목을 추가하고 내용을 확인할 수 있는 기능이다.
초기 상황
아래 시퀀스 다이어그램은 기존 방식을 설명한다.
CheckoutHandler에서 장바구니 담기와 가격 책정 기능을 모두 포함하고 있다.
가격 책정
가격 책정 기능을 분리해야 한다. 그 이유는 이 글 처음에 작성했다. 새로운 시퀀스 다이어그램은 아래와 같다.
새로운 시퀀스 다이어그램에서는 몇 가지 변경 사항이 포함된다.
- 가격은 분리되어 제공된다.
- CheckoutView는 더 이상 가격 정보를 반환하지 않는다.
- 클라이언트는 결제와 가격 책정 사이의 흐름을 조정한다.
가격 책정 서비스 대체
가격 책정 기능을 분리하여 사용하기로 결정했다면, API Gateway Pattern을 적용하여 외부에 노출되는 API와 Backend 서비스의 접점을 분리시켜줘야 한다. Apache APISIX Gateway는 실시간으로 경로 구성이 가능하고 클라이언트에 노출된 URL을 변경하지 않고도 신규 추가된 가격 책정 서비스의 API와 매핑이 가능하다.
결론
저자는 본 글에서 마이크로 서비스를 사용하지 말아야 하는 이유에 중점을 두고 예제 코드를 작성했다고 언급하고 있다. 마이크로 서비스 대신 특정 부분을 전용 서비스로서의 기능으로 분리할 수 있다고 한다.
내가 생각하기에는 이런 작업들이 계속 반복된다면, 결국 아래의 방식으로 서비스가 쪼개질 것이라고 생각한다. 처음 시작은 Monolith에서 필요에 의해 기능을 분리하는 방식으로 진행했지만, 결국에는 Monolith가 마이크로 서비스로 점진적으로 마이그레이션 되는 방식이라 생각한다.
물론, 저자가 의도한 바는 New features 단계(아래의 첫번째 단계)라고 볼 수 있다.
이 글을 읽는 분들은 이 상황에 대해서 어떻게 생각하시는지요?
References:
잠깐, 글이 유익했나요?
