Optimalizace nákladů a infrastruktury v cloudu – na co se musíte zaměřit ještě před migrací?

V článku se budu věnovat primárně prostředí Amazon Web Services (AWS) – přece jen jsem AWS architekt – ale většina zmíněných doporučení je lehce přenositelná i do Microsoft Azure nebo do Google Cloudu.

Článek je volným pokračováním mého předchozího textu, ve kterém jsem se optimalizaci nákladů v cloudu věnoval obecněji a popisoval její základní principy. Tentokrát půjdeme do většího detailu a zaměříme se na technické aspekty cloudové infrastruktury, a to právě z pohledu jejího architekta.

Z průzkumu State of the Cloud Report vyplývá, že bez ohledu na rozsah použití cloudu v organizaci je toto téma naprosto klíčové pro všechny. Ať už s cloudem začínají, nebo v něm už provozují mnoho aplikací.

Co nás čeká před migrací do cloudu

Cloud přináší obrovské množství služeb, kdy každá má svou specifickou cenotvorbu a charakteristiku. Na jedné straně tedy stojí velké příležitosti k optimalizaci, na té druhé mnohem větší nároky na architekty.

Při návrhu on-premise infrastruktury jsme standardně počítali procesory, velikost RAM a velikost disku. Někteří z nás možná rozeznávali i různé typy datových polí (storage postavený z SSD disků má přece jen jinou cenu než storage z disků magnetických).

V cloudu je však situace složitější a při návrhu potřebujeme znát mnohem více parametrů. Respektive nemusíme, ale v tom případě nebude infrastruktura optimální (jak technicky, tak nákladově). Na co bychom se tedy měli zaměřit?

Vyberte si ty správné servery

Většina z nás při návrhu infrastruktury v cloudu již nepočítá s variantou 1:1 se stávající infrastrukturou, přesto se u ní na chvíli zastavme.

Pokud v on-premise provozujeme server se 4 CPU a 16 GB RAM, tak to ještě neznamená (ale může!), že takový server potřebujeme i v cloudu. Vždy navrhujme takovou infrastrukturu, která odpovídá reálným výkonnostním požadavkům naší aplikace. Což samozřejmě znamená, že musíme stávající infrastrukturu monitorovat.

Následující obrázek ukazuje reálné vytížení jednoho databázového serveru (8 CPU):

Na první pohled vidíme, že server po většinu času „skoro nic nedělá“, ale občas se objeví nějaká drobná špička. Jak se k takovému vytížení postavit?

Konzervativní architekt by dospěl k závěru, že utilizace serveru je přes 50 % a snížení počtu CPU na polovinu (z 8 na 4) tedy není možné. To může být pravda.

Zaměřme se ale nyní na samotný procesor, na kterém tento virtuální server běží – v tomto případě Intel Xeon Gold 6148. Jaký je jeho reálný výkon v porovnání například s C7i instancí v AWS?

Aktuálně nejmodernější C7i compute-optimized instance běží na 8 488 Intel Xeon Platinum procesorech, které jsou v porovnání se starší generací procesorů mnohem výkonnější. Dá se tedy předpokládat, že snížení počtu procesorů z 8 na 4 nebude mít na výkon žádný dopad.

Zdroj: https://www.cpubenchmark.net/compare/5621.2vs3176.2/Intel-Xeon-Platinum-8488C-vs-Intel-Xeon-Gold-6148

Optimalizace nákladů před migrací s burstable instancemi

Cloudový architekt může vzít navíc v potaz i variantu burstable instancí, které krátkodobě nabízejí relativně vysoký výkon, nicméně tohoto „burstu“ nejsou schopny dosahovat kontinuálně. Pro dlouhodobé využití je obvykle nedoporučuji, ale může to být také zajímavá alternativa.

Následující tabulka ukazuje, jaká je maximální „baseline“ performance těchto instancí ve druhé polovině roku 2024:

Zdroj: https://aws.amazon.com/ec2/instance-types/t3/

Například instance t3a.2xlarge, která má 8 procesorů, může běžet konstantně na 40 % a jednou za čas na plný výkon. Jak by to vypadalo v tomto případě? AWS nabízí T3a burstable instance (běžící na AMD EPYC 7571), které jsou zhruba stejně výkonné jako Intel Xeon 6148.

Zdroj: https://www.cpubenchmark.net/compare/3543vs3176/AMD-EPYC-7571-vs-Intel-Xeon-Gold-6148

Co si z tohoto příkladu odnést? Že máme k dispozici několik možností, přičemž každá mé své klady, zápory a cenu:

• Můžeme sáhnout po výkonnější EC2 instanci a snížit počet CPU (což může mít u databázového serveru zásadní dopad na cenu licencí!).
• Můžeme zachovat stav 1:1 a vybrat nějakou „průměrnou“ EC2 instanci s 8 CPU.
• Můžeme použít (levnější) burstable instance, které nám pokryjí špičky.
• Můžeme případně oželet trochu výkonu výměnou za nejlepší cenu.

