Pro připomenutí, výpadek Amazon AWS odstavil na (v některých případech i na více než 24 hodin) mnohé velké weby v severní Americe. Mezi ty nejhlasitější patřily Reddit a Quora (), z těch v Čechách známějších pak třeba Foursqaure nebo Gooddata.
Co je cloud služba Amazon AWS, rozebíráme na Lupě zde.
Nepovedená údržba
V první řadě je třeba uvést na pravou míru, k čemu vlastně došlo. Výpadek započal ve čtvrtek 21. dubna po půlnoci místního času a podařilo se jej plně zvládnout až brzy ráno o tři dny později, tedy po více než 72 hodinách. V tu dobu už samozřejmě asi všechny postižené služby běžely z vlastních záloh a jednalo se pouze o obnovu dat na straně AWS.
Nebudu zde do detailů rozebírat příčiny, ty publikoval Amazon a pokud AWS používáte, jedná se skutečně o velmi poučný dokument. Ve zkratce byla původcem chyba obsluhy při rutinní údržbě sítě. Omylem došlo k zahlcení vnitřní sítě, kterou používají disková úložiště (EBS – viz dále). Jednotlivé EBS jednotky si po ztrátě konektivity myslely, že došlo k poruše jejich replikace a začaly automaticky hledat nové replikační cíle a masivně se na ně replikovat. Tím vyvolaly replikační bouři (v originále skutečně replication storm
) a spotřebovaly veškerý dostupný diskový prostor a zahltily řídící servery. Při probíhající replikaci je jednotka EBS uzamčená, takže mnoho takových jednotek zůstalo pro aplikace nedostupných na několik hodin.
Přestože se jedná o nejrozsáhlejší výpadek v historii AWS a velkých cloudů vůbec, byl tento výpadek stále lokalizovaný na malé procento služeb. Fakticky došlo pouze k výpadku konektivity k EBS a to v jedné ze 4 zón (availability zone) v jednom z pěti regionů, ve kterých má AWS datacentra. Amazon ve svém detailním post mortem celé události tvrdí, že postiženo bylo v jeden okamžik až 13% všech EBS jednotek v dané zóně. V různých fázích výpadku byly různým způsobem ovlivněny i zbylé zóny regionu, ovšem podle dostupných informací se jednalo převážně pouze o zvýšenou latenci a chybovost API rozhraní.
Jak funguje AWS
EBS je redundantní perzistentní síťové diskové úložiště (AWS uvádí nejméně desetkrát nižší riziko ztráty dat oproti běžnému disku), které se používá pro ukládání dat z instancí virtuálních serverů EC2. V případě problémů s virtuálním serverem lze přes API prakticky ihned EBS od instance odpojit a připojit jej k jiné instanci, stejně tak lze instance z EBS přímo startovat. Jedná se o jedno ze čtyř hlavních datových úložišť, které AWS nabízí.
Ve světě AWS je důležitá zejména ona perzistence, protože diskový prostor dostupný přímo na instanci virtuálního serveru existuje pouze tak dlouho, jako instance sama a po jejím ukončení neexistuje způsob, jak se k němu dostat. Typickou oblastí využití jsou například databáze, kdy virtuální server ukládá data právě do EBS a data tak spolehlivě přežijí selhání samotného serveru. Velmi podobně funguje i vlastní managed databázové řešení od samotného AWS, nazývané RDS.
AWS rozděluje každý region do několika samostatných zón (availability zone), které mají zcela nezávislé napájení, konektivitu, chlazení a další technické vybavení. Primárním účelem zón je možnost zajistit dostupnost při výpadku jedné z nich z ostatních zón. AWS nabízí dobré prostředky, jak aplikaci postavit napříč zónami – vyžaduje to ale práci na straně aplikace a samozřejmě to také zvyšuje náklady. Přestože jsou zóny důsledně odděleny, jsou stále na stejné vnitřní síti a některé služby sdílejí – například službu load balanceru (ELB) a samotné API.
Pokud požaduje zákazník ještě vyšší záruky dostupnosti, může svou aplikaci nainstalovat do fyzicky zcela oddělených a logicky nezávislých regionů. Teoreticky stoprocentní dostupnost je ovšem vykoupena vysokými náklady. Z praktického pohledu je totiž oddělení možná až příliš důsledné, k rozdělení do regionů AWS nenabízí žádnou infrastrukturní podporu, a proto to v praxi jen málokdo dělá.
Proč se výpadek tak rozsáhle projevil?
Na základě vlastních zkušeností s AWS mohu dospět jen k jedinému závěru, a to sice že firmy (včetně nás) byly ukolébané dosavadní špičkovou dostupností. Amazon v dokumentaci poukazuje na to, že výpadky nastávat budou a vybízí k tomu, aby zákazníci vystavěli své systémy tak, aby jim odolávaly. Nabízí k tomu mnoho podpůrných systémů, například dynamické rozdělování zátěže napříč zónami nebo interní monitorovací systém CloudWatch ve spojení s Auto-scaling groups.
Jenže například my (všechny servery máme v regionu EU-WEST-1) jsme za 2 roky nezaznamenali ani jeden výpadek celé zóny, dokonce ani jeden výpadek konkrétního serveru (a to nám jich ve špičce běží téměř dvě desítky), který bychom mohli jednoznačně přičíst na vrub například selhání hardware na straně AWS.
Přizpůsobit web provozu v cloudu – tak, aby bylo možné využívat dynamického škálování a tolerance proti poruchám – není vůbec jednoduché ani levné. Mnoho firem jednoduše vezme stávající architekturu na fyzických serverech a přesune ji bez větších úprav do prostředí cloudu, přičemž pak už záleží na slovíčkaření, zdali vůbec lze mluvit o hostování v cloudu.
V našem případě vyvíjíme všechny nové projekty (např. WhichAirline.com) už přímo pro prostředí cloudu, přičemž jen vývoj a testování sdílených sessions, centrálních úložišť dat, sdílené cache a dalších komponent nás stál stovky hodin času navíc. To je také důvod, proč naše staré weby, mezi nimi i kovářova kobyla hostingy.cz, stále provozujeme na fyzických dedikovaných serverech, byť by byl jejich provoz z cloudu variabilními náklady levnější.
Jak moc bude váš cloud odolávat výpadkům, je otázka peněz. Na jedné straně jsou náklady na vystavění a provoz takového řešení, na straně druhé odhadované riziko, že k takovému výpadku dojde a ztráty, které způsobí. Jak se ukazuje, mnoho velkých webů podcenilo pravou stranu rovnice a nemělo spolehlivé failover řešení ani na úrovni výpadku jedné zóny.
Vysoká škola architektury dostupných systémů
Jako příklad firem, které výpadek přestály bez ztráty kytičky, se uvádí (kromě samotného Amazonu) například Engine Yard a Netflix. Ta první z nich měla velké štěstí (píší zde) – v beta režimu testovala replikaci napříč regiony a při výpadku pouze systém o něco dříve nasadila. Netflix (největší americká online videopůjčovna) se už dříve uváděl jako příklad firmy, která je posedlá dostupností. Architekturu, kterou používají, si můžete nastudovat z jejich prezentace. Výborné čtení o samotném velikonočním výpadku pak vývojáři sepsali na svém blogu.
Základem, který Netflix používá, je rozdělení trafficu do tří zón – pokud o jednu přijde, zbývající dvě stále dokáží pokrýt požadavky. To se týká jak vlastních instancí virtuálních serverů, tak i všech dat, které také replikují do všech zón. Kapacita pochopitelně musí být plánována tak, aby náhlý výpadek zbývající zóny nepřetížil.
Kromě dostatečné rezervy instancí Netflix používá metody označované jako graceful degradation a loose coupling při návrhu samotné aplikace. Společně zajišťují, že v případě problémů s přetížením nebo dokonce výpadkem nějakého podsystému služby stále běží, byť v horší kvalitě. Například místo výpočetně náročného personalizovaného doporučení filmů se uživateli zobrazí pouze statická náhradní varianta obsahu. Rozdělení do systému nezávislých komponent a krátké timeouty pak zajišťují, že pokud některá komponenta přestane fungovat, uživateli se vrátí stránka sice neúplná, zato ale v rozumném čase.
Pro našince už prakticky z jiné dimenze pochází takzvaná Chaos monkey
, což je interní služba, jejíž starostí je vnášet do systému poruchy. Zákeřná opička náhodně vypíná servery a sleduje, jak se s tím systém vypořádá. Jako reakci na výpadek Netflix připravuje vylepšení opičky s názvem „Chaos gorilla“, která má simulovat právě výpadek celé zóny.
Konec cloudu? To snad ne…
Přestože výpadek významně pošramotil pověst celého AWS, nemyslím si, že by postižené firmy hned běžely jinam. Lock-in na AWS je velký. Nejde ani tak o vlastní virtuální servery – nainstalovat identické nové někde jinde těžké nebude, ale zejména o služby s přidanou hodnotou, které jinde vůbec neexistují, nebo se používají úplně jinak. Za nás si nedovedu vůbec představit náklady na přesun infrastruktury k někomu jinému, a to zatím nevyužíváme ani polovinu služeb, které AWS nabízí.
To, že konkurent doposud podobný výpadek neměl, neznamená, že podobný nebo horší problém jej nemůže postihnout hned zítra. Stejně tak se může hned zítra opakovat závada na AWS. Bohužel nelze nijak spočítat, že problém specifikovaného rozsahu nastane s pravděpodobností jednou za sto let, jako je tomu například u povodní. Historie cloudů je zkrátka příliš krátká na to, aby se vůbec dala odhadnout dlouhodobá spolehlivost jednotlivých řešení.
Paradoxně se domnívám, že bude-li mít výpadek na finanční výsledky AWS nějaký dopad, bude nakonec pozitivní. Po Velkém velikonočním výpadku 2011 totiž už firmy nebudou bezmezně spoléhat na to, že to až doteď perfektně fungovalo a že případné selhání profesionálové od cloudu jistě brzy opraví. Namísto toho budou samy více investovat do redundance a záloh a budou budovat architekturu systémů tak, aby zátěž i riziko rozkládaly do více zón a regionů.
