네이티브 이미지 사용기

네이티브 이미지 사용기

10개월 정도 GraalVm을 이용한 Native Image를 사용해서 개인서비스를 운영해봤다. 그동안 겪은 이슈나 운영 후기들에 대해 간략히 적어 놓으려고 한다.

시작 동기

서버메모리 사용량

aws t2.micro를 사용중인데, 램이 1GB인 서버다. 그래서 항상 리눅스 메모리 사용량을 보면 80~90프로에 육박하고 있었는데, 메모리 사용량이 너무 많은 것 같아서 네이티브 이미지를 도입해봤다.

그런데 요즘은 메모리 사용량이 문제 상황이 맞는지 잘 모르겠다. OOM으로 죽은 적도 없고, 점유율 올라갔다가 다시 잘 내려오고, 굳이 예민하게 반응할 필요가 없었던 것 같다. 저 서버에서 추가적인 작업을 하거나 다른 인스턴스를 띄울거면 문제 상황이 맞는데, 나는 도커로 자바 앱 하나 띄우는 상황이 몇 년째 고정이라 잘 모르겠다.

확실히 메모리 점유율이 줄어들기는 했다. 그리고 컴파일 방식이라 별도의 웜업도 필요없어서 빠릿빠릿하기는 하다.

사용 후기

메모리 사용량

로컬에서 이미지만 단순히 띄운거라 실제 운영할때는 좀 다를 수 있는데, 확실히 줄어들기는 한다.

위의 사진이 기존 JVM으로 어플리케이션을 실행했을 때의 메모리 사용량인데, 네이티브로 컴파일하면 훨씬 줄어들기는 한다.

이게 네이티브 이미지로 실행한 값인데, 훨씬 줄어들기는 했다.

웜업

기존 JVM에서는 처음 띄웠을 때 api 첫 호출 시 이것저것 읽고 컴파일 해야되서 살짝 느린감이 있는데, 얘는 애초에 컴파일 방식이라 그런 이슈는 없긴 하다. 그런데 나는 초기 응답시간이 그렇게 중요한 앱은 아니라서 상황마다 다를 것 같다.

모니터링

그라파나로 몇몇 지표들은 추적이 안된다. JVM 관련 지표들 중에 GC 타이밍 같은건 추적이 안된다.

더 찾아보니 해당 문제를 그랄 측에서도 인지는 하고 있는데, 당장의 우선순위가 아니라서 해결되기까지는 아직 더 시간이 걸릴 것 같다.

관련 이슈: [GR-51307] Unable to collect GC data with NotificationEmitter in native build

그래도 메모리 사용량은 추적이 된다. 에덴이나 서바이버 같은 애들은 잘 나온다. 위의 사진을 보면서 혹시 필요한 지표가 추적이 안되는 게 보인다면 사용을 잘 생각해보자.

이미지 빌드 리소스

이건 배포할 때 좀 문제가 될 것 같은데, Github Action 으로 private 레포 같은곳에서 Github 서버로 빌드 돌리면 과금 꽤 될 것 같다.

도커 초기화 상태, 그러니까 아무런 이미지도 받아놓지 않은 깔끔한 상태에서 빌드 시작하면 10분씩 걸렸던 것 같다. 생각보다 제법 걸린다. cpu 점유율도 쫙 끌어다 쓰고, 메모리도 있는대로 다 땡겨쓰기 때문에 한 번쯤 고려할만한 요소 같다.

코드 레벨

AOT나 리플렉션 관련 말이 많아서 해도 되나 싶었는데 생각보다 별 문제 없었다. 그랄로 빌드한 클래스들 보면 좀 독특하게 결과물이 나와있긴 한데, 어쨌든 생각보다 큰 문제는 없었다.

참고

• 내 경험