Optimalizace nákladů a infrastruktury v AWS prostředí – jak optimalizovat náklady provozovaných aplikací?

Rightsizing aneb využívám opravdu to, co potřebuji?

Rightsizing je téma, o kterém se stále mluví. Je jedním z prvních ve kterémkoliv článku o optimalizaci nákladů v cloudu a tento text nebude výjimkou. Musíme se totiž ptát: odpovídá vaše infrastruktura (resp. její konfigurace) reálnému vytížení?

Základem je monitoring využití infrastruktury. V AWS máme naštěstí nástroj umožňující detailní sledování: AWS CloudWatch.

Optimalizace instancí

Pro detailní monitoring EC2 instancí (virtuálních serverů) je vhodné použít i CloudWatch agent, abychom byli schopni sbírat také detailní metriky ze samotného operačního systému. Z pohledu rightsizingu nás totiž zajímá především využitá paměť (monitoring CPU je možný i bez použití CloudWatch agenta). Pojďme se podívat ne jednu konkrétní EC2 instanci, jejíž aktuální sizing je r7i.8xlarge, tedy 16 CPU a 128 GB RAM. Víme, že tato instance opravdu potřebuje 128 GB RAM, to je fakt. Ale z pohledu CPU tato instance „nic nedělá”.

Co se s takovým serverem dá dělat? V tomto konkrétním případě toho mnoho není (především kvůli vysokým požadavkům na paměť), ale i tak se najde možná úspora. Obecně sice nedoporučuji využívat starší řady instancí, ale v tomto konkrétním případě nám to vadit nebude. Podívejme se na řadu R6a, která má oproti novější R7i o něco pomalejší frekvenci a je v ní použito AMD: protože CPU v tomto případě ale de facto „nic nedělá“, nebude to na škodu.

Instance	CPU	Memory	Network (Gbps)	EBS (Gbps)	Price (PAYG, monthly)
r7i.4xlarge	16	128	Up to 12.5	Up to 10	932 USD
r6a.4xlarge	16	128	Up to 12.5	Up to 10	798 USD

Z tabulky vyplývá, že tato drobná změna přináší úspory cca 15 %. Není to mnoho. Na druhou stranu ušetřit 140 USD měsíčně bez dopadu na výkon serveru není špatné.

Ve vašem prostředí narazíte určitě na instance s ještě větším prostorem pro optimalizaci.

Optimalizace disků

Druhou oblastí rightsizingu je optimalizace disků, především EBS volumes. O vhodnosti migrace na nejnovější typy disků, tedy například o migraci z gp2 na gp3 (typická úspora cca 10 %), jsme už psali. Dnes se navíc podíváme na další charakteristiky a jejich dopad na cenu.

Jak známo, u většiny typů disků je možné nezávisle konfigurovat throughput a IOPS. Pojďme se opět podívat na příklad.

Disk o velikosti 2 700 GB s konfigurovanou propustností 1 000 GBps a 16 000 IOPS (maximum pro disky typu gp3) má reálné vytížení takové, že i výchozí konfigurace (125 Mbps Throughput a 3 000 IOPS) bohatě převyšuje požadavky systému.

Jaký je finanční dopad případné změny konfigurace? Rozdíl činí více něž 32 % – v absolutním čísle cca 119 USD měsíčně.

Zdroj: AWS Pricing Calculator

Costs Optimization Hub

Manuálně monitorovat jednotlivé EC2 a EBS volumes může být ve větších prostředích značně časově náročné. Představte si desítky EC2 serverů a například stovky EBS volumes.

Naštěstí máme (zcela zdarma) k dispozici Costs Optimization Hub, který za nás odvede veškerou práci.

Cost Optimization Hub naleznete v sekci Billing and Costs Management. Nezapomínejte na tento nástroj! Přináší řadu jednoduchých doporučení, jak nákladově optimalizovat vaši infrastrukturu – včetně detailních doporučení, jak optimalizaci provést.

Ach ty licence

Náklady na licence často převyšují náklady na samotnou infrastrukturu. Typickým příkladem je Microsoft SQL Server nebo Oracle Database: cena infrastruktury představuje pouze zlomek celkové ceny, zbytek ceny je cena samotné licence.

Rightsizing podruhé

V prvním kroku se vždy zaměřte na rightsizing. Změna počtu CPU u RDS databáze má dramatický dopad na cenu, protože CPU definuje cenu licencí. CloudWatch vám bude opět dobrým pomocníkem.

Na obrázku vidíme, že aktuální vytížení RDS databáze je ve špičkách maximálně 30 % (při konfiguraci 8 CPU a 32 GB RAM). Pokud bychom upravili instanci na 4 CPU a 32 GB RAM, dopad do ceny by byl 39 % – v absolutním čísle poté 1492 USD měsíčně!

Zdroj: AWS Pricing Calculator

Self-managed databáze provozované v rámci EC2 instancí

Druhou oblastí úspor v případě licencí jsou self-managed databáze provozované v rámci EC2 instancí. Obecně doporučujeme využít PaaS RDS databáze, ale za určitých okolností může být (cenově) vhodné využit stávající licence pro databázové servery a přenést je do prostředí AWS.

