Einführung

Ein recht g?ngiger Ansatz bei der Arbeit mit serverlosem Code besteht darin, ihn als Python-, Node- oder Go-Anwendung zu schreiben, da diese für ihre sehr schnellen Kaltstarts bekannt sind.

Was aber, wenn wir mit bereits vorhandenen Java-Apps konfrontiert werden, die auf serverlose Umgebungen wie AWS Lambda abzielen? M?glicherweise hostet ein gro?er Teil unserer Codebasis Java, und wir haben ein umfangreiches ?kosystem an Tools und Bibliotheken entwickelt, die wir gerne wiederverwenden würden. Das Umschreiben der gesamten Flotte solcher Anwendungen in eine andere Sprache ist teuer, ganz zu schweigen davon, dass wir auf Funktionen wie statische Typsicherheit und Optimierungen der Kompilierzeit verzichten.

Vor einiger Zeit war ich mit genau diesem Szenario konfrontiert: 9 in Java geschriebene AWS Lambda-Apps, die bei Kaltstarts so langsam waren, dass es bei einigen von ihnen gelegentlich zu Timeouts kam.

Die betreffenden Lambdas wurden hinter API Gateway platziert und für Admin-Aufgaben durch Aufruf der entsprechenden REST-APIs verwendet. Diese Funktionalit?t wurde nicht sehr stark genutzt und so waren Kaltstarts unvermeidlich; Da dies jedoch kein kritischer Dienst war, war es eine perfekte Gelegenheit zum Experimentieren: um herauszufinden, ob diese Lambdas gerettet werden k?nnten.

Es dauerte nicht lange, bis ich auf mehrere andere Blogbeitr?ge über Entwickler stie?, die GraalVM und Frameworks wie Quarkus erfolgreich nutzten, um genau dieses Problem anzugehen. Und so habe ich beschlossen, es selbst auszuprobieren.

Aber was sind das überhaupt für Tools?

GraalVM

Kurz gesagt ist GraalVM eine Java Virtual Machine, die über ein Toolset verfügt, mit dem Java zu einem nativen Image kompiliert und mithilfe der Graal-JVM ausgeführt werden kann.

Normalerweise verwendet Java den ?Just In Time“ (JIT)-Compiler, der, wie der Name schon sagt, w?hrend der Ausführung unseres Codes Optimierungen und Kompilierungen durchführt. Die lang laufenden Anwendungen profitieren davon, da die JVM-Optimierer die Programmausführung st?ndig überwachen und Feinabstimmungen vornehmen, die im Laufe der Zeit zu einer besseren Leistung führen.

Das ist gro?artig, wenn eine Anwendung einmal instanziiert wird und voraussichtlich mehrere Stunden oder l?nger ausgeführt wird, aber nicht so toll, wenn wir es mit Kubernetes, AWS Lambdas und Batch-Jobs zu tun haben, die Java-Apps schnell starten und ausführen sollen zeitkritische Vorg?nge und Skalierung je nach Bedarf – wo wir gerade von einem Turboloch für die Autoenthusiasten da drau?en sprechen.

Und hier kommt die Native Image-Funktion von GraalVM ins Spiel. Anstatt den JIT-Compiler zu verwenden, w?hlt es einen ganz anderen Ansatz, unseren Code im Voraus zu kompilieren (AOT). Es backt unseren Kuchen mithilfe statischer Codeanalyse vor und initialisiert sogar bestimmte Klassen w?hrend der Erstellungszeit vor, sodass sie jederzeit einsatzbereit sind, wenn unser Anwendungscode ausgeführt wird.

Das Ergebnis? Sehr schnelle Kaltstarts, wodurch native Images in serverlosen Dom?nen, in denen Apps nur eine kurze Lebensdauer haben und schnell gestartet werden müssen, sehr leistungsf?hig sind.

Es ist zu beachten, dass GraalVM zwar AOT-f?hig ist, aber auch als Ersatz für die vorhandene JVM dienen kann und angesichts des neuen in Java geschriebenen JIT-Compilers von GraalVM eine bessere Leistung bietet.

Aber Moment, es gibt noch mehr! Da Native Image nur den Code enth?lt, der sich auf dem bekannten Ausführungspfad befindet, reduzieren wir den Fettgehalt und alle Java-Klassen, deren Beibehaltung nicht explizit deklariert wurde, sind nicht verfügbar. Da wir nur die Bits behalten, deren Ausführung erwartet wird, erh?hen wir die Sicherheit unserer Anwendung.

Nehmen Sie zum Beispiel die berüchtigte Log4J-Sicherheitslücke, die Remotecodeausführung als Mittel zur Gef?hrdung des Hosts nutzte. Bei Native Images ist die Gadget-Verkettung h?chstwahrscheinlich nicht erfolgreich, da die Teile des Bibliothekscodes, die zur übermittlung des Angriffs erforderlich sind, nicht einmal erreichbar sind.

Quarkus

