Cadec 2025 Stockholm
2025-01-23
Cadec 2025 Stockholm
Konferensen för utvecklare som vill utvecklas
Länk till utvärderingen Cadec Stockholm 2025
Cadec-appen
Ladda ner Cadec-appen, där kan du ställa frågor till talarna under konferensen. Välj någon av länkarna nedan.
Om Cadec 2025
Boka in torsdagen den 23:e januari 2025 – då går Cadec av stapeln i Stockholm. Missa inte chansen att få en rivstart på det nya året med ett inspirerande kunskapslyft. Vi kan utlova ett fullspäckat program med både bredd och djup, och som vanligt handlar föredragen om de senaste trenderna inom arkitektur och utveckling.
Här kan du se det kompletta programmet.
Platsen är Filmstaden Sergel, där kan vi erbjuda en presentationsupplevelse utöver det vanliga. Vi ser fram emot att återigen få träffa alla deltagare personligen.
Det blir naturligtvis också After Cadec på vårt kontor där vi kan varva ner efter konferensen med mat, dryck och mingel. En separat inbjudan till After Cadec kommer vid ett senare tillfälle.
Konferensen är kostnadsfri.
Tid: torsdag 23:e januari 2025 kl 13.00 till 17.00
Plats: Filmstaden Sergel, Hötorget 3, Stockholm
After Cadec: på Callistas kontor, direkt efter konferensen. Separat inbjudan kommer senare.
Välkommen!
önskar teamet på Callista
Presentationer på YouTube
Alla presentationer från årets Cadec finns i denna spellista (se Callistas YouTube-kanal för presentationer från tidgare år)
Presentationer
Snabbare uppstart av Java-applikationer med CRaC
Magnus Larsson
Med en ökad användning av mikrotjänster och molnbaserade arkitekturer har snabba uppstartstider för applikationer blivit allt viktigare för effektiv skalning och minskad nertid. För Java-applikationer kan dock krav på korta uppstartstider vara svåra att uppfylla.
I denna presentation introducerar vi CRaC (Coordinated Restore at Checkpoint), en teknik som kan minska uppstartstiden avsevärt för Java-applikationer. Vi går igenom hur man går tillväga för att använda CRaC och demonstrerar hur det fungerar för applikationer utvecklade med Spring Boot.
Presentationen jämför också CRaC med andra tekniker för att minska uppstartstider såsom GraalVM native compile, AppCDS och project Layden.
Frågor och svar
Vilken typ av service kan man använda Scale to Zero-strategi på?
Ju mindre service desto bättre skulle jag vilja säga. Typfallet är väl FaaS, Function as a Service. Men baserat på de tester jag gjort så här långt ser jag ingen teoretisk övre gräns för hur stor en Spring Boot-applikation kan vara, givet att man använder CRaC. Ju större applikation desto större minnesutnyttjande, och därmed kommer en checkpoint ta allt större plats på disk, vilket borde kunna bli ett praktiskt problem.
Finns det risk för svårupptäckta fel genom att den CRaC:ade applikationen på något sätt skiljer sig från originalet?
Förutom de områden som togs upp under presentationen, har jag inte sett några andra specifika problemområden. Självklart kan det finnas buggar i CRaC i sig som kan ge upphov till fel. En återstartad CRaC-applikation körs som en vanlig applikation i en Java-VM, till skillnad från t.ex. en applikation som är native-kompilerad med Graal VM och som därmed kör maskinkod direkt istället för att vara baserad på Java bytecode.
Finns det en stor community som hjälper till med CRaC-implementering?
Ja, det är ett OpenJDK-projekt. För mer info se OpenJDK CRaC.
Does the checkpoint contain heap data that could be sensitive?
Ja, det är därför viktigt att uppvärmningen före checkpoint körs mot en tillfällig träningsmiljö. Då blir den känsliga informationen som skrivs ner på disk vid checkpoint utan värde.
Kan man inte förenkla byggprocessen genom att göra warmup och checkpoint direkt i byggservern, givet att den kör Linux? Då skulle man ju slippa bygga den första jar-baserade Docker-imagen.
Nej, det tror jag är väldigt svårt, i alla fall baserat på de tester jag gjort. För att CRaC:s restore ska fungera krävs det att samma operativsystem och Java-installation används som vid CRaC:s checkpoint. Jag har löst problemet genom att använda samma bas-Docker-image (för OS och Java) för checkpoint och restore.
Har du provat att använda Testcontainers istället för Docker Compose för att starta ett träningslandskap?
Ja, men eftersom checkpointen måste köras i en container, i den lösning jag jobbat med (se frågan ovan), så kommer Testcontainers-ramverket behöva starta syskon-containrar, dvs anropa Dockers API. Det ska gå rent tekniskt att få till, men jag tycker alltid att det är knöligt och väldigt störkänsligt. Så jag undviker det. De som vill prova kan läsa mer på Testcontainers Docker-in-Docker.
What about connection with a database, will it establish again?
Se bild med rubriken “State and Connections” i min presentation. 3PP-biblioteket som används för databaser måste implementera CRaC:s Resource-interface för att hantera detta.
Olika JVM-versioner vid bygge och restart?
Ingen bra idé, enligt mina erfarenheter. För att CRaC:s restore ska fungera krävs det att samma operativsystem och Java-installation används som vid CRaC:s checkpoint. Om man beaktar att restore i princip handlar om att läsa tillbaka minnet i en process från disk så inser man att det är bra om det underliggande operativsystemet och Java-miljön är identiska med hur de såg ut vid checkpoint-tillfället. Jag har löst problemet genom att använda samma bas-Docker-image (för OS och Java) för checkpoint och restore.
Är CRaC lämpligt för större applikationer eller har det negativ påverkan på CRaC?
Jag kan tänka mig att en större applikation har större minnesutnyttjande, och därmed kommer en checkpoint ta allt större plats på disk, vilket borde kunna bli ett praktiskt problem.
How can I use CRaC to keep my boss happy about my development approaches? It is clear that CRaC can keep management happy about our development work.
Om bossen är bekymrad över (dvs. ni har ett affärsrelaterat problem med) långa startup-tider för en eller flera av era Java-applikationer (t.ex. i ett scale-to-zero-sammanhang), så kan absolut CRaC vara en väg framåt för att göra bossen och er verksamhet nöjd.
När du väl har flödet på plats är det ju super men verkar vara massor med jobb. Hur skulle det funka att bara köra i ‘live’ - dvs första deploy är från jar och sedan när live är varmkörd ta en snapshot och fortsättningsvis köra från den? Secrets är såklart ett problem men config behöver inte trixas med.
Ja, håller med. Hoppas min nästa bloggpost kan ge er en flygande start för att automatisera skapandet av CRaC-baserade Docker-images :-) Att bara köra checkpoint/restore live är väl i princip hur AWS SnapStart-stödet för Java-baserade Lambda-funktioner fungerar. Så, det får man väl säga fungerar :-). Jag har själv dock inte testat eller funderat på den ansatsen.
Can a checkpoint be made at any point in the program? Benefits, challenges (e.g. connections to external services)?
Tekniskt sett ja, men för att hålla nere uppstartstiden efter en restore så är det viktigt att applikationen är “tillräckligt” uppvärmd innan checkpointen tas. Detta kommer i de flesta fall leda till att man måste återetablera connections till databaser, köhanterare mm efter restore. En stor del av presentationen handlade om detta, så kika gärna igenom presentationen igen när den blivit publicerad.
Vilka begränsningar eller utmaningar finns med CRaC?
Tror det finns rätt matnyttiga svar ovan på den frågan.
Could CRaC be used not just at build and deploy time but even at runtime for event sourced applications to save regular checkpoints so it doesn’t have to replay all the events at every startup?
Det var ju en intressant idé! Jag har inte själv funderat i banor av att persistera (event) data mha CRaC. Med tanke på att data ändras mycket fortare än applikationen så blir det kanske rätt ineffektivt att checkpointa applikationen varje gång man vill checkpointa sin event-data.
Finns det någon nackdel med CRaC eller ska man automatisera det och alltid ha den approachen?
Som med all ny teknik så skall man införa det med viss måtta tycker jag. Börja med att prova ut det där det finns en tydlig vinst, t.ex. i ett scale-to-zero-scenario. Utvärdera och besluta därefter hur ni vill gå vidare. Men att automatisera ser jag som ett grundkrav innan man använder det i produktion.
Vad händer när appen kraschar? Vill man använda checkpoint då?
Oftast, ja, skulle jag vilja säga. Enda fallet jag kan tänka mig teoretiskt är om kraschen skulle bero på hur man värmde upp applikationen innan man tog checkpointen. Då måste man ju hitta och rätta felet i applikationen och sedan ta en ny checkpoint av den nya versionen. Som workaround, i väntan på den nya versionen, borde man kunna ändra i warmup-proceduren för att undvika att trigga felet i applikationen innan checkpoint.
Kan man kombinera CRaC med native compile / Graal?
Det avråder jag bestämt från! Blanda tekniker på det sättet är att be om problem. Dessutom ser jag spontant inte nyttan, native-kompileringen kommer ju i slutändan skapa maskinkod, så nyttan av CRaC uteblir vad jag kan förstå.
Hur ser du på ROI av CRaC:ade tjänster? Är det värt insatsen?
Ja, givet att man har ett behov av snabbare startuptider. Ju mer verksamheten vinner på en snabbare uppstart desto fortare ger investeringen vinst. Om t.ex. användare slipper vänta 5 sek vid uppstart av en Java-applikation i ett scale-to-zero-scenario, så kan man säkert snabbt räkna hem investeringen. Dvs i form av att man inte behöver ha sin applikation igång när den inte används.
Rensas minnesdumpen från disk när applikationen startats upp igen och i vilket läge återskapas den i så fall? Eller återanvänds den första checkpointen om och om igen och ligger kvar på disk?
Så som jag visade i min presentation så läggs minnesdumpen in i en Docker-image, och rensas därmed inte utan återanvänds varje gång en container skall startas från den versionen av Docker-imagen.
Bör man skriva andra tester för att få CRaC att fungera bra jämfört med de man vanligen har av kvalitetsskäl?
Om man tänker på tester som skall användas under uppvärmningen före man tar en checkpoint så är min tanke att man till stor del skall kunna återanvända befintliga tester som används för att säkra kvaliteten. Men det borde ju kunna uppstå, rent teoretiskt, behov av tester för att säkerställa en tillräckligt bra uppvärmning och som befintliga kvalitetstester inte täcker in. Men börja med ansatsen att återanvända befintliga tester och se om ett behov dyker upp för specialtester för uppvärmning.
Do you have to be careful having the application ”idle” (no external operations in progress) when creating the checkpoint?
Den ansatsen jag har utgått från är att checkpoint tas i byggsteget och där har man full kontroll på applikationen. Där tar man checkpointen efter uppvärmningen är klar och applikationen är “idle”. Då CRaC kräver att externa connections är stängda vid en checkpoint, så låter det svårt att ta en checkpoint “i farten”.
Bör man tänka på GC innan snapshot?
Det låter som en intressant tanke, jag har själv inte laborerat med det.
What happens to the stack and any open file descriptors when a process is CRaCed?
Se bild med rubriken “State and Connections” i min presentation, filer och andra externa connections måste stängas före en checkpoint och återetableras efter en restore. CRaC-interfacet Resource kan användas av en applikation för att få reda på när en checkpoint skall ske och när en restore har utförts.
Finns det alternativ på ‘Docker-nivån’? Där minne av pausad container sparas till disk?
Inget jag har kikat på. Handlar det om en kortare paus så kanske det kan fungera utan att applikationen blandas in. Annars får man väl samma problem att handskas med externa connections och konfiguration som inte längre är relevant vid en återstart.