Článek přečtěte do 5 min.

Slyšeli jste o Azul Optimizer Hub a zajímá vás, jak se hodí do vaší architektury AWS. Jako architekt AWS jste pravděpodobně obeznámeni s výkonnostními problémy spojenými se spouštěním úloh Java v kontejnerizovaných, cloudově nativních prostředích – zejména se zpožděním spouštění a režií zdrojů, která je spojena s kompilací JIT. Optimizer Hub je nativní řešení Kubernetes, které běží na Amazon EKS a zásadně mění tuto rovnici, čímž umožňuje optimální výkon aplikací od prvního požadavku. Zde je vše, co potřebujete vědět o integraci této revoluční technologie do vašeho prostředí AWS.

Tradiční Java spouští kód v pomalejším interpretovaném režimu, dokud si nevytvoří optimalizační profil. To znamená, že optimalizaci může spustit až poté, co aplikace začne přijímat provoz a dotkne se kritických cest kódu. Takže právě když se snažíte horizontálně navýšit provoz kvůli velkému nárůstu provozu, vaše počítače běží nejpomaleji a rozdělují dostupný výkon CPU mezi zpracování požadavků a provádění nákladných JIT optimalizací.

Díky nástroji Optimizer Hub mohou aplikace v Javě dosáhnout plné rychlosti rychleji a s minimálním zatížením CPU na straně klienta.

Optimizer Hub poskytuje dvě služby, které řeší tradiční problém s rozběhem Javy:

  • ReadyNow Orchestrator: Monitoruje vzorce používání v celé vaší flotile a vytváří optimalizační profily, které řídí kompilace v JVM. Nově spuštěné JVM přeskakují fázi profilování a kompilují metody ihned po inicializaci, což umožňuje, aby velká část JIT kompilace proběhla během inicializace aplikace, než začne přebírat provoz.
  • Cloudový nativní kompilátor (CNC): Poskytuje optimalizaci na straně serveru tím, že přesouvá JIT kompilaci do samostatné, vyhrazené JIT farmy. CNC ukládá optimalizace do mezipaměti, aby se zabránilo stonásobnému opakování stejné optimalizace, což klientům umožňuje věnovat 100 % svého CPU zpracování požadavků, aniž by se rezervovala kapacita pro počáteční špičky JIT kompilace.

V kombinaci vám tyto služby zajistí rychlejší dosažení plné rychlosti, plynulejší využití CPU během zahřívání a menší plýtvání kapacitou. A na rozdíl od jiných technologií zahřívání, jako je Graal Native Image, lze Optimizer Hub použít na jakékoli verzi JDK a zvládne všechny vzory kódu Java – a nevyžaduje žádné změny vašeho kódu.

Jaká je architektura?

Optimizer Hub se dodává jako cluster Kubernetes, který spouštíte ve svém VPC, obvykle ve službě Elastic Kubernetes [obrázek 1].

SCHÉMA: Optimizer Hub je dodáván jako cluster Kubernetes, který spouštíte ve svém VPC pro zlepšení výkonu aplikací.
Obrázek 1: Optimizer Hub je dodáván jako cluster Kubernetes, který spouštíte ve svém VPC pro zlepšení výkonu aplikací.

Důležité detaily:

  • Nejlepší způsob instalace je použití našich Helm grafů (verze je v3.8.0 nebo novější).
  • Všechny obrazy jsou na DockerHubu, ale většina zákazníků si je stáhne do svých interních systémů pro správu artefaktů a poté aktualizuje Helm grafy tak, aby ukazovaly na nové umístění.
  • Operátor se stará o veškeré škálování a potřebuje oprávnění k volání do Kubernetes API. Optimizer Hub nepoužívá škálování HPA.
  • Optimizer Hub vyžaduje připojení k S3. Požadovaným uzlům můžete udělit oprávnění RW k úložištím S3 nebo nastavit servisní účty AWS pro správu přístupu.
  • Optimizer Hub je sdílená služba, kde jedna instance může obsluhovat všechny JVM spuštěné v dané zóně dostupnosti. Pro každou aplikaci nepotřebujete samostatnou instanci Optimizer Hub, ideálně by měla nacházet ve stejné zóně dostupnosti jako aplikace, které obsluhuje.
  • Optimizer Hub poskytuje plnou vysokou dostupnost a JVM mohou fungovat, i když je přístup k Optimizer Hubu zcela ztracen.
SCHÉMA: Jedna instance kompilátoru Cloud Native Compiler obsluhuje mnoho JVM pro lepší výkon aplikací a nižší náklady na cloud.
Obrázek 2: Jedna instance kompilátoru Cloud Native Compiler obsluhuje mnoho JVM pro lepší výkon aplikací a nižší náklady na cloud.