Quarkus hingegen ist ein für serverlose Anwendungen optimiertes Java-Framework, das über eine Toolbox verfügt, die die Erstellung nativer Images erleichtert, indem sie eine Erweiterung für die spezifische Konfiguration und Erstellung von AWS Lambdas als native ausführbare Dateien bietet.

C1-Compiler

W?hrend meiner Lambda-Optimierungsreise bin ich auch auf alternative Optimierungstechniken gesto?en. Eine dieser Optimierungen war die vorgeschlagene ausschlie?liche Verwendung eines C1-Compilers w?hrend der Ausführung von Lambda, was schnellere Kaltstarts versprach. Normalerweise verwenden Java-Anwendungen, die in einer JVM ausgeführt werden, eine mehrstufige Kompilierung, die aus einem schnelleren, aber weniger optimalen C1 besteht, gefolgt von C2, das langsamer ist, aber eine optimalere Leistung für Java-Apps bietet, die über einen l?ngeren Zeitraum ausgeführt werden. Da Lambdas nur von kurzer Dauer sind, sind die Vorteile der C2-Kompilierung vernachl?ssigbar.

Eine Anleitung, die durch den Prozess der Konfiguration der C1-Kompilierung für AWS Lambdas führt, ist hier verfügbar.

Natürlich wollte ich wissen, welche Verbesserung diese Technik im Vergleich zu meinem bestehenden GraalVM-Masterplan bieten kann, und habe sie daher auch in meine nachstehenden Ergebnisse aufgenommen.

Weitere Details zur mehrstufigen Kompilierung von JVM sowie zum brandneuen JIT-Compiler von GraalVM finden Sie in diesem Baeldung-Artikel.

?Aber Moment, was ist mit AWS SnapStart?“

Ironischerweise brachte AWS ein paar Monate, nachdem ich meine ?nderungen in die Produktion gebracht hatte, seine neueste SnapStart-Funktion auf den Markt, die einen Snapshot eines laufenden Lambda erstellt und, anstatt ihn noch einmal neu zu initialisieren, Snapshot-Bilder als verwendet ein Wiederherstellungspunkt, der schnellere Kaltstarts verspricht. Ich musste es ausprobieren, um herauszufinden, ob der Einsatz von GraalVM vergebliche Mühe war, und habe es auch in meine Erkenntnisse einbezogen.

Es ist erw?hnenswert, dass für die optimale Nutzung von SnapStart eine Code-Umgestaltung erforderlich gewesen w?re, um die Hooks beforeCheckpoint und afterRestore zu nutzen (weitere Details hier). Da ich gr??ere Code?nderungen m?glichst vermeiden wollte, habe ich diese Funktion ?wie sie ist“ verwendet, ohne diese Methoden zu implementieren und Code neu anzuordnen.

Der Masterplan

Jetzt zurück zu GraalVM! Zu meiner überraschung waren nach der Integration dieser L?sung, abgesehen vom Hinzufügen und Anpassen von Build-Konfigurationsdateien und einigen erforderlichen Metadaten, absolut keine ?nderungen am Java-Code erforderlich.

Klingt zu sch?n, um wahr zu sein?

Vielleicht ein bisschen. Angesichts der Tatsache, dass wir in der Java-Welt die AOT-Kompilierung verwenden, stellt dies eine gewisse Herausforderung dar, wenn es um die Verwendung von Sprachfunktionen wie Reflexionen, Proxys, Schnittstellen und Dienstregistern geht, auf die viele Bibliotheken angewiesen sind. Aus diesem Grund erfordert der GraalVM-Compiler die Deklaration zus?tzlicher Konfigurationsmetadaten, die bestimmte Klassen und Dienste explizit registrieren, damit sie in das endgültige Artefakt aufgenommen werden k?nnen. GraalVM bietet einen sogenannten Agenten, der neben Ihrer ausführbaren Datei ausgeführt werden kann, um automatisch die erforderliche Konfiguration zu identifizieren, was diesen Prozess vereinfachen kann.

Quarkus bietet mehrere Erweiterungen für bekannte Bibliotheken, um sie ?Native-Image-freundlich“ zu machen. Da ich jedoch mit einer vorhandenen Codebasis arbeitete und mein Ziel darin bestand, gr??ere Umgestaltungen (oder Code?nderungen) zu vermeiden ), begnügte ich mich damit, die erforderlichen Konfigurationsdateien zu erstellen, die die vorhandenen Bibliotheken ben?tigten, um native Bilder erfolgreich zu erstellen.

Beachten Sie, dass das Kompilieren nativer Bilder ressourcenintensiv ist und im Vergleich zur Bytecode-Kompilierung, die auf eine Standard-JVM-Laufzeit abzielt, deutlich l?nger dauert. Es besteht die M?glichkeit, dass Sie einem Build-Knoten mehr RAM zuweisen müssen, um Speicherprobleme zu vermeiden. Dies sollte kein Problem darstellen, ist aber auf jeden Fall etwas, das Sie im Hinterkopf behalten sollten.