Scénář	Zachování stavu	Výkonnější instance	Burstable instance	Nižší výkon
Typ instance	m6a.2xlarge	m7i.xlarge	t3a.2xlarge	m7i.large
Počet CPU	8	4	8	2
Cena (PAYG)	302 USD	176 USD	252 USD	88 USD

Zdroj: https://calculator.aws/#/estimate?id=0f7a94f7d6de4bf81decae4d07213921986c0226

Počet CPU tedy není klíčovým faktorem. Při výběru správného serveru v EC2 zohledňujeme i další hlediska:

• Jak je můj server vytížený?
• Jaký procesor používám (resp. jaký mohu použít)?
• Potřebuji konstantní zátěž, nebo burstable?
• Pokud snížím výkon serveru, bude to mít nějaký vliv na samotnou aplikaci?
• Má počet CPU vliv na licencování aplikace či serveru?

Vyberte si ty správné disky

Vybrat si správný typ disku pro server může být podobně náročné jako vybrat samotný server. AWS má k dispozici šest typů disků o různých charakteristikách:

• generické SSD (gp2, gp3)
• výkonné SSD (io1, io2)
• tradiční HDD (st1, sc1)

Jak se disky liší a jaký dopad na cenu bude mít naše volba? Začněme s SSD disky:

Zdroj: https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html

Jak číst výše uvedenou tabulku? Pokud nevíte, co potřebujete, vyberte si standardní SSD disk typu gp3. Pokud to víte, pak tato sekce není pro vás 🙂

General purpose SSD disky

Disky typu gp3 nabízejí v porovnání s gp2 disky lepší výkonnostní charakteristiky. Zatímco u gp2 disků však potřebujete znát pouze velikost disku v GB, u gp3 musíte definovat i další parametry (resp. nemusíte, pokud vám dostačuje „základ“):

Nutno také podotknout, ze původní gp2 disky jsou typu burstable a neposkytují kontinuální výkon. Proto doporučuji gp2 disky nepoužívat a sáhnout raději po discích typu gp3.

Rozhodovat se pak můžete podle velikosti disku, která definuje, „jak dlouho“ budou disky poskytovat požadovaný IO výkon:

Zdroj: https://docs.aws.amazon.com/ebs/latest/userguide/general-purpose.html

Provissioned IOPS disky

Pokud potřebujete výkonný disk, pravděpodobně sáhnete po disku typu io1 či io2. Tentokrát už musíte explicitně definovat počet IOPS, který se projeví na ceně. IOPS se váže na velikost disku, přičemž vazba je následující:

• io1: 50 IOPS per GB
• io2: 1 000 IOPS per GB

Dvě technické poznámky:

• Disky typu io2 vytvořené před listopadem 2023 nejsou „block express“, a tudíž mají jiné limity. Pro povýšení stačí modifikovat nastavení.
• Extrémně velké nebo extrémně rychlé io1/2 disky se dají připojit jenom na určité typy instancí – pozor na to!

Ukázka charakteristik io2 disku:

Zdroj: https://docs.aws.amazon.com/ebs/latest/userguide/provisioned-iops.html

Výše uvedený graf ukazuje, že propustnost disku u malých bloků (16 KB) je lineární, kdežto u velkých bloků (256 KB) dosáhnete maximální propustnosti téměř okamžitě.

IO disky jsou tedy vhodné pro extrémně zatížené systémy, kde potřebujete opravdu rychlé úložiště bez jakéhokoliv kompromisu.

Magnetické disky

Na trhu jsou k dispozici dva druhy magnetických disků:

• st1 – takzvané throughput optimized disky – nabízejí kompromis mezi cenou a výkonem,
• sc1 jsou cold disky vhodné spíše pro archivaci dat a minimální přístup k nim (malý IO výkon i malý throughput).

V obou případech je výkon (throughput) opět „variabilní“ a závisí na velikosti disku.

Disk st1 má následující charakteristiku:

Zdroj: https://docs.aws.amazon.com/ebs/latest/userguide/hdd-vols.html

Charakteristika sc1 disku vypadá takto:

Zdroj: https://docs.aws.amazon.com/ebs/latest/userguide/hdd-vols.html

Jak tyto dva grafy číst? Disk typu st1 nabízí vyšší výkon než sc1, nicméně jeho cena je logicky vyšší.

Který disk si tedy vybrat?

Stručný návod může vypadat takto:

• Pokud si nejste jistí, použijte gp3.
• Když hledáte extra rychlý disk, vhodným kandidátem by měl být disk io1.
• Jestli potřebujete extrémně vysoké IOPS nebo extrémně vysoký poměr IOPS vs. volume size, použijte io2.
• Pokud zároveň potřebujete extra malý disk s velkým výkonem, velmi pravděpodobně sáhnete po io2.
• Chcete-li dlouhodobě skladovat velké množství dat, použijte sc1.
• Jestliže budete kontinuálně ukládat vetší množství dat a zároveň s nimi pracovat, vyberte si st1.
• Nepoužívejte disky gp2.

Ukázka ceny 1 000 GB disku se 3 000 IOPS:

Zdroj: https://calculator.aws/#/estimate?id=03f50922e338d20afa465411f6f2ccd4067944f4

