Webinář: Prediktibilita v cloudu

00:00:00
Dobrý den, já jsem Marek Arneker, pracuji jako produktový manažer cloudových služeb v Českých radiokomunikacích. ČRáčka jsme tu v podstatě jako zástupci ne Public Cloudu, ne SelvoSys řešení nebo podobných jiných, ale jsme tady jako zástupci virtuálně privátních řešení, na kterých stavíme. Stavíme je standardně na VMwareu a děláme dneska kubernety, infrastrukturu, platformu a další věci okolo toho. A to, co jsem si vybral za téma, připadá mi dneska jako důležitý, tak je prediktibilita nákladů v cloudu nebo obecně v cloudových moderních řešeních, protože současně s rostoucím tématem Kubernetes a vysoké distribuovanosti a škálovatelnosti, tak ta prediktibilita toho, kolik vás to finálně bude stát, seví jako mnohem důležitější než třeba dřív. Byť to téma je tady v podstatě asi v každé přednášce zmíněný. Tak hned první část. Tady tu pyramidu věřím, že všichni znáte. To je taková ta pyramida ideálního cloudu. od spoda infrastruktura, platforma, software a tahle ta pyramida říká, že pokud se snažíme v jakýkoliv z těch levlů, v jakýkoliv z těch vrstev postavit cloud, tak vlastně předpokládáme, že všechny ty vrstvy pod ní se chovají taky cloudově. Takže pokud se to podstavit software, který je škálovatelný a který platíte podle spotřeby nebo je 24-7 dostupný a to je jako standardní pravidla cloudu, tak z principu předpokládáte, že ho provozujete na platformě, která má úplně stejné vlastnosti, protože jakmile vám někde ta vlastnost chybí, tak ji musíte suplovat. Titulky vytvořil JohnyX musíme je držet. Máme nějaký měsíční čtvrtletní roční cyklus a další věci. Věřím, že to je téma i pro vás, že to není jenom téma naše, to je běžný téma. Potřebujeme vědět, jestli je dodržíme nebo jestli je nedodržíme. Ve skutečnosti nejsme ochotní měnit tu cenu tak rychle, jak bychom chtěli. Ta realita vlastně toho, jak se ohybá ta infrastrukturní služba, kolik nás stojí, ta se samozřejmě v průběhu času mění. A já bych potřeboval těm kolegům v IoT říct, hele, včera to stálo fungoval billing a tady těm zajištěm, aby jim fungoval mail a tady těm támhleto, ale úplně stejně tak, i přesto, že mají nějaké interní přeúčtování a vědí, kolik je stojí jeden zaměstnanec, nebo vědí, kolik je stojí vytisknout fakturu, nebo provozovat ten systém a podobné věci, tak nedělají tu revizi nákladů tak rychle, jak by to ta situace vlastně v tu chvíli vyžadovala. Takže děláme nějaké odhady, nějaké predikce a podobné věci stavíme na nějakých statistických modelech. Ty horší schémata, který jsem tady vypsal, je, že v produkt, to, co vy provozujete, ať už jste jako IT oddělení, nebo jste firma, která má nějaký produkt, který má faktickýho zákazníka, vnějšího a tak dál, tak nemá realistickou vazbu na to, co to vaše IT dělá. Takže velmi často je scénář, že? Jasně, my jsme IT manažeři a z principu dostáváme nějaký budget na to, aby jsme provozovali to naše IT, ale reálně vyrábíme auta. Chcem si trochu vymyslet, tam jsme nebyli, ale reálně vyrábíme klimatizace do aut. Tam jsme byli. A kolik vyrobíme klimatizací do aut versus kolik nás stojí naše A když se podíváte na to všechno, co tady teď říkal třeba Vojta, ale myslím si, že jsem to slyšel i od kolegy z F5, tak dneska jsou v podstatě dva modely, se kterými se můžete setkat. Určitě je znáte. Jakmile se tady zmíní AWS, zmíní se tu Azure, jakýkoliv hyperscaler, tak se setkáte s oběmi těmito modely. Prostě oba tam jsou. A jakmile jste spíš v lokální sféře, budete se dívat třeba právě na ČRáčka nebo na někoho tady v Čechách, a za tu platím 1000 dolarů měsíčně. A jestli jste přenesli giga, nebo ne přenesli giga, je úplně jedno. Jestli jste přes to přenesli dvě peta, nebo jste přes to přenesli nula, tak je taky úplně jedno. Platíte za to, že tu službu máte a máte ji v čase. Tyhle dva zásadní modely, jak asi vnímáte, pokud znáte toto amazoní vyučtování, tamhle obrázek přichází vyučtování, tak v něm to můžete vidět obojí současně. Typický scénář je, vy si objednáte VPS, VPS, VDS, Za to VPSko za hodinu zaplatíte, teď si jako plácnu, 1,50 dolar. Vedle toho za to, kolik jste udělali IOPSů, nebo kolik jste udělali dotazů do DNSka, nebo dotazů na SQLko, nebo já nevím co všechno, na S3ku, get, post, že jo, to ještě škáluje podle toho, jakýho jsou typu, tak zaplatíte v tom event-oriented modelu. Tohle je jako důležitý point. To, co je možná fér říct, je, že, a už to tady taky zaznělo, v tom ideálním světě, v tom event-oriented modelu, neexistuje limit, kromě vašeho budžetu. To není pravda. My víme, že ten technický limit existuje. Vojta to zrovna před chvílí zmiňoval, on se většinou objeví v momentě, kdy ho nejméně očekáváte, ale existuje. Zatímco v tom service-oriented modelu, tak tam existuje limit, vy ho znáte, je v definici té služby a znamená to, že v momentě, kdy ji narazíte, Tak, a já se posunu dál. Tohleto je jedna z mých, řekl bych, zajímavých zkušeností s jedním z hyperscalerů. To je roční přehled pladeb, tak, jak jsem je skutečně měl. Já jsem tam schválně neuváděl rok, on už je to pár let zpátky, ale já se týčím roka 2018, tak jo. Můžete tam vidět jako schéma toho, kolik jsem platil. Platil jsem nějaké 40 dolarů maximu. Každý měsíc se to lišilo. Reálně jsem na tom provozoval nějaké osobní služby a nějaké služby pro kamarády, Tady jsem rozklíčoval ty náklady na to, které jsou vlastně v tom modelu event-oriented a které jsou v tom service-oriented. A ten výsledek, ten vypadá zajímavě v tom duchu, že kdybyste to vzali jako nějakou prostou matematikou, tak ten průměr je 33% event-oriented. To jsou náklady, které, když já jsem začínal tady s tou akcí, jako ve smyslu tohle to budu provozovat, budu tady mít 10 webových stránek, nějakých svých kamarádů a tak dále, Nemám vůbec šajna. Jako opravdu vůbec. By the way, je to dva miliony. Dneska to vím, protože jsem to vyčetl v toho vyučtování. Ale absolutně netuším, jestli v momentě, kdy přijmu dvakrát tolik e-mailů, tak jestli budou tři miliony. A nebo pět. A nebo jestli to bylo řízené na všemnosti nebo na těch webových stránkách. Tohle je jednostě k zákoutí toho, že vy vlastně, i přesto, že máte pocit, že ten produkt, ten finální produkt, který chcete poskytovat, ve smyslu já poskytuji webovou stránku, nebo mail, nebo nějakou podobnou jinou službu Naopak těch 66% nákladů, který jsem tady jako vyčíslil, tak ty jsem věděl dopředu. To byly náklady, o kterých jsem se vědomě rozhodl, že jsem řekl, OK, já budu mít tenhle server, bude to tahle kapacita, tahle rychlost, tolik CPU, RAM, bla, bla, bla, a pojedu o 24.7. Takže jsem to věděl. Mohl jsem ho někdy vypnout a ušetřit, anebo někdy prostě jako třeba nějak zvětšit, nebo si třeba přidat ještě další a bylo by to super. Ale byly to opravdu náklady, o kterých jsem se naprosto vědomě rozhodl. Tak to je pro před Já se mrknu ještě na to, jaký vlastně vy máte možnosti, když tady mluvím o těch 33%, jaký vy máte možnosti je zalimitovat. Oni ty možnosti jsou. Zase budu tady opakovat něco, co už tady padlo, což je zvláštní, ale zkusíme rozebrat, co se vlastně stane. Všichni ty hyperscalery, minimálně všichni ty velcí hyperscalery, tak vám nabízí, abyste zalimitovali všechny ty event-oriented pricing modely. Takže můžete říct, jasně, To je super scénář, to vám ušetří spoustu peněz a předpokladu, že nějaký moment předpokládáte, že tuto částku, respektive to množství překonáte, ale problém je, že vy v tu chvíli ty služby zastavíte. Všechny ty event modely, které jsou postavené, tak jsou postavené na tom, co je pro vás kruciální. V podstatě ty hyperskillery by byly reálně, nevím, jestli to není nějaký zástupce někoho z hyperskillerů, ale byly by hloupý, kdyby to dělali jinak. V momentě, kdy vy řeknete OK, tak já teda obslužím těch prvních 10 milionů a Teď mám čerstvou zkušenost, se o ní chci podělit, je to taková jako rychlá vsuvka. Nedávno mi z Road 50, respektive nedávno mi A, dobře. Nedávno mi volal Bráška, že mu nefunguje mail. Ukázalo se, že já mám v AWSku zaregistrovanou kreditní kartu, kterou se s rámi mezi ním vypršela. Bylo to super. ale A to vedlo k tomu, že u Google jsem nezaplatil Gmail, což vedlo k tomu, že na to AVSko, na to Route 53, kde mám doménu a DNSka k té doméně, tak se zvětšil trafik na to DNSko asi tě desetinásobě. Během těch 15 minut všechny ty systémy, které se snažily nám doručit mail, ale ten je odmítal, protože jsem ho nezaplatil, tak to zkoušeli znova a znova a znova. Kdybych to nechal být, tak by to mohla být poměrně zajímavá cena a množství těch requestů se zvýšilo přibližně desetinásobě. Tak to jen tak jako stranu. Takže limitace v event-oriented modelu je Pito má v tom, že Teď se tím prostě zastavíte. Takže se pro vás stává něco jako mnohem podstatnějšího, zajímavým a to rozlišit, který event je ten dobrý, který chcete odbavit a který je ten špatný, který odbavit nechcete. A tady už se potom můžeme bavit o těch F5 a podobných jiných systémech, které tady už jako přede mnou prezentovali. Nápad v tom series oriented modelu, tam máte těch přílitostí potenciálně asi Asi víc. Vy si můžete zvolit nějakou strategii. Vy si můžete zvolit strategii ve stylu OK, tak já teda budu pracovat s tím, že všechny neodbavím a budu počítat s tím, že mám nějaké píky a v tu chvíli třeba zavřu. Asi to není dobrá strategie třeba pro e-shop, který by v tu chvíli přicházel o velké množství peněz, ale v případě třeba jiného projektu, na kterém se podívíme, což je fotbalovej klub, tak v momentě, kdy je příliš velká návštěvnost jejich bojových stránek, protože zrovna vyhodili trenéra, naj tisíc megavů, protože vám stačí. To je ostatně jako jedna ze strategií, kterou si potom můžete zvolit, že řeknete OK, tak já to zvládnu, protože vím, kdy mi ten pík přichází a na tuhle dobu si vezmu další čtyři servery, nebo rychlejší linku, nebo víc paměti, nebo nevím, něco si vymyslete, co je pro vás zajímavé. Tohle je nějaký jako mezistav, jako záměr, vlastně poměrně zajímavý mezistav. Když se na to podíváme trošku statisticky. Tohle jsou dva grafy, dva různý setupy, který každý míří k něčemu úplně jinému. Já myslím, že to je na první pole zřetelné. Ten vlevo pro vás, tak je setup, který míří k vysoký míře škálování v krátkém čase. Když se podíváte na ty průměry, které jsem tam dole vepsal, tak ty grafy jsou schválně připravené tak, aby měly stejný průměr. Jsou to samozřejmě virtuální jednotky výkonu a v čase. Osim jsem nepopsal, moje chyba, pardon. Vráceně OSY. je čas a osa x je virtuální jednotka výkonu. To říkám dobře, už jsem to zapomněl, mám to ze školy. Prostě ta dole je čas a ta nahoru. Děkuju. Ta nahoru je výkon. To, co se stane vlevo, to jsou scénáře, kterými třeba zažíváme přesně u toho fotbalového klubu. Fotbalový klub si vymyslel, že bude posílat notifikace svým klientům, respektive svým fanouškům, to jsou ty lidé. A v momenti, kdy tohle se to provede, tak oni ve velmi krátkém čase, typu jako jedna, dvě, tři minuty, tak vygenerují obrovské množství návštěvnosti a následně ta návštěvnost zase veškerá zmizí. Ten obsah obecně není zájem dlouho, jako trvalé. Naopak ten graf pravo, tak to je typický graf, který byste mohli vidět u jednoho z našich dodavatelů nějakého e-shopového řešení, nebo respektive e-shopu, který tu svoji progresi velmi přesně zná. A myslím, že mám ještě lepší příklad od jedného našeho kl všechno vidět. Je to moc hezký. A je to spíš ten graf vpravo. Oba dva mají stejný průměr, takže kdybychom chtěli postavit infrastrukturu na průměrný výkon, tak by nám stačila víceméně stejná. To by byla jednoduchá úvaha, proto jsou ty grafy takhle připraveny. Ale oba dva mají výrazně jinou standardní odchylku. A to je to, co vám ukáže, nebo je takový hezký ukazatel toho, jestli je pro vás event-oriented model zajímavý, nebo není, nebo případně, pomůžu si dalším grafem, je pro vás zajímavý snažit se konvergovat vaši infrastrukturu k tomu, aby vám stačila. Tohle to je rozebraný ten graf zprava vhostit řešení, tak to je typicky tohle. Nebo můžete mít taktiku udělat 80% je vlastně dost. Paratová služba řekne, to je dobře. Já pokryju 80% svojich požadavků a na těch 20% budu spolehat, že budu nenastanou. A nebo když nastanou, takže je odbavím s nějakým spožděním. To může být ten fotbalovej klub, který o kávy normálně kliknete na web, on se vám zobrazí stránka, zběžně to trvá 33 milisekund, ty čísla teda malinko vymejším, já si to nepamatuji, a v momentě, kdy budeme v tomto vytížení, tak ty lidé počkají vteřinu, dvě, tři, dobrý. Taky dobrý point, ona se k tomu ta infrastruktura nakonec dostane, aby to odbavila. Někdo uvidí timeout, to uvidí po dlouhé době, ale refrešné, Takže to je dobrá taktika pro někoho. Každý musí zvolit svoji. Je to dobrá taktika, protože tím ušetříte dost peněz. Jste v tuhle chvíli pokryli v podstatě drtivou většinu času, ale některý píky jste tím nepokryli. To, co je zjevné, je, že obě dvě tyhle taktiky jsou absolutně nevhodné v momentě, kdybychom se dívali, zkusím jít zpátky, na ten graf vlevo. Protože u grafu vlevo, kdybychom se podívali na tu statickou rovinu, tak jsme na maximum, máme nějakých 15-16 tisíc jednotek, takže bychom museli stavit infrastrukturná 16 tisíc jednotek výkonu Takže to je jedna věc. Stejný senář 80%. Úplně stejně jako špatně v tom smyslu. Obrovské množství času a výkonu vám leží ladem. Proto je to taky rozbíraný ten scénář s relativně malou odchylkou, co standardní odchylkou, chování ty infrastruktury. No a nebo je tady možnost naučit se konvergovat, naučit se škálovat, konvergovat infrastrukturu, škálovat infrastrukturu. Podstatně to samý škálování je jeden ze způsobů, jaký konvergovat k těm vašim potřebám, to není nic jiného. Tady je takový zakopanej pes, malinko, já se mu tam schválně neuved, ale je jako hezký a jsem doufal, že mě někdo hned okřikne, Jak to říct? Vy můžete konvergovat tu infrastrukturu samozřejmě. To klíčové je, jak rychle ji konvergujete vůči tomu, jak rychle jste schopní zjistit, že ji konvergovat potřebujete. Chceme rozumět. Pár lidí kývá, že ano. Děkuju. Jestli mi nebylo rozumět, tak prosím, otázky. Vy prostě v momentě, kdy víte, že v 8 hodin vám nastává špička, tak samozřejmě 5 minut před 8 můžete už dílovat nový servery nebo podobné věci. A když víte, že vám stačí konvergovat nějaký výkon infrastruktury v řádech dní, tak vám možná bude stačit si ty servery půjčovat. Nemusíte si jen pronajmout a se vrátit. Ale když je to v řádech vteřin, tak je vám určitě jasný, že to vám možná nezajistí kde byste konvergovali v řádech desítek vteřin nebo minut třeba. Takže rychlost konvergence a vlastně rychlost toho, jak rychle vy to potřebujete, jakou službu potřebujete zaistit, je to, co rozhoduje. Tady v tom grafu rozhoduje o tom, jestli tahle taktika je vůbec schopná nebo není schopná. Tak. Pomůžu si posledním grafem. To je taková rychlá analýza, hodně zjednodušená, ale moc rád ji jako případně dovysvětlím, toho, kolik to stojí. Palinka nahoře zase. Schválně jsem zrušil čísla na těch osách, takže ty ceny jsou jenom poměrem vůči sobě, stejně tak jako jednotky výkonu jsou nějakou virtuální jednotkou výkonu. My jsme použili to, co normálně prodáváme, to je virtuálně privátní cloud v nějakým privátním, případně nějakým kubernetním setupu a nějakým dalším, to je celkem detail. Použili jsme téměř to samé, ale v dynamický rovině. Přijdete-li a řeknete, OK, ale já si chci tady automaticky měnit, jestli chci ještě 100 CPU-ček nahoru nebo 100 giga RAM nahoru nebo dol jsou Izraelci, potkali jsme je asi před rokem na VMwareu a jsou zajímaví tím, že se snaží to dělat líp než AVS a zároveň trochu vlastně. Jako good enough prostě, tak bych to řekl. Good enough. Nemají všechno, ale jsou hrozně zajímavý tím, že právě nemají všechno. To, co mají, mají dobře. Tak ta linka nahoře je event-oriented model. Je jasně nejdražší, to asi nikoho nepřekvapí. Má tu velkou výhodu, že neplatíte to, co nepotřebujete. Takže zaplatíte jenom za ty jednotky výkonu, které jste spotřebovali. Jestli jste přenesti 10 PETA, tak super, tak se zaplatíte. Sice vás jedno PETA bude stát raketoplán, ale těch 10 PETA jste přenesli. Takže fair enough, 10 raketoplánů. V momentě, kdy se podíváte na service-oriented modely, tak ty jsou typicky levnější. Jenomže tam platíte i za čas, kdy ten výkon reálně nepotřebujete. A právě ta taktika toho, dnech, nebo typu jako závěrka a takový věci, které se odehrávají poslední tři dny měsíci nebo první tři dny v dalším, kdy to dělají lidi, to nevím vlastně, tak to zase už nemusí být pravda. Takže jsou tam jako pořád, jsou tam proměný. Jedna z nich je ta rychlost konvergence, druhá z nich je ta vaše schopnost to predikovat a ta třetí je v podstatě to, kterou z těch taktik vy si chcete zvolit. No a To je všechno, co jsem vám dneska chtěl říct. Takže pokud jsou otázky,

