Drága AWS ...

A rendszer nagyobbik része AWS-en fut így ezzel folyattuk a vizsgálatot  a korábbi kérés alapján: Lásd itt...

Mivel nemrég kellett a reidst használnom, így gondoltam megnézem mi a helyzet vele. Itt meg is jegyezném hogy nem vagyok DevOps, erre van külön emberünk. 
Itt egyből látszott, hogy van Valkeyre is lehetőség és kiderült, hogy amúgy sincs kihasználva a redis szerver. Valkey egy opensource redis kompatibilis megoldás amit a redis licencváltása hívott életre. Mivel korábbi projekten volt tapasztalatom a Redis -> Valkey váltással kapcsolatban (fájdalommentes volt), így ezt is megléptük. Jelenleg feleannyiba kerül az üzemeltetés.

Megvizsgáltuk a nagy FineOps keretében, hogy végül nincs szükségünk Multi-AZ RDS-re nem kritikus a működésünk, nem is volt leállás. Update miatti leállás se zavaró még.

Fontos megjegyezni, hogy sok lehetőség van abban is milyen fizetési opciót választunk. Nagyon nem mindegy hogy On-Demand, vagy Savings Planst használunk.

Tesztkörnyezettel is lehet spórolni, ha a tesztszervert például hétvégenként és este leálltjuk.

( khiraly | 2025. 05. 23., p – 13:01 )

Irhatnal a havi/eves penzugyi keretrol aranyosan leosztva, hogy ne legyen szivarogtatas.

Pl. 1000 petak van havonta, ebbol 800-at koltottunk, 400 aws, 200 sajat hardware uzemeltetes (+ ber), 100 sajat hardware vasarlas, stb, stb.

 

Csak, hogy el lehessen kepzelni.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( gelei v | 2025. 05. 23., p – 13:02 )

Megvizsgáltuk a nagy FineOps keretében, hogy végül nincs szükségünk Multi-AZ RDS-re nem kritikus a működésünk

Ez az availability zone, meg georedundancia meg társai amúgy is elég félreértett dolog. Tök jó, bekattintod a checkboxot, hogy innentől read-access multiregion replikációt akarsz. És? Az alkalmazás felkészült arra, hogy ha az elsődleges régió kiesik, akkor csak olvasni tudja a blobokat? Vagy még jobb, fogja tudni, hogy milyen endpointon keresse az olvasható replikát? Vaaagy tud kezdeni valamit azzal a helyzettel, hogy a replika még nincs szinkronban?

Itt sincs silver bullet.

Nagyon nem mindegy hogy On-Demand, vagy Savings Planst használunk.

+10000000

Azure-ben 50-60% discountot össze lehet szedni spend commitmenttel (tehát még csak nem is a konkrét workload/SKU-ra kell ígéretet tenni, csak hogy ennyit és ennyit elköltesz majd náluk), az utcáról beesve, egyéni feltételek nélkül.

>  fogja tudni, hogy milyen endpointon keresse az olvasható replikát?

Én úgy láttam a R/O replika endpointja fix, tehát ha van konfig opció rá, akkor azt nem AWS API-ból kell kitalálni, az RDS életciklusa során nem változik. Rosszul láttam?

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( kubi | 2025. 05. 23., p – 15:27 )

SW architekteknek fel kell keszulni hasonlo feladatokra mar a tervezes folyaman is. Eleg sokfele parameterre lehet, es kell is egyre inkabb optimaliani a szoftvert.

Par eve, mikor HW+SW platformot fejlesztettunk, eleg szigoru KPI-ok voltak a releasenkenti memoria es processzor hasznalat valtozasara. Georednel meg a ket oldal kozti savszelessegigenyre (men termett akkor sem a bokorban a nagy rendelkezesreallasu Gbps berelt vonal).

> eleg szigoru KPI-ok voltak a releasenkenti memoria es processzor hasznalat valtozasara.

Irigyellek titeket. Nálunk konkrétan azt vadászni kell, hogy mennyi a tényleges igénye 1-1 cuccnak, mert hogy mi megy ki az ügyfélnek, az egy dolog, de nekem a belső tesztkörnyezetet is üzemeltetnem kell valahogyan. Meglepően sok olyan ember van a fejlesztők között, akik lélekben pingvinek, és ilyen kérdéskenél előjön a valódi énjük.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-