[MSA] 프로젝트 회고 - (1) 시작하기

 

 

소프트웨어 아키텍처의 종류로 MSA 프로젝트를 구현하려고 한다.

MSA로 구현하려면 바로 구현하기보다 우선 모놀리식 아키텍처로 구현 하고 넘어가는 것이 좋다.

그럼 왜 바로 구현하면 안될까 ?

 

 

모놀리식 아키텍처와 MSA 아키텍처

모놀리식 아키텍처는 비교적 간단하고 배포가 용이하다. 개인 프로젝트나 팀프로젝트를 시작하면서 설계할 때 대용량 트래픽이나 사용자를 고려하고 구현하지만 처음 구현을 시작할 때 부터 MSA로 구현하게 된다면 시간 비용이 많이 들게 된다.

 

 

 

 

 

사진과 같이 모놀리식은 서비스가 모두 같은 데이터 베이스와 연결되어 있어 결합성이 높다. 관리가 간편하기에 처음 프로젝트를 시작할 땐 모놀리식으로 구현한 후 기본적인 서비스가 완성되면 MSA로 나누게 된다. 이 때, 바로 MSA로 넘어가게 되면 연관되었던 지점들을 끊어주어야 해서 에러가 많이 발생하게 된다. 그래서 멀티 모듈 즉, 다중 모듈 아키텍처로 변경한 다음 MSA로 넘어가는 것이 코드 리팩토링에 용이하다. 물론 바로 MSA로 넘어가는 것도 방법이다.

 

나는 MSA 프로젝트를 처음해봤기 때문에 모놀리식에서 점차적으로 MSA까지 변경했다. 모놀리식 프로젝트는 단일 Appliccation으로 모든 기능을 관리하고 멀티모듈과 MSA는 각 서비스 마다 Application이 독립적으로 존재한다. 그래서 MSA와 멀티모듈의 차이를 크게 모르는 경우가 많다. Core Module이 존재하지 않으면 MSA와 형태가 매우 비슷하기 때문이다.

 

 

멀티 모듈 아키텍처와 MSA 아키텍처

두 아키텍처의 디렉토리 구조를 살펴보면 한 눈에 이해할 수 있다.

 

MsaProject
├── core-service-1/
├── core-service-2/
├── discovery-server/
├── gateway-server/
├── order-service/
├── product-service/
├── quantity-service/
└── user-service/


MultiModuleProject
├── README.md
├── build.gradle
├── discovery-server/
├── gateway-server/
├── gradle/
│   └── wrapper/
│       ├── gradle-wrapper.jar
│       └── gradle-wrapper.properties
├── gradlew*
├── order-service/
├── product-service/
├── quantity-service/
├── settings.gradle
└── user-service/

 

 

settings.gradle 에서도 차이를 알 수 있다. 멀티모듈은 Root 에서 settings.gradle에 모든 모듈이 include 하게된다. 그리고 각 모듈의 settings.gradle은 삭제해주어 gradle의 형태가 root gradle에 모든 모듈의 gradle이 포함될 수 있도록 만들어준다. 이렇게 되면 root와의 의존성은 남아있다. 공통 dependency  root gradle에 포함시켜 각 모듈에서 root gradle을 의존하여 구현한다. 자세히 구현하는 방법은 이 블로그를 참고하면 좋다.

 

 

[MSA] 개인 프로젝트 Monolithic to MSA 전환기 - (1) MSA란?

 

/* 
멀티모듈 settings.gradle	
*/

rootProject.name = 'market'

include 'gateway-service'
include 'discovery-service'
include 'user-service'
include 'order-service'
include 'product-service'
include 'quantity-service'
include 'core-service-1'
include 'core-service-2'

 

 

그러나 MSA는 각 모듈에 rootProject를 해당 모듈의 서비스로 설정해주어 gradle이 각자 생성될 수 있도록 구현한다. 이렇게 되면 각 모듈의 연관성이 사라지게 되고 이를 소통하기 위해서는 메세지 큐나 API를 소통할 있도록 하는 라이브러리를 사용해야 한다. 멀티 모듈에서 DB에 연관관계를 모두 없애고 구현했기에 멀티모듈에서 MSA로 넘어가는 것은 어렵지 않다. 공통 gradle에 분리해두었던 dependency를 다시 각 모듈로 가져와 구현해주면 된다. 멀티모듈과 MSA는 모듈간의 종속성이 있냐 없냐의 차이이다. 이 때, core 모듈이나 root 모듈과의 종속성이 강하면 MSA로 넘어갈 때 난이도가 높아진다. 

그렇다면 언제 MSA를 사용하고 모놀리식을 사용할까 ?

 

 

 

아키텍처 별 사용 사례

모놀리식은 앞서 이야기 한 것처럼 초기 단계에 많이 사용된다. 혹은 작은 규모의 프로젝트에 사용된다. 단일 코드베이스를 사용했기 때문에 개발 및 배포가 간편하기 때문이다. 그리고 기술스택이 자주 바뀌지 않는 프로젝트에 사용해야 한다. 모놀리식 프로젝트에는  연관과 종속이 많기 때문에 기술스택을 바꾸려면 전체 코드를 리팩토링 해야하는 상황이 발생한다.

 

MSA는 중간 이상 규모의 프로젝트에서 사용한다. 분할된 서비스를 사용하기 때문에 서비스가 그만큼 존재해야 사용하는 가치가 높아진다. 작은 규모에서 사용하게 되면 시간 비용만 많이 들게 되고 생산성이 현저히 떨어지게 된다.

 

 

최신기술이라고 무조건 좋은 것은 아니다. 프로젝트의 규모에 따라 각자 알맞은 아키텍처를 사용해야 한다.