멀티모듈.
한 번쯤 들어보지 않았나요?
개발 초보로서는 처음 접했을 때 좀 당황스러웠습니다.
멀티모듈? 모듈이 뭔데? MSA? 그게 다 뭐지?
대체 이걸 어떻게 적용하는 거고, 왜 사용하는 걸까요?
너무 멀게만 느껴지는 이 개념을 한 번 이해해보고자 합니다!
모놀리식 아키텍처
1. 단일 모듈 멀티 프로젝트
하나의 서비스에서 api, admin, batch, web, db 등이 관리되는 구조이다.
user interface, business logic, data access, db infra 레이어를 모두 하나의 프로젝트에서 다룬다.
어쩐지 익숙한 설명이지 않나요?
주니어인 저에게는 굉장히 익숙한 형태의 프로젝트 구조입니다.
한 프로젝트 안에서 api 요청을 처리하고, service에서 business logic을 처리하고...
짧게 말하자면, 모든 서비스의 코드가 하나의 프로젝트 안에 있는것이라고 할 수 있겠네요.
batch?
api 처럼 요청받은 데이터를 실시간으로 처리하는게 아니라, 모아뒀다가 특정 시간에 일괄적으로 처리하는 것(대용량)이다.
사용자에게 빠른 응답이 필요하지 않다.
대용량 비즈니스/로깅/추적/통계/트랜잭션관리 등이 될 수 있다.
2. 멀티 모듈 단일 프로젝트
그럼 멀티모듈은 서비스마다 분리를 해놓은 건가? 엥?🙁
멀티모듈에 대한 접근은 이와 조금 다릅니다.
중복을 줄이기 위해서 만들어졌다고 볼 수 있겠네요.
중복 코드에 대한 처리 = 공통모듈
멀티 모듈에서는 중복된 코드를 하나의 "공통모듈"에 작성하고, 나머지 모듈은 이 공통모듈을 의존한다.
예를 들어 앞서 말한 단일 모듈 멀티 프로젝트의 경우,
하나의 서비스에서 사용하는 API 프로젝트와 batch 프로젝트가 있다고 생각해봅시다.
이 두 프로젝트가 같은 domain을 사용한다면 어떨까요?
똑같은 domain 로직을 API와 batch에 따로 작성해야 합니다.
이 말은 즉, domain 정책이나 로직이 바뀌었을때 2번 변경해서 작성해야 한다는 의미입니다.
이게 2개 이상이라고 생각했을때... 조금 끔찍하지 않나요? IDE를 프로젝트 개수만큼 켜서 직접 일일이 수정해줘야 합니다.
멀티모듈은 이러한 코드의 중복을 줄이고 유지보수성을 높이기 위해서 하나의 공통된 프로젝트를 만들어 사용하자는 의도에서 만들어졌습니다.
각자 다른 프로젝트에 있던 하나의 모듈들을 한 프로젝트에 모이게 하면서, 다음과 같은 형태가 될 것입니다.
이 무슨 끔찍한 그림..
API는 common을 의존하고, batch또한 common을 의존합니다.
common 프로젝트의 로직을 그대로 사용할 수 있게 되는 겁니다!
동시에, 이 common은 다른 모듈들을 하나로 이어주는 다리역할이 됩니다.
하지만 공통 모듈은 주의해서 사용해야한다.
공통 모듈은 최대한 사용을 지양하고 비즈니스 로직을 담지 않는 것이 중요합니다.
바로 앞에서 중복 코드를 줄이기 위해서 공통 모듈을 사용한다고 했는데요, 여기서 주의할 점이 있습니다.
모든 중복 코드를 다 공통 모듈에 넣다보면, 결국 비즈니스 로직이 추가될 수밖에 없습니다.
API에서만 쓰이는 로직이 common에 추가가 된다면 어떨까요?
batch에서는 알 필요도 없는 로직을 의존하게 됩니다.
이렇게 한 번 의존성이 꼬이기 시작하면, 스파게티 코드가 되면서 나중에 common을 분리하고 싶을 때 굉장히 까다로운 작업이 되겠죠.
그럼 공통 모듈에는 뭘 써야 하는건데? 라는 의문점이 들겠죠?
전체 모듈을 통틀어서 사용하는 enum 클래스나, 프로젝트 내에서 사용하는 util 등을 작성해주는 것이 좋습니다.
중요한 점은 다른 라이브러리에 대한 의존성을 최소화하는 것입니다. 즉, 순수한 자바 코드로 작성해주는 것이 좋습니다.
또, 공통으로 사용되는 Type, Util 등을 정의하는 용도로 사용합니다.
저 같은 경우는 exception의 response enum 클래스를 넣어주었습니다.
이상적인 멀티 모듈
역할과 의존성 관리가 멀티 모듈의 핵심
이것도 익숙한 말이죠? 개발을 공부할 때부터 역할과 책임을 분리해라~~ 지겹게 들었던 말입니다.
1. 명확한 추상화 경계
각 모듈이 갖는 책임과 역할을 명확하게 하는 것이 중요합니다.
어떤 모듈이 어디까지 개발해야하는지 경계가 명확해지면서, 의존성이 남발하는 스파게티 코드를 덜 쓸 수 있습니다.
2. 최소 의존성
각 모듈은 자기가 필요한 것만을 의존하면 됩니다.
예를 들어 API 모듈에서는 request, response 등 user interface와 통신하는 것만을 신경쓰면 되겠죠! 의존성도 그것에 관한 것만 다루면 되기 때문에, 불필요한 것은 다루지 않게 됩니다.
앞서 말했던 것 처럼 공통 모듈에 비즈니스 로직 작성을 최대한 피하기 위해서는 모듈 별로 책임과 역할을 분명히하는 것이 가장 중요합니다.
애초에 이 분리가 제대로 되지 않으면 공통 모듈에 비즈니스 로직을 작성할수밖에 없게 됩니다 ㅎㅎ..
가장 흔하게 사용되는 멀티모듈 구조
레이어 별로 모듈을 구성하는 것입니다.
즉, api 모듈, application 모듈, domain 모듈.. 우리가 흔히 알고있는 layer별로 나누어서 모듈을 분리할 수 있습니다.
마이크로서비스 아키텍처 MSA
멀티모듈과 비슷해보이겠지만, 다릅니다.
MSA라는 이름만 봐도 느낌이 좀 오지 않나요?
말 그대로, 마이크로서비스를 조각조각 모아서 하나의 거대한 서비스를 만드는 구조입니다.
즉, 모놀리식 서비스들을 모아서 하나의 서비스를 만들 수도 있습니다.
서비스 gateway
MSA는 완전히 독립적으로 작동할 수 있는 작은 서비스(micro service) 별로 분리하여 gateway를 통해 하나의 큰 서비스로 작동할 수 있게합니다.
여기에서 서비스 분리의 기준은 도메인 단위가 됩니다. (주문, 결제, 회원..)
이런 도메인 단위의 분리 때문에 특정 서비스 별로 독립적인 배포가 가능하고, 서비스 확장도 쉽습니다.
또한 특정 서비스에 대한 리팩토링이나 기술 변경과같은 큰 변화가 있을 때, 전체를 변경하지 않아도 되어서 유리합니다.
아래의 그림을 통해 모놀리식과 마이크로서비스를 좀 더 쉽게 이해할 수 있을 것 같네요.
하지만 이 말만 들었을 때는, 멀티모듈과 큰 차이점이 없어 보입니다.
멀티모듈과 MSA의 차이점
쇼핑몰을 하나의 예시로 들어볼까요?
모놀리식 아키텍처 - 멀티모듈
모놀리식 아키텍처에서는 쇼핑몰 자체를 하나의 서비스로 봅니다.
주문, 결제, 회원.. 이 모든 것이 하나의 서비스이기 때문에 api도 한번에 처리하게 되는거죠.
게시판 api에 문제가 생기면 전체 서비스가 작동하지 않게 됩니다.
MSA
반면 MSA에서는 모든 서비스를 도메인별로 분리합니다.
주문서비스, 결제서비스, 회원서비스... 이런식으로 서비스를 작게 분리하여 조각조각 맞추는 형태로 하나의 거대한 서비스가 됩니다.
하나의 작은 서비스가 없어도 다른 작은 서비스에는 문제가 없게 되는거죠.
즉, 게시판 서비스에 어떤 결함이 있을 때, 주문이나 결제 서비스는 정상적으로 작동됩니다.
굉장히 이상적인 구조이죠?
이상은 이상일 뿐일 수도 있다..
MSA처럼 도메인별로 서비스를 분리해서 개발을 한다면, 분명히 유지보수와 확장성과 같은 장점이 뚜렷합니다.
어떤 프로젝트가 어떤 책임을 갖고있는지 명확하게 보이기 때문에 다른 모듈을 뒤져서 확인할 필요도 없죠.
하지만 그에 따른 오버헤드를 무시할 수 없습니다.
모듈마다 JVM이 다르게 동작하기 때문에 데이터 간 동기화, 즉 트랜잭션 관리 때문에 서비스간의 통신을 잘 다뤄야하고, 큐 관리, 분산 db관리 등등... 신경써야하는 것이 굉장히 많아집니다.
분명히 이상적인 아키텍처를 위해서 모듈간 철저하게 분리하는 것은 좋은 시도가 될 것입니다.
하지만 실제로 사용할 때는 프로젝트의 성격에 맞게 유연하게 변경하는 것이 좋아보입니다.
후기
개인프로젝트를 만들 때, 처음부터 멀티모듈로 프로젝트를 구성하려고 하면 많은 어려움이 있을 수 있습니다. 제가 그랬거든요..
일단 처음 시작하는 단계에서는 모노리스~모놀리식 단일 아키텍처로 구성하다가, 점점 프로젝트의 스케일이 커지면 멀티모듈~MSA로 분리하는 것이 바람직해보입니다.
어차피 멀티모듈을 배우고 적용하면서 정말 많은 시행착오를 겪게 되기 때문에 프로젝트 구조를 많이 갈아엎게 됩니다.
저는 초보개발자이기 때문에 기초 개념부터 다시 공부하느라고 시간이 더 많이 걸렸네요.(도메인이 뭔데.. 서비스 비즈니스말고 도메인 비즈니스가 따로있단말이야? 이건 뭔데.. 인프라는 왜 또 따로 하는거고..)
멀티 모듈을 적용하기 앞서서 기초개념부터 잘 잡혀있어야한다는 것을 새삼 깨달았습니다..ㅎㅎ
지금도 제대로 알고있다는 생각이 들지 않네요.
어려운 개념이고, 어떤 것이 좋은 아키텍처인지는 모두 다른 의견을 갖고 있기 때문에 자신이 생각한 대로 적용해본 뒤 다양한 피드백을 받는 것이 제일 좋아보입니다ㅠㅠ
