V lete tradične klesá nákupná aktivita aj intenzita zmien v infraštruktúre webových projektov, hovorí nám Captain Obvious. Jednoducho preto, že aj IT špecialisti občas chodia na dovolenku. A tiež CTO. O to ťažšie je to pre tých, ktorí zostanú vo funkcii, ale o to teraz nejde: možno práve preto je leto tým najlepším obdobím na pomalé premýšľanie o existujúcej rezervačnej schéme a vypracovanie plánu na jej zlepšenie. A skúsenosť Yegora Andreeva z , o ktorej hovoril na konferencii .
Existuje niekoľko úskalí, do ktorých sa môžete dostať pri vytváraní záložných lokalít. A chytiť sa do nich je absolútne nemožné. A čo nás v tom všetkom ničí, ako aj v mnohých iných veciach, je perfekcionizmus a... lenivosť. Snažíme sa robiť všetko, všetko, všetko dokonale, ale nemusíme to robiť dokonale! Musíte robiť len určité veci, ale robiť ich správne, dokončiť ich tak, aby fungovali správne.
Failover nie je nejaký druh zábavy, zábavná vec; toto je vec, ktorá by mala robiť presne jednu vec – znížiť prestoje, aby služba, firma, prišla o menej peňazí. A pri všetkých metódach rezervácie navrhujem uvažovať v nasledujúcom kontexte: kde sú peniaze?
Prvá pasca: keď budujeme veľké, spoľahlivé systémy a využívame redundanciu, znižujeme počet nehôd. To je hrozná mylná predstava. Keď sa zapojíme do prepúšťania, pravdepodobne zvýšime počet nehôd. A ak urobíme všetko správne, spoločne znížime prestoje. Nehôd bude viac, no vzniknú s nižšími nákladmi. Čo je rezervácia? - ide o komplikáciu systému. Akákoľvek komplikácia je zlá: máme viac ozubených kolies, viac ozubených kolies, jedným slovom, viac prvkov – a teda väčšiu šancu na poruchu. A naozaj sa rozbijú. A budú sa častejšie lámať. Jednoduchý príklad: povedzme, že máme webovú stránku s PHP a MySQL. A to si treba urgentne rezervovať.
Shtosh (c) Vezmeme druhé miesto, postavíme identický systém... Zložitosť je dvojnásobná - máme dve entity. Zavádzame aj určitú logiku prenosu údajov z jednej lokality na druhú – to znamená replikáciu údajov, kopírovanie statických údajov atď. Takže logika replikácie je zvyčajne veľmi zložitá, a preto celková zložitosť systému môže byť nie 2, ale 3, 5, 10 krát väčšia.
Druhá pasca: keď staviame naozaj veľké komplexné systémy, fantazírujeme o tom, čo chceme nakoniec dosiahnuť. Voila: chceme získať super spoľahlivý systém, ktorý funguje bez akýchkoľvek prestojov, prepne sa za pol sekundy (alebo ešte lepšie, okamžite) a začneme si plniť sny. Ale je tu aj nuansa: čím kratší je požadovaný čas spínania, tým zložitejšia je logika systému. Čím zložitejšiu logiku musíme urobiť, tým častejšie sa bude systém rúcať. A môžete sa dostať do veľmi nepríjemnej situácie: zo všetkých síl sa snažíme znížiť prestoje, no v skutočnosti všetko komplikujeme a keď sa niečo pokazí, prestoje sa predĺžia. Tu sa často pristihnete, ako si myslíte: no... bolo by lepšie nerobiť si rezerváciu. Bolo by lepšie, keby to fungovalo samostatne a s pochopiteľnými prestojmi.
Ako s tým môžete bojovať? Musíme si prestať klamať, prestať sa lichotiť, že tu teraz postavíme vesmírnu loď, ale primerane pochopiť, ako dlho môže projekt ležať. A na tento maximálny čas si vyberieme, aké metódy vlastne použijeme na zvýšenie spoľahlivosti nášho systému.
Je čas na “príbehy z w”... zo života, samozrejme.
Príklad číslo jedna
Predstavte si webovú stránku s vizitkou pre valcovňu rúr číslo 1 v meste N. Veľkými písmenami je na nej napísané - ZÁVOD NA VALICOVANIE POTRUBÍ číslo 1. Hneď nižšie je slogan: „Naše rúry sú najokrúhlejšie rúry v N.“ A nižšie je telefónne číslo generálneho riaditeľa a jeho meno. Chápeme, že musíte urobiť rezerváciu - to je veľmi dôležitá vec! Začnime zisťovať, z čoho pozostáva. Html-statika - teda pár obrázkov, kde generálny riaditeľ v skutočnosti diskutuje o nejakom ďalšom obchode pri stole v kúpeľoch so svojou partnerkou. Začíname uvažovať o prestojoch. Prichádza na myseľ: musíte tam ležať päť minút, nie viac. A potom vyvstáva otázka: koľko predajov bolo celkovo z tejto našej stránky? Koľko-koľko? Čo znamená "nula"? A to znamená: pretože generál uskutočnil všetky štyri transakcie minulý rok pri jednom stole, s tými istými ľuďmi, s ktorými chodia do kúpeľov a sedia pri stole. A chápeme, že aj keď stránka sedí jeden deň, nič strašné sa nestane.
Na základe úvodných informácií je deň, kedy sa má tento príbeh nadviazať. Začnime uvažovať o schéme redundancie. A pre tento príklad volíme najideálnejšiu schému redundancie: redundanciu nepoužívame. Toto celé môže každý admin zdvihnúť do pol hodiny s dymovými prestávkami. Nainštalujte webový server, pridajte súbory - to je všetko. Bude to fungovať. Na nič netreba dohliadať, na nič si netreba dávať špeciálne pozor. To znamená, že záver z príkladu číslo jeden je celkom zrejmý: služby, ktoré nie je potrebné rezervovať, nie je potrebné rezervovať.
Príklad číslo dva
Firemný blog: špeciálne vyškolení ľudia tam píšu novinky, zúčastnili sme sa takej a takej výstavy, ale vydali sme ďalší nový produkt atď. Povedzme, že toto je štandardné PHP s WordPress, malou databázou a trochou statiky. Samozrejme, opäť prichádza na myseľ, že by ste si za žiadnych okolností nemali ľahnúť - "nie viac ako päť minút!" To je všetko. Ale zamyslime sa ďalej. Čo robí tento blog? Ľudia tam prichádzajú z Yandexu, z Google na základe nejakých dopytov, organicky. Skvelé. Má s tým niečo spoločné predaj? Epiphany: V skutočnosti nie. Reklamná návštevnosť smeruje na hlavnú stránku, ktorá je na inom počítači. Začnime premýšľať o schéme rezervácie. V dobrom slova zmysle ho treba zdvihnúť za pár hodín a bolo by fajn sa na to pripraviť. Bolo by rozumné vziať stroj z iného dátového centra, natočiť naň prostredie, teda webový server, PHP, WordPress, MySQL a nechať ho tam. V momente, keď pochopíme, že je všetko pokazené, treba urobiť dve veci – vyvaliť mysql skládku 50 metrov, doletí tam za minútu a vyvaliť tam určitý počet obrázkov zo zálohy. Toto tam tiež nie je bohvie ako dlho. Takto sa za pol hodinu celá vec zdvihne. Žiadna replikácia, alebo mi Boh odpusť, automatické zlyhanie. Záver: to, čo môžeme rýchlo zaviesť zo zálohy, nie je potrebné zálohovať.
Príklad číslo tri, zložitejší
Internetový obchod. PHP s otvoreným srdcom je trochu vylepšené, mysql s pevným základom. Pomerne veľa statického (napokon, online obchod má krásne HD obrázky a všetky tieto veci), Redis pre reláciu a Elasticsearch pre vyhľadávanie. Začíname uvažovať o prestojoch. A tu je, samozrejme, zrejmé, že internetový obchod nemôže bezbolestne ležať ani jeden deň. Veď čím dlhšie leží, tým viac peňazí strácame. Oplatí sa zrýchliť. Koľko? Myslím, že keď si hodinu ľahneme, nikto sa nezblázni. Áno, niečo stratíme, ale ak začneme tvrdo pracovať, bude to len horšie. Definujeme schému prestojov povolených za hodinu.
Ako sa dá toto všetko zarezervovať? V každom prípade potrebujete auto: hodina času je dosť málo. Mysql: tu už potrebujeme replikáciu, živú replikáciu, pretože za hodinu sa 100 GB s najväčšou pravdepodobnosťou nepridá na skládku. Statistika, obrázky: opäť za hodinu 500 GB možno nestihne pridať. Preto je lepšie obrázky ihneď skopírovať. Redis: Tu to začína byť zaujímavé. V Redis sú relácie uložené – nemôžeme to len tak vziať a pochovať. Pretože to nebude veľmi dobré: všetci používatelia budú odhlásení, ich košíky budú vyprázdnené atď. Ľudia budú nútení znova zadať svoje používateľské meno a heslo a veľa ľudí sa môže odtrhnúť a nedokončiť nákup. Konverzie opäť klesnú. Na druhej strane, Redis je priamo aktuálny, pričom posledných prihlásených používateľov zrejme tiež netreba. A dobrým kompromisom je vziať Redis a obnoviť ho zo zálohy zo včera, alebo ak to robíte každú hodinu, tak z pred hodinou. Našťastie jeho obnovenie zo zálohy znamená skopírovanie jedného súboru. A najzaujímavejší príbeh je Elasticsearch. Kto kedy chytil replikáciu MySQL? Kto kedy zachytil replikáciu Elasticsearch? A po kom to normálne fungovalo? Myslím tým, že v našom systéme vidíme určitú entitu. Zdá sa, že je to užitočné - ale je to zložité.
Komplexný v tom zmysle, že naši kolegovia inžinieri nemajú s prácou s ním žiadne skúsenosti. Alebo existuje negatívna skúsenosť. Alebo chápeme, že je to stále celkom nová technológia s nuansami alebo surovosťou. Myslíme si... Sakra, aj elastický je zdravý, tiež dlho trvá jeho obnovenie zo zálohy, čo mám robiť? Chápeme, že elastický v našom prípade sa používa na vyhľadávanie. Ako sa predáva náš internetový obchod? Chodíme za obchodníkmi a pýtame sa, odkiaľ ľudia pochádzajú. Odpovedajú: "90% z trhu Yandex prichádza priamo na kartu produktu." A buď to kúpia, alebo nie. Preto vyhľadávanie potrebuje 10 % používateľov. A udržiavanie elastickej replikácie, najmä medzi rôznymi dátovými centrami v rôznych zónach, skutočne existuje veľa nuancií. Ktorý východ? Vezmeme gumičku z vyhradenej stránky a nič s ňou nerobíme. Ak sa záležitosť bude naťahovať, možno ju niekedy nastolíme, ale to nie je isté. V skutočnosti je záver plus-mínus rovnaký: opäť nerezervujeme služby, ktoré neovplyvňujú peniaze. Aby bol diagram jednoduchší.
Príklad číslo štyri, ešte ťažší
Integrátor: predaj kvetov, volanie taxíka, predaj tovaru, vo všeobecnosti čokoľvek. Vážna vec, ktorá funguje 24/7 pre veľké množstvo používateľov. S plnohodnotným zaujímavým stackom, kde sú zaujímavé základy, riešenia, vysoká záťaž a hlavne bolí viac ako 5 minút ležať. Nielen a nie tak preto, že ľudia nebudú kupovať, ale pretože ľudia uvidia, že táto vec nefunguje, budú naštvaní a možno sa už vôbec nevrátia.
OK. Päť minút. Čo s tým urobíme? V tomto prípade, rovnako ako dospelí, používame všetky peniaze na vybudovanie skutočnej záložnej stránky s replikáciou všetkého a možno aj čo najviac automatizujeme prechod na túto stránku. A okrem toho musíte pamätať na jednu dôležitú vec: v skutočnosti napíšte pravidlá prepínania. Predpisy, aj keď máte všetko automatizované, môžu byť veľmi jednoduché. Zo série „spustite taký a taký ansible skript“, „kliknite na také a také začiarkavacie políčko na ceste 53“ a tak ďalej – ale toto musí byť nejaký presný zoznam akcií.
A všetko sa zdá byť jasné. Prepínanie replikácie je triviálna úloha, inak sa prepne sama. Prepísanie názvu domény v DNS je z rovnakej série. Problém je v tom, že keď takýto projekt zlyhá, začne panika a dokonca aj tí najsilnejší, bradatí správcovia môžu byť náchylní na to. Bez jasných pokynov „otvorte terminál, poďte sem, adresa nášho servera je stále taká“, je ťažké splniť 5-minútový časový limit určený na resuscitáciu. No a navyše, keď použijeme tieto predpisy, je ľahké zaznamenať napríklad nejaké zmeny v infraštruktúre a podľa toho zmeniť predpisy.
No, ak je rezervačný systém veľmi zložitý a v určitom okamihu sme urobili chybu, potom môžeme zničiť našu záložnú stránku a navyše premeniť dáta na tekvicu na oboch stránkach - to bude úplne smutné.
Príklad číslo päť, úplný hardcore
Medzinárodná služba so stovkami miliónov používateľov po celom svete. Všetky časové pásma sú, vysoké zaťaženie pri maximálnej rýchlosti, nemôžete si vôbec ľahnúť. Chvíľu - a bude to smutné. Čo robiť? Rezervácia opäť podľa kompletného programu. Urobili sme všetko, o čom som hovoril v predchádzajúcom príklade, a ešte trochu viac. Ideálny svet a naša infraštruktúra je v súlade so všetkými koncepciami vývoja IaaC. To znamená, že všetko je v Gite a stačí stlačiť tlačidlo.
Čo chýba? Jeden - cvičenia. Bez nich to nejde. Zdá sa, že u nás je všetko dokonalé, vo všeobecnosti máme všetko pod kontrolou. Stlačíme tlačidlo, všetko sa stane. Aj keď je to tak – a chápeme, že sa to takto nedeje – náš systém interaguje s niektorými inými systémami. Napríklad toto je dns z trasy 53, úložisko s3, integrácia s nejakým api. V tomto špekulatívnom experimente nebudeme môcť predvídať všetko. A kým skutočne nevytiahneme prepínač, nebudeme vedieť, či to bude fungovať alebo nie.
To je asi všetko. Nebuďte leniví ani to nepreháňajte. A môže byť s vami uptime!
Zdroj: hab.com