영호
[Spring] 역할에 따른 멀티모듈 구성으로 프로젝트 개선하기 본문
멀티모듈로 분리한 이유
기존 프로젝트는 단일모듈로 구성되어 있어 코드 변경 시 전체 코드가 컴파일, 배포되는 구조입니다. 현재 프로젝트에서는 크게 2가지 영역이 있습니다.
- 주기적으로 외부 api 를 호출해 주차장 잔여 좌석을 갱신하는 스케줄러
- spring mvc 를 활용한 어플리케이션 코드
스케줄러의 코드 변경은 어플리케이션 코드에 전혀 영향이 없습니다. 그러나 단일 모듈 구조에서는 스케줄러 코드가 변경되어도 전체 코드가 컴파일, 배포 됩니다.
현재 단일 모듈의 단점
- 스케줄러 코드의 변경으로 전혀 영향이 없는 어플리케이션 코드도 재배포 됩니다.
- 변경 주기가 다른 스케줄러, 어플리케이션 코드가 항상 같이 재배포되는 구조입니다.
- CI 속도가 불필요하게 오래 걸린다.
- 스케줄러 코드 변경으로 인해 전체 코드 테스트 수행 → 전체 코드 컴파일 → 배포 되는 구조이기 때문에 스케줄러 모듈만 배포하는 것보다 CI 에 오랜 시간이 걸립니다.
모듈 분리하기
- 스케줄러와 어플리케이션 코드(spring mvc) 의 변경 주기는 다르다.
- 스케줄러와 어플리케이션 코드(spring mvc) 의 역할은 명확하게 차이가 난다.
위 2가지 이유로 스케줄러 모듈과 앱 모듈을 분리하기로 했습니다. 스케줄러 모듈에서 사용하는 엔티티는 앱 모듈의 엔티티를 그대로 사용하기로 결정했습니다. 그 이유는 스케줄러에서 주차장 정보를 갱신하고, 앱 모듈에서는 이 정보들을 각 요청에 맞게 조회하여 보여주기 때문에 분리할 필요가 없다고 판단했습니다.
그래서 '스케줄러 모듈 → 앱 모듈' 로의 의존성을 설정했습니다.
그 구조는 아래와 같습니다.
결과(장점)
- CI 를 위한 테스트 시간
- 스케줄러 변경이 발생하면 해당 모듈만 다시 배포하면 되기 때문에 CI 시간이 단축됩니다.
- 독립적으로 확장 가능한 구조
- 이제 스케줄러 모듈과 앱 모듈은 독자적으로 확장될 수 있습니다.
- 스케줄러 모듈의 경우 경기도의 주차장 정보를 추가하더라도 독립적으로 배포가 가능해 확장성을 개선할 수 있습니다.
- 재배포 주기 개선
- 앱 모듈의 불필요한 재배포를 줄일 수 있습니다.
- 처음 서버를 띄우면 JVM 에 클래스가 로드 되어야 하기 때문에 서버 성능이 떨어지는 시점이 존재합니다. 그래서 실제로 배포 후 웜업을 진행한다는 세미나도 존재합니다.
- 앱 모듈의 불필요한 재배포를 줄일 수 있습니다.
'Spring' 카테고리의 다른 글
@ConfigurationProperties 는 무엇을 기준으로 값을 주입할까 (2) | 2024.07.15 |
---|---|
[spring] Transactional outbox pattern 을 활용해 이벤트 유실 개선하기 (0) | 2024.04.27 |
[Spring] TaskScheduler 를 활용해 만료된 인증코드 제거하기 (0) | 2024.03.12 |
스탬프 중복 적립 개선기 (0) | 2024.02.23 |
[Spring] @TransactionalEventListener 에서 CUD 가 안되는 이유 (0) | 2023.10.15 |
Comments