Spring Boot 로딩 시간 및 빌드 시간 단축하기

개요

프로젝트의 모듈 수와 코드량이 증가함에 따라 로컬에서 Spring Boot 애플리케이션을 완전히 구동하는 데 소요되는 시간이 지속적으로 길어졌다. 이로 인해 로컬에서 코드를 수정하고 다시 구동하여 테스트하는 과정에서 불필요한 시간이 늘어났고, 빌드 시간도 증가하면서 CI 수행시간이 길어져 개발 생산성이 계속 저하되었다. 이를 개선하기 위해 애플리케이션 로딩 시간과 빌드 시간을 단축할 수 있는 방법을 찾아보고 적용해 보았다.(Spring Boot v3.2.7, Gradle v8.5 사용 중)

1. 불필요한 컴포넌트 스캔 범위 축소 및 지연 초기화(lazy initialization) 설정

   적용 이후 애플리케이션 로딩 시간 47% 단축

• Mac(M4 Pro): 53초 → 22초
• Windows(ASUS gu603): 90초 → 48초

2. Gradle 병렬 처리(parallel execution) 및 빌드 캐시(build cache) 활용

   적용 이후 빌드 시간 91% 단축

• 전체 빌드 기준: 3분 16초 → 17초

 

 

1. 지연 초기화(lazy initialization) 설정

Spring은 기본적으로 애플리케이션 구동 시점에 컨텍스트에 등록된 모든 싱글톤 빈을 즉시 생성하고 초기화한다. 그러나 실제 개발 시점에서는 모든 빈을 사용하는 경우는 웬만해선 잘 없다. 당장 내가 속한 프로젝트만 하더라도 여러 스쿼드가 동일한 레포지토리에서 모듈별로 나눠 사용하는데 다른 스쿼드의 모듈 같은 경우는 사용하지 않고, 내가 사용하는 모듈에서도 지금 개발하는 로직 말고는 사용되지 않는 빈들이 대다수다.

이러한 상황에서 spring.main.lazy-initialization=true 설정을 적용하면, 모든 빈의 생성을 한 번에 실제 사용 시점까지 지연시킬 수 있다. 

https://www.baeldung.com/spring-boot-lazy-initialization

즉시 초기화 방식과 달리 지연 초기화 방식에서는 불필요한 빈을 생성하지 않으므로, 애플리케이션 로딩 시 필요한 클래스와 빈의 수가 대폭 감소하여 로딩 시간이 크게 단축될 수 있다.

실제로 프로젝트에서 Java Flight Recorder(JFR)를 활용하여 지연 초기화 적용 전후로 메서드 호출 횟수가 얼마나 줄어들었는지 비교해 보았다. 

-XX:StartFlightRecording=duration=60s,filename=boot.jfr,settings=profile

JFR은 VM options에 위 옵션을 주고 실행하면 수집이 가능하고, IntelliJ를 사용 중이라면 별도로 JMC를 설치하지 않고도 JFR을 IntelliJ에서 열어볼 수 있다.

 

Profiler 결과

지연 로딩 적용 전: 5,290회

지연 로딩 적용 후: 2,202회

초기 로딩 시 메서드 호출 횟수가 절반 이상 감소했다.

 

적용 전: 로딩 시간 53초

적용 후: 로딩 시간 22초

그리고 이에 따라 로딩이 완료되는 시간도 절반 이상이 줄어들었다.

 

성능이 좋은데 왜 기본 설정이 아닐까?

지연 초기화를 설정하면 부트 로딩 속도가 눈에 띄게 빨라진다. 그런데도 스프링의 기본 설정은 왜 즉시 초기화일까?

https://spring.io/blog/2019/03/14/lazy-initialization-in-spring-boot-2-2

지연 초기화가 초기 로딩 시 성능적으로 뛰어난데도 기본 설정이 아닌 이유는 순환 참조, 메모리 부족 오류 등의 문제를 즉시 발견하지 못하는 등 잠재적 문제가 발생할 수 있기 때문이다. 따라서 로컬에서 띄울 때만 선택적으로 적용하는 것이 안전하게 성능의 이점을 누릴 수 있다고 생각된다.

만약 모든 빈을 지연 초기화하는 것이 부담스럽거나, 배포 환경에서도 적용하고 싶다면 @Lazy를 사용해 선택적으로 테스트해 보고 하나씩 적용하면 될 것 같다.

 

 

2. Gradle 병렬 처리(parallel execution) 및  빌드 캐시(build cache)

