Quarkus의 네이티브 컴파일 - 중요한 이유

안녕하세요 여러분! 이것은 Quarkus 시리즈의 두 번째 게시물입니다. 오늘은 네이티브 컴파일에 대해 이야기하겠습니다.

쿼쿠스 은 Java 스택입니다. Kubernetes. 여기서 해야 할 일이 확실히 더 많지만 JVM 및 여러 프레임워크 최적화를 포함하여 여러 측면에서 많은 훌륭한 작업을 수행했습니다. 개발자들의 관심이 높아진 Quarkus의 기능 중 하나는 Java 코드를 특정 운영 체제용 실행 파일(소위 "네이티브 컴파일")로 변환하는 포괄적이고 원활한 접근 방식입니다. 이는 C 및 C++와 유사합니다. 일반적으로 빌드, 테스트 및 배포 주기가 끝날 때 발생합니다.

아래에서 살펴보겠지만 네이티브 컴파일도 중요하지만 Quarkus는 스택 전체에 구현된 성능 향상 덕분에 가장 일반적인 Java 시스템인 OpenJDK Hotspot에서 매우 잘 실행된다는 점에 유의해야 합니다. 따라서 네이티브 컴파일은 원하거나 필요에 따라 사용할 수 있는 추가 보너스로 간주되어야 합니다. 실제로 Quarkus는 네이티브 이미지와 관련하여 OpenJDK에 크게 의존합니다. 그리고 개발자들이 적극적으로 수용하는 개발 모드는 Hotspot에 구현된 동적 코드 실행의 고급 기능으로 인해 변경 사항을 거의 즉각적으로 테스트할 수 있도록 보장합니다. 또한 기본 GraalVM 이미지를 생성할 때 OpenJDK 클래스 라이브러리 및 HotSpot 기능이 사용됩니다.

그렇다면 모든 것이 이미 완벽하게 최적화되어 있는데 왜 네이티브 컴파일이 필요한가요? 우리는 아래에서 이 질문에 답하려고 노력할 것입니다.

분명한 것부터 시작해 보겠습니다. Red Hat은 프로젝트 개발 중에 JVM, 스택 및 프레임워크를 최적화하는 광범위한 경험을 보유하고 있습니다. JBoss, 포함:

• 플랫폼의 클라우드에서 작동하는 최초의 애플리케이션 서버 Red Hat OpenShift.
• 컴퓨터에서 실행되는 최초의 애플리케이션 서버 PC를 연결하세요.
• 실행되는 최초의 애플리케이션 서버 라즈베리 파이.
• 장치에서 실행되는 다양한 프로젝트 Android.

우리는 수년 동안 클라우드와 리소스가 제한된 장치(읽기: IoT)에서 Java 애플리케이션을 실행하는 문제를 해결해 왔으며 성능 및 메모리 최적화 측면에서 JVM을 최대한 활용하는 방법을 배웠습니다. 다른 많은 사람들과 마찬가지로 우리는 오랫동안 Java 애플리케이션의 기본 컴파일 작업을 수행해 왔습니다. G.C.J., 조류, 엑셀시어 제트 심지어 달빅 그리고 우리는 이 접근 방식의 장단점을 잘 알고 있습니다(예를 들어 "한 번 빌드하면 어디서나 실행"이라는 보편성과 컴파일된 애플리케이션이 더 작고 더 빠르게 실행된다는 사실 사이에서 선택해야 하는 딜레마).

이러한 장점과 단점을 고려하는 것이 왜 중요한가요? 어떤 상황에서는 그 비율이 결정적이 되기 때문입니다.