Klíčovou oblastí je dobré pochopení licenčních možností v prostředí AWS a vnímání rozdílu mezi sdíleným a dedikovaným hardware.

Zdroj: AWS Microsoft Workloads on AWS Cost Optimization

Využití dedicated hosts je klíčové v případě optimalizace Microsoft SQL Server licencí. Pojďme se podívat na příklad provozu několika instancí v režimu shared instance versus dedicated host.

Zde je opět klíčové chápat licencování Microsoft SQL Serveru. V případě fyzického serveru se licencují fyzické procesory, v případě virtualizovaného prostředí se licencují virtuální procesory.

V této konkrétní situaci tedy srovnáváme 48 fyzických CPU Cores (v případě dedicated hosts) a 96 virtuálních CPU Cores (v případě shared tenancy modelu).

Konsolidace MSSQL databází

Představte si, že provozujete větší množství dedikovaných databází pro jednotlivé aplikace. Licencujete vždy alespoň čtyři SQL Core licence, přestože nepotřebujete ani zdaleka takový procesorový výkon. Ale licenční ujednání hovoří jasně – čtyři licence jsou vždy minimum.

Místo provozu několika menších SQL serverů můžete provozovat jeden či více větších. Samozřejmě, konsolidace má vliv na operační model. Ve většině společností jsou však databázová prostředí provozována dedikovaným týmem, pro který je irelevantní, jestli se jedná o dedikované databáze nebo sdílené prostředí.

Zdroj: AWS Microsoft Workloads on AWS Cost Optimization

Jak vidíte, v oblasti licencování Microsoft produktů je obrovský potenciál pro úsporu. Pochopení veškerých nuancí licenčních ujednání a detailních možností konfigurace v prostředí AWS nicméně může být trochu komplikované.

A nešlo by aplikace optimalizovat jednodušeji?

Naštěstí ano. Je tu totiž AWS Optimization and Licensing Assessment. Tento assessment se zaměřuje právě na optimalizaci infrastruktury a licencí pro následující prostředí:

• Microsoft SQL Server and Windows Server on Amazon EC2
• VMware-based workloads to AWS
• Oracle Database and Oracle business applications

Zdroj: https://aws.amazon.com/optimization-and-licensing-assessment/

Tento typ assessmentu provádí AWS Partner, nikoliv sám zákazník. A díky tomu, že ORBIT úspěšně prošel validací AWS a držíme Service Delivery Designation for Amazon EC2 for Windows Server, můžeme tento assessment realizovat přímo s námi!

Na co dalšího při optimalizaci aplikací nezapomínat?

Téma optimalizace infrastruktury by vydalo na samostatnou knihu. Ale tolik prostoru bohužel nemáme. Rád bych v rychlosti, bez hlubšího detailu, bodově zmínil ještě několik oblastí, na které doporučuji se podívat:

• Elastic Block Storage

Podívejte se, jestli náhodou nemáte ve vašem prostředí unattached volumes – tedy disky, které někdy někdo vytvořil, ale nejsou připojeny k žádnému serveru a je možné je odstranit.

• CloudWatch Logs

Logovat do CloudWatch je ideální. Je to jednoduché, bezproblémové a s minimem konfigurace. Ale v případě větších objemů dat může cena za zpracování logů prudce narůstat. Například v případě, že někdo zapomene vypnout Debug režim své aplikace, který generuje stovky či tisíce irelevantních záznamů za sekundu. Viděl jsem situace, kdy díky této nepozornosti stál log monitoring tisíce dolarů.

• Elastic File System

Při vyšších objemech dat může být cenově značně nákladný. Určitě nezapomeňte na EFS lifecycle a případné odkládání starých souborů na archivní storage.

• Network transfer

Každý přenesený GB dat se počítá. A platí. Zaměřte se na cross-region a cross-zone síťové přenosy. Například provozujete jednu EC2 v AZ1 a druhou EC2 v AZ2. Komunikace mezi nimi je zpoplatněna.

Kolik nákladů ušetří optimalizace aplikací vám?

Doufám, že vám tento díl encyklopedie pomůže k optimalizaci nákladů vámi provozované infrastruktury. Ať již provozujete tradiční aplikace využívající EC2 instance, PaaS RDS databáze nebo cloud native aplikace, prostor pro optimalizaci je vždy.

Optimalizace infrastruktury je totiž kontinuální proces, který byste měli provádět neustále.

V ideálním případě (ve větších prostředí je to spíše nutnost) je dobré stanovit formální pozici, která tuto aktivitu zasíťuje. Odpovědná osoba bude mít na starost provádění revizí infrastruktury, repoting nákladů a bude na technické týmy delegovat samotnou technickou realizaci. Naše zkušenost říká, že kolektivní odpovědnost nikdy nefunguje. Pokud máte zájem, rádi se s vámi setkáme a probereme konkrétní možnosti a kroky vedoucí k úspoře nákladů vašeho AWS prostředí.