Petr Soukup: Proč jsme migrovali do cloudu Amazonu (AWS)
 x   TIP: Přetáhni ikonu na hlavní panel pro připnutí webu

Petr Soukup: Proč jsme migrovali do cloudu Amazonu (AWS)Petr Soukup: Proč jsme migrovali do cloudu Amazonu (AWS)

 

Petr Soukup: Proč jsme migrovali do cloudu Amazonu (AWS)

Google       13. 1. 2014       15 703×

Za ty roky provozování e-shopů jsme přešli přes různá řešení zázemí. Začali jsme na obyčejném hostingu, přešli na dedikovaný server, pak vlastní server, více vlastních serverů, zpět na dedikované servery a nyní jsme migrovali do AWS. Co nás k tomu vedlo?

Co je to AWS?

Amazon kromě toho, že provozuje e-shop, tak také provozuje cloud s datacentry po celém světě. A vůbec se s ním nemaže – je větší než tři největší konkurenti dohromady. Není to přitom jen nějaký hloupý hosting, ale skutečně cloud – pronajímáte si od hodiny stavební bloky a z těch si tvoříte vlastní infrastrukturu. Žádné posuvníčky na přidání RAM, ale skutečnou infrastrukturu, která může obsluhovat od jednoho návštěvníka až prakticky do nekonečna.

Důvod 1: Auto-scaling

Hlavním důvodem pro přechod do cloudu byla pro naše e-shopy specifická nárazová návštěvnost. U vlastních serverů je nejdražší čas, kdy nic nedělají. Představte si, že draze nakoupíte servery a ty 340 dní v roce nedělají prakticky nic, ale musíte je mít, protože 25 dní budou stěží zvládat. Když jich ale bude méně, tak bude průšvih. Potřebný výkon je navíc potřeba odhadnout s předstihem – těžko budete ve vánoční špičce doplňovat rychle další servery.

Vánoční špička jde ale aspoň předvídat. Horší je to u nečekaných výkyvů. Představte si e-shop, kam v průměru chodí denně 5 000 lidí. Pak se o něm někdo zmíní v Superstar a hop!, najednou se na něj musí jít podívat 50 000 lidí během půlhodiny.

V cloudu tohle ale vůbec není problém, protože se tam se zdroji pracuje od hodiny. Je potřeba další server? Není problém, do minuty bude online. Navíc tu lze pracovat s menšími kroky – u klasického serveru je přidání nového stroje velký skok (viz zbytečný výkon), ale v cloudu lze velikost „serverů“ snadno měnit. Pro větší názornost jsem to zkusil naznačit do grafu denní návštěvnosti. U vlastního/dedikovaného serveru během dne s celkovým výkonem nic neděláte. Můžete si tedy jen vybrat, zda budete platit za nevyužitý výkon celý den nebo jen část dne a ještě riskovat nedostatek.

V grafu je návštěvnost během dne (potřebný výkon) a dostupný výkon pro dedikovaný server vs. cloud. Všechno nad modrou čarou návštěvnosti jsou zbytečně utracené peníze.

Graf, který porovnává využití výkonu serverů. Zdroj: Souki.cz

 Důvod 2: Best practices a ušetřený čas

V AWS si sice můžete pronajmout jen surový výpočetní výkon a vše si udělat sami, ale daleko zajímavější je použít to, co už je připraveno, anebo oni sami doporučí. Na vlastních serverech jsme například měli udělaný cluster pro MySQL. Strávili jsme hodně času, aby tam dokonale fungoval failover a zálohování. Po dlouhém vývoji nám zálohy fungovaly tak, že jedním kliknutím šlo obnovit databázi do libovolného času. V Amazonu je tohle naprostá samozřejmost a dostanete takovou funkci rovnou.