Gradle의 빌드 성능을 개선에 대한 자세한 문서는 Gradle Performance 문서를 참고하면 된다. 성능개선 외에도 모든 속성에 대해 알고 싶다면 Gradle Properties문서를 참고하자.

성능 개선과 관련된 주요 속성은 아래 세 가지이다.

1. org.gradle.daemon=true

Gradle 빌드를 위해 JVM을 매번 새로 띄우는 대신 백그라운드에서 항상 실행되는 데몬 프로세스를 재사용하는 기능이다. JVM 초기화 비용을 절감할 수 있기 때문에 빌드 시작이 훨씬 빨라진다. 다만 Gradle v3.0부터는 default가 true이기 때문에 명시적으로 설정하지 않아도 아마 대부분의 프로젝트에서 기본적으로 활성화되어 있을 가능성이 크다.

2. org.gradle.caching=true

이전 빌드에서 생성된 task 결과(컴파일 결과, 리소스 처리 등)를 저장해 두었다가, 다음 빌드 시 입력값이 동일할 경우 해당 결과를 재사용하는 기능이다. 특히 멀티 모듈과 같은 프로젝트에서 공통 모듈이 자주 재사용되는 경우에 큰 효과를 볼 수 있다.

참고로 ./gradlew clean을 실행하더라도 캐시는 삭제되지 않고 유지된다. 따라서 별도로 캐시를 지우지 않는 한 clean 후 build를 수행하더라도 캐시는 적용된다. 캐시를 삭제하려면 Gradle의 캐시 디렉터리를 직접 삭제하면 된다. (~/.gradle/)

3. org.gradle.parallel=true

서로 의존하지 않는 task들을 동시에 병렬로 수행하여 빌드 속도를 높인다. 이때 '의존관계에 따른 순서를 따로 지정해주어야 하나?' 싶을 수도 있지만 의존 관계에 따른 실행 순서는 따로 정의해주지 않더라도 보장된다. Gradle은 빌드 실행 전에 태스크 간 의존 관계 그래프를 구성하는데 이 그래프를 기반으로 태스크의 실행 순서를 자동으로 관리하기 때문이다.

https://docs.gradle.org/current/userguide/build_lifecycle.html#:~:text=As%20a%20build%20author%2C%20you,order%20dictated%20by%20these%20dependencies

따라서 의존성이 있는 태스크는 반드시 선행 태스크가 완료된 후 실행되며, 의존성이 없는 태스크는 병렬로 실행된다.

적용방법은 project root에 gradle.properties를 만들고 속성을 허용해 주면 된다.

# gradle.properties
org.gradle.daemon=true
org.gradle.parallel=true
org.gradle.caching=true

 

적용 후 메모리 부족 문제

해당 설정들을 적용한 이후 빌드 중 메모리 부족 문제가 발생할 수 있다. 이 경우 아래 예시처럼 본인 환경에 맞게 JVM 힙 메모리와 메타스페이스 크기를 조정해주면 된다.

org.gradle.jvmargs=-Xmx2048m -XX:MaxMetaspaceSize=512m

 

Profiler 결과

./gradlew build --scan 명령어를 통해 빌드 메타데이터를 분석했다.

아무 설정도 하지 않았을 때

기본 설정으로 빌드를 수행한 결과 총 26개의 프로젝트에서 363개의 태스크가 실행되었고, 전체 빌드 시간은 3분 16초가 소요되었다.

 

caching만 적용했을 때

org.gradle.caching=true 옵션을 적용한 경우, 동일하게 363개의 태스크가 실행되었지만 이 중 70개의 태스크가 캐시로 처리되었다. 덕분에 약 1분 37초를 절약하여 전체 빌드 시간은 1분 35초로 단축되었다.

 

caching + parallel 적용했을 때

org.gradle.parallel=true 옵션까지 추가 적용한 결과 병렬 처리가 효과적으로 이뤄진 것을 타임라인에서 확인할 수 있다. 전체 빌드 시간은 단 17초로 성능이 획기적으로 개선되었다.

위 속성들을 추가함으로써 로컬뿐만 아니라 CI단계에서도 빌드 시간을 대폭 줄일 수 있었다.

 

 

정리

이번 최적화 작업을 통해 Spring Boot 애플리케이션의 로딩 시간은 최대 47%, 빌드 시간은 최대 91%까지 단축할 수 있었다. 특히 지연 초기화와 Gradle의 캐시 및 병렬 처리 설정은 적용 방법이 간단하면서도 눈에 띄는 성능 향상을 제공하기에 나처럼 낭비되는 시간 오버헤드에 대해 개선 고민을 한다면 한 번쯤 적용해 보면 좋을 것 같다.