Instalace na EKS

Požadavky na infrastrukturu:

  • Typy instancí: Instance EC2 na vyžádání nebo rezervované instance (bez spotových instancí).
  • Velikost: Minimálně 8 virtuálních jader a 32 GB RAM na uzel.
  • Doporučené instance: rodiny instancí m6 nebo m7.
  • Možnosti nasazení: Instalace do existujícího clusteru EKS nebo vytvoření vyhrazeného clusteru pomocí poskytnutého skriptu eksctl.

Skript eksctl vytvoří ve vašem účtu AWS následující:

  • Zásobníky CloudFormation pro hlavní cluster EKS a každou z NodeGroups v clusteru.
  • Virtuální privátní cloud s názvem eksctl--cluster/VPC. Pokud se rozhodnete použít existující VPC, tento se nevytvoří. VPC a související síťové komponenty si můžete prohlédnout v konzoli AWS VPC. VPC má nakonfigurované všechny potřebné síťové komponenty:
  • Sada tří veřejných podsítí a tří privátních podsítí.
  • Internetová brána.
  • Směrovací tabulky pro každou z podsítí.
  • Elastická IP adresa pro cluster.
  • Brána NAT.
  • Klastr EKS, včetně čtyř skupin uzlů s jednou zřízenou instancí m5.2xlarge:
  • infra – Pro spuštění Grafany a Promethea.
  • opthubinfra – Pro spouštění komponent infrastruktury Optimizer Hub.
  • opthubcache – Pro spuštění mezipaměti Optimizer Hub.
  • opthubserver – Pro spuštění nastavení kompilačního brokera Optimizer Hub.
  • Artefakty IAM pro skupiny automatického škálování:
  • Role pro skupiny automatického škálování pro cluster a pro každou podsíť.
  • Zásady pro automatické škálování EKS.

Automatické škálování

Optimizer Hub má dva režimy – pouze ReadyNow a plný režim (s ReadyNow a CNC). Režim ReadyNow nevyžaduje mnoho zdrojů a neškáluje se. CNC naopak škáluje značné množství zdrojů v krátkých časových intervalech, kdy se spouští JVM, a poté je snižuje, jakmile se požadavky na kompilaci snižují.

Na rozdíl od tradičního HPA, které škáluje na základě metrik CPU/paměti, operátor Optimizer Hub škáluje komponenty gateway, compile-broker a cache na základě pracovní zátěže kompilace. Systém monitoruje hloubku kompilační fronty a škáluje zdroje tak, aby odpovídaly příchozím požadavkům na kompilaci a výpočetní kapacitě.

Vyvažování zátěže a vysoká dostupnost v Optimizer Hubu

V produkčních systémech musíte k instancím Optimizer Hub připojit load balancer nebo service mesh. JVM připojující se k Optimizer Hub potřebují stabilní, jediný vstupní bod pro komunikaci se službou. Můžete použít load balancer založený na DNS (např. Amazon Route 53) nebo service mesh Kubernetes (např. Istio). Brány Optimizer Hub zahrnují standardní kontroly připravenosti, které můžete použít k určení, kdy odeslat provoz do clusteru.

Instance Optimizer Hub lze nakonfigurovat tak, aby automaticky synchronizovaly profily ReadyNow mezi sebou. Pokud tedy nejbližší instance aplikace není k dispozici, ostatní instance mají profily potřebné k zajištění plynulého spuštění.

Pokud se Optimizer Hub stane nedostupným, nově spuštěné JVM pokračují v provozu, ale s pomalejším zahříváním a v některých případech s nižší rychlostí kódu.

  • Profily ReadyNow nebudou k dispozici, takže JVM nemohou načíst JIT kompilaci příliš brzy v cyklu. To může vést k vyššímu zatížení CPU a kratší době odezvy, když aplikace zatěžuje provoz.
  • Kompilátor Cloud Native Compiler nebude k dispozici, což znamená, že všechny kompilace probíhají lokálně. Pokud CNC není k dispozici, můžete JVM nakonfigurovat tak, aby používaly nižší úroveň kompilací, a minimalizovat tak dopad lokálního provádění kompilací.

Vyzkoušejte si to sami

Optimizer Hub je zdarma k použití s ​​jakoukoli licencovanou instancí Azul Platform Prime. Stream Buildy Azul Platform Prime jsou k dispozici pro vyhodnocení a testování. Pro další informace nás neváhejte kontaktovat.

Zdroj: Azul