00:26:05
Tak prosím sem s nimi, teď. Můžeme říkat já. Pardon.

00:26:13
Michale, prosím vás, teď je vaše slovo. Tak otázky teď. Online tady žádná není, kromě toho, že se někdo ptal, kde má hlasovat, aby mohl vyhrát tady ten multitool.

00:26:27
Tak tomu doufám taky povíte.

00:26:28
To jsme mu řekli.

00:26:29
To jsme mu řekli.

00:26:31
A pustili jsme mu rovnou vaši anketní otázku. Tak co tady? Nějaký dotaz? Bylo to natolik vyčerpávající? Zazvěděli jste se úplně všechno? Nebo se chcete na něco? Já jsem věděl, že vyprovokuju. Dobrý.

00:26:55
Takže ty prostředky jsou vlastně jako sdílený, že jo, předpokládám. Takže v podstatě, když máte dva klienty, který má třeba jednu charakteristiku, kterou jste měl vlevo a druhou vpravo, tak se to nějak vlastně vykompenzuje mezi sebou, ne? Předpokládám.

00:27:55
Ale nefunguje vám to, nedá vám to ty výsledky. Takže my sledujeme tohle CPU ready, jiní provideri to dělají buď podobně nebo jinak, to jako nedokážu říct. Znám několik, kteří to dělají velmi podobně jako my, ale nejsou to určitě zdaleka všichni. A je to podobný mechanismus jako měřit třeba SLA. Takže ve finále to, jestli agregujete, nebo agreguje ten provider, to se určitě agreguje, téměř každej. Ale jak moc a jestli to dělá dobře a vám to neškodí, nebo vám to škodí, to určí nějakej parametr, který není tady úplně jako, Ale možná stojí za to ještě dodat, že v tom obchodním modelu je to většinou zohledněné. To je ten důvod, proč ty prostředky můžou být taky nikdy úplně jinak drahý, než když je vlastně jako rezervujete celý pro sebe. To je typický scénář toho obchodního modelu, že tam se z nějakou agregací počítá.

00:28:46
Tak ještě, ano.

00:28:56
Já bych se chtěl jenom zeptat, jak to máte vnitřně udělané, protože vy garantujete dostupnost aplikace, ale než to k té aplikaci doleze, tak tam je mnoho mezi stupňů v té infrastruktuře. Jestli teda dimenzujete každou tu část infrastruktury, nebo jestli máte na to nějaký automatický mechanismus nebo něco takového?

00:29:16
U nás je to tak, že my poskytujeme infrastrukturní cloud. Pro nás tou aplikací je virtuální server. Jestli vy na tom virtuálním servoru provozíte ta databáze a ta jede nebo nejede, tak to je něco, čím vám jsme schopni nějak pomoct, ale nejsme schopni vám to garantovat. My vám budeme garantovat, že ten virtuální server bude mít prostředky na CPU, že dostane čas, aby se odbavilo to, co chce dělat. To vám jsme schopni garantovat, to je zahrnutým nějakým SLA, SLO a tak dále v dalších metrikách. Ale jestli vám ta databáze jede nebo nejede, jestli máte přetíženou malej disk nebo jste si ji špatně naindexoval No, ty sondy, které měří nebo ukazují obecně dostupnosti infrastruktury, tak jsou nezávislí a dívají se na ty věci zevnitř. Takže vy to samozřejmě jako klient zvenší vás může zachytit cokoliv po cestě. To je o tom vůbec žádná. Pak hrozně záleží na tom, jestli to je součástí té služby nebo není. A budu trochu to zobecnit. To nebylo čistě ČR, ale u každého providera to v podstatě bude přibližně stejný. Ten vám řekne, jestli je to manage služba, my mám ten firewall,

00:30:52
Tak, ještě máme nějakou? Otázku?

00:30:58
Ne? Vyčerpali jsme to? Super, tady se koukneme online jistě nic. Skvělé, díky Marko Hernekerovi.

00:31:04
Já moc děkuji, mějte se. Díky.