Spring Boot Native, GraalVM i JHipster

Spring Boot na GraalVMie? Brzmi ciekawie, ale czy to jest możliwe?

Według wpisu sprzed 2 miesięcy prosty projekt można postawić na GraalVM Native Image. Jednak prosty CRUD, to nie system produkcyjny, który wymaga różnych bibliotek. Pytanie, jak to wygląda z nieco bardziej skomplikowanym stackiem technologicznym?

JHipster

Nie będę oczywiście pisał wszystkiego od zera. W zeszłym roku napisałem szybką aplikację (i wpis o niej). W niej wykorzystałem generator kodu JHipster. Taki generator to jest dobry dla szybkich, krótkich projektów, gdyż oprócz wygenerowanego modelu dostarcza wielu standardowych wymagań takich jak uwierzytelnienie, autoryzacja, metryki, obsługa logowania, a nawet stworzenie obrazu Dockerowego. Warto spojrzeć na ten projekt oraz co nim się da wygenerować również po to, żeby poznać technologie, zaczerpnąć ewentualnie patternów zaimplementowanych w takim projekcie.

Posiadając już apkę z Spring Bootem w wersji 2.2.7 postanowiłem zastosować w nim Spring Boot Native. Pierwszym wymogiem jest podbicie wersji Spring Boota do 2.4.5. Oczywiście podbicie wersji Spring Boota pociąga za sobą podbicie innych wersji bibliotek używanych przez Springa. Wchodząc do tego piekła ciężko z niego wyjść. Zatem od razu sobie odpuściłem manualne podbijanie, gdy w kolejnej wersji JHipstera (w wersji 7.0) podbicie Spring Boota do wersji 2.4.x jest zrobione out-of-the-box.

Zatem przeszedłem do ponownego wygenerowania na podstawie metadanych JHipstera. Rzecz jasna po tym należało zmerge’ować wygenerowany kod z moimi zmianami. Rzecz jasna to też nie było przyjemnie, ale wiązało się z mniejszym ryzykiem, niż manualne podbicie wersji.

Spring Boot + Spring Boot Native

Po podbiciu Spring Boota można było wprowadzić zmiany wymagane przez Spring Boot Native. Po uaktualnieniu pom.xml można było spróbować pierwszy raz uruchomić proces budowania. Pierwszy raz budowanie zakończyło się porażką na etapie budowania Mavena z komunikatem podobnym do Nie udało się, bo się nie wysypało. Pierwszym rozwiązaniem okazało się dodanie do parametrów kompliacji Mavena paramteru <forceJavacCompilerUse>true</forceJavacCompilerUse> . Po drugiej próbie kompilacji komunikat już był precyzyjny. Tym razem problem był po mojej stronie – źle zmerge’owałem źródła.

Trzecia kompilacja zakończyła się wielkim sukcesem – po 15 minutach mielenia na moim starym lapku projekt skompilował się! Uruchomienie przyniosło jednak szybkie rozczarowanie – logback nie może dostać się do pliku z konfiguracją. Po kilku próbach (czyt. kilkukrotnym czekaniu po 15 minut) i przeczesaniu internetu na temat tego błędu, zmigrowałem konfigurację na taką, która bazuje na przekazanych propertiesach.

Czwarta (15 minut) kompilacja zakończyła się porażką – uruchomienie aplikacji natywnej zakończyła się problemem z Audytowaniem uwierzytelniania. Nie jest to kluczowa funkcjonalność tego projektu, zatem szybkie zakomentowanie @EnableJpaAuditing(auditorAwareRef = "springSecurityAuditorAware") rozwiązało problem.

Piąta (15 minut) kompilacja zakończyła się kolejną porażkę. Tym razem okazało się, że Swagger to zbyt duże wyzwanie dla Spring Native. Rozwiązanie – zakomentowanie uruchamiania profilu słagerowego.

Szósta (15 minut) kompilacja zakończyła się znów porażką. Tym razem kontekst Springa nie wstał. Po prostu. Bez informacji, co nie działa, gdzie i o co chodzi. Tutaj się poddałem.

