Proč jsme migrovali do cloudu Amazonu (AWS)

Posted 05. 01. 2014 / By Petr Soukup / Eshop

awslogoZa 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.

cloudgraf

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.

 

Další díly:

  1. Proč jsme migrovali do cloudu Amazonu (AWS)
  2. Cloud na český způsob
  3. Jak na AWS cloud - první kroky
  4. AWS cloud za hubičku! - první server, úspory a load balancer
  5. Vychytávky v Amazon cloudu
  6. Jak se programuje v cloudu

Update: Nestačí vám články? Nově nabízím i konzultace AWS cloudu :)



O blogu
Blog o provozování eshopů a technologickém zázemí.
Aktuálně řeším hlavně cloud, bezpečnost a optimalizaci rychlosti.

Rozjíždím službu pro propojení eshopů s dodavateli.