Boostez les microservices Java avec Quarkus et GraalVM Native Image

Dans le paysage dynamique du développement logiciel moderne, les microservices sont devenus l'approche architecturale privilégiée. Si cette méthodologie offre de nombreux avantages, elle n’est pas sans défis. Des problèmes tels que des empreintes mémoire importantes, des heures de démarrage prolongées et une utilisation élevée du processeur accompagnent souvent les services traditionnels basés sur JVM. Ces défis ont non seulement un impact sur les aspects techniques, mais ont également des implications financières qui peuvent affecter de manière significative le coût global d'exploitation et de maintenance des solutions logicielles.

Qu'est-ce que l'image native GraalVM ?

GraalVM Native Image est une fonctionnalité clé de GraalVM, qui est un environnement d'exécution hautes performances qui prend en charge divers langages de programmation et modes d'exécution. Plus précisément, GraalVM Native Image vous permet de compiler des applications Java à l'avance en exécutables natifs autonomes, évitant ainsi le besoin d'une machine virtuelle Java (JVM) pendant l'exécution. Cette approche innovante produit des fichiers exécutables qui présentent des temps de démarrage quasi instantanés et une consommation de mémoire considérablement réduite par rapport à leurs homologues JVM traditionnels. Ces exécutables natifs sont méticuleusement conçus, ne contenant que les classes, méthodes et bibliothèques dépendantes essentielles au fonctionnement de l'application. Au-delà de ses prouesses techniques, GraalVM Native Image s’impose comme une solution stratégique aux implications profondes. Non seulement il surmonte les défis techniques, mais il présente également un argument financier convaincant. En facilitant le développement d'applications Java cloud natives efficaces, sécurisées et instantanément évolutives, GraalVM joue un rôle déterminant dans l'optimisation de l'utilisation des ressources et la promotion de la rentabilité. Essentiellement, il joue un rôle central dans l’amélioration des performances et de l’efficacité financière des solutions logicielles dans des environnements contemporains et dynamiques.

Défis techniques et implications financières

1. Grandes empreintes de mémoire

Impact technique
Les services traditionnels basés sur JVM entraînent souvent une surcharge de mémoire importante en raison du chargement de classes et des métadonnées des classes chargées.

Cas Financier
Une consommation élevée de mémoire se traduit par une augmentation des coûts d’infrastructure. L'élimination par GraalVM des métadonnées pour les classes chargées et d'autres optimisations conduit à une utilisation plus efficace des ressources, entraînant des économies potentielles.

2. Heures de début prolongées

Impact technique
Les démarrages à froid dans les microservices peuvent entraîner des temps de réponse plus longs, avoir un impact sur l'expérience utilisateur et potentiellement provoquer une dégradation du service.

Cas Financier
Des heures de démarrage prolongées affectent non seulement la satisfaction des utilisateurs, mais contribuent également à des coûts opérationnels plus élevés. Les optimisations de GraalVM, telles que l'élimination des frais de chargement de classes et la pré-génération du tas d'images pendant la construction, réduisent considérablement les temps de démarrage, minimisant ainsi potentiellement les dépenses opérationnelles.

3. Utilisation élevée du processeur

Impact technique
Les JVM traditionnelles brûlent souvent des cycles de processeur pour le profilage et la compilation Just-In-Time (JIT) au démarrage.

Cas Financier
Une utilisation excessive du processeur entraîne une augmentation des coûts d’infrastructure cloud. Le fait que GraalVM évite le profilage et les frais généraux de JIT contribue directement à réduire la consommation du processeur, ce qui se traduit par des économies potentielles dans l'utilisation du cloud.

Résoudre le problème du démarrage à froid

Les microservices, en particulier dans les environnements sans serveur ou conteneurisés, sont souvent confrontés au problème du démarrage à froid, ce qui a un impact sur les temps de réponse et l'expérience utilisateur. GraalVM relève ce défi en mettant en œuvre plusieurs optimisations :

1. Aucune surcharge de chargement de classe

Les applications Java traditionnelles s'appuient sur le chargement de classes au moment de l'exécution pour charger et lier dynamiquement les classes. Ce processus introduit une surcharge, notamment lors de la phase de démarrage. GraalVM minimise cette surcharge grâce à un processus appelé compilation statique ou anticipée (AOT). Cela implique le préchargement, la liaison et le lancement partiel de toutes les classes requises par l'application. Par conséquent, il n'est pas nécessaire de charger les classes d'exécution lors du démarrage de l'application.

2. Élimination du code interprété

Les machines virtuelles Java traditionnelles s'appuient sur un mode d'exécution interprété avant d'appliquer la compilation Just-In-Time (JIT). Cela peut contribuer à des retards de démarrage et à une utilisation accrue du processeur. Les exécutables natifs ne contiennent aucun code interprété, ce qui contribue encore à des temps de démarrage plus rapides.

3. Pas de profilage ni de frais généraux de JIT

