AWS přesouvá studený start před první požadavek — ne vždy zdarma

AWS v představení SdkWarmUp z 25. září 2026 popsalo funkci dostupnou v AWS SDK for Java 2.x od verze 2.54.0. Přípravu cesty klienta přesouvá před první skutečný požadavek služby. Při zahřívání HTTP klienta provede jeden nepodepsaný síťový požadavek, za který AWS neúčtuje operaci služby; aplikace ale musí na dokončení zahřívání počkat.

Vývojář může zavolat SdkWarmUp.warmUp(S3Client.class) pro vybraného klienta Amazon S3, nebo SdkWarmUp.warmUp() pro všechny klienty služeb na classpath. Funkce je součástí modulu sdk-core a nepotřebuje další závislost. Rozdíl mezi oběma voláními určuje, kolik práce aplikace vykoná při startu, ještě než přijme provoz.

Co se přesune před první volání služby

Při prvním provozním volání JVM načítá a inicializuje třídy používané cestou požadavku. SDK zároveň připravuje sestavení požadavku a zpracování odpovědi. Připojení k endpointu může zahrnovat vyhledání DNS, navázání TLS a ověření certifikátu. Zahřívání spustí tyto části práce dříve, takže nemusí celé připadnout na čekání při prvním volání služby.

Klient služby při zahřívání zpracuje místní připravenou odpověď. Tím projde kód pro serializaci požadavku a zpracování odpovědi, aniž by provedl skutečnou operaci služby. Síťová část má jiný účel: nepodepsaný požadavek na endpoint AWS připraví cestu HTTP klienta. Nepotřebuje přihlašovací údaje ani oprávnění IAM.

Náklad se tedy projevuje v čase inicializace, ne v poplatku za zahřívací operaci služby. Načtení tříd a síťový kontakt mohou oddálit okamžik, kdy je instance připravená přijmout požadavek. Funkce dává největší smysl tam, kde je žádoucí vykonat tuto práci předem nebo ji zahrnout do snímku inicializované aplikace.

Rozsah zahřívání rozhoduje o délce startu

Záznam vydání na NewReleases uvádí, že verze 2.54.0 vyšla 19. srpna 2026 a už obsahovala volání pro celý classpath i přetížení pro vybrané třídy. Zářijové představení AWS proto přišlo po vydání kódu. Pro použití funkce je podstatná verze SDK, ne datum publikace návodu.

Nejmenší selektivní příklad používá import software.amazon.awssdk.core.warmup.SdkWarmUp, import software.amazon.awssdk.services.s3.S3Client a volání SdkWarmUp.warmUp(S3Client.class). Má-li aplikace na první provozní cestě také Amazon DynamoDB, může ve stejném volání uvést DynamoDbClient.class. Výčet tříd zahřeje právě pojmenované klienty a HTTP cestu, kterou používají.

Pro celý classpath stačí import SdkWarmUp a volání SdkWarmUp.warmUp(). SDK vyhledá dostupné klienty služeb a zahřeje je spolu s jejich HTTP klienty. Tato varianta odpovídá aplikaci s malým počtem modulů služeb, která většinu z nich skutečně používá. Bezparametrické zahřátí proběhne nanejvýš jednou v rámci JVM; po úspěšném dokončení se další volání ihned vrátí.

Pokud závislosti přinesou moduly služeb, které aplikace nevolá, bezparametrická metoda jim přesto věnuje čas při startu. Výběr tříd drží přípravu blíž skutečnému použití. Záleží i na podobě klienta: třída synchronního klienta zahřívá synchronní cestu, zatímco třída asynchronního klienta zahřívá asynchronní cestu. Příprava S3Client proto sama o sobě neznamená přípravu S3AsyncClient.

SnapStart a CRaC potřebují zahřátí před snímkem

Návod AWS pro SdkWarmUp umisťuje volání při Lambda SnapStart do konstruktoru handleru před pořízením snímku a při samostatném CRaC do inicializace před checkpointem. Lambda vytváří snímek až po běhu konstruktoru, takže obnovené prostředí může využít připravený stav SDK. Volání vložené až do obsluhy požadavku by tuto práci vrátilo na cestu prvního požadavku.

U aplikace se samostatným CRaC musí být kromě zahřívání vyřešen životní cyklus spojení kolem checkpointu. Klienty služeb je třeba před checkpointem zavřít a po obnovení vytvořit znovu. Při použití HTTP klienta založeného na AWS CRT zůstává otevřená také sdílená smyčka událostí; tu je nutné před checkpointem uvolnit zvlášť. U klientů založených na Netty a Apache se prostředky uvolní zavřením klienta služby.

SdkWarmUp má použití i v dlouho běžící službě bez snímkování. Volání může proběhnout před registrací instance u nástroje pro rozdělování provozu nebo před oznámením její připravenosti. V takovém nasazení se čas přípravy projeví při náběhu každé nové JVM. U SnapStart se příprava uskuteční před vytvořením snímku, z něhož se následně obnovují instance.

Kdy se předčasná příprava vyplatí

Kratší první volání služby samo neříká, zda se zkrátila celá cesta od spuštění instance k obsluze požadavku. Zahřívání přesouvá práci do dřívější fáze; při širokém classpathu může příprava nepoužívaných klientů tuto fázi prodloužit. Rozhodující jsou proto současně délka inicializace, okamžik připravenosti a latence prvního skutečného volání v dané aplikaci.

Selektivní volání je vhodnější tam, kde první požadavek používá jen malou část přibalených služeb nebo je čas do připravenosti přísně omezen. Bezparametrická varianta ušetří ruční výčet, pokud se používaní klienti přibližně shodují s klienty dostupnými na classpath. Pro obě varianty platí stejný mechanismus místní přípravy klienta služby a síťové přípravy HTTP klienta; mění se počet cest, které aplikace připraví předem.

Výsledná úspora latence závisí na složení aplikace, jejích klientech a způsobu spuštění. AWS pro novou funkci nepublikovalo obecný výsledek měření použitelný pro každé nasazení. V prostředí s krátkým limitem inicializace proto může být čas získaný při prvním volání vykoupen pozdějším dosažením připravenosti instance.