Poleti se tradicionalno zmanjšata tako nakupna aktivnost kot intenzivnost sprememb v infrastrukturi spletnih projektov, nam pove Captain Obvious. Preprosto zato, ker gredo včasih tudi informatiki na dopust. In tudi tehnični direktor. Še toliko težje je tistim, ki ostajajo na položaju, a zdaj ne gre za to: morda je ravno zato poletje najboljši čas, da počasi razmislimo o obstoječi rezervacijski shemi in pripravimo načrt, kako jo izboljšati. In izkušnje Yegorja Andreeva iz , o čemer je govoril na konferenci .
Obstaja več pasti, v katere se lahko ujamete pri gradnji rezervnih spletnih mest. In popolnoma nemogoče se je ujeti vanje. In kar nas pri vsem tem, kot pri marsičem drugem, uničujeta, sta perfekcionizem in ... lenoba. Poskušamo narediti vse, vse, vse popolno, vendar nam ni treba, da naredimo popolno! Narediti morate samo določene stvari, vendar jih narediti pravilno, jih dokončati, da delujejo pravilno.
Failover ni nekakšna zabavna, zabavna stvar; to je stvar, ki bi morala storiti natanko eno stvar - zmanjšati izpade, tako da storitev, podjetje izgubi manj denarja. In pri vseh rezervacijskih metodah predlagam razmišljanje v naslednjem kontekstu: kje je denar?
Prva past: ko gradimo velike, zanesljive sisteme in izvajamo redundanco, zmanjšamo število nesreč. To je strašno napačno prepričanje. Ko se lotimo odpuščanja, bomo verjetno povečali število nesreč. In če bomo naredili vse pravilno, bomo skupaj zmanjšali izpade. Nesreč bo več, vendar bodo nastale z nižjimi stroški. Kaj je rezervacija? - to je zaplet sistema. Vsako zapletanje je slabo: imamo več zobnikov, več prestav, z eno besedo več elementov – in s tem večjo možnost okvare. In res se bodo zlomili. In pogosteje se bodo zlomili. Preprost primer: recimo, da imamo spletno stran s PHP in MySQL. In nujno ga je treba rezervirati.
Shtosh (c) Vzamemo drugo mesto, zgradimo enak sistem ... Kompleksnost postane dvakrat večja - imamo dve entiteti. Uvajamo tudi določeno logiko za prenos podatkov z enega mesta na drugo - to je podvajanje podatkov, kopiranje statičnih podatkov itd. Torej je logika replikacije običajno zelo zapletena, zato celotna kompleksnost sistema ni lahko 2, ampak 3, 5, 10-krat večja.
Druga past: ko gradimo res velike kompleksne sisteme, fantaziramo o tem, kaj želimo na koncu dobiti. Voila: želimo dobiti superzanesljiv sistem, ki deluje brez izpadov, preklopi v pol sekunde (ali še bolje, takoj) in začnemo uresničevati sanje. Toda tukaj je tudi odtenek: krajši kot je želeni preklopni čas, bolj zapletena postane sistemska logika. Bolj kot moramo kompleksno narediti to logiko, pogosteje se bo sistem pokvaril. In lahko se znajdete v zelo neprijetni situaciji: na vso moč se trudimo, da bi skrajšali izpade, v resnici pa vse bolj zapletamo in ko gre kaj narobe, se izpadi na koncu podaljšajo. Tukaj se pogosto ujameš, da misliš: no ... bolje bi bilo, da ne rezerviraš. Bolje bi bilo, če bi deloval sam in z razumljivimi izpadi.
Kako se lahko boriš proti temu? Nehati moramo lagati sami sebi, nehati si laskati, da bomo zdaj tukaj zgradili vesoljsko ladjo, ampak ustrezno razumeti, kako dolgo lahko projekt leži. In za ta največji čas bomo izbrali, katere metode bomo dejansko uporabili za povečanje zanesljivosti našega sistema.
Čas je za “zgodbe iz w”...iz življenja seveda.
Primer številka ena
Predstavljajte si spletno stran vizitke za valjarno cevi št. 1 v mestu N. Z velikimi črkami piše - valjarna cevi št. 1. Tik spodaj je slogan: "Naše cevi so najbolj okrogle cevi v N." In spodaj je telefonska številka generalnega direktorja in njegovo ime. Zavedamo se, da morate rezervirati - to je zelo pomembna stvar! Začnimo ugotavljati, iz česa je sestavljen. Html-statika - torej nekaj slik, kjer se generalni direktor pravzaprav za mizo v kopalnici s partnerjem pogovarja o nekem naslednjem poslu. Začnemo razmišljati o izpadih. Pride na misel: tam morate ležati pet minut, nič več. In potem se pojavi vprašanje, koliko je bilo sploh prodaj s te naše strani? Koliko - koliko? Kaj pomeni "nič"? In to pomeni: ker je general lani vse štiri transakcije opravil za isto mizo, z istimi ljudmi, s katerimi gredo v kopališče in sedijo za mizo. In razumemo, da tudi če spletno mesto stoji en dan, se ne bo zgodilo nič strašnega.
Na podlagi uvodnih informacij je dan za dvig te zgodbe. Začnimo razmišljati o shemi odpuščanja. In za ta primer izberemo najbolj idealno shemo redundance: ne uporabljamo redundance. To vso zadevo lahko dvigne vsak admin v pol ure z dimnimi pavzami. Namestite spletni strežnik, dodajte datoteke - to je to. Delovalo bo. Na nič vam ni treba paziti, ničemur ni treba biti posebej pozoren. To pomeni, da je sklep iz primera številka ena povsem očiten: storitev, ki jih ni treba rezervirati, ni treba rezervirati.
Primer številka dve
Blog podjetja: tam pišejo novice posebej usposobljeni ljudje, udeležili smo se takšne in drugačne razstave, pa smo izdali še en nov izdelek itd. Recimo, da je to standardni PHP z WordPressom, majhno bazo podatkov in malo statike. Seveda spet pride na misel, da pod nobenim pogojem ne bi smeli ležati - "ne več kot pet minut!" To je vse. A razmislimo naprej. Kaj počne ta blog? Ljudje pridejo tja iz Yandexa, iz Googla na podlagi nekih poizvedb, organsko. Super. Ali ima prodaja kaj opraviti s tem? Epifanija: res ne. Oglaševalski promet gre na glavno spletno mesto, ki je na drugem računalniku. Začnimo razmišljati o shemi rezervacij. Na dober način ga je treba dvigniti v nekaj urah in lepo bi bilo, da bi se na to pripravili. Smiselno bi bilo vzeti stroj iz drugega podatkovnega centra, vanj naviti okolje, torej spletni strežnik, PHP, WordPress, MySQL, in ga pustiti tam. V trenutku, ko razumemo, da je vse pokvarjeno, moramo narediti dve stvari - odložiti mysql dump 50 metrov, tja bo odletel čez minuto, in tam razviti določeno število slik iz varnostne kopije. Tudi tega ni že bog ve koliko časa. Tako v pol ure vse skupaj naraste. Brez podvajanja ali, bog odpusti, samodejni preklop. Zaključek: tistega, kar lahko hitro izpeljemo iz varnostne kopije, ni treba varnostno kopirati.
Primer številka tri, bolj zapleten
Spletna trgovina. PhP z odprtim srcem je malo popravljen, mysql s solidno osnovo. Precej statike (navsezadnje ima spletna trgovina lepe HD slike in vse te zadeve), Redis za sejo in Elasticsearch za iskanje. Začnemo razmišljati o izpadih. In tukaj je seveda očitno, da spletna trgovina ne more neboleče ležati en dan. Konec koncev, dlje kot leži, več denarja izgubimo. Vredno je pospešiti. Koliko? Mislim, da če eno uro poležimo, ne bo nobenemu znorelo. Ja, nekaj bomo izgubili, a če se bomo lotili trdega dela, bo samo še slabše. Določimo shemo dovoljenega izpada na uro.
Kako vse to rezervirati? V vsakem primeru potrebujete avto: ura časa je malo. Mysql: tukaj že potrebujemo replikacijo, replikacijo v živo, ker v eni uri 100 GB najverjetneje ne bo dodanih na smetišče. Statika, slike: spet, v eni uri 500 GB morda ne bo imel časa za dodajanje. Zato je bolje, da slike takoj kopirate. Redis: tukaj stvari postanejo zanimive. V Redisu so seje shranjene - ne moremo jih kar vzeti in zakopati. Ker to ne bo zelo dobro: vsi uporabniki bodo odjavljeni, njihove košarice se bodo izpraznile itd. Ljudje bodo prisiljeni znova vnesti svoje uporabniško ime in geslo, veliko ljudi pa se lahko odcepi in ne dokonča nakupa. Ponovno bodo padle konverzije. Po drugi strani je Redis neposredno posodobljen, pri čemer verjetno tudi zadnji prijavljeni uporabniki niso potrebni. In dober kompromis je, da vzamete Redis in ga obnovite iz varnostne kopije od včeraj ali, če to počnete vsako uro, izpred ene ure. Na srečo obnovitev iz varnostne kopije pomeni kopiranje ene datoteke. In najbolj zanimiva zgodba je Elasticsearch. Kdo se je kdaj lotil podvajanja MySQL? Kdo se je kdaj lotil replikacije Elasticsearch? In komu je potem normalno delal? Mislim, da v našem sistemu vidimo določeno entiteto. Zdi se, da je uporabno - vendar je zapleteno.
Kompleksno v smislu, da naši kolegi inženirji nimajo izkušenj z delom z njim. Ali pa obstaja negativna izkušnja. Ali pa razumemo, da je to še vedno dokaj nova tehnologija z odtenki ali surovostjo. Mislimo ... Prekleto, tudi elastika je zdrava, tudi obnavljanje iz varnostne kopije traja veliko časa, kaj naj naredim? Razumemo, da se elastika v našem primeru uporablja za iskanje. Kako poteka prodaja v naši spletni trgovini? Gremo k tržnikom in vprašamo, od kod prihajajo ljudje. Odgovorijo: "90% s trga Yandex pride neposredno na kartico izdelka." In ali ga kupijo ali pa ne. Zato iskanje potrebuje 10% uporabnikov. Ohranjanje elastične replikacije, zlasti med različnimi podatkovnimi centri v različnih conah, ima res veliko odtenkov. Kateri izhod? Elastiko vzamemo iz rezerviranega mesta in z njo ne naredimo ničesar. Če se bo zadeva vlekla, jo bomo morda kdaj dvignili, a to ni gotovo. Pravzaprav je zaključek enak, plus ali minus: spet ne rezerviramo storitev, ki ne vplivajo na denar. Da bo diagram preprostejši.
Primer številka štiri, še težji
Integrator: prodaja rož, klicanje taksija, prodaja blaga, na splošno karkoli. Resna zadeva, ki deluje 24/7 za veliko število uporabnikov. S polnopravnim zanimivim skladom, kjer so zanimive podlage, rešitve, visoka obremenitev in kar je najpomembneje, boli ležati več kot 5 minut. Ne samo in ne toliko zato, ker ljudje ne bodo kupovali, ampak ker bodo ljudje videli, da ta stvar ne deluje, se bodo razburili in se morda sploh ne bodo vrnili.
V REDU. Pet minut. Kaj bomo naredili glede tega? V tem primeru, kot odrasli, porabimo ves denar za izdelavo prave rezervne strani, z replikacijo vsega in morda celo avtomatiziramo prehod na to stran, kolikor je to mogoče. In poleg tega se morate spomniti, da morate narediti eno pomembno stvar: pravzaprav napisati predpise o preklopu. Predpisi, tudi če imate vse avtomatizirano, so lahko zelo preprosti. Iz niza "zaženi tak in tak ansible skript", "klikni to in to potrditveno polje na poti 53" in tako naprej - toda to mora biti nekakšen natančen seznam dejanj.
In vse se zdi jasno. Preklapljanje replikacije je nepomembna naloga ali pa se bo preklopilo samo. Prepisovanje imena domene v DNS je iz iste serije. Težava je v tem, da ko tak projekt propade, se začne panika, za katero so lahko dovzetni tudi najmočnejši, bradati admini. Brez jasnih navodil »odpri terminal, pridi sem, naslov našega strežnika je še vedno tak«, je težko izpolniti 5-minutno časovno omejitev, ki je namenjena oživljanju. No, poleg tega, ko uporabljamo te predpise, je enostavno zabeležiti na primer nekatere spremembe v infrastrukturi in ustrezno spremeniti predpise.
No, če je rezervacijski sistem zelo zapleten in smo na neki točki naredili napako, potem lahko uničimo svojo rezervno stran, poleg tega pa podatke na obeh straneh spremenimo v bučo - to bo popolnoma žalostno.
Primer številka pet, popoln hardcore
Mednarodna storitev z več sto milijoni uporabnikov po vsem svetu. Vsi časovni pasovi so, velika obremenitev pri največji hitrosti, sploh ne moreš ležati. Minuto - in žalostno bo. Kaj storiti? Rezerva spet po polnem programu. Naredili smo vse, o čemer sem govoril v prejšnjem primeru, in še malo več. Idealen svet, naša infrastruktura pa je po vseh konceptih IaaC devops. To pomeni, da je vse v git-u in samo pritisnete gumb.
Kaj manjka? Ena - vaje. Brez njih ne gre. Zdi se, da je pri nas vse popolno, na splošno imamo vse pod nadzorom. Pritisnemo gumb, vse se zgodi. Tudi če je temu tako - in razumemo, da se to ne dogaja tako - naš sistem sodeluje z nekaterimi drugimi sistemi. Na primer, to je dns iz poti 53, shranjevanje s3, integracija z nekim api. V tem špekulativnem eksperimentu ne bomo mogli predvideti vsega. In dokler stikala dejansko ne potegnemo, ne bomo vedeli, ali bo delovalo ali ne.
To je verjetno vse. Ne bodite leni in ne pretiravajte. In naj bo uptime z vami!
Vir: www.habr.com