• 예를 들어 서버리스/이벤트 중심 환경에서는 서비스를 시작하기만 하면 됩니다 이벤트에 응답할 시간을 갖기 위해 (하드 또는 소프트) 실시간으로. 수명이 긴 영구 서비스와 달리 여기서 콜드 스타트 ​​기간은 요청에 대한 응답 시간을 크게 늘립니다. JVM은 시작하는 데 여전히 상당한 시간이 걸리며, 경우에 따라 순수한 하드웨어 방법으로 이를 줄일 수 있지만 5초와 XNUMX밀리초의 차이가 삶과 죽음의 차이가 될 수 있습니다. 예, 여기에서 Java 머신의 핫 리저브를 생성해 볼 수 있습니다(예를 들어 우리는 다음과 같이 했습니다). OpenWhisk를 Knative로 포팅) 그러나 이것 자체만으로는 로드가 확장됨에 따라 요청을 처리하기에 충분한 JVM이 있다는 것을 보장하지 않습니다. 그리고 경제적 관점에서 볼 때 이것은 아마도 가장 올바른 선택이 아닐 것입니다.
• 게다가 자주 나타나는 또 다른 측면이 바로 멀티테넌시입니다. JVM은 기능 면에서 운영 체제와 매우 유사하다는 사실에도 불구하고 여전히 Linux에서 익숙한 프로세스 격리 작업을 수행할 수 없습니다. 따라서 하나의 스레드가 실패하면 전체 Java 시스템이 다운될 수 있습니다. 많은 사람들은 실패로 인한 결과를 최소화하기 위해 각 사용자의 애플리케이션에 대해 별도의 JVM을 전용으로 사용하여 이러한 단점을 해결하려고 합니다. 이는 매우 논리적이지만 스케일링에는 적합하지 않습니다.
• 또한 클라우드 지향 애플리케이션의 경우 중요한 지표는 호스트의 서비스 밀도입니다. 방법론으로의 전환 12가지 적용 요소, 마이크로서비스 및 Kubernetes는 애플리케이션당 Java 머신 수를 늘립니다. 즉, 이 모든 것이 탄력성과 신뢰성을 제공하지만 동시에 서비스 측면에서 기본 메모리 소비도 증가하며 이러한 비용 중 일부가 항상 꼭 필요한 것은 아닙니다. 정적으로 컴파일된 실행 파일은 서비스가 실제로 사용하는 프레임워크 부분(JDK 자체 포함)만 최종 이미지에 포함되는 경우 낮은 수준의 데드 코드 제거와 같은 다양한 최적화 기술로 인해 이점을 얻습니다. 따라서 Quarkus 네이티브 컴파일은 보안을 손상시키지 않고 호스트에 서비스 인스턴스를 조밀하게 배치하는 데 도움이 됩니다.

실제로 위의 주장은 이미 Quarkus 프로젝트 참가자의 관점에서 네이티브 컴파일의 정당성을 이해하기에 충분합니다. 그러나 기술적이지는 않지만 중요한 이유가 또 있습니다. 최근 몇 년 동안 많은 프로그래머와 개발 회사가 Java를 포기하고 새로운 프로그래밍 언어를 선호하고 있으며 Java는 JVM, 스택 및 프레임워크와 함께 너무 많이 사용되었습니다. 메모리가 부족하거나 너무 느립니다.

그러나 어떤 문제를 해결하기 위해 동일한 도구를 사용하는 습관은 항상 옳은 것은 아닙니다. 때로는 한발 물러서서 다른 것을 찾는 것이 더 나을 때도 있습니다. 그리고 Quarkus가 사람들을 잠시 멈추고 생각하게 만든다면 그것은 전체 Java 생태계에 좋은 일입니다. Quarkus는 보다 효율적인 애플리케이션을 구축하는 방법에 대한 혁신적인 관점을 제시하여 Java를 서버리스와 같은 새로운 애플리케이션 아키텍처에 더욱 적합하게 만듭니다. 또한 확장성으로 인해 Quarkus는 Java 확장의 전체 에코시스템을 보유하게 되어 즉시 사용 가능한 애플리케이션에서 기본 컴파일을 지원하는 프레임워크의 수가 크게 늘어날 것입니다.

출처 : habr.com