Teoretycznie jest jakiś ticket na dostosowanie JHipstera do Spring Native, a nawet można dostać 500$ za dostarczenie tego feature’u. Można podejrzewać, że dostosowanie do Spring Native ostatecznie zostanie wykonane. Ale to póki co, to pieśń przyszłości.

Inne rozwiązania

JHipster jest już dość dojrzałym projektem – na frontendzie oferuje nie tylko Angulara, ale również Reacta i Vue.js, za to na backednzie wsparcie obejmuje Spring Boota, a także Micronauta i Quarkusa. Co ciekawe język programowania wymienić na Kotlina (ze Spring Bootem), C# (.Net), czy Javascript (NestJS).

W przypadku Micronauta niestety wsparcie nie obejmuje kompliacji do Native Image. Szkoda, bo Micronaut ma API bardzo podobne do Spring Boota.

Został JHipster z Quarkusem. Tutorial tłumaczący, jak stworzyć wygenerować taką aplikację jest dosadnie prosty. Wsparcie obejmuje również Native Image. Zatem do dzieła.

JHipster + Quarkus

Ponownie musiałem przegenerować na podstawie metadanych JHipstera. Niestety API Quarkusa różni się zdecydowanie od Spring Boota.

Począwszy od bazy danych i JPA różni się podejście do „owrapowania JPA„. W Spring Boot mamy bardzo przyjazne Spring Data Quarkus oferuje nam za to Panache, który jest frameworkiem dedykowanym dla Quarkusem. W nim dominującym podejściem do pobierania i zapisywania krotek jest ActiveRecord, choć da się również stworzyć klasy Repository. Jest wsparcie dla paginacji, customowych projekcji, zapytań w JPQL. Jedyne, czego brakuje, to odpowiednik uproszczenia JPA Criteria Query.

Jak mówiłem, podejściem dominującym jest Active Record, to w modelowaniu klas – zamiast klas POJO z getterami i setterami – dominuje klasa z publicznymi polami bez getterów i setterów dziedzicząca po PanacheEntity. Tutaj również musiałem dostosować swoje customowe zmiany.

Wsparcie dla cache’ów jest, ale w moim przypadku nie było potrzebne (i nie działało ;)), zatem je wyłączyłem.

Wsparcie dla security contextu jest, jednak dostęp nie jest przez ThreadLocala zwanego SecurityContextHolderem, a przez dodatkowy parametr wywołania endpointa.

Dodatkowo Quarkus wymusza poznawanie innych frameworków (czyt. RedHatowych, Eclipse’owych). I tak zamiast Jacksona mamy JSONB, zamiast Springa MVC mamy Jax-Rs. Wstrzykiwanie zależności wykonywane jest przez @Inject, choć Spring również wspiera tę adnotację.

Ostatnie, o czym trzeba pamiętać, to żeby do DTOsów i innych obiektów obrabianych refleksją (encje bazodanowe, projekcje) dodać adnotację @RegisterForReflection.

Wynik

Quarkus jest stworzony dla GraalVM Native Image, więc w tym przypadku nie było żadnego problemu z kompilacją do kodu natywnego. Sam czas kompilacji na mojej maszynie, to około 10 minut, czyli o 1/3 szybciej, niż kompilacja Spring Boot Native.

Normalnie na OpenJDK aplikacja wstaje lokalnie w około 5 sekund. Po skompilowaniu do kodu natywnego, uruchomienie aplikacji trwa do 100 milisekund.

Drugą kwestią jest, że taką aplikację można postawić niewielkim Heapie – dałem -Dxmx=64M, co łącznie z OffHeapem łącznie daje 200 MB (tyle przynajmniej pokazuje htop). Obstawiam, że gdyby zrezygnować z wielu JHipsterowych feature’ów, to dało by się zejść z zużyciem pamięci jeszcze niżej.
Spring Boota to z mniejszym Heapem niż 128 to bym nawet nie próbował startować, a jak wiadomo OffHeap też swoje waży. Jakkolwiek istnieją ludzie, którzy ze Spring Bootem potrafią zejść poniżej 80MB mierząc wszystko…