GraalVM évite le besoin de démarrer le compilateur Just-In-Time (JIT), réduisant ainsi l'utilisation du processeur lors du démarrage.

4. Génération de tas d'images au moment de la construction

L'utilitaire d'image natif de GraalVM permet l'exécution de processus d'initialisation pour des classes spécifiques pendant le processus de construction. Cela entraîne la génération d'un tas d'images comprenant des parties pré-initialisées, accélérant ainsi le démarrage de l'application.

L'utilitaire d'image natif d'Oracle GraalVM a démontré des temps de démarrage près de 100 fois plus rapides que les applications traditionnelles basées sur JVM. Le graphique ci-dessous illustre la réduction substantielle des besoins en mémoire d'exécution, démontrant l'efficacité de GraalVM par rapport à HotSpot (Figure 1).

Figure 1 – Les exécutables natifs démarrent presque instantanément (oracle.com)

Atteindre une empreinte mémoire plus légère

GraalVM contribue à réduire l'empreinte mémoire grâce aux optimisations suivantes :

1. Aucune métadonnée pour les classes chargées

GraalVM évite de stocker les métadonnées des classes chargées dynamiquement dans la mémoire non tas. Pendant le processus de construction, les informations de classe nécessaires sont préchargées et liées, minimisant ainsi le besoin de métadonnées supplémentaires au moment de l'exécution.

2. Aucune donnée de profilage ni optimisation JIT

Étant donné que le bytecode est déjà en code natif, GraalVM élimine le besoin de collecter des données de profilage pour les optimisations JIT, réduisant ainsi la surcharge de mémoire.

3. Technologie d'isolation

GraalVM introduit Isolates, une technologie qui divise le tas en « tas » plus petits et indépendants, améliorant ainsi l'efficacité, en particulier dans les scénarios de traitement des requêtes.

En commun, il consomme jusqu'à 5 fois moins de mémoire par rapport à une exécution sur une JVM(Figure 2)

Figure 2 – Mémoire des exécutables natifs par rapport à Go ou Java HotSpot (oracle.com)

En conclusion, l'utilitaire d'image natif de GraalVM offre une solution transformatrice aux défis posés par les microservices, en répondant aux problèmes de temps de démarrage, d'empreinte mémoire et d'utilisation du processeur. En adoptant GraalVM, les développeurs peuvent créer des applications Java cloud natives qui sont non seulement efficaces et sécurisées, mais offrent également une expérience utilisateur supérieure.

Java natif avec Quarkus

Pour compiler votre service Quarkus dans une image native, différentes méthodes sont disponibles. Bien que cet article n'approfondisse pas la procédure de construction native de Quarkus, il donne un aperçu des étapes essentielles.

Avant de procéder à toute approche de création d'une image native, il est crucial de configurer le profil natif approprié dans votre fichier pom.xml. Ajoutez le profil suivant :

  native  native   

Produire un exécutable natif avec GraalVM installé

Vérifiez votre version de GraalVM à l'aide de la commande suivante :

./gu info native-image

Cette commande affichera la version de GraalVM installée :

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

Et pour créer un exécutable natif, utilisez :

./mvnw install -Dnative

Ces commandes génèrent un binaire *-runner dans le répertoire cible, vous permettant d'exécuter l'exécutable natif :

./target/*-runner

Création d'un exécutable natif sans GraalVM installé

Si l'installation locale de GraalVM pose des problèmes, une version en conteneur peut être utilisée :

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

Cette commande lance la construction dans un conteneur Docker et fournit le fichier image nécessaire. Vous pouvez ensuite démarrer l'application avec :

./target/*-runner

Dans les cas où la création de l'image native s'avère difficile, l'équipe RedHat propose une distribution spécialisée de GraalVM conçue pour le framework Quarkus appelée Mandrel. Le mandrin rationalise
GraalVM, se concentrant uniquement sur les capacités d'image native essentielles aux applications Quarkus. Pour utiliser Mandrel, suivez ces étapes :

1. Identifier la version appropriée du référentiel Mandrel

2. Définissez la version du mandrin dans votre fichier application.properties :
   

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

3.Exécutez la commande Maven build :

./mvnw clean install -Pnative

Création manuelle d'un conteneur

Pour ceux qui préfèrent un contrôle manuel sur la création de conteneurs, une version Docker en plusieurs étapes peut être utilisée.

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"]

Ce Dockerfile orchestre une construction en plusieurs étapes, aboutissant à une image Docker avec votre application Quarkus. Exécutez ce Dockerfile pour produire l'image Docker, prête à exécuter votre application Quarkus.

Résumé

GraalVM Native Image est une technologie puissante qui peut révolutionner la façon dont vous développez et déployez des microservices Java. En adoptant GraalVM Native Image, vous pouvez créer des microservices qui sont :

• Plus vite
• Plus évolutif
• Plus simple à déployer
• Plus rentable

GraalVM Native Image est un élément clé du développement Java cloud natif et peut vous aider à atteindre les performances, l'évolutivité et les économies de coûts exigées par votre entreprise.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!