Fitdo를 개발과정에서 멀티모듈을 적용하며 배운점들을 기록합니다.
Fitdo는 AWS EC2 프리티어 서버에서 API 서버를 구동하는 프로젝트로, 메모리 부족 문제가 빈번히 발생했습니다. 서버가 배포 과정에서 다운되거나 스와핑을 반복하는 상황에서, 배치 작업까지 추가되면 서버에 과부하가 걸릴 것이 분명했습니다. 이를 해결하기 위해 배치를 분리된 서버(Lambda)를 통해 실행하는 방식으로 전환하기로 결정했습니다.
하지만 기존 Fitdo의 구조는 하나의 모놀리틱 프로젝트로 구성되어 있었고, API 코드와 배치 코드가 하나의 도커 이미지에 담겨 있었습니다. 이를 분리하여 독립적인 서버 배포가 가능하도록 하기 위해 멀티모듈 구조를 도입했습니다.
멀티모듈이란?
멀티모듈은 말 그대로 하나의 프로젝트를 여러 개의 모듈로 나누는 방식입니다.
여기서 모듈은 Java 9에서 도입된 개념으로, 특정 기능이나 도메인을 중심으로 패키지를 묶어 재사용성을 높이고, 프로젝트를 더 효율적으로 관리할 수 있도록 합니다.
멀티모듈의 장점
- 코드 재사용성 증가: 중복된 코드를 제거하여 유지보수가 용이합니다.
- 모듈 간 책임 분리: 기능별로 모듈을 분리해 응집도를 높입니다.
- 독립 배포 가능: 필요한 모듈만 선택적으로 배포할 수 있습니다.
Fitdo의 멀티모듈 설계
Fitdo의 주요 도메인 중 하나는 운동(Exercise)입니다. 이를 통해 다음과 같은 시나리오를 상상해볼 수 있었습니다
- 사용자 API 서버와 관리자 API 서버가 각각 운동 도메인을 필요로 하는 경우.
만약 모듈화를 하지 않고, 각각을 따로 배포를 하려하면 관리자와 사용자 API를 위해 중복된 운동도메인을 붙혀넣기할수밖에 없을것입니다. 따라서 운동 도메인을 별도로 분리하여 중복을 방지할수 있습니다.
모듈 구조 설계
설계 원칙
멀티모듈 설계의 핵심은 모듈 간 의존성을 최소화하고 독립성을 유지하는 것입니다. Fitdo의 경우 유지보수가 주된 작업이 될 것을 예상하고, 배포 시점을 기준으로 모듈을 다음과 같이 나누었습니다.
모듈 구성
-
Domain 모듈
- 데이터베이스와의 영속성 계층을 담당.
- 다른 모듈이 공통적으로 참조.
-
Core 모듈
- 비즈니스 로직 구현.
- Domain 모듈에 의존하며, Web 모듈에서 호출됨.
-
Web 모듈
- 외부와 통신하는 API 계층.
- 사용자 요청을 받아 Core 모듈의 비즈니스 로직을 실행.
-
Batch 모듈
- 배치 작업을 수행.
- AWS Lambda에 독립적으로 배포
구현 과정에서 배운 점
모든 코드는 Fitdo에서 확인할수 있습니다.
서비스가 확장됨에 따라 유지보수를 편리하게 하기 위해 모듈을 적절히 분리하는 것은 매우 효과적인 방법이라고 생각합니다. 이전에 MSA를 경험해보기 위해 여러 개의 레포지토리를 생성하고, IDEA를 4~5개씩 실행하며 개발했던 기억이 납니다. 하지만 멀티모듈 방식을 도입하면 배포와 코드 관리의 편의성이 크게 향상될 것으로 기대됩니다.
다만, 모듈의 개수가 많아질수록 의존성 관리와 추가적인 설정 파일(build.gradle 등)에 대한 부담이 커질 수 있어 생산성이 오히려 낮아질 가능성도 있습니다. 따라서 상황에 맞게 신중히 판단하여 멀티모듈 방식을 활용하는 것이 중요할것 같습니다.
