멀티 모듈 / MSA 구조 이해하기

1. 모놀리식 아키텍처

---

1) 단일 모듈 멀티 프로젝트

일반적으로 익숙한 하나의 서비스에서 api, admin, batch, web, db 등이 관리되는 구조로, 여러개의 서비스 프로젝트가 레이어드 아키텍처 구조를 갖고 있는 형태입니다.

 

레이어드 아키텍처

 

레이어드 아키텍처 기반 멀티 프로젝트

batch
api 처럼 요청받은 데이터를 실시간으로 처리하는 것이 아닌, 모아뒀다가 특정 시간에 일괄적으로 처리하는 것(대용량)입니다.
사용자에게 빠른 응답이 필요하지 않습니다.
대용량 비즈니스/로깅/추적/통계/트랜잭션관리 등이 해당됩니다.

 

2) 멀티 모듈 단일 프로젝트

멀티모듈은 기존의 모놀리식과 MSA구조의 중간 단계라고 할 수 있습니다.

앞선 멀티 프로젝트의 중복을 줄이기 위해서 만들어졌습니다.

 

✔️ 중복 코드에 대한 처리

앞서 말한 단일 모듈인 API 프로젝트와 batch 프로젝트가 같은 domain 정책을 사용한다면 어떨까요? 똑같은 domain 로직을 API와 batch에 따로 작성해야 하는데, 이것이 변경되면 2번 변경해서 작성해야합니다.

만일 프로젝트가 2개 이상이라고 생각하면, IDE를 프로젝트 개수만큼 켜서 직접 일일이 수정해줘야 합니다.

멀티모듈은 이러한 코드의 중복을 줄이고 유지보수성을 높이기 위해서 하나의 공통된 프로젝트를 만들어 사용하자는 의도에서 만들어졌습니다.

💡 공통모듈 규칙
멀티 모듈에서는 중복된 코드를 하나의 "공통모듈"에 작성하고, 나머지 모듈은 이 공통모듈을 의존합니다.

 

 

 

각자 다른 프로젝트에 있던 하나의 모듈들을 한 프로젝트에 모이게 하면서, 위와 같은 형태가 구성됩니다.

API와 batch 등 모든 모듈이 common 모듈을 의존하게 되어 common 프로젝트의 로직을 그대로 사용할 수 있게 됩니다.

이 때 각 모듈은 역할과 의존성 관리가 중요합니다.

• 명확한 추상화 경계
  • 어떤 모듈이 어디까지 개발해야하는지 경계가 명확해지면서, 의존성이 남발하는 스파게티 코드를 덜 쓸 수 있습니다.
  • 각 모듈이 갖는 책임과 역할을 명확하게 하는 것이 중요합니다.
• 최소 의존성
  • 예를 들어 API 모듈에서는 request, response 등 user interface와 통신하는 것만을 신경쓰면 됩니다. 의존성도 그것에 관한 것만 다루면 되기 때문에, 불필요한 것은 다루지 않게 됩니다.이 분리가 제대로 되지 않으면 공통 모듈에 비즈니스 로직을 작성할수밖에 없게 됩니다.
  • 앞서 말했던 것 처럼 공통 모듈에 비즈니스 로직 작성을 최대한 피하기 위해서는 모듈 별로 책임과 역할을 분명히하는 것이 가장 중요합니다.
  • 따라서 각 모듈은 자기가 필요한 것만을 의존하면 됩니다.

 

✔️ 주의점

모든 중복 코드를 다 공통 모듈에 넣다보면, 결국 비즈니스 로직이 추가될 수밖에 없습니다.

예를 들어 특정 API 모듈에서만 쓰이는 로직이 common에 추가된다면, batch에서는 알 필요가 없는 로직을 의존하게 됩니다.

이렇게 한 번 의존성이 꼬이기 시작하면, 스파게티 코드가 되어 추후 common 모듈의 분리가 까다로워집니다.

따라서 공통 모듈은 최대한 사용을 지양하고 비즈니스 로직을 담지 않는 것이 중요합니다.

 

공통모듈에서 사용할 로직