Podsumowanie

Należy pamiętać, że Spring Native jest jeszcze w fazie beta, zatem nie wszystko może tam działać. Możliwe, że tworzenie serwera od początku do końca było by lepszą strategią pozwalającą na znalezienie wszystkich przyczyn błędów.

Jednak każdorazowa rekompilacja trwająca 15 minut skutecznie odrzuca. Jako programista Java jestem przyzwyczajony do kompilacji klasy do bytecodu mierzonej w maksymalnie sekundach. Nawet kompilacja z użyciem Mavena takiego projektu trwa maksymalnie minutę.

Trzeba poczekać na pierwszy release, wtedy będzie można cokolwiek powiedzieć. Póki co jest zbyt wcześnie…

 

Quarkus – co ciekawego siedzi w środku.

Nie wiem, czy śledzicie wpisy na JvmBloggers, jednak w poprzednim tygodniu były 4 wpisy CRUDowe o Quarkusie. Jeżeli wszyscy o tym piszą, to przecież nie będę gorszy 😉

Jeśli chcecie się dowiedzieć, jak napisać CRUDa to tutaj po polsku, a tu po angielsku. Ja osobiście zajmę się bezużyteczną wiedzą – dlaczego to jest fajne i jaki to ma potencjał. Ale od początku.

GraalVM

GraalVM jest to Oracle’owa maszyna wirtualna bazowana na OpenJDK. Jej celem było stworzenie uniwersalnej maszyny wirtualnej, która obsługuje wiele języków programowania – zarówno JVMowe (Java, Scala, Groovy), jak również skryptowe (Js, Ruby, Python, R) i natywne (C++). Pozwala również na bardzo wydajne wywoływania funkcji zdefiniowanych w różnych językach (takie cross-językowe wywołania).

Jednak stworzenie takiej VMki to była długa droga… Najwięcej działo się przy releasie JDK 9. Wtedy położono fundamenty pod GraalVM – wydzielono w źródłach JDK interfejs kompilatora, poukładano projekt OpenJDK modularnie oraz wprowadzono kompilator Ahead-of-time. Skoro już był wydzielony interfejs kompilatora, to można było wprowadzić nowy kompilator – modularny, piękny i pachnący, o wdzięcznej nazwie Graal. W dodatku cały napisany w Javie (bo kto umie w C++, gdzie nawet GCka nie ma). Uczyniono to w JDK 10 w JEP 317. Tenże kompilator Graal jest w niektórych względach lepszy od C2 – z pewnością lepiej radzi sobie ze różnego rodzaju streamami. Swego czasu popularne było stwierdzenie, że Twitter przeszedł z C2 na Graala i zjadało mu 5% procesora mniej. Jakkolwiek mowa była o Scali, nie o Javie.

W końcu GraalVM wyszedł w maju zeszłego roku. W założeniu miał pozwalać na łatwe wywoływanie międzyjęzykowych funkcji. Standardowym use case’m miało być wydajne wywoływanie funkcji Machne Learningowych napisanych w R lub Pythonie (jak wiadomo Java w tej dziedzinie nie jest zbyt popularna). Innym przykładem może być jednokrotne tworzenie walidacji po stronie frontendu oraz wywoływanie tej walidacji także na backendzie (pozdro Apzumi! 😉 ). Jednak osobiście moim faworytem jest narzędzie do generowania kodu natywnego.

GraalVM Native Image

Narzędzie to pozwala na stworzenie łatwo uruchamianej aplikacji napisanej w Javie skompilowanej do wersji natywnej dla systemu operacyjnego. W pierwszej wersji (19) wspierano tylko Linuxa i MacOSa, w wersji 20 wpierany jest również Windows. GraalVM jest dostępny z JDK w wersji 8 jak i 11. Kompilacja do kodu natywnego jest wykonywana z użyciem wspomnianego wcześniej kompilatora Graal.

