[Spring] 역할에 따른 멀티모듈 구성으로 프로젝트 개선하기

멀티모듈로 분리한 이유

기존 프로젝트는 단일모듈로 구성되어 있어 코드 변경 시 전체 코드가 컴파일, 배포되는 구조입니다. 현재 프로젝트에서는 크게 2가지 영역이 있습니다.

• 주기적으로 외부 api 를 호출해 주차장 잔여 좌석을 갱신하는 스케줄러
• spring mvc 를 활용한 어플리케이션 코드

스케줄러의 코드 변경은 어플리케이션 코드에 전혀 영향이 없습니다. 그러나 단일 모듈 구조에서는 스케줄러 코드가 변경되어도 전체 코드가 컴파일, 배포 됩니다.

현재 단일 모듈의 단점

• 스케줄러 코드의 변경으로 전혀 영향이 없는 어플리케이션 코드도 재배포 됩니다.
  • 변경 주기가 다른 스케줄러, 어플리케이션 코드가 항상 같이 재배포되는 구조입니다.
• CI 속도가 불필요하게 오래 걸린다.
  • 스케줄러 코드 변경으로 인해 전체 코드 테스트 수행 → 전체 코드 컴파일 → 배포 되는 구조이기 때문에 스케줄러 모듈만 배포하는 것보다 CI 에 오랜 시간이 걸립니다.

모듈 분리하기

• 스케줄러와 어플리케이션 코드(spring mvc) 의 변경 주기는 다르다.
• 스케줄러와 어플리케이션 코드(spring mvc) 의 역할은 명확하게 차이가 난다.

위 2가지 이유로 스케줄러 모듈과 앱 모듈을 분리하기로 했습니다. 스케줄러 모듈에서 사용하는 엔티티는 앱 모듈의 엔티티를 그대로 사용하기로 결정했습니다. 그 이유는 스케줄러에서 주차장 정보를 갱신하고, 앱 모듈에서는 이 정보들을 각 요청에 맞게 조회하여 보여주기 때문에 분리할 필요가 없다고 판단했습니다.

그래서 '스케줄러 모듈 → 앱 모듈' 로의 의존성을 설정했습니다.

 

그 구조는 아래와 같습니다.

결과(장점)

• CI 를 위한 테스트 시간
  • 스케줄러 변경이 발생하면 해당 모듈만 다시 배포하면 되기 때문에 CI 시간이 단축됩니다.
• 독립적으로 확장 가능한 구조
  • 이제 스케줄러 모듈과 앱 모듈은 독자적으로 확장될 수 있습니다.
  • 스케줄러 모듈의 경우 경기도의 주차장 정보를 추가하더라도 독립적으로 배포가 가능해 확장성을 개선할 수 있습니다.
• 재배포 주기 개선
  • 앱 모듈의 불필요한 재배포를 줄일 수 있습니다.
    • 처음 서버를 띄우면 JVM 에 클래스가 로드 되어야 하기 때문에 서버 성능이 떨어지는 시점이 존재합니다. 그래서 실제로 배포 후 웜업을 진행한다는 세미나도 존재합니다.