In der dynamischen Landschaft der modernen Softwareentwicklung sind Microservices zum bevorzugten Architekturansatz geworden. Obwohl diese Methode zahlreiche Vorteile bietet, ist sie nicht ohne Herausforderungen. Probleme wie großer Speicherbedarf, verlängerte Startzeiten und hohe CPU-Auslastung gehen häufig mit herkömmlichen JVM-basierten Diensten einher. Diese Herausforderungen wirken sich nicht nur auf die technischen Aspekte aus, sondern haben auch finanzielle Auswirkungen, die sich erheblich auf die Gesamtkosten für den Betrieb und die Wartung von Softwarelösungen auswirken können.

Was ist GraalVM Native Image?

GraalVM Native Image ist eine Schlüsselfunktion von GraalVM, einer Hochleistungslaufzeit, die Unterstützung für verschiedene Programmiersprachen und Ausführungsmodi bietet. Insbesondere können Sie mit GraalVM Native Image Java-Anwendungen im Voraus in eigenständige native ausführbare Dateien kompilieren, ohne dass zur Laufzeit eine Java Virtual Machine (JVM) erforderlich ist. Dieser innovative Ansatz führt zu ausführbaren Dateien, die im Vergleich zu ihren herkömmlichen JVM-Gegenstücken nahezu sofortige Startzeiten und einen deutlich geringeren Speicherverbrauch aufweisen. Diese nativen ausführbaren Dateien werden sorgfältig erstellt und enthalten nur die wesentlichen Klassen, Methoden und abhängigen Bibliotheken, die für die Funktionalität der Anwendung unerlässlich sind. Über seine technischen Fähigkeiten hinaus erweist sich GraalVM Native Image als strategische Lösung mit weitreichenden Auswirkungen. Es meistert nicht nur technische Herausforderungen, sondern bietet auch überzeugende finanzielle Argumente. Durch die Erleichterung der Entwicklung effizienter, sicherer und sofort skalierbarer Cloud-nativer Java-Anwendungen leistet GraalVM einen entscheidenden Beitrag zur Optimierung der Ressourcennutzung und zur Förderung der Kosteneffizienz. Im Wesentlichen spielt es eine entscheidende Rolle bei der Steigerung der Leistung und finanziellen Effizienz von Softwarelösungen in modernen, dynamischen Umgebungen.

Technische Herausforderungen und finanzielle Auswirkungen

1. Großer Speicherbedarf

Technische Auswirkungen
Herkömmliche JVM-basierte Dienste verursachen aufgrund des Klassenladens und der Metadaten für geladene Klassen häufig einen erheblichen Speicheraufwand.

Finanzfall
Ein hoher Speicherverbrauch führt zu höheren Infrastrukturkosten. Die Eliminierung von Metadaten für geladene Klassen und andere Optimierungen durch GraalVM führen zu einer effizienteren Nutzung von Ressourcen, was zu potenziellen Kosteneinsparungen führt.

2. Erweiterte Startzeiten

Technische Auswirkungen
Kaltstarts in Microservices können zu längeren Reaktionszeiten führen, die Benutzererfahrung beeinträchtigen und möglicherweise zu einer Verschlechterung des Dienstes führen.

Finanzfall
Längere Startzeiten wirken sich nicht nur auf die Benutzerzufriedenheit aus, sondern tragen auch zu höheren Betriebskosten bei. Die Optimierungen von GraalVM, wie die Eliminierung des Klassenladeaufwands und die Vorgenerierung des Image-Heaps während des Builds, reduzieren die Startzeiten drastisch und minimieren möglicherweise die Betriebskosten.

3. Hohe CPU-Auslastung

Technische Auswirkungen
Herkömmliche JVMs beanspruchen während des Startvorgangs häufig CPU-Zyklen für die Profilerstellung und die Just-In-Time-Kompilierung (JIT).

Finanzfall
Eine übermäßige CPU-Auslastung führt zu höheren Kosten für die Cloud-Infrastruktur. Die Vermeidung von Profiling- und JIT-ing-Overhead durch GraalVM trägt direkt zu einem reduzierten CPU-Verbrauch bei, was zu potenziellen Kosteneinsparungen bei der Cloud-Nutzung führt.

Das Kaltstartproblem angehen

Microservices, insbesondere in serverlosen oder containerisierten Umgebungen, sind häufig mit dem Kaltstartproblem konfrontiert, das sich auf die Reaktionszeiten und die Benutzererfahrung auswirkt. GraalVM begegnet dieser Herausforderung durch die Implementierung mehrerer Optimierungen:

1. Kein Klassenladeaufwand

