GraalVM 네이티브 이미지: Spring WebFlux VS Quarkus 2개 분석
안녕하세요! 여러분! JAVA 대표 프레임워크와 GraalVM 대표 프레임워크인 Spring WebFlux VS Quarkus 의 차이를 심층 비교 합니다.
목차
소개
필자는 Java프레임워크는 현재 Quarkus만 이용 합니다. 그 이유는 아래 지표를 보시면 (출처 : 구글 검색)
- Swift
- Vapor: Reqs/sec 13701.82
- Perfect: Reqs/sec 41246.18
- Node.JS
- Express: Reqs/sec 20178.73
- Go
- net/http module : Reqs/sec 56270.09, Perfect results Reqs/sec 41246.18
- Java
- Spring — first run: Reqs/sec 22573.60
- Spring — second run: Reqs/sec 31517.60
- Spring Web Flux: Reqs/sec 66734.35
Java Spring Web Flux가 프레임워크 성능 중 가장 월등 한 것으로 나옵니다. 쿠버네티스에 최적화 되어 있는 Quarkus에 대해 아래 소개 드립니다.
GraalVM?
GraalVM은 고성능 런타임 환경으로, 다양한 프로그래밍 언어 및 실행 환경을 지원하는 현대적인 다용도 가상 머신입니다. Oracle에서 개발하였으며, 그 주요 특징 및 기능은 다음과 같습니다:
- 다양한 언어 지원: GraalVM은 Java, JavaScript, Ruby, R, Python, WebAssembly 및 JVM 기반 언어(예: Scala, Kotlin) 등 다양한 언어를 지원합니다.
- 고성능 JIT(Just-In-Time) 컴파일러: GraalVM은 JVM 상에서 작동하는 프로그램을 최적화하며 높은 실행 속도를 제공하는 JIT 컴파일러를 포함하고 있습니다.
- 네이티브 이미지 생성: GraalVM의 Truffle 프레임워크와 함께 사용하면 Java 어플리케이션을 미리 컴파일된 네이티브 바이너리로 변환할 수 있습니다. 이 바이너리는 JVM 없이 실행되며, 빠른 시작 시간과 낮은 메모리 사용량을 보입니다.
- 통합 런타임: 다양한 언어로 작성된 프로그램 간의 상호 운용성을 높여, 한 프로그램 내에서 여러 언어를 자유롭게 혼합하고 사용할 수 있게 해줍니다.
- LLVM 기반 언어 지원: GraalVM은 LLVM bitcode를 실행할 수 있도록 설계되었기 때문에 C, C++ 및 Rust와 같은 LLVM 기반 언어도 지원됩니다.
GraalVM의 이러한 기능은 특히 마이크로서비스 아키텍처와 서버리스 환경에서 유용하게 활용될 수 있습니다. 시작 시간이 중요한 환경에서 네이티브 이미지 생성 기능을 활용하면 애플리케이션의 시작 시간을 크게 줄일 수 있습니다.
GraalVM 네이티브 이미지?
Oracle이 2018년 GraalVM 1.0 출시를 발표한 이후로 Java 커뮤니티는 이 범용 가상 머신의 잠재력에 대해 떠들썩해졌습니다. Java, Scala, Kotlin 등과 같은 JVM 기반 언어는 물론 C 및 C++와 같은 LLVM 기반 언어로 작성된 애플리케이션을 실행하도록 설계된 GraalVM은 성능과 효율성의 새로운 시대를 열었습니다.
GraalVM의 가장 흥미로운 기능 중 하나는 JVM 기반 애플리케이션을 종종 “네이티브 이미지”라고 하는 네이티브 바이너리로 컴파일하는 기능입니다. 이러한 바이너리는 JVM 없이도 작동하므로 몇 가지 장점이 있지만 절충점과 제한 사항도 있습니다.
Spring WebFlux VS Quarkus
Spring 프레임워크 및 네이티브 이미지
JVM 세계에서 가장 성숙하고 인기 있는 프레임워크 중 하나인 Spring에는 앞서 언급한 제한 사항으로 인해 처음에는 기본 이미지 컴파일 기능이 부족했지만 커뮤니티는 솔루션을 열망했습니다. 2019년 중반까지 네이티브 이미지 컴파일을 Spring Boot로 가져오기 위해 ‘spring-graalvm-native’ 프로젝트가 시작되었습니다.
그러나 도전은 계속되었습니다. 컴파일에는 상당한 메모리가 필요하므로 저사양 컴퓨터를 사용하는 개발자에게는 어려움이 있습니다. 그러나 빌드 프로세스를 보다 원활하게 만들기 위해 상당한 메모리 최적화가 도입되면서 지속적으로 개선이 이루어졌습니다.
새로운 Java 프레임워크의 등장
Quarkus, Micronaut 및 Helidon을 입력하십시오. 이러한 최신 Java 프레임워크에는 기본 이미지 컴파일에 대한 지원이 내장되어 있습니다. 작년에 Quarkus와 그 출시에 대해 들었을 때 저는 흥미를 느꼈습니다. 그러나 ‘spring-graal-native’를 사용하여 Spring에 대해 Quarkus를 벤치마킹하는 초기 실험은 어려운 것으로 판명되었습니다. 문제는 지속되었지만 프로젝트의 실험적 성격으로 인해 이는 예상되었습니다.
Spring WebFlux VS Quarkus 벤치마크: 설정 및 매개변수
테스트 중인 애플리케이션 유형:
- WebMVC를 사용한 스프링 부트
- Webflux를 사용한 스프링 부트
- Quarkus
- Spring API 확장 기능을 갖춘 Quarkus
평가된 작업:
- ID로 가져오기
- 페이지 단위로 가져오기
- 특정 컬럼으로 필터링
- 새로운 데이터 삽입
- 삭제
컴파일 및 빌드 프로세스:
빌드 프로세스는 vCPU 4개와 16GiB RAM을 갖춘 가상 머신에서 실행되었습니다. 관찰된 빌드 시간은 다양했습니다.
- 스프링부트 : 8분 39초
- Webflux를 사용한 Spring Boot: 8분 12초
- 쿼커스: 3분 55초
- Spring API 확장이 포함된 Quarkus: 3분 57초
성능 지표:
Spring의 빌드 시간과 결과 바이너리 크기가 눈에 띄게 커져서 Spring 5.3과 ‘spring-graalvm-native’의 비실험 버전에 대한 기대가 촉발되었습니다.
모든 애플리케이션의 시작 시간은 인상적이었으며 vCPU가 1개 또는 2개 있는 시스템에서 1초도 채 안 되어 시작되었습니다.
스트레스 테스트 및 처리량:
스트레스 테스트를 위해 JMeter를 사용하여 애플리케이션은 vCPU 1개와 2GiB RAM이 있는 VM에서 호스팅되었습니다. 예비 테스트를 통해 JMeter 스레드 및 연결 풀 크기에 대한 최적의 설정이 결정되었습니다. 이러한 매개변수를 사용하여 15분 동안 테스트를 실행한 후 관찰된 처리량은 다음과 같습니다.
- 스프링 부트: 390.1 요청/초
- Webflux를 사용한 Spring Boot: 631.6 요청/초
- Quarkus: 1042.7 요청/초
- Spring API 확장이 포함된 Quarkus: 871.1 요청/초
Spring WebFlux VS Quarkus 결론
Quarkus는 특히 스트레스 테스트에서 놀라운 성능을 보였습니다. Spring Boot의 Webflux는 가능성을 보였지만 표준 버전은 뒤처졌습니다. 이 실험은 Java 생태계의 급속한 발전을 입증하는 역할을 합니다. Spring 5.3과 ‘spring-graalvm-native’의 다음 버전이 곧 출시될 때 커뮤니티는 숨을 죽이고 기다립니다.
JVM 기반 개발의 참호에 있는 사람들에게 성능과 효율성에 대한 탐구는 지속적인 여정입니다. 그러나 GraalVM, Quarkus 및 진화하는 Spring 생태계와 같은 도구와 프레임워크를 사용하면 미래가 유망해 보입니다.
저와 함께 이 탐구에 대해 깊이 생각해 주셔서 감사합니다. Java 세계의 더 많은 벤치마크, 실험 및 발견을 살펴보세요!
다음 Quarkus 개발환경 세팅은 아래 포스트를 확인하세요!
Quarkus와 이클립스를 이용한 개발환경 세팅 5단계 가이드
자료 출처는 아래 사이트 방문 하세요!