Vyberte si správné služby

Tato oblast rozhodování je aktuálně asi nejkomplikovanější a vydala by na samostatný workshop. Může při ní navíc docházet k rearchitektuře samotné aplikace, což celou změnu dále prodraží.

Příklad 1

Pojďme se podívat na hypotetický příklad z oblasti uchovávání dat:

• Představte si, že provozujete aplikaci typu Document Management System, která uchovává 10 TB dat.
• Aplikaci každodenně používá 100 uživatelů.
• Každý uživatel průměrně vytvoří pět nových dokumentů a pracuje s 20 existujícími dokumenty.
• S majoritou dokumentů se nepracuje (90 % dokumentů je pouze archivováno).

Kam data uložit?

První, co nás napadne, bude standardní disk typu gp3 o velikosti 10 TB. Toto řešení ale nebude ideální z pohledu vysoké dostupnosti, protože s diskem může pracovat pouze jedna EC2 instance. Pokud by bylo potřeba pracovat s daty z více instancí, musíme použít nějaký sdílený file system, v tomto případě například standardní Elastic File System (EFS). Nebo můžeme zvolit objektový storage Simple Storage Service (S3).

Kolik by nás uvedené varianty stály? Pro kalkulaci uvažuji identické požadavky na throughput v případě EBS a EFS (tedy125 MBps):

Scénář	EBS	EFS	S3
Cena	974 USD	1 145 USD	252 USD
Poznámka	Problematická vysoká dostupnost	10 % dat je aktivně využíváno	Cena nejen za GB, ale i API operace

Zdroj: https://calculator.aws/#/estimate?id=958f3d773dfa31f0ea5c260d9f78384e734096dd

Zde jasně vidíme, že cena za uložení a práci s tímto objemem dat může být až 6× vyšší (EFS vs. S3).

Příklad 2

Druhý příklad odpovídá reálnému scénáři z projektu, který aktuálně v ORBITu řešíme. Demonstruje totiž (aniž bych zacházel do detailů) obrovský vliv scénáře na cenu – a v tomto konkrétním případě také na čas zpracování.

Náš scénář je takový, že potřebujme zpracovat zhruba 1 milion záznamů. Zpracování jednoho záznamu (o velikosti několika kb) si vyžádá asi 10 sekund strojového času (vyšší výkon nepřinese zrychlení, ani není možné nějak rozumně paralelizovat).

Diskutovali jsme tři varianty:

1. Použijeme standardní EC2 a python script uvnitř instance, který zpracuje požadované záznamy (bez paralelizace).
2. Použijeme standardní EC2 a python script uvnitř instance, který zpracuje požadované záznamy, a současně zkusíme vymyslet, jak proces paralelizovat.
3. Použijeme cloud-native technologie, v tomto případě masivně paralelizované lambda funkce.

Závěry byly zhruba následující:

Scénář	EC2 bez paralelizace	EC2 a paralelizace	cloud-native
Cena infrastruktury	± 35 USD	±125 USD	± 14 USD
Infrastruktura	1 CPU (t3a.micro)	8 CPU (t3a.2xlarge)	lambda funkce
Běh „úkolu“	115 dnů	14 dnů	3 hodiny
Cena paralelizace	0 MDs	1 MD = 10 000 CZK	0 MDs

• Když nebudeme paralelizovat běh v EC2, stačí nám minimálně velký (a levný) server, ale zpracování dat poběží extrémně dlouho.
• Jestliže paralelizovat budeme, vynaložíme náklady na přípravu paralelizace, osminásobně zkrátíme zpracování dat, ale cena bude trojnásobná.
• Pokud použijeme cloud-native přístup, cena bude minimální a čas zpracování extrémně krátký.

Zdroj: https://calculator.aws/#/estimate?id=42255e5155377257b4a3cd164f61e3063f674ec0

Jak tedy vypadala výsledná architektura?

• Data ke zpracování jsou uložena v DynamoDB (1 milion záznamů).
• Na základě DynamoDB Streams je ID záznamů vloženo pomocí lambda funkce do Simple Queue Service.
• Simple Queue Service je navázána na další lambda funkci (1 000 simultánně běžících).
• Výstupy ze zpracování jsou opět uloženy do DynamoDB.

Co si z tohoto příkladu odnést? Že komplexní změna architektury může přinést extrémní hodnotu – ať už z pohledu ceny infrastruktury nebo z pohledu rychlosti zpracování.

Optimalizace nákladů a infrastruktury zkrátka začíná už před migrací

Jak říká náš CEO Lukáš Klášterský: „Cloud je tak trochu jiné zvíře.“ A platí to i v tomto případě.

Už samotný návrh správné cloudové infrastruktury může být oříškem. Pokud si jím nejste jistí nebo byste rádi probrali některé jeho specifické aspekty (a že jich je!), neváhejte se mi ozvat.

A na co se můžete těšit příště? Podíváme se na to, jak optimalizovat náklady a infrastrukturu po migraci do cloudu, především se zaměříme na:

• nové služby a jejich vliv na cenu,
• optimalizace architektury aplikace,
• kontinuální revizi architektury.