• 공통으로 사용되는 Type, Util
• 다른 라이브러리에 대한 의존성을 최소화 = 순수한 자바 코드로 작성

 

✔️ 멀티모듈 장점

멀티모듈은 상호 연결된 여러개의 모듈로 구성된 하나의 프로젝트입니다.

각 모듈은 독립적으로 배포되어 전체서비스 구성요소로 작동됩니다. (실제로 jar파일이 분리되어 있지만 의존성에 의해 api.jar 안에 application 모듈과 common 모듈이 포함됨)

앞선 주의점대로 common 모듈에 비즈니스 로직을 담지 않는다면 공통 로직을 처리하고자 만들어진 멀티모듈의 본래 목적에 단점이 존재하지만, 그럼에도 여전히 다음과 같은 장점을 가지고 있습니다.

• 여러개로 구성되어있던 프로젝트를 하나의 프로젝트로 통합시켜, 여러개의 IDE를 하나로 통일할 수 있습니다.
• 역할과 책임을 보다 명확히 분리하여 모듈간의 의존성을 최소화하면 유지보수에 도움이 됩니다.

 

✔️ 멀티 모듈 구조

• 레이어드 아키텍처
  • 기존 모놀리식에서 사용했던 그대로, api와 business, data와 같이 레이어 별로 모듈을 구성할 수 있습니다.
• 도메인 아키텍처
  • 앞선 기존의 레이어드아키텍처의 멀티모듈을 발전시켜, 도메인 별로 모듈을 구성하여 MSA로 발전시킬 수 있습니다.

 

 

2. 마이크로서비스 아키텍처 MSA

---

MSA는 말그대로 마이크로서비스를 조각조각 모아서 하나의 거대한 서비스를 만드는 구조입니다.

즉, 모놀리식 서비스들을 모아서 하나의 서비스를 만들 수도 있습니다.

 

✔️ MSA 핵심: 서비스 gateway

MSA는 완전히 독립적으로 작동할 수 있는 작은 서비스(micro service) 별로 분리하여 gateway를 통해 하나의 큰 서비스로 작동할 수 있게합니다.

이 때, 서비스 분리의 기준은 도메인 단위가 됩니다. = DDD (Domain driven development)

• 특정 서비스 별로 독립적인 배포가 가능하고, 서비스 확장이 쉽습니다.
• 특정 서비스에 대한 리팩토링이나 기술 변경과같은 큰 변화가 있을 때, 전체를 변경하지 않아도 되어서 유리합니다.

 

✔️ 멀티모듈과 MSA의 차이점

• 멀티모듈
  • 모놀리식 아키텍처로서, 레이어드 기반
  • common 모듈 의존
  • 모놀리식 → MSA 전환 시 중간 단계
• MSA
  • 도메인 기반 (주문, 결제, 회원…)
  • API Gateway로 도메인별(기능별) 서버 분할 → 즉, 주문 서비스에 어떤 결함이 있을 때, 결제나 회원 서비스는 정상적으로 작동됩니다.
  • 데이터 동기화 문제, 메시지큐, 로드밸런싱, 분산DB등 오버헤드 증가

 

✔️ MSA 확장 시 주의점

MSA처럼 도메인별로 서비스를 분리해서 개발을 한다면, 분명히 유지보수와 확장성과 같은 장점이 뚜렷합니다.

어떤 프로젝트가 어떤 책임을 갖고있는지 명확하게 보이기 때문에 다른 모듈을 뒤져서 확인할 필요도 없죠.

하지만 그에 따른 오버헤드를 무시할 수 없습니다.

모듈마다 JVM이 다르게 동작하기 때문에 데이터 간 동기화, 즉 트랜잭션 관리 때문에 서비스간의 통신을 잘 다뤄야하고, 큐 관리, 분산 db관리 등등... 신경써야하는 것이 굉장히 많아집니다.

이상적인 아키텍처를 위해서 모듈간 철저하게 분리하는 것은 좋은 시도가 되겠지만, 실제로 프로젝트에 적용할 때는 프로젝트의 성격이나 규모를 따져 적절한 선택이 필요합니다.

 

 

실제 적용에 대한 예시는 여기에서 확인할 수 있습니다.