W czasie kompilacji do kodu natywnego ma miejsce stworzenie grafu zależności między klasami, polami, metodami, dzięki którego analizie wszystkie nieużywane pola, klasy, metody są usuwane. Wycięcie 90% platformy powoduje, że aplikacja wstaje w milisekundy zamiast sekund. Dodatkowo zużywa znacznie mniej pamięci (mierzone w dziesiątkach megabajtów zamiast setek). Choć na kompilację trzeba poświęcić kilka minut…

Co więcej – GraalVM Native Image nie wspiera wszystkich opcji dostępnych dla standardowego JDK. Brakuje między innymi MethodHandles, InvokeDynamic, serializacji, security managera. W przypadku użyciu refleksji, DynamicProxy, JNI lub dynamicznego ładowania klas wymagana jest rejestracja używanych klas w osobnym pliku konfiguracyjnym. Więcej o ograniczeniach można poczytać na tej podstronie.

Jest kilka rzeczy, które są robione inaczej. Najlepszym przykładem jest wykonywanie inicjalizacji klas na etapie kompilacji źródeł. Dzięki temu GraalVM uruchamia się szybciej. Czasem może jednak to prowadzić do dziwnych błędów. Inną różnicą jest to, że przekazywane propertiesty przy kompilacji są dostępne dla klas inicjalizowanych na etapie kompilacji, a na etapie runtime już nie.

GraalVM umożliwia również wydawanie natywnych bibliotek do systemów operacyjnych, co wcześniej w Javie nie było możliwe.

Jak to w środku działa?

W miarę normalnie – mamy normalny Heap, który co jakiś czas jest odśmiecany. Z tego gdzieś mi się obiło o oczy, a czego znaleźć aktualnie nie potrafię są dostępne 2 GCki. Jeden jest pewną odmianą Parallel GC, drugi jest z rodziny Lowlatency.
Przy uruchamianiu normalnie definiujemy parametry -Xmx oraz -Xms (gdyż normalnie bierze 1/4 całej pamięci 😉 ). Debugować się nie da, chyba, że z użyciem debuggerów natywnych takich jak GDB. VisualVM bodajże jest, choć dla Native Image jest ograniczony. Heap Dump można wykonać, lecz tylko w wersji Enterprise Edition, gdyż z czegoś Oracle musi żyć.

Ciekawe jest to, że na użytek inicjalizacji klas w czasie budowania i obiektów w nim stworzonych jest osobny tzw. Image Heap.

A co na tym można uruchomić?

Z pewnością nie Springa. Bazuje on bowiem z założenia na refleksji, generowaniu bytecode’u, proxy i innych. Nawet gdyby się dało uruchomić, byłoby to wciąż wolne.

Dlatego specjaliści od Red Hata postanowili stworzyć Quarkusa. Sam Quarkus jest nakładką na Vert.x zapewniającą odpowiednie działanie dla GraalVM Native Image. Dodatkowo istnieje wiele „wtyczek” do Quarkusa, w których głównym założeniem jest wykorzystanie pełni potencjału GraalVMa.

Przykładowo mechanizm Dependency Injection ogarnięte jest w czasie kompilacji zamiast w runtime. Inicjalizacja „kontrolerów” webowych również w czasie inicjalizacji.

Nawet Hibernate jest porządnie zoptymalizowany dzięki wtyczce do Quarkusa. A gdy zmigrują Hibernate na Jandexa, wówczas i część inicjalizacji metadanych możnaby przenieść na czas kompilacji.

Podobne pole do optymalizacji widzę również w Jacksonie. Już teraz można cache’ować metadane obiektów w zewnętrznych implementacjach. Nie sprawdzałem jednak, czy w Quarkusie tak się aktualnie dzieje.

Nawet jeśli jeszcze istniejące rozwiązania nie są optymalne, to:1. Projekt ma mniej niż rok, więc spokojnie 😉

2. Już teraz aplikacje uruchamiają się w czasie mierzonym w milisekundach, więc raczej będzie tylko lepiej.