Ljeti se tradicionalno smanjuje i kupovna aktivnost i intenzitet promjena u infrastrukturi web projekata, kaže nam Captain Ovious. Jednostavno zato što čak i IT stručnjaci ponekad odu na odmor. I CTO također. Utoliko je teže onima koji ostaju na funkciji, ali to sada nije poenta: možda je zato ljeto najbolji period da polako razmislite o postojećoj šemi rezervacija i napravite plan za njeno poboljšanje. I iskustvo Jegora Andreeva iz , o čemu je govorio na konferenciji .
Postoji nekoliko zamki u koje možete upasti kada pravite rezervne stranice. I apsolutno je nemoguće upasti u njih. A ono što nas u svemu ovome, kao i u mnogim drugim stvarima, uništava je perfekcionizam i...lijenost. Trudimo se da sve, sve, sve radimo savršeno, ali ne treba da radimo savršeno! Potrebno je samo da uradite određene stvari, ali da ih uradite ispravno, da ih dovršite tako da rade kako treba.
Failover nije neka zabavna, zabavna stvar; ovo je stvar koja treba da uradi samo jednu stvar - da smanji zastoje tako da usluga, kompanija, gubi manje novca. I u svim metodama rezervacije predlažem razmišljanje u sljedećem kontekstu: gdje je novac?
Prva zamka: kada gradimo velike, pouzdane sisteme i uključimo se u redundantnost, smanjujemo broj nesreća. Ovo je strašna zabluda. Kada se uključimo u višak radnika, vjerovatno ćemo povećati broj nesreća. A ako sve učinimo kako treba, onda ćemo zajedno smanjiti vrijeme zastoja. Biće još nesreća, ali će se desiti po nižim troškovima. Šta je rezervacija? - ovo je komplikacija sistema. Svaka komplikacija je loša: imamo više zupčanika, više zupčanika, jednom riječju, više elemenata - i, stoga, veće šanse za kvar. I zaista će se slomiti. I češće će se lomiti. Jednostavan primjer: recimo da imamo web stranicu sa PHP-om i MySQL-om. I to hitno treba rezervisati.
Štoš (c) Uzimamo drugu lokaciju, gradimo identičan sistem... Kompleksnost postaje duplo veća - imamo dva entiteta. Uvodimo i određenu logiku za prijenos podataka s jedne lokacije na drugu - odnosno replikaciju podataka, kopiranje statičkih podataka itd. Dakle, logika replikacije je obično vrlo složena, pa stoga ukupna složenost sistema može biti ne 2, već 3, 5, 10 puta veća.
Druga zamka: kada gradimo zaista velike složene sisteme, maštamo o tome šta želimo da dobijemo na kraju. Voila: želimo da dobijemo super-pouzdan sistem koji radi bez ikakvih zastoja, prebacuje se za pola sekunde (ili još bolje, trenutno) i počinjemo da ostvarujemo snove. Ali ovdje postoji i nijansa: što je kraće željeno vrijeme uključivanja, to sistemska logika postaje složenija. Što složeniju moramo napraviti ovu logiku, to će se sistem češće kvariti. I možete završiti u vrlo neugodnoj situaciji: svim silama pokušavamo smanjiti zastoje, a zapravo sve komplikujemo, a kada nešto krene po zlu, zastoj će na kraju biti duži. Ovdje se često uhvatite kako mislite: pa... bolje bi bilo da ne rezervišete. Bilo bi bolje da radi sam i sa razumljivim zastojima.
Kako se možeš boriti protiv ovoga? Moramo da prestanemo da lažemo sami sebe, da prestanemo da laskamo sebi da ćemo sada ovde da gradimo svemirski brod, ali da adekvatno shvatimo koliko dugo projekat može da leži. I za ovo maksimalno vrijeme, mi ćemo izabrati koje ćemo metode zapravo koristiti za povećanje pouzdanosti našeg sistema.
Vrijeme je za “priče iz w”... iz života, naravno.
Primjer broj jedan
Zamislite web stranicu sa vizit kartama za Valjaonicu cijevi br. 1 u gradu N. Na njoj velikim slovima piše - Fabrika za valjanje cijevi br. 1. Odmah ispod je slogan: "Naše lule su najokruglije lule u N." A ispod je telefonski broj izvršnog direktora i njegovo ime. Razumijemo da morate izvršiti rezervaciju - ovo je vrlo važna stvar! Počnimo shvatiti od čega se sastoji. Html-statika - odnosno par slika na kojima generalni direktor, u stvari, raspravlja o nekakvom sljedećem dogovoru za stolom u kupatilu sa svojim partnerom. Počinjemo razmišljati o zastoju. Pada mi na pamet: tu treba ležati pet minuta, ne više. I onda se postavlja pitanje koliko je uopšte bilo prodaja sa ovog našeg sajta? Koliko-koliko? Šta znači "nula"? A to znači: zato što je general sve četiri transakcije prošle godine napravio za istim stolom, sa istim ljudima sa kojima idu u kupatilo i sjede za stolom. I razumijemo da se ništa strašno neće dogoditi čak i ako stranica stoji jedan dan.
Na osnovu uvodnih informacija, postoji dan za pokretanje ove priče. Počnimo razmišljati o shemi redundancije. I mi biramo najidealniju shemu redundancije za ovaj primjer: ne koristimo redundantnost. Cijelu ovu stvar svaki admin može podići za pola sata sa pauzama za dim. Instalirajte web server, dodajte fajlove - to je to. Upalit će. Ne morate paziti ni na šta, ne morate ni na šta obraćati posebnu pažnju. Odnosno, zaključak iz primjera broj jedan je sasvim očigledan: usluge koje ne treba rezervirati ne moraju biti rezervirane.
Primjer broj dva
Blog kompanije: tamo pišu novosti specijalno obučeni ljudi, učestvovali smo na takvoj i takvoj izložbi, ali smo izbacili još jedan novi proizvod i tako dalje. Recimo da je ovo standardni PHP sa WordPress-om, malom bazom podataka i malo statike. Naravno, opet mi pada na pamet da ni u kom slučaju ne treba ležati - "ne više od pet minuta!" To je sve. Ali hajde da razmislimo dalje. Šta radi ovaj blog? Ljudi tamo dolaze iz Yandexa, iz Gugla na osnovu nekih upita, organski. Odlično. Ima li prodaja ikakve veze s tim? Bogojavljenje: ne baš. Promet oglašavanja ide na glavnu stranicu, koja je na drugoj mašini. Počnimo razmišljati o šemi rezervacije. U dobrom smislu, treba ga podići za par sati i bilo bi lijepo pripremiti se za to. Bilo bi razumno uzeti mašinu iz drugog data centra, na nju prebaciti okruženje, odnosno web server, PHP, WordPress, MySQL i ostaviti ga tamo. U momentu kada shvatimo da je sve pokvareno, treba da uradimo dve stvari - da odmotamo mysql dump 50 metara, on će doleteti tamo za minut, i tamo izbaciti određeni broj slika iz rezervne kopije. Ovoga takođe nema bogzna koliko dugo. Tako se za pola sata cijela stvar diže. Bez replikacije, ili Bože oprosti mi, automatsko prebacivanje na grešku. Zaključak: ono što možemo brzo izbaciti iz sigurnosne kopije ne mora biti sigurnosno kopirano.
Primjer broj tri, komplikovaniji
Online prodavnica. PhP otvorenog srca je malo dotjeran, mysql sa solidnom bazom. Dosta statike (na kraju krajeva, online prodavnica ima prelepe HD slike i sve te stvari), Redis za sesiju i Elasticsearch za pretragu. Počinjemo razmišljati o zastoju. I ovdje je, naravno, očito da online trgovina ne može bezbolno ležati jedan dan. Uostalom, što duže leži, gubimo više novca. Vrijedi ubrzati. Koliko? Mislim da ako legnemo sat vremena, niko neće poludeti. Da, nešto ćemo izgubiti, ali ako počnemo vredno raditi, biće samo još gore. Definiramo shemu dozvoljenog zastoja po satu.
Kako se sve ovo može rezervisati? Auto vam je u svakom slučaju potreban: sat vremena je malo. Mysql: ovdje nam je već potrebna replikacija, replikacija uživo, jer za sat vremena 100 GB najvjerovatnije neće biti dodato u dump. Statika, slike: opet, za sat vremena 500 GB možda neće imati vremena da se doda. Stoga je bolje odmah kopirati slike. Redis: ovdje stvari postaju zanimljive. U Redis-u se sesije pohranjuju - ne možemo to samo uzeti i zakopati. Jer ovo neće biti baš dobro: svi korisnici će biti odjavljeni, njihove korpe će biti ispražnjene, itd. Ljudi će biti primorani da ponovo unesu svoje korisničko ime i lozinku, a mnogi ljudi se mogu odvojiti i neće završiti kupovinu. Opet, konverzije će pasti. S druge strane, Redis je direktno ažuran, pri čemu vjerovatno nisu potrebni ni posljednji prijavljeni korisnici. A dobar kompromis je da uzmete Redis i vratite ga iz rezervne kopije od jučer, ili, ako to radite svaki sat, od prije sat vremena. Srećom, vraćanje iz sigurnosne kopije znači kopiranje jedne datoteke. A najzanimljivija priča je Elasticsearch. Ko je ikada preuzeo MySQL replikaciju? Ko je ikada preuzeo Elasticsearch replikaciju? I za koga je to poslije normalno funkcioniralo? Ono što mislim je da vidimo određeni entitet u našem sistemu. Čini se da je korisno - ali je složeno.
Kompleksan u smislu da naši kolege inženjeri nemaju iskustva u radu sa njim. Ili postoji negativno iskustvo. Ili razumijemo da je ovo još uvijek prilično nova tehnologija s nijansama ili sirovošću. Mislimo... Dođavola, elastična je i zdrava, takođe je potrebno dosta vremena da se vrati sa rezervne kopije, šta da radim? Razumijemo da se elastična u našem slučaju koristi za pretragu. Kako se prodaje naša internet prodavnica? Idemo do marketinških radnika i pitamo odakle ljudi dolaze. Oni odgovaraju: "90% sa Yandex Marketa dolazi direktno na karticu proizvoda." I ili ga kupuju ili ne. Stoga je pretraga potrebna za 10% korisnika. A održavanje elastične replikacije, posebno između različitih centara podataka u različitim zonama, zaista ima mnogo nijansi. Koji izlaz? Uzimamo elastičnu sa rezervisanog sajta i ne radimo ništa sa njom. Ako se stvar oduži, vjerovatno ćemo je jednom pokrenuti, ali to nije sigurno. Zapravo, zaključak je isti, plus ili minus: mi, opet, ne rezervišemo usluge koje ne utiču na novac. Da bi dijagram bio jednostavniji.
Primjer broj četiri, još teži
Integrator: prodaja cvijeća, pozivanje taksija, prodaja robe, općenito, bilo čega. Ozbiljna stvar koja radi 24/7 za veliki broj korisnika. Sa punopravnim zanimljivim stekom, gdje postoje zanimljive osnove, rješenja, veliko opterećenje, i što je najvažnije, boli ležati više od 5 minuta. Ne samo i ne toliko zato što ljudi neće da kupuju, već zato što će ljudi videti da ovo ne radi, uznemiriće se i možda se uopšte neće vratiti.
UREDU. Pet minuta. Šta ćemo učiniti po tom pitanju? U ovom slučaju, mi, kao i odrasli, koristimo sav novac da napravimo pravi backup sajt, sa replikacijom svega, a možda čak i automatizujemo prelazak na ovu stranicu koliko god je to moguće. I pored ovoga, morate zapamtiti da uradite jednu važnu stvar: zapravo, napišite propise o prebacivanju. Propisi, čak i ako imate sve automatizirano, mogu biti vrlo jednostavni. Iz serije “pokreni tu i takvu ansible skriptu”, “klikni na taj i takav kvadratić na ruti 53” i tako dalje - ali ovo mora biti neka vrsta tačne liste akcija.
I sve izgleda jasno. Prebacivanje replikacije je trivijalan zadatak, ili će se sama prebaciti. Prepisivanje imena domena u DNS-u je iz iste serije. Nevolja je u tome što kada takav projekat propadne, počinje panika, pa čak i najjači, bradati administratori mogu biti podložni tome. Bez jasnih instrukcija „otvori terminal, dođi ovamo, adresa našeg servera je i dalje ovakva“, teško je ispoštovati rok od 5 minuta za reanimaciju. Pa, plus, kada koristimo ove propise, lako je zabilježiti neke promjene u infrastrukturi, na primjer, i shodno tome promijeniti propise.
Pa, ako je sistem rezervacija vrlo složen i u nekom trenutku smo pogriješili, onda možemo uništiti našu rezervnu stranicu, a uz to pretvoriti podatke u bundevu na obje stranice - ovo će biti potpuno tužno.
Primjer broj pet, potpuni hardcore
Međunarodna usluga sa stotinama miliona korisnika širom svijeta. Sve vremenske zone postoje, veliko opterećenje pri maksimalnoj brzini, nikako ne možete ležati. Minut - i biće tužno. sta da radim? Rezervišite, opet, po punom programu. Uradili smo sve o čemu sam govorio u prethodnom primjeru, i još malo više. Idealan svijet, a naša infrastruktura je u skladu sa svim konceptima IaaC devopsa. To jest, sve je u git-u, a vi samo pritisnete dugme.
Šta nedostaje? Jedan - vežbe. Bez njih je nemoguće. Čini se da je kod nas sve savršeno, generalno sve imamo pod kontrolom. Pritisnemo dugme, sve se dešava. Čak i ako je to tako - a mi razumijemo da se to ne dešava na ovaj način - naš sistem je u interakciji sa nekim drugim sistemima. Na primjer, ovo je dns sa rute 53, s3 skladište, integracija sa nekim API-jem. U ovom spekulativnom eksperimentu nećemo moći sve predvidjeti. I dok zapravo ne povučemo prekidač, nećemo znati hoće li raditi ili ne.
To je vjerovatno sve. Nemojte biti lijeni ili pretjerati. I neka je produženje rada uz vas!
izvor: www.habr.com