TIL - 20241110

GraalVM 도입으로 JVM 백엔드 애플리케이션의 구동 초기 성능 문제 해결하기

기존 JVM에서의 문제점

JVM의 경우 JIT 컴파일로 동작하기 때문에 구동 직후의 성능은 매우 나쁘고 시간이 지날수록 프로파일 정보를 활용해서 점점 빨라짐. 그래서 JVM 앱에서는 웜업과정이 있고 Blue/Green 배포 시에 점차적으로 트래픽을 차차 늘려가야지 사용자 입장에서 불편함을 느끼지 않게 됨.
다만 이렇게 되는 경우 수동으로 비율을 늘려가야 하는 문제와 배포시에 시간이 매우 오래 걸린다는 문제가 있었음.
또한 긴급 상황에서 인스턴스를 급하게 증설해야 하는데, 이런 경우 노드를 많이 투입하는 등의 방식으로 해결할 수도 있긴 하지만 이렇게 되면 웜업이 끝난 후에는 인스턴스의 자원이 놀게되는 이슈가 있음.

GraalVM의 등장

JVM앱을 AOT로 컴파일 할 수 있게 해주는 방법.
구동 직후의 성능은 JIT로 동작하는 Hotspot 보다 훨씬 빠르지만 웜업이 완료된 Hotspot보다는 느린 특징이 있음.
다만 AOT로 컴파일을 하는 경우 여러 JVM 관련 기능을 사용할 수 없는 문제가 있는데 대표적으로 Reflection이나 Dynamic Proxy 등의 기술을 사용할 수 없는 문제가 있음.
이렇게 되면 할 수 있는게 없으니 GraalVM은 Tracing Agent를 제공해서 앱이 종료될 때까지 발생한 모든 비명시적인 의존성을 추적해서 Reachability metadata를 생성해주고 이를 바탕으로 동적 의존성에 대한 코드를 미리 정적 코드로 만들어줄 수 있음

테스트 및 벤치마킹

앱 초기화 시간의 경우 기존 3.76초에서 0.103초로 약 36배 빨라짐.
앱 기동 직후 응답시간의 경우 Hotspot의 경우 초기에는 매우 느리지만 시간이 지날수록 점차 감소하는 것을 보여주고, GraalVM의 경우에는 기동 후 걸린 시간에 상관 없이 거의 일정한 응답 시간을 보여주는 특징을 가지고 있음
TPS의 경우 최종적으로는 웜업이 끝난 Hotspot에 비해 GraalVM은 약 25% 정도 떨어지는 성능을 보이고 있음

Profile-Guided Optimization은 JIT 컴파일러가 런타임 프로파일 정보를 활용해서 컴파일을 진행하기 때문에 코드 성능이 좋아지므로 이와 유사하게 AOT 컴파일 시에도 해당 프로파일 정보를 넘겨주는 방법

그래서 pgo 측정용으로 컴파일을 해서 실제와 유사한 트래픽을 투입해서 프로파일 이벤트 데이터를 획득하고 해당 데이터를 넘겨주어서 컴파일을 진행함. 이를 통해 약 8% 정도의 TPS 차이를 보이도록 만들 수 있었음

또한 기존 Hotspot 의 경우 구동 직후에 CPU의 사용량이 급격하게 증가하는 이슈가 있어서 점진적인 트래픽 스위치가 필요한 반면 GraalVM의 경우 CPU 사용량이 큰 차이가 없어서 즉시 스위칭할 수 있는 특징이 있음

장점

• 더 빠르게 실행할 수 있음.
• 더 적은 기동 충격으로 점진적인 트패픽 스위칭이 필요하지 않아 배포 관리 공수가 줄어듬
• 더 작은 메모리 풋프린트와 실행 파일이미지도 줄어듬

단점

• Serial GC와 G1GC만 지원하는 문제가 있음
• Reachability Metadata 관리에 대한 부담이 있음
• 느린 빌드 시간. (약 5배 정도의 차이)
• 일부 라이브러리 지원이 미흡함
• PGO 적용이 어려움. (인스턴스의 속도 느림 이슈와 실트래픽을 투입해야하는 부담)

개인적인 생각

아직까지 GraalVM을 실제로 적용하기에는 많은 허들이 있는 것으로 느껴졌음. 카카오톡과 같이 많은 트래픽을 받아야 하는 서비스가 아니라면 웜엄 과정에서의 응답 시간이 오래 걸리는 부분은 어느정도 괜찮을 것으로 보임.
물론 자주 배포를 하는 앱이라면 한 번쯤 GraalVM을 적용하는 건 나쁘지 않을 것으로 보이나 앱 배포주기가 긴 경우에는 GraalVM을 적용할 필요는 없을 것으로 보임

참고: youtube, slide