Nachdem ich meine nativen Image-Lambdas kompiliert und gepackt hatte, war es an der Zeit, sie in einer Testumgebung bereitzustellen. Normalerweise nutzen Java Lambdas zur Ausführung die Java Runtimes von AWS; Da wir jedoch versuchen, ein natives Image zu verwenden, bei dem es sich um ein bin?res Artefakt handelt, das unseren App-Code in der Graal-JVM enth?lt, müssen wir eine der ?benutzerdefinierten“ Amazon Linux-Umgebungen ausw?hlen, die AWS anbietet.

Testmethodik

Ich habe eine Postman-API-Sammlung verwendet, um Anfragen an alle 9 Lambdas zu senden und die Kaltstart-Reaktionszeiten für jede der oben genannten Techniken zu messen. Um sicherzustellen, dass es immer zu einem Kaltstart kommt, habe ich die Konfiguration des Ziel-Lambdas neu geladen, um sicherzustellen, dass beim n?chsten Aufruf keine Instanz verwendet wird, die m?glicherweise bereits warm ist. Alle Lambdas wurden mit 1 GB RAM konfiguriert. Ich habe auch einen einzelnen Aufruf für jede Konfiguration gemessen, da der Vorgang zeitaufw?ndig war; Die beobachteten Reaktionszeiten ergaben jedoch ein ziemlich klares Bild.

Ergebnisse

Hat es also funktioniert? Absolut! Hier sind die Ergebnisse:

Und der klare Gewinner ist: GraalVM Native Images – im Durchschnitt hat es zu einer dreifachen Beschleunigung im Vergleich zu den unver?nderten Java Lambdas geführt – keine Timeouts mehr und viel bessere Antwortzeiten, was genau das ist, was ich wollte erreichen.

SnapStart funktionierte ohne Code?nderungen nicht so gut, wie ich es mir vorgestellt hatte. Wenn der C1-Compiler zus?tzlich zur SnapStart-Funktion verwendet wurde, verkürzte er die Kaltstartzeiten weiter, übertraf aber immer noch nicht das native Image von GraalVM. Das soll nicht hei?en, dass es sich nicht um eine praktikable Option als schnell und einfach umzusetzende Verbesserung handelt; Wenn wir jedoch unser Lambda so weit wie m?glich optimieren m?chten und etwas Zeit und Ressourcen haben, um die Konfiguration und unseren Build-Prozess anzupassen, ist GraalVM definitiv überlegen, wenn es um Leistung und Sicherheit geht.

Ged?chtnis-Fu?abdruck

Wie von GraalVM behauptet, ben?tigen native Images im Vergleich zu ihren regul?ren JVM-Gegenstücken weniger Ressourcen, um effektiv ausgeführt zu werden. Ich wollte sehen, wie sich die Kaltstart- und Warmstartleistung halten würde, wenn ich die Menge an RAM reduzieren würde, mit der diese Lambdas arbeiten mussten. Dieses Mal habe ich nur eine einzige Lambda-App ausgew?hlt, um diesen Test durchzuführen. Hier sind die Ergebnisse:

Und sie haben ihr Versprechen gehalten! Beim Versuch, eine Konfiguration mit 256 MB und weniger zu konfigurieren, reichte bei regul?ren JVM-Lambdas der Arbeitsspeicher aus, wohingegen das native Image scheinbar nicht phasengesteuert war und weiterhin ausgeführt wurde. Wenn 128 MB nicht die niedrigste verfügbare Speicheroption gewesen w?ren, frage ich mich, wie viel niedriger wir h?tten gehen k?nnen. Native Images sind nicht nur beim Kaltstart schneller, sondern bieten auch bei der Arbeit mit begrenzten Ressourcen eine konstante Leistung, was sich in niedrigeren Betriebskosten niederschl?gt.

Abschluss

Das ?kosystem von Java ist reichhaltig und umfangreich. Jeden Tag entstehen viele neue Technologien und Verbesserungen, die Java im Spiel halten, wenn es um serverlose Anwendungen geht. Eine dieser aufstrebenden Technologien ist GraalVM. Was als Forschungsprojekt begann, wird nun langsam angenommen und stellt eine praktikable Alternative zu einer Standard-JVM wie HotSpot dar. In diesem Blogbeitrag habe ich kaum an der Oberfl?che dessen gekratzt, was GraalVM zu bieten hat, und ich m?chte die Leser ermutigen, es weiter zu erkunden. Es gibt mehrere Erfolgsgeschichten von Unternehmen wie Adyen (Artikel-Link) oder Facebook (Artikel-Link), die GraalVM nutzen konnten, um Zeit und Geld zu sparen.

Wenn Sie also Java das n?chste Mal als Option rabattieren, probieren Sie GraalVM aus. Und da Spring Boot 3 jetzt native GraalVM-Images sofort unterstützt, ist es einfacher denn je, sie für Ihre serverlosen Workloads zu nutzen, um von der Leistung, dem geringen Ressourcenverbrauch und der zus?tzlichen Sicherheit zu profitieren, die GraalVM zu bieten hat.

Das obige ist der detaillierte Inhalt vonJava kann auch serverlos sein: Verwendung von GraalVM für schnelle Kaltstarts. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!