AWS költségoptimalizálás a gyakorlatban

Pár kiegészítés, ha már végignéztem:

• A t3 vs. t3a vs. t4g (illetve Intel vs. AMD vs. Graviton) téma nem ennyire egyértelmű. A tapasztalataim alapján workloadja válogatja, hogy melyikből jön ki olcsóbban ugyanaz a throughput vagy az elvárt latency. Ez igaz mind a computing (EC2, EKS), mind az adatábzis (RDS) részekre. Mérni kell, nem érdemes anélkül választani.
• A -200% TCO az azt jelenti, hogy amennyit fizettem eddig az AWS-nek, most már ők fizetnek annyit nekem? :-D
• Az ElastiCache/Redis sem ennyire tiszta dolog. A tömörítés spórol a cache oldali memóriaigényen és használt a sávszélességen - cserébe kliens oldalon több CPU kell a betömörítés/kitömörítés miatt, plusz növekszik a latency legalább annyival, amennyi a kitömörítéshez kell. Nem mondom, hogy nem jó az ötlet, általában megéri a tradeoff (különösen ha pl. a kliens ténylegesen a customer gépe, és nem valami szerver az AWS-ben :D), de ez is inkább mérendő dolog.
• Ezek alapján az "A tesztelés is segíthet, de a józan paraszti ész fontosabb" mondást én elengedném, szerintem a mérés sokkal-sokkal fontosabb, mint amit a prezentáció hangsúlyoz.

Saját sztori az elmúlt hetekből, hogy egy közepes loggyűjtő Elasticsearch cluster (az elmúlt 3 évre ~90 TB adat) méretezését sikerült 3+18 node-ról (master+hot) redukálni 3+3+5 (master+hot+warm) node-ra. A szükséges lépések:

• mérés, hogy milyen régi adatokhoz milyen gyakori a hozzáférés
  • kijött, hogy 3 hónapig tök aktív a hozzáférés, 6 hónapig picit aktív a hozzáférés, 6 hónapnál régebbi adathoz lényegében nincs hozzáférés csak tévedésből
  • adódik ebből a tiering - 0-3 hónap hot, 3-6 hónap warm, 6+ hónap cold
  • (itt szándékosan nem az Elasticsearch cold tier, hanem egy S3 backup repository lett kiválasztva, nem-techikai, hanem politikai okokból)
• reindexing az adatok egy részére, mert nem havi indexekben, illetve nem megfelelő számú primary sharddal voltak tárolva (a túl nagy shardokba olykor beletörik az ultrawarm migrációs bicska)
• pár nap várás, mire végzett a cluster a reindexinggel...
• archiválás az S3 backup repository-ba
• pár nap várás, mire végzett a cluster a backupokkal...
• index state management beállítása, hogy automatikus legyen a tier-ek közötti mozgatás ezek után
• pár nap várás, mire végzett a cluster a migrációkkal...
• felesleges node-ok eltávolítása a clusterből
• pár új monitor/alarm beállítása a tiered storage-nak megfelelő módosításokkal
• "nézzünk rá nyár végén, meg beszéljük már rá az ügyfelet, hogy cold tier legyen, ne backup repository, ne kelljen se kézzel archiválni, se Curatorral bohóckodni" értesítés felírása az értesítések közé

Az eredmény napi ~370 dollár spórolás a computing és a storage részeken összesen, az effektíve belerakott munka ~2 nap (bár az átfutási idő hetekben mérhető volt a sok várás miatt).

kezdjuk azzal, hogy te egy ertelmes krapek vagy, egyszer szivesen diskuralnek veled, vagy szivesen elhivnank akar eloadni is valamikor. :) megtenned h irsz egy privatot, hogy meglegyen a neved es a telefonod.

a fenti feedbackre. igen, ketsegtelen, hogy ez azert nem egy osztonos dolog, az egesz folott levo meres, monitoring, transzparencia nelkul ez igy max kicsiben mukodik. nagyjabol az egesz finops evolicio is valami iyen volt, voltak a Péterhez hasonló arcok, aki teljesen devops oldalrol osztonosen kozelitettek meg. es ez tok jo is. de ezen mara jocskan tulmutat a dolog. betoltak az egeszet a linux found ala, ezeket a devopsos tapasztalatokat, praktikakat pedig egy valamifele egyseges keretbe raktak, ami mar a meresi es szervezeti dolgokat is kezeli, illetve a cloudra jellemzo allando valtozast. tulajdonkeppen amit itt Peter bemutat, azok a modszertan osztonos gyokerei, de innen meg van tovabb is.