[Videó] The rocky road to Dublin, avagy egy nagybank kalandozásai a publikus felhő világában

Címkék

Egy nagybanki on-premise rendszer összehangolása a clouddal nem kis feladat, ennek tapasztalatairól szól a rövid előadás.

(Kollár László (OTP Bank) előadása a HWSW free! meetup-sorozat 2021. december 9-i cloudos tematikájú állomásán hangzott el.)

Hozzászólások

Van még egy roadblock, amit érdemes megemlíteni szerintem: kéne tudni angolul annyira, hogy ne érts félre dolgokat. Több fejtörést okozott ez nekem, mint a 2. helyen szereplő, "a fejlesztőnek magáévá kellene tennie a The Practice of Cloud System Administration könyv tartalmát". :-)

+1 ha te is csak az index kép miatt indítottad el a videót! :)

Ertekeltem volna, ha jobban kifejti, miert kell a cloudba menni. "Onnan jon az innovacio" - ezt nem ertem. Gyorsabban skalazodik? Ok. Ha penz nem szamit (ahogy mondja), akkor az on-prem kapacitas duplazasa sem lenne problema, nem?

Az on-prem kapacitást megduplázni ha ultragyors vagy is 6 nap. Egy OTP méretű cégnél jó esetben 6 hónap. A felhőben 6 perc. Az OTP ez alapján nagyjából 8640x gyorsabban tudja megduplázni a kapacitását a felhőben, mint az on-prem géptermeiben. Ez releváns gyorsulás.

Milyen szorzó?

Nem ismerem az OTP belső rendszereit, igényeiket - segített volna, ha az előadás mond példát.

Egyik oldalt (a földön, ahogy az előadó mondja), ott a klasszikus infrastruktúra, (állítólag) vertikálisan skálázható gépekkel. Egy adatbázis failoverrel, néhány frontend szerver, például. Egyszerű szoftver, egyszerű üzemeltetés.

Másik oldalon a cloud, gyors horizontális skálázódás, alapjaiban más szemléletű szoftver, más/bonyolultabb állapotkezelés (distributed consesus pl), load balancing stb., más képességeket igénylő üzemeltetés.

Azt el tudom képzelni, hogy a googlenek, twitternek, facebooknak, netflixnek miért van szüksége az utóbbira.
Nyilván fantáziátlan vagyok, de az OTP esetében nem tudom elképzelni, pláne, hogy meg vannak még szórva rengeteg szabályozással. Szóval tényleg érdekelne, hogy nekik ez hogy lesz jó. Egyik napról a másikra megduplázódik a netbank terhelése, és bővíteni kell? Hirtelen nyitnak még 50 bankfiókot, és bővíteni kell? Durván felpörög a hitelpiac, és olyan ütemben kell elbírálni, hogy bővíteni kell? Nem tudok ostobább példákat mondani, segítsetek.

Egyik napról a másikra megduplázódik a netbank terhelése, és bővíteni kell?

Ennek kicsi az esélye, de ennél kisebb mértékű szezonalitás simán lehet. Fizetésnap körül extra terhelés, éjjel minimális forgalom, reggelente többen kérnek számlatörténetet, vagy mittudomén. 

Ezért vetettem fel ellenérvként: év elején duplázzák az *eddig kihasznált* kapacitást (pénz ugye nem számít), és akkor biztos nem lesz gond 1 évig, ha 10%-t nő a load. Cserébe az összes szoftver, üzemeltetési tapasztalat marad.

Ha meg nem ilyen triviális a terhelés változása, akkor az talán megér néhány mondatot az előadásban, nem?

Ezt szépen ki kell számolni, hogy a konkrét esetben melyik konstrukció éri meg jobban – nem lesz rá általános igazság. Szerintem a netbank rövid távon jelentős szezonalitást mutat, lehet minden év elején a tavalyi csúcsterhelésre méretezni, de szerintem nem éri meg. Vagy lehet, hogy megéri, ezt majd az OTP eldönti. :)

pénz ugye nem számít

Én nem láttam a videót, de ezzel kapcsolatban kicsit szkeptikus vagyok :)

akkor az on-prem kapacitas duplazasa sem lenne problema, nem?

Cloudban egyfajta axioma, nem vertikálisan (feltételezve, hogy jelenleg ez a gyakorlat) , hanem horizontálisan skálázol, a hardver pedig egy utility -a devop-os fejlesztőknek-,  ahogyaz előadásban is elhangzik. Yaml fájlokkal hozod létre az erőforrásaidat, szerver, adatbázis, load balancer, fix ip , stb.

Árakról annyit, hogy csinálsz 3 clustert, legalapabb  computokból , hagyod, rá se nézel, csak úgy van, és a hónap végén kapsz egy kb.  100 $-os számlát. A végén még megérjük, hogy saját  on-prem cloud jön a divatba. És akkor senkinek nem lesz igaza...

A végén még megérjük, hogy saját  on-prem cloud jön a divatba.

Már most is ez az irány, de ez ott működik jól, ahol több különböző szolgáltatás vagy folyamat alá kell vas, és akkor az ezek közötti rugalmasságot jól kezeli a private cloud. Ha 1 db szolgáltatásom van, akkor a kapacitástervezést nem oldja meg (más szempontok miatt persze jó lehet).