AWS má navíc opravdu velmi dobrou technickou podporu. Když jsem narazil na něco, co jsem nevěděl jak vyřešit, stačilo napsat na podporu (placenou 50$/měsíc) a do hodiny přišla velmi podrobná odpověď s odkazy na dokumentaci a několika návrhy, jak bych k tomu mohl přistoupit.

Důvod 3: Monitoring

Všechny stavební bloky v AWS mají velmi podrobný monitoring. Nemyslím tím jen měření dostupnosti, ale podrobné údaje o počtech přístupů na disk, průměrné době odezvy aplikace atd. Na metriky pak lze úplně jednoduše nastavit alarm – ten pak buď jen pošle email, anebo rovnou něco udělá. Díky tomu lze snadno nastavit chytrá pravidla autoscalingu a inteligentně automaticky přidávat/ubírat výkon. Navíc díky tomu dostáváte kompletní přehled o aplikaci. Když je nějaký problém, stačí si vyfiltrovat metriky, najít nějakou s výkyvem a hned je vidět příčina. Oproti vlastnímu měření má toto výhodu, že se měří věci, které by mě nenapadlo měřit (do prvního problému).

Důvod 4: Experimenty

Chtěli jste si někdy zkusit, jak se bude vaše aplikace chovat, když bude mít úplně jinak postavenou infrastrukturu? Nebo otestovat změnu infrastruktury na části provozu? Se skutečnými servery to je celkem problém. Musíte totiž mít nějaké připravené bokem, aby bylo na čem zkoušet. Případně to zkusíte v menším měřítku a doufáte, že se to bude v plné verzi chovat stejně. V cloudu to není problém. Na dvě kliknutí si prostě infrastrukturu zduplikujete, vyzkoušíte a přepnete provoz. Na chvíli tak zdvojnásobíte počet „serverů“, ale protože je to placené od hodiny, tak za celý megaexperiment zaplatíte třeba 5$.

Důvod 5: Vývoj

Minimálně jednou týdně mi přijde od AWS email, co přidali nového. A nejsou to žádné drobnosti. Neustále rozšiřují stávající služby a hlavně přidávají nové. Víceméně každý týden tak říkám „to je super, to hned nasadíme!“ Stejně tak aktualizují i infrastrukturu.

Teď například přidali nové typy serverů, které mají jen SSD disky. Na pár kliknutí jsme otestovali, že to má znatelný vliv na výkon, na dalších pár kliknutí se původní „servery“ zahodily a vše se přemigrovalo na tyto nové – to celé v poledne a během pár minut. Zkuste takový upgrade udělat s vašimi servery.

Časté důvody proti:

Od migrace do cloudu jsem slýchal několik argumentů proti pořád dokola, tak je rovnou vypíšu:

Argument 1: Cloud je drahý

Když si vezmete specifikaci svého serveru a dáte ji do kalkulačky AWS, vypadne vám nějaké naprosto šílené číslo. Trik je v tom, že takhle nelze ceny porovnávat. AWS server rozkládá na dílčí bloky, takže se cena porovnává komplikovaně. Hned po migraci nás provoz vyšel zhruba na pětinásobek. Po úpravách logiky, aby byla víc cloudovější, a optimalizacích (podrobné metriky hodně pomohly) už jsme na podobné ceně jako s vlastním řešením, ale s úplně jinou úrovní.

Argument 2: Je to v Irsku a má to pomalý ping

Vzdálenost je tam skutečně znát, ale ne zase tolik. Na server v Masteru v Praze mám ping 18ms, do Amazonu 48ms. Trik je ale v tom, že 95% trafficu jde z CDN (Praha) a skutečně z Amazonu tak je jen samotná HTML stránka, ale ne obrázky apod. Rozdíl je tak minimální a ani ho nikdo nepostřehl.

Argument 3: Cizákovi bych data nesvěřil

Zatímco třeba u Wedosu hostují webtržníci, tak v Amazonu hostuje NASA, Netflix nebo Raiffeisenbank. Pokud nemají s ukládání u třetí strany problém oni, tak ani já. O tomto bodu ale moc pěkně psal už Petr Šimeček z Keboola, takže si utíkejte přečíst jeho článek Cloud – nejvíc nebezpečná věc pro české firmy.

Po čtyřech měsících v cloudu

Jsme v cloudu asi čtyři měsíce, ale pořád mi přijde, že využíváme jen zlomek toho, co nabízí. Vůbec nechápu, proč jsme do něj nemigrovali už dávno. Pokud začínáte s novým projektem, tak ho rozhodně vyzkoušejte. Kdybychom do cloudu migrovali už dříve, ušetříme stovky hodin vývoje infrastruktury kvůli růstu požadavků. V cloudu si vyrobíte aplikaci, běží vám tam za pár dolarů a když je úspěšná, tak prostě jen naklikáte více prostředků. Žádné závazky, žádné starosti.

Článek jsme publikovali se svolením Petra Soukupa ze Simplia.cz, kde se věnuje tvorbě e-shopů.

×Odeslání článku na tvůj Kindle

Zadej svůj Kindle e-mail a my ti pošleme článek na tvůj Kindle.
Musíš mít povolený příjem obsahu do svého Kindle z naší e-mailové adresy kindle@programujte.com.

E-mailová adresa (např. novak@kindle.com):

TIP: Pokud chceš dostávat naše články každé ráno do svého Kindle, koukni do sekce Články do Kindle.

Hlasování bylo ukončeno    
13 hlasů
Google
(fotka) Lukáš ChurýLukáš je šéfredaktorem Programujte, vyvíjí webové aplikace, fascinuje ho umělá inteligence a je lektorem na FI MUNI, kde učí navrhovat studenty GUI. Poslední dobou se snaží posunout Laser Game o stupeň výše a vyvíjí pro něj nové herní aplikace a elektroniku.
Web     Twitter     Facebook     LinkedIn    

Nové články

Obrázek ke článku Hybridní inteligentní systémy 2

Hybridní inteligentní systémy 2

V technické praxi využíváme často kombinaci různých disciplín umělé inteligence a klasických výpočtů. Takovým systémům říkáme hybridní systémy. V tomto článku se zmíním o určitém typu hybridního systému, který je užitečný ve velmi složitých výrobních procesech.

Obrázek ke článku Jak vést kvalitně tým v IT oboru: Naprogramujte si ty správné manažerské kvality

Jak vést kvalitně tým v IT oboru: Naprogramujte si ty správné manažerské kvality

Vedení týmu v oboru informačních technologií se nijak zvlášť neliší od jiných oborů. Přesto však IT manažeři čelí výzvě v podobě velmi rychlého rozvoje a tím i rostoucími nároky na své lidi. Udržet pozornost, motivaci a efektivitu týmu vyžaduje opravdu pevné manažerské základy a zároveň otevřenost a flexibilitu pro stále nové výzvy.

Obrázek ke článku Síla týmů se na home office může vytrácet. Odborníci radí, jak z pracovních omezení vytěžit maximum

Síla týmů se na home office může vytrácet. Odborníci radí, jak z pracovních omezení vytěžit maximum

Za poslední rok se podoba práce zaměstnanců změnila k nepoznání. Především plošné zavedení home office, které mělo být zpočátku jen dočasným opatřením, je pro mnohé už více než rok každodenní realitou. Co ale dělat, když se při práci z domova ztrácí motivace, zaměstnanci přestávají komunikovat a dříve fungující tým se rozpadá na skupinu solitérů? Odborníci na personalistiku dali dohromady několik rad, jak udržet tým v chodu, i když pracovní podmínky nejsou ideální.

Reklama autora

Hostujeme u Českého hostingu       ISSN 1801-1586       ⇡ Nahoru Webtea.cz logo © 20032024 Programujte.com
Zasadilo a pěstuje Webtea.cz, šéfredaktor Lukáš Churý