V tomto příspěvku se dozvíte o třech hlavních způsobechkniha_VM, jak můžete pomocí lepších JVM snížit systémové <náklady na cloudové výpočty v aplikacích a infrastruktuře založených na Javě a JVM:
- Rychlost: JVM, které spouští aplikační kód rychleji, může snížit množství využití CPU pro vykonání stejného množství práce.
- Konzistence: JVM, které zlepšuje konzistenci provádění při vyšších úrovních využití, umožňuje organizacím zvýšit jejich cíle využití a vytěžit více práce z každého virtuálního CPU, za který zaplatí.
- Elasticita: JVM, které zlepšuje zahřívání redukcí souvisejících artefaktů ovlivňujících úroveň služeb, umožňuje zvýšit elasticitu bez negativního dopadu na provoz. Výpočetní zdroje můžete agresivněji vypínat, když nejsou potřeba nebo jsou nedostatečně využívány.
Podíváme se na každou z nich a ukážeme, jak je lze využít ke snížení nákladů.
Jedním z nejzřejmějších způsobů, jak snížit výpočetní náklady, je zlepšit výkon každé aplikace, aby mohla zvládat stejné množství práce s menším množstvím zdrojů. I když přepracování kódu aplikace v každé aplikaci za účelem zvýšení její efektivity může někdy vést k významným ziskům, existují rychlejší a systematičtější způsoby, jak zlepšit výkon a snížit náklady.
Nejzřejmějším a nejbezprostřednějším způsobem, jak zlepšit výkon aplikace, je spouštět stejný kód aplikace na rychlejší nebo levnější výpočetní infrastruktuře.
Odkud se tedy bere rychlejší a levnější výpočetní infrastruktura?
VCPU, na kterých můžeme běžet, se v průběhu let obecně zrychlují a zrychlují. Jakmile se rychlejší vCPU stanou dostupnými za stejnou cenu za vCPU (nebo dokonce za lepší poměr rychlosti vCPU k utracenému dolaru), je přesun cloudových výpočtů na používání těchto novějších vCPU jako prostředek ke snížení nákladů zřejmý. Volba opaku je obvykle plýtvání.
Totéž platí, když jsou k dispozici levnější vCPU, které dokáží poskytnout stejný výkon. K tomu někdy dochází u architektury vCPU nebo změn dodavatele (např. x86-64 a Aarch64, Intel vs. AMD). Děje se to však také v průběhu času v rámci dané architektury a dodavatele hardwaru, protože stále více vCPU se vejde do křemíkových čipů díky přirozenému vývoji Mooreova zákona.
Nejzřejmějším a nejbezprostřednějším způsobem, jak zlepšit výkon aplikace, je spouštět stejný kód aplikace na rychlejší nebo levnější výpočetní infrastruktuře.
Aplikace založené na Javě a JVM mohou využít těchto posunů v podkladových vCPU, protože ve většině případů může stejný kód Java běžet prakticky na všech typech instancí cloudových výpočetních systémů. A protože podkladové JVM přizpůsobí kód aplikace tak, aby běžel na jakémkoli hardwaru, na kterém se nachází, a byl pro něj optimalizován, není pro přizpůsobení se měnícím se hardwarovým možnostem nutná žádná rekompilace. Zákazníci si mohou vybrat typy instancí, které jim v daném okamžiku poskytnou nejlepší „poměr ceny a výkonu“ neboli práci na vynaložené peníze, a přepínat mezi nimi podle toho, jak se tyto metriky v průběhu času mění a vyvíjejí.
Jak váš výběr JVM ovlivňuje náklady na cloud
Možná méně zřejmá je volba JVM použitého pro běh na těchto vCPU. Tato volba může také zajistit rychlejší a levnější výpočetní infrastrukturu. JVM, které dokáže spustit stejný aplikační kód rychleji na stejném vCPU, [zjevně] povede ke snížení nákladů stejným způsobem jako rychlejší a levnější vCPU.
Rozdíl v rychlosti mezi JVM se nyní zvětšil než rozdíly v rychlosti mezi po sobě jdoucími generacemi vCPU a mezi architekturami vCPU. Díky tomu je volba JVM stejně účinná jako volba CPU, pokud jde o omezení nebo snížení nákladů na cloudové výpočty.
Další zdroje pro optimalizaci nákladů na cloud
Upozorňujeme, že se nejedná o volbu buď-anebo. Výhody výběru instancí s lepším poměrem rychlosti vCPU k nákladům a rychlejších JVM se vzájemně doplňují a aditivní. Ve skutečnosti jsou rychlejší JVM obvykle také lepší v odhalování dalších zrychlení s novými vCPU, protože mají tendenci lépe optimalizovat jejich novější funkce a možnosti.
Stručně řečeno, výhody běhu na rychlejším JVM jsou stejně zřejmé jako běh na rychlejším vCPU. Nedělat tak je plýtvání.
Běžná realita v cloudových výpočtech
Podívejme se na běžný příklad využití a zdrojů v cloudovém prostředí. Níže uvedený graf je převzat z vícedenního vzoru skutečné produkční aplikace zákazníka běžící ve velkém měřítku. Znázorňuje využití CPU v čase [obrázek 1]. Vzory v tomto grafu se opakují u mnoha zákazníků.
Tato organizace platí za 100% CPU poskytnutého v tomto aplikačním clusteru, ale využívá pouze 10–30% výpočetní kapacity, za kterou platí. Zbývajících 70–90% výpočetní kapacity zůstává nevyužito a neposkytuje žádnou práci.
Nikdo se k této úrovni využití nedostane náhodou. Lidé sem obvykle přicházejí, protože když se snažili více zapracovat, nelíbila se jim úroveň služeb, které se jim výsledkem podařilo dosáhnout. To vyvolává přirozenou otázku: Co můžeme udělat pro zlepšení systému z hlediska nákladů?
Jak využít lepší rychlost, konzistenci a elasticitu
Vezmu tři věci, které Azulovy JVM v aplikacích vylepšují – rychlost, konzistenci a elasticitu – a položím je na tento obrázek, abych ukázal zlepšené efekty.
Krok první: Začněme s rychlostí
Předpokládejme, že k provedení určitého množství práce za „X“ časového úseku s daným JVM je zapotřebí „Y“ CPU. Jiný JVM, který dokáže stejnou aplikační logiku spustit rychleji, může snížit „Y“ CPU potřebné k provedení stejného množství práce v průběhu času. Pokud bychom měli stejný počet cloudových podů nesoucích stejné množství práce, ale s použitím Azul Zing JVM místo „vanilkového“ OpenJDK JVM, každý pod by spotřeboval méně CPU, protože Azul Zing JVM jednoduše spouští stejný aplikační kód rychleji.
Nyní odvádíme stejné množství práce ve stejném čase, ale s mnohem menším využitím procesoru díky efektivnějšímu provádění kódu v JVM Azul Zing. Zřejmým a okamžitým krokem je pak vypnout dostatek instancí, podů Kubernetes nebo instancí, aby se modrá čára vrátila na úroveň, na které byla zelená čára předtím [obrázek 2].
Můžete to dělat opatrně a postupně, pokud chcete: Jakmile uvidíte toto snížení využití CPU, můžete začít snižovat počet běžících uzlů z např. 10 na devět, osm, možná i sedm podů, dokud nedosáhnete stejné úrovně využití CPU jako předtím, a zároveň zachováte úroveň služeb beze změny.
| Jak spustit férový srovnávací test spotřeby CPU |
|---|
| Někdy je těžké si uvědomit, že pouhá změna JDK z OpenJDK na Azul Platform Prime může mít na výsledek tak dramatický vliv. Abychom to dokázali, často se hodí porovnání 50:50 vedle sebe. Pokud máte například cluster s 20 pody a provoz je rovnoměrně rozložen mezi všemi pody, můžete polovinu z nich spustit na „vanilkovém“ OpenJDK a druhou polovinu na Prime. Tímto způsobem můžete získat rozumné srovnání spotřeby CPU, kterou každý typ JVM vykazuje při ekvivalentní zátěži.
Vyvažování zátěže však v mnoha prostředích není „rovnoměrné“. Ve skutečnosti v mnoha prostředích založených na service-mesh rychlejší pody nakonec dostanou více práce, protože rychleji vyprazdňují své fronty požadavků. To znamená, že test, jako je výše uvedený, může vést k tomu, že zátěž nebude napříč konfiguracemi JDK ekvivalentní. Abychom zohlednili různé pody, které přebírají různé množství práce, je třeba zaznamenat jak úrovně CPU, tak i úrovně celkové zátěže, které každá „polovina“ zažívá. S těmito informacemi můžete porovnat „% využití CPU na pracovní rychlost“, které dvě různé možnosti JVM skutečně vykazují při kombinovaném zatížení. |
Toto (využití rychlosti) je pouze prvním (a často nejrychlejším a nejjednodušším) krokem k dosažení úspor s využitím Zing JVM. Pokud se znovu podíváte na tvar tohoto grafu, vypadá stejně jako tam, kde jsme začali. Stále má několik neefektivity, které lze řešit.
- Ano, celkový počet použitých vCPU je již snížen – protože kód je rychlejší, jsme schopni zvládat stejnou pracovní zátěž se stejnou úrovní využití CPU a zároveň s menším počtem vCPU. Zvýšili jsme hodnotu každého vCPU, za který platíme, ale nezměnili jsme tvar grafu…
- – i při maximálním využití vidíme pouze ~30% míru využití zřízených (a zaplacených) CPU. Jinými slovy, i při maximálním využití se více než dvě třetiny utracených dolarů stále nevyužívají.
- A využití CPU v procentech je nerovnoměrné, v průměru je hluboko pod špičkou – využití CPU se pohybuje mezi ~10% a ~30%. Mimo špičkové úrovně zatížení je využití ještě nižší a plýtvání (množství zaplaceného, ale nevyužitého CPU) je ještě vyšší.
Existuje důvod, proč se organizace často spokojí s takovými výsledky. Obvykle se [těžce] naučily, že pokud zvýšíte využití ve špičce, věci se nepovedou dobře. Možná se také naučily, že pokud se pokusíte vypnout zdroje během nízkého zatížení a doby nízkého využití a později je znovu zapnout, když úroveň zatížení vzroste, věci se také nepovedou dobře. Jejich indikátory SLA budou ukazovat špatné věci nebo si vaši uživatelé budou stěžovat, takže netlačí ani neformují své využití na úrovně, které tyto věci způsobují.
Druhý krok: Využijte vylepšenou konzistenci
JVM od Zing je speciálně navrženo tak, aby spouštělo aplikační kód s konzistentnějším výkonem (méně zádrhelů, pauz, „dočasných zpomalení“ nebo zablokování při dané úrovni zátěže) než „vanilkové“ JVM od OpenJDK. V důsledku toho každá instance a každý pod obvykle zvládne vyšší využití CPU, než se začnou dít takové „špatné věci“, a frekvence artefaktů ovlivňujících úroveň služeb snižuje chování na nepřijatelnou úroveň.
S využitím této vylepšené konzistence je dalším krokem ke snížení nákladů vypnutí dalších podů tak, aby špičkové využití CPU překročilo předchozí cílovou hodnotu. I zdánlivě malým posunem tohoto cíle můžeme dosáhnout značných úspor. Například snížení počtu podů za účelem zvýšení špičkového využití CPU z ~30% na ~40% by snížilo celkový počet podů o ~25%, přičemž každý zbývající pod by nesl o 33% více práce než dříve.
A právě zde se investice společnosti Azul do konzistence JVM v průběhu let skutečně vyplácí, protože nám umožňuje posunout cílové hodnoty CPU výše, než jsou dnes, což vede k velkým úsporám [obrázek 3].
| Jak vyhodnotit, jak lze vylepšenou JVM posunout k vyššímu využití |
|---|
Krok tři: Povolte a zvyšte elasticitu
I s prvními dvěma vylepšeními (rychlost, konzistence), pokud se využití v čase stále výrazně mění, přetrvává značná neefektivnost, kterou lze řešit. Obrázek 4 výše stále vykazuje vrcholy a dna s velkými rozdíly ve využití mezi nimi. V okamžicích, kdy se zdroje nevyužívají na cílové úrovni využití, dochází k velkému plýtvání, například o půlnoci v tomto grafu, kdy je potřeba méně než polovina zdrojů, ale instance nebyly vypnuty, ani když je využití velmi nízké.
Zjistili jsme, že mnoho grafů využití aplikací má tento tvar. Tam, kde ho vidíme, to často naznačuje, že elasticita a automatické škálování nejsou vůbec nebo jen částečně využívány. Například mnoho organizací, které používají automatické škálování jako formu pojištění proti extrémním špičkám, se jeho „běžnému“ používání vyhne tím, že si udrží konzervativní minimální počet podů, pod který neklesnou.
Taková variabilita ve využití je obvykle výsledkem nedostatečné ochoty vypínat zdroje, když nejsou potřeba. V moderních prostředích s možností automatického škálování (např. k8s) se tato nedostatečná ochota obvykle nepřipisuje tomu, co se stane, když jsou pody vypnuty (při nízkém využití je to obvykle neškodné), ale škodlivému chování, které se projevuje při opětovném spuštění nových instancí. Takové „problémy se zahříváním“, kdy se dočasně pomalé nebo závadové chování objevuje na začátku životnosti nové instance JVM, vedou ke špatné úrovni služeb pro klientský provoz zpracovávaný těmito instancemi, dokud nejsou plně zahřáté a „běží rychlostí“. Toto chování se obvykle projevuje jako zvýšená chybovost, časové limity nebo artefakty doby odezvy. A tyto závady obvykle nejsou funkcí zátěže, ale funkcí „pomalých“ nebo „dosud nezahřátých“ instancí obsluhujících provoz.
A zde přichází na řadu třetí krok ke snížení nákladů založené na „lepším JVM“: Díky Azul Prime JVM, na kterých běží vaše aplikace, lze plně aktivovat elasticitu, aniž by docházelo ke snížení úrovně služeb, které je tak často spojováno s „zahříváním“ a automatickým škálováním.
Volba JVM je stejně účinná jako volba CPU, pokud jde o omezení nebo snížení nákladů na cloudové výpočty.
„Vanilla“ OpenJDK JVM se efektivně zahřívají pouze zpracováním skutečného provozu, protože optimalizují kód až poté, co pozorují, že je dostatečně často procvičován (zpracovává dostatek klientského provozu), aby mohly učinit optimalizační rozhodnutí. V podstatě musí každý nově spuštěný pod „zatížit“ dostatek provozu, aby se naučil, co a jak optimalizovat, a aby dosáhl bodu, kdy již provozu neškodí.
Produkt Azul Platform Prime dramaticky zlepšuje chování jednotlivých podů při zahřívání kombinací technik vytvořených explicitně pro tento účel. Díky technologiím Azul ReadyNow a Optimizer Hub mohou flotily JVM sdílet těžce získané zkušenosti s zahříváním, což umožňuje nově spuštěným podům „připravit se“ na základě předchozích znalostí a vyhnout se zatěžování provozu, aby se „naučili“, co a jak optimalizovat. Azul Optimizer Hub využívá svou schopnost cloudového nativního kompilátoru< k efektivní optimalizaci kódu v celé flotile, takže jednotlivé JVM v nově spuštěných podech nemusí během spouštění provádět těžkou práci s optimalizací. Díky těmto technikám se výkonné optimalizace aplikují ještě předtím, než provoz dorazí do nově spuštěných podů, a eliminují se pomalé, dosud nezahřáté pody v provozu.
Centrum optimalizace Azul automaticky organizuje a amortizuje optimalizace, což umožňuje produkčnímu prostředí efektivní a organickou samooptimalizaci. Tyto produkční optimalizace se projevují beze změny v životním cyklu vývoje softwaru (SDLC). S tím, jak se zavádějí nové verze aplikace, rané instance (obvykle kanárkovské) automaticky zavádějí prostředí a optimalizace, které následné pody využívají při svém spuštění v důsledku zavádění a automatického škálování.
Tato optimalizační funkce pro celý vozový park přímo řeší negativní artefakty na úrovni služeb, které jsou obvykle spojeny s „zahříváním“ a automatickým škálováním. Díky tomu je automatické škálování praktické a prospěšné pro většinu aplikací a služeb.
Po odstranění překážek automatického škálování lze plně aktivovat a široce přijmout elasticitu. Aplikace, které se dříve automatickému škálování vyhýbaly, jej nyní mohou aktivovat. Aplikace, které dosud automaticky škálovaly pouze konzervativně (např. používaly automatické škálování pouze pro řešení vzácných špiček s použitím vysokého minimálního počtu podů), mohou přejít na kontinuální automatické škálování [obrázek 4]. Hluboké poklesy využití během období nízkého zatížení lze eliminovat bezpečným vypnutím podů pro zvýšení využití během nízkého zatížení a jejich bezpečným opětovným zapnutím (bez negativních dopadů na úroveň služeb) po návratu zatížení.
| Další výhody řízení nákladů, které vyplývají z praktické elasticity |
|---|
| Jakmile lze plně aktivovat elasticitu bez dopadů na úroveň služeb během „zahřívání“, objeví se nové možnosti využití modelů spotřeby cloudových instancí a cenových modelů (například snížení rezervací a širší využití spotových instancí), které dříve nemusely být praktické. Ty mohou snížit průměrné náklady na hodinu vCPU, což vede k dalším úsporám. |
Shrnutí
Spouštěním aplikací a služeb na JVM, které je rychlejší, konzistentnější a eliminuje artefakty na úrovni služeb související s zahříváním, lze výrazně snížit výpočetní náklady. Azul Zing JVM a Prime Platform přinášejí reálné úspory zvýšením efektivního finančního využití výdajů na cloudové výpočty [viz obrázek 5].
| „Chcete-li snížit náklady,… zaměřte se na snižování nákladů.“ |
|---|
| Při hodnocení potenciálu úspor nákladů obvykle chceme prokázat snížení nákladů co nejrychleji s co nejmenším vynaloženým úsilím. Ze zkušeností jsme se naučili, že na cestě existují určitá úskalí a rozptýlení a že některé kroky zaměřené na cíl mohou pomoci s tím, co považujeme za „pilotní“ projekt pro účely úspory nákladů.
Je důležité si uvědomit, že ačkoli funkce rychlosti, konzistence a elasticity, které Azul Prime nabízí, lze využít k úsporám nákladů, lze je využít i k jiným účelům. Pokud je vaším cílem snížení nákladů, je důležité se nenechat rozptylovat nebo se zamotat do honby za těmito dalšími výhodami jen proto, že jsou „cool“, nebo dokonce proto, že by mohly být jinak užitečné. Například, protože se latence běžných případů a odlehlých hodnot v raných testech při stejných úrovních využití často zlepšují, lidé se mohou začít soustředit na tuto výhodu a ztratit pozornost na cíli nákladové a přínosné hodnoty. Někdy jim dokonce musíme připomenout, že pokud chceme měřit nákladovou a přínosnou hodnotu, měli bychom být ochotni obětovat jakékoli zlepšené chování v oblasti latence nebo doby odezvy pro zvýšení úrovně využití. Tyto metriky rychlosti a konzistence často znamenají, že „měli byste se více snažit a vypínat více podů“. I po dosažení úspor a po vynaložení maximálního úsilí můžeme mít (a obvykle i máme) určité výhody v oblasti rychlosti a konzistence (např. lepší mediánové nebo průměrné doby odezvy, mnohem nižší magnitudy a frekvence odlehlých hodnot) a to i po dosažení úspor. V kontextu snahy o snížení nákladů je však vnímáme jako „bonus“. Nejsou cílem. Pokud chcete lepší latence, méně odlehlých hodnot nebo více „výher“ či „shod“ a pokud snížení nákladů není vaším hlavním cílem, je Azul Prime vynikajícím řešením i pro tyto cíle. Ale to je téma pro jiný blogový příspěvek. |