Herkömmliche Java-Anwendungen verlassen sich auf das Laden von Klassen zur Laufzeit, um Klassen dynamisch zu laden und zu verknüpfen. Dieser Prozess verursacht einen Mehraufwand, insbesondere während der Startphase. GraalVM minimiert diesen Overhead durch einen Prozess, der als statische oder AOT-Kompilierung (Ahead-of-Time) bezeichnet wird. Dazu gehört das Vorladen, Verknüpfen und teilweise Initiieren aller Klassen, die die Anwendung benötigt. Daher ist beim Anwendungsstart kein Laden der Laufzeitklasse erforderlich.

2. Eliminierung von interpretiertem Code

Traditionelle Java Virtual Machines verlassen sich auf einen interpretierten Ausführungsmodus, bevor sie die Just-In-Time-Kompilierung (JIT) anwenden. Dies kann zu Startverzögerungen und erhöhter CPU-Auslastung führen. Native ausführbare Dateien enthalten keinen interpretierten Code, was zusätzlich zu schnelleren Startzeiten beiträgt.

3. Kein Profiling- und JIT-ing-Overhead

GraalVM umgeht die Notwendigkeit, den Just-In-Time-Compiler (JIT) zu starten, und reduziert so die CPU-Auslastung während des Startvorgangs.

4. Image-Heap-Generierung zur Erstellungszeit

Das native Image-Dienstprogramm von GraalVM ermöglicht die Ausführung von Initialisierungsprozessen für bestimmte Klassen während des Build-Prozesses. Dies führt zur Generierung eines Image-Heaps, der vorinitialisierte Teile enthält, was den Start der Anwendung beschleunigt.

Das native Image-Dienstprogramm von Oracle GraalVM hat gezeigt, dass die Startzeiten fast 100-mal schneller sind als bei herkömmlichen JVM-basierten Anwendungen. Die folgende Grafik veranschaulicht die erhebliche Reduzierung des Laufzeitspeicherbedarfs und zeigt die Effizienz von GraalVM im Vergleich zu HotSpot (Abbildung 1).

Abbildung 1 – Native ausführbare Dateien starten fast sofort (oracle.com)

Einen schlankeren Gedächtnis-Fußabdruck erreichen

GraalVM trägt durch die folgenden Optimierungen zu einem geringeren Speicherbedarf bei:

1. Keine Metadaten für geladene Klassen

GraalVM vermeidet das Speichern von Metadaten für dynamisch geladene Klassen im Nicht-Heap-Speicher. Während des Build-Prozesses werden die erforderlichen Klasseninformationen vorab geladen und verknüpft, wodurch der Bedarf an zusätzlichen Metadaten zur Laufzeit minimiert wird.

2. Keine Profiling-Daten oder JIT-Optimierungen

Da sich der Bytecode bereits im nativen Code befindet, entfällt bei GraalVM das Sammeln von Profilierungsdaten für JIT-Optimierungen, wodurch der Speicheraufwand reduziert wird.

3. Isolationstechnik

GraalVM führt Isolates ein, eine Technologie, die den Heap in kleinere, unabhängige „Heaps“ unterteilt und so die Effizienz steigert, insbesondere in Anforderungsverarbeitungsszenarien.

Im Allgemeinen verbraucht es bis zu x5-mal weniger Speicher im Vergleich zur Ausführung auf einer JVM(Abbildung 2)

Abbildung 2 – Nativer Speicher für ausführbare Dateien im Vergleich zu Go oder Java HotSpot(oracle.com)

Zusammenfassend lässt sich sagen, dass das native Image-Dienstprogramm von GraalVM eine transformative Lösung für die Herausforderungen von Microservices bietet und Bedenken hinsichtlich der Startzeit, des Speicherbedarfs und der CPU-Auslastung berücksichtigt. Durch die Einführung von GraalVM können Entwickler cloudnative Java-Anwendungen erstellen, die nicht nur effizient und sicher sind, sondern auch ein hervorragendes Benutzererlebnis bieten.

Natives Java mit Quarkus

Um Ihren Quarkus-Dienst in ein natives Image zu kompilieren, stehen verschiedene Methoden zur Verfügung. Dieser Artikel geht zwar nicht näher auf den nativen Build-Vorgang von Quarkus ein, bietet aber einen Überblick über die wesentlichen Schritte.

Bevor Sie mit der Erstellung eines nativen Images fortfahren, ist es wichtig, das richtige native Profil in Ihrer pom.xml-Datei einzurichten. Fügen Sie das folgende Profil hinzu:

nativenative

Erstellen einer nativen ausführbaren Datei mit installierter GraalVM

Überprüfen Sie Ihre GraalVM-Version mit dem folgenden Befehl:

./gu info native-image

Dieser Befehl zeigt die installierte GraalVM-Version an:

Downloading: Component catalog from www.graalvm.org
Filename : https://github.com/graalvm/graalvm-ce-builds/releases/download/vm-22.3.0/native-image-installable-svm-java19-linux-amd64-22.3.0.jar
Name     : Native Image
ID       : native-image
Version  : 22.3.0
GraalVM  : 22.3.0
Stability: Experimental
Component bundle native-image cannot be installed
        - The same component Native Image (org.graalvm.native-image[22.3.0.0/55b341ca1bca5219aafa8ed7c8a2273b81d184dd600d8261c837fc32d2dedae5]) is already installed in version 22.3.0

Und um eine native ausführbare Datei zu erstellen, verwenden Sie:

./mvnw install -Dnative

Diese Befehle generieren eine *-runner-Binärdatei im Zielverzeichnis, sodass Sie die native ausführbare Datei ausführen können:

./target/*-runner

Erstellen einer nativen ausführbaren Datei ohne installierte GraalVM

Wenn die lokale Installation von GraalVM eine Herausforderung darstellt, kann ein In-Container-Build verwendet werden:

./mvnw install -Dnative -Dquarkus.native.container-build=true -Dquarkus.native.builder-image=graalvm

Dieser Befehl initiiert den Build innerhalb eines Docker-Containers und stellt die erforderliche Image-Datei bereit. Anschließend können Sie die Anwendung starten mit:

./target/*-runner

In Fällen, in denen sich die Erstellung des nativen Images als schwierig erweist, stellt das RedHat-Team eine spezielle Distribution von GraalVM namens Mandrel bereit, die für das Quarkus-Framework entwickelt wurde. Dorn rationalisiert
GraalVM konzentriert sich ausschließlich auf die nativen Image-Funktionen, die für Quarkus-Anwendungen unerlässlich sind. Um Mandrel zu verwenden, befolgen Sie diese Schritte:

1. Identifizieren Sie die entsprechende Mandrel-Version. Mandrel-Repository

2. Legen Sie die Mandrel-Version in Ihrer application.properties-Datei fest:
   

quarkus.native.builder-image=quay.io/quarkus/ubi-quarkus-mandrel-builder-image:23.0.1.2-Final-java17

3.Führen Sie den Maven-Build-Befehl aus:

./mvnw clean install -Pnative

Manuelles Erstellen eines Containers

Für diejenigen, die die manuelle Kontrolle über die Containererstellung bevorzugen, kann ein mehrstufiger Docker-Build verwendet werden.

FROM quay.io/quarkus/ubi-quarkus-mandrel-builder-image:23.0.1.2-Final-java17 AS build
COPY --chown=quarkus:quarkus mvnw /app/mvnw
COPY --chown=quarkus:quarkus .mvn /app/.mvn
COPY --chown=quarkus:quarkus pom.xml /app/
USER quarkus
WORKDIR /app
RUN ./mvnw -B org.apache.maven.plugins:maven-dependency-plugin:3.6.1:go-offline
COPY src /app/src
RUN ./mvnw package -Dnative

FROM quay.io/quarkus/quarkus-micro-image:2.0
WORKDIR /app/
COPY --from=build /app/target/*-runner /app/application

RUN chmod 775 /app /app/application \
  && chown -R 1001 /app \
  && chmod -R "g rwX" /app \
  && chown -R 1001:root /app

EXPOSE 8080
USER 1001

CMD ["./application", "-Dquarkus.http.host=0.0.0.0"]

Diese Docker-Datei orchestriert einen mehrstufigen Build, der zu einem Docker-Image mit Ihrer Quarkus-Anwendung führt. Führen Sie diese Docker-Datei aus, um das Docker-Image zu erstellen, das zur Ausführung Ihrer Quarkus-Anwendung bereit ist.

Zusammenfassung

GraalVM Native Image ist eine leistungsstarke Technologie, die die Art und Weise, wie Sie Java-Microservices entwickeln und bereitstellen, revolutionieren kann. Durch die Einführung von GraalVM Native Image können Sie folgende Microservices erstellen:

• Schneller
• Skalierbarer
• Einfacher bereitzustellen
• Kostengünstiger

GraalVM Native Image ist ein wichtiger Faktor für die Cloud-native Java-Entwicklung und kann Ihnen dabei helfen, die Leistung, Skalierbarkeit und Kosteneinsparungen zu erreichen, die Ihr Unternehmen benötigt.