V létě tradičně klesá jak nákupní aktivita, tak intenzita změn v infrastruktuře webových projektů, říká Captain Obvious. Jednoduše proto, že i IT specialisté občas vyrazí na dovolenou. A také CTO. O to těžší je to pro ty, kteří zůstávají ve funkci, ale o to teď nejde: možná právě proto je léto tím nejlepším obdobím k pomalému zamyšlení nad stávajícím rezervačním schématem a sestavení plánu na jeho zlepšení. A zkušenost Yegora Andreeva z , o kterém na konferenci hovořil .
Existuje několik úskalí, do kterých se můžete dostat při vytváření záložních webů. A je absolutně nemožné se v nich chytit. A co nás v tom všem ničí, stejně jako v mnoha jiných věcech, je perfekcionismus a... lenost. Snažíme se dělat všechno, všechno, všechno dokonale, ale nepotřebujeme to dělat dokonale! Musíte dělat jen určité věci, ale dělat je správně, dokončit je, aby správně fungovaly.
Failover není nějaká legrace, zábavná věc; to je věc, která by měla dělat přesně jednu věc – snížit prostoje, aby služba, firma, přišla o méně peněz. A u všech rezervačních metod navrhuji přemýšlet v následujícím kontextu: kde jsou peníze?
První past: když budujeme velké, spolehlivé systémy a využíváme redundanci, snižujeme počet nehod. To je hrozná mylná představa. Když se zapojíme do redundance, pravděpodobně zvýšíme počet nehod. A pokud vše uděláme správně, společně snížíme prostoje. Nehod bude více, ale budou vznikat s nižšími náklady. Co je rezervace? - to je komplikace systému. Jakákoli komplikace je špatná: máme více ozubených kol, více ozubených kol, jedním slovem více prvků – a tudíž vyšší pravděpodobnost poruchy. A opravdu se rozbijí. A budou se častěji lámat. Jednoduchý příklad: řekněme, že máme web s PHP a MySQL. A to je naléhavě nutné rezervovat.
Shtosh (c) Vezmeme druhé místo, postavíme identický systém... Složitost je dvakrát větší – máme dvě entity. Zavádíme také určitou logiku pro přenos dat z jednoho webu na druhý – tedy replikaci dat, kopírování statických dat a tak dále. Replikační logika je tedy obvykle velmi složitá, a proto celková složitost systému může být ne 2, ale 3, 5, 10krát větší.
Druhá past: když stavíme opravdu velké komplexní systémy, fantazírujeme o tom, co chceme nakonec získat. Voila: chceme získat super spolehlivý systém, který funguje bez výpadků, přepne se během půl sekundy (nebo ještě lépe okamžitě) a začneme plnit sny. Ale je zde také nuance: čím kratší je požadovaný spínací čas, tím složitější je logika systému. Čím složitější musíme tuto logiku vytvořit, tím častěji se bude systém rozpadat. A můžete se dostat do velmi nepříjemné situace: ze všech sil se snažíme zkrátit prostoje, ale ve skutečnosti všechno komplikujeme, a když se něco pokazí, prostoje se prodlouží. Zde se často přistihnete, jak si říkáte: no... bylo by lepší rezervaci neprovádět. Bylo by lepší, kdyby to fungovalo samostatně a s pochopitelnými prostoji.
Jak s tím můžeš bojovat? Musíme si přestat lhát, přestat si lichotit, že tady teď postavíme vesmírnou loď, ale přiměřeně pochopit, jak dlouho může projekt ležet. A po tuto maximální dobu si vybereme, jaké metody skutečně použijeme ke zvýšení spolehlivosti našeho systému.
Je čas na „příběhy z w“... ze života, samozřejmě.
Příklad číslo jedna
Představte si webovou stránku s vizitkou pro Válcovnu trub č. 1 ve městě N. Velkým písmem je na ní napsáno - VALOVNA POTRUBÍ č. 1. Hned níže je slogan: „Naše trubky jsou nejkulatější trubky v N.“ A níže je telefonní číslo generálního ředitele a jeho jméno. Chápeme, že musíte provést rezervaci - to je velmi důležitá věc! Začněme zjišťovat, z čeho se skládá. Html-statika - tedy pár obrázků, kde generální ředitel ve skutečnosti probírá nějakou další dohodu u stolu v lázních se svou partnerkou. Začínáme přemýšlet o prostojích. Napadá mě: musíte tam ležet pět minut, ne víc. A pak vyvstává otázka: kolik prodejů bylo z této naší stránky obecně? Kolik-kolik? Co znamená "nula"? A to znamená: protože generál provedl všechny čtyři transakce v loňském roce u jednoho stolu, se stejnými lidmi, se kterými chodí do lázní a sedí u stolu. A chápeme, že i když web sedí den, nic hrozného se nestane.
Na základě úvodních informací je den, kdy tento příběh nastolit. Začněme přemýšlet o schématu redundance. A pro tento příklad zvolíme nejideálnější schéma redundance: nepoužíváme redundanci. Tohle celé může každý admin vyzvednout během půl hodiny s kouřovými přestávkami. Nainstalujte webový server, přidejte soubory – to je vše. Bude to fungovat. Není potřeba nic hlídat, na nic si dávat zvláštní pozor. To znamená, že závěr z příkladu číslo jedna je zcela zřejmý: služby, které není třeba rezervovat, není nutné rezervovat.
Příklad číslo dvě
Firemní blog: speciálně vyškolení lidé tam píší novinky, účastnili jsme se takové a takové výstavy, ale vydali jsme další nový produkt a tak dále. Řekněme, že se jedná o standardní PHP s WordPressem, malou databází a trochou statiky. Samozřejmě znovu přichází na mysl, že byste si za žádných okolností neměli lehnout - "ne více než pět minut!" To je vše. Ale zamysleme se dále. Co dělá tento blog? Lidé tam přicházejí z Yandexu, z Googlu na základě nějakých dotazů, organicky. Skvělý. Má s tím něco společného prodej? Epiphany: vlastně ne. Reklamní provoz směřuje na hlavní web, který je na jiném počítači. Začněme přemýšlet o rezervačním schématu. V dobrém slova smyslu je potřeba ho zvednout za pár hodin a bylo by hezké se na to připravit. Rozumné by bylo vzít stroj z jiného datového centra, narolovat na něj prostředí, tedy webový server, PHP, WordPress, MySQL a nechat ho tam. V momentě, kdy pochopíme, že je vše rozbité, je potřeba udělat dvě věci – vyvalit mysql skládku 50 metrů, doletí tam za minutu a vyrolovat tam určitý počet obrázků ze zálohy. To tu také není bůhví jak dlouho. Tak se za půl hodiny celá věc zvedne. Žádná replikace, nebo mi Bůh odpusť, automatické převzetí služeb při selhání. Závěr: to, co můžeme rychle zavést ze zálohy, nemusí být zálohováno.
Příklad číslo tři, složitější
Internetový obchod. PHP s otevřeným srdcem je trochu vylepšené, mysql s pevným základem. Docela hodně statické (koneckonců, online obchod má krásné HD obrázky a všechny ty věci), Redis pro relaci a Elasticsearch pro vyhledávání. Začínáme přemýšlet o prostojích. A zde je samozřejmě zřejmé, že internetový obchod nemůže bezbolestně ležet ani den. Koneckonců, čím déle leží, tím více peněz ztrácíme. Vyplatí se zrychlit. Jak moc? Myslím, že když si hodinu lehneme, nikdo se nezblázní. Ano, o něco přijdeme, ale pokud začneme tvrdě pracovat, bude to jen horší. Definujeme schéma povolených prostojů za hodinu.
Jak se to všechno dá zarezervovat? Auto potřebujete v každém případě: hodina času je docela málo. Mysql: tady už potřebujeme replikaci, živou replikaci, protože za hodinu 100 GB s největší pravděpodobností nebude přidáno na výpis. Statistika, obrázky: zase za hodinu se 500 GB nemusí stihnout přidat. Proto je lepší obrázky hned zkopírovat. Redis: Tady jsou věci zajímavé. V Redis jsou relace uloženy – nemůžeme to jen tak vzít a pohřbít. Protože to nebude moc dobré: všichni uživatelé budou odhlášeni, jejich košíky budou vyprázdněny a tak dále. Lidé budou nuceni znovu zadat své uživatelské jméno a heslo a mnoho lidí se může odtrhnout a nákup nedokončit. Opět dojde k poklesu konverzí. Na druhou stranu Redis je přímo aktuální, přičemž poslední přihlášení uživatelé asi také nepotřebují. A dobrým kompromisem je vzít Redis a obnovit ho ze zálohy ze včerejška, nebo, pokud to děláte každou hodinu, tak před hodinou. Naštěstí jeho obnovení ze zálohy znamená zkopírování jednoho souboru. A nejzajímavější příběh je Elasticsearch. Kdo kdy zvedl replikaci MySQL? Kdo kdy vyzvedl replikaci Elasticsearch? A po kom to normálně fungovalo? Chci říct, že v našem systému vidíme určitou entitu. Zdá se to být užitečné - ale je to složité.
Komplexní v tom smyslu, že naši kolegové inženýři nemají s prací s ním žádné zkušenosti. Nebo existuje negativní zkušenost. Nebo chápeme, že je to stále docela nová technologie s nuancemi nebo syrovostí. Myslíme si... Sakra, elastický je taky zdravý, obnova ze zálohy taky trvá dlouho, co mám dělat? Chápeme, že elastický v našem případě slouží k vyhledávání. Jak se náš internetový obchod prodává? Chodíme za obchodníky a ptáme se, odkud lidé pocházejí. Odpovídají: "90 % z trhu Yandex přichází přímo na kartu produktu." A buď to koupí, nebo ne. Vyhledávání tedy potřebuje 10 % uživatelů. A zachování elastické replikace, zejména mezi různými datovými centry v různých zónách, má opravdu mnoho nuancí. Který východ? Vezmeme gumu z rezervovaného místa a nic s tím neděláme. Pokud se případ bude protahovat, možná ho jednoho dne vzneseme, ale to není jisté. Závěr je vlastně plus mínus stejný: my zase nerezervujeme služby, které nemají vliv na peníze. Aby byl diagram jednodušší.
Příklad číslo čtyři, ještě obtížnější
Integrátor: prodej květin, volání taxi, prodej zboží, obecně čehokoli. Vážná věc, která funguje 24/7 pro velké množství uživatelů. S plnohodnotným zajímavým stackem, kde jsou zajímavé základy, řešení, vysoká zátěž a hlavně bolí déle než 5 minut ležet. Nejen a ne tak proto, že lidé nebudou kupovat, ale protože lidé uvidí, že tato věc nefunguje, budou naštvaní a nemusí se vůbec vrátit.
OK. Pět minut. co s tím budeme dělat? V tomto případě, stejně jako dospělí, používáme všechny peníze na vybudování skutečného záložního webu s replikací všeho a snad i co nejvíce automatizujeme přepínání na tento web. A kromě toho si musíte pamatovat na jednu důležitou věc: ve skutečnosti napsat pravidla pro přepínání. Předpisy, i když máte vše zautomatizované, mohou být velmi jednoduché. Ze série „spustit takový a takový ansible skript“, „zaškrtnout takové a takové zaškrtávací políčko v cestě 53“ a tak dále – ale to musí být nějaký přesný seznam akcí.
A vše se zdá být jasné. Přepínání replikace je triviální úkol, jinak se přepne sama. Přepsání názvu domény v DNS je ze stejné řady. Potíž je v tom, že když takový projekt selže, začne panika a dokonce i ti nejsilnější, vousatí admini mohou být náchylní k ní. Bez jasných pokynů „otevři terminál, pojď sem, adresa našeho serveru je stále taková“, je obtížné dodržet 5minutový časový limit určený pro resuscitaci. No a navíc, když použijeme tyto předpisy, je snadné zaznamenat například nějaké změny v infrastruktuře a podle toho upravit předpisy.
No, pokud je rezervační systém velmi složitý a v určitém okamžiku jsme udělali chybu, pak můžeme zničit náš záložní web a navíc proměnit data na dýni na obou webech - to bude úplně smutné.
Příklad číslo pět, úplný hardcore
Mezinárodní služba se stovkami milionů uživatelů po celém světě. Jsou tam všechna časová pásma, vysoké zatížení při maximální rychlosti, nemůžete si vůbec lehnout. Minuta - a bude to smutné. Co dělat? Rezervace opět podle plného programu. Udělali jsme vše, o čem jsem mluvil v předchozím příkladu, a ještě něco navíc. Ideální svět a naše infrastruktura je v souladu se všemi koncepty vývoje IaaC. To znamená, že vše je v git a stačí stisknout tlačítko.
Co chybí? Jedna - cvičení. Bez nich to nejde. Zdá se, že u nás je vše dokonalé, obecně máme vše pod kontrolou. Stiskneme tlačítko, vše se stane. I když tomu tak je – a chápeme, že se to tak neděje – náš systém interaguje s některými jinými systémy. Jedná se například o dns z route 53, úložiště s3, integraci s nějakým api. V tomto spekulativním experimentu nebudeme schopni předvídat vše. A dokud skutečně nevytáhneme spínač, nebudeme vědět, zda to bude fungovat nebo ne.
To je asi vše. Nebuďte líní a nepřehánějte to. A může být s vámi!
Zdroj: www.habr.com