Ljeti se tradicionalno smanjuje i kupovna aktivnost i intenzitet promjena u infrastrukturi web projekata, kaže Captain Obvious. Jednostavno zato što i informatičari ponekad odu na godišnji odmor. I CTO također. Utoliko je teže onima koji ostaju na funkciji, ali nije sada u tome stvar: možda je zato ljeto najbolje razdoblje da se polako razmisli o postojećoj shemi rezervacija i napravi plan kako je poboljšati. I iskustvo Jegora Andreeva iz , o čemu je govorio na konferenciji .
Postoji nekoliko zamki u koje možete upasti prilikom izrade rezervnih stranica. I apsolutno je nemoguće uhvatiti se u njih. A ono što nas u svemu tome, kao i u mnogim drugim stvarima, upropaštava je perfekcionizam i... lijenost. Pokušavamo učiniti sve, sve, sve savršeno, ali ne trebamo to učiniti savršeno! Trebate samo raditi određene stvari, ali raditi ih ispravno, dovršavati ih tako da rade kako treba.
Failover nije neka vrsta zabavne, zabavne stvari; ovo je stvar koja bi trebala učiniti točno jednu stvar - smanjiti zastoje kako bi usluga, tvrtka, gubila manje novca. I u svim načinima rezervacije predlažem razmišljanje u sljedećem kontekstu: gdje je novac?
Prva zamka: kada gradimo velike, pouzdane sustave i uključimo se u redundanciju, smanjujemo broj nesreća. Ovo je užasna zabluda. Kad se uključimo u redundanciju, vjerojatno ćemo povećati broj nesreća. A ako sve napravimo kako treba, zajednički ćemo smanjiti vrijeme zastoja. Bit će više nesreća, ali će se dogoditi uz manje troškove. Što je rezervacija? - ovo je komplikacija sustava. Svako kompliciranje je loše: imamo više zupčanika, više zupčanika, jednom riječju, više elemenata - a time i veće šanse za kvar. I stvarno će se slomiti. I češće će se lomiti. Jednostavan primjer: recimo da imamo web stranicu s PHP-om i MySQL-om. I hitno ga treba rezervirati.
Shtosh (c) Uzimamo drugo mjesto, gradimo identičan sustav... Složenost postaje dvostruko veća - imamo dva entiteta. Također uvodimo određenu logiku za prijenos podataka s jednog mjesta na drugo - to jest replikaciju podataka, kopiranje statičkih podataka i tako dalje. Dakle, logika replikacije je obično vrlo složena, pa stoga ukupna složenost sustava može biti ne 2, već 3, 5, 10 puta veća.
Druga zamka: kada gradimo stvarno velike složene sustave, maštamo o tome što želimo dobiti na kraju. Voila: želimo dobiti super-pouzdan sustav koji radi bez ikakvih zastoja, prebacuje se u pola sekunde (ili još bolje, odmah), i počinjemo ostvarivati snove. Ali ovdje postoji i nijansa: što je kraće željeno vrijeme prebacivanja, to je logika sustava složenija. Što kompleksniju ovu logiku moramo napraviti, to će se sustav češće kvariti. I možete doći u vrlo neugodnu situaciju: mi se svim silama trudimo smanjiti vrijeme zastoja, a zapravo sve kompliciramo i kad nešto pođe po zlu, zastoj će na kraju biti duži. Ovdje se često uhvatite kako mislite: pa... bilo bi bolje da ne rezervirate. Bilo bi bolje da radi samostalno i uz razumljive zastoje.
Kako se možete boriti protiv ovoga? Moramo prestati lagati sami sebe, prestati si laskati da ćemo sada ovdje graditi svemirski brod, već razumjeti koliko dugo projekt može ležati. I za to maksimalno vrijeme, mi ćemo odabrati koje metode ćemo zapravo koristiti za povećanje pouzdanosti našeg sustava.
Vrijeme je za “priče iz w”... iz života, naravno.
Primjer broj jedan
Zamislite web stranicu posjetnice Valjaonice cijevi br. 1 u gradu N. Velikim slovima piše - Valjaonica cijevi br. 1. Odmah ispod je slogan: "Naše lule su najzaobljenije lule u N." A ispod je telefonski broj glavnog direktora i njegovo ime. Razumijemo da morate rezervirati - ovo je vrlo važna stvar! Počnimo shvaćati od čega se sastoji. Html-statika - odnosno par slika na kojima generalni direktor, zapravo, za stolom u kupatilu sa svojim partnerom raspravlja o nekakvom sljedećem poslu. Počinjemo razmišljati o zastoju. Pada mi na pamet: morate ležati pet minuta, ne više. I onda se postavlja pitanje koliko je uopće bilo prodaja s ove naše stranice? Koliko-koliko? Što znači "nula"? A to znači: zato što je general prošle godine sve četiri transakcije napravio za istim stolom, s istim ljudima s kojima idu u kupalište i sjede za stolom. I razumijemo da čak i ako stranica sjedi jedan dan, ništa strašno se neće dogoditi.
Na temelju uvodnih informacija, postoji dan za podizanje ove priče. Počnimo razmišljati o shemi otpuštanja. I mi biramo najidealniju shemu redundancije za ovaj primjer: ne koristimo redundanciju. Cijelu ovu stvar može podići svaki admin u pola sata uz pauze za dim. Instalirajte web poslužitelj, dodajte datoteke - to je to. Radit će. Ne trebaš ništa paziti, ne trebaš ni na što posebno paziti. Odnosno, zaključak iz primjera broj jedan sasvim je očit: usluge koje se ne moraju rezervirati ne moraju se rezervirati.
Primjer broj dva
Blog tvrtke: tamo posebno obučeni ljudi pišu vijesti, sudjelovali smo na toj i takvoj izložbi, ali smo izdali još jedan novi proizvod, i tako dalje. Recimo da je ovo standardni PHP s WordPressom, malom bazom podataka i malo statike. Naravno, opet pada na pamet da ni pod kojim okolnostima ne biste trebali ležati - "ne više od pet minuta!" To je sve. Ali razmislimo dalje. Što ovaj blog radi? Ljudi tamo dolaze s Yandexa, s Googlea na temelju nekih upita, organski. Sjajno. Ima li prodaja ikakve veze s tim? Bogojavljenje: ne baš. Oglašavački promet ide na glavnu stranicu, koja je na drugom stroju. Počnimo razmišljati o shemi rezervacija. Na dobar način, treba ga podignuti za nekoliko sati, a bilo bi lijepo pripremiti se za to. Bilo bi razumno uzeti stroj iz drugog podatkovnog centra, uvaljati na njega okruženje, odnosno web server, PHP, WordPress, MySQL i ostaviti ga tamo. U trenutku kada shvatimo da je sve pokvareno, trebamo napraviti dvije stvari - razvaljati mysql dump 50 metara, on će doletjeti za minutu, i tamo razvaljati određeni broj slika iz backupa. Ovoga također nema bog zna koliko dugo. Ovako, za pola sata sve se digne. Nema replikacije, ili Bože oprosti, automatski failover. Zaključak: ono što možemo brzo pokrenuti iz sigurnosne kopije ne treba sigurnosno kopirati.
Primjer broj tri, kompliciraniji
Internet trgovina. PhP s otvorenim srcem je malo dotjeran, mysql sa solidnom bazom. Dosta statike (uostalom, online trgovina ima prekrasne HD slike i sve te stvari), Redis za sesiju i Elasticsearch za pretraživanje. Počinjemo razmišljati o zastoju. I ovdje je, naravno, očito da internetska 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, nitko neće poludjeti. Da, izgubit ćemo nešto, ali ako se počnemo truditi, bit će samo gore. Definiramo shemu dopuštenog zastoja po satu.
Kako se sve to može rezervirati? Automobil vam treba u svakom slučaju: sat vremena je malo. Mysql: ovdje već trebamo replikaciju, replikaciju uživo, jer za sat vremena 100 GB najvjerojatnije neće biti dodano u dump. Statika, slike: opet, za sat vremena 500 GB možda neće imati vremena za dodavanje. Stoga je bolje kopirati slike odmah. Redis: ovdje stvari postaju zanimljive. U Redisu su sesije pohranjene - ne možemo to samo uzeti i zakopati. Jer ovo neće biti baš dobro: svi će korisnici biti odjavljeni, njihove košarice će biti ispražnjene i tako dalje. Ljudi će biti prisiljeni ponovno unijeti svoje korisničko ime i lozinku, a mnogi bi se ljudi mogli odvojiti i ne dovršiti kupnju. Opet, konverzije će pasti. S druge strane, Redis je izravno ažuran, a posljednji prijavljeni korisnici vjerojatno nisu ni potrebni. A dobar kompromis je uzeti Redis i vratiti ga iz sigurnosne 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. Tko je ikada pokupio MySQL replikaciju? Tko je ikada pokupio Elasticsearch replikaciju? I kome je to poslije normalno radilo? Ono što mislim je da vidimo određeni entitet u našem sustavu. Čini se da je korisno - ali je složeno.
Kompleksan u smislu da naši kolege inženjeri nemaju iskustva u radu s njim. Ili postoji negativno iskustvo. Ili razumijemo da je ovo još uvijek prilično nova tehnologija s nijansama ili sirovošću. Mislimo... K vragu, i elastika je zdrava, također je potrebno dosta vremena da se obnovi iz sigurnosne kopije, što da radim? Razumijemo da se elastik u našem slučaju koristi za pretragu. Kako se prodaje naša online trgovina? Idemo kod trgovaca i pitamo odakle dolaze ljudi. Oni odgovaraju: "90% s Yandex Marketa dolazi izravno na karticu proizvoda." I ili ga kupuju ili ne. Dakle, pretraživanje je potrebno za 10% korisnika. A održavanje elastične replikacije, posebno između različitih podatkovnih centara u različitim zonama, ima stvarno mnogo nijansi. Koji izlaz? Uzimamo elastiku s rezerviranog mjesta i ne radimo ništa s njom. Ako se slučaj bude odugovlačio, možda ćemo ga kad-tad podignuti, ali to nije sigurno. Zapravo, zaključak je isti, plus ili minus: mi opet ne rezerviramo usluge koje ne utječ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 što. Ozbiljna stvar koja radi 24/7 za veliki broj korisnika. S punopravnim zanimljivim snopom, gdje postoje zanimljive baze, rješenja, veliko opterećenje, i što je najvažnije, boli ležati dulje od 5 minuta. Ne samo i ne toliko zato što ljudi neće kupovati, već zato što će ljudi vidjeti da ova stvar ne radi, uzrujat će se i možda se uopće neće vratiti.
U REDU. Pet minuta. Što ćemo učiniti u vezi ovoga? U ovom slučaju, mi, poput odraslih, koristimo sav novac za izradu prave backup stranice, s replikacijom svega, a možda čak i automatiziramo prebacivanje na ovu stranicu koliko god je to moguće. I uz to, morate se sjetiti učiniti jednu važnu stvar: zapravo napisati propise o prebacivanju. Propisi, čak i ako imate sve automatizirano, mogu biti vrlo jednostavni. Iz niza “pokreni taj i taj ansible skript”, “klikni na taj i taj potvrdni okvir u ruti 53” i tako dalje - ali ovo mora biti neka vrsta točnog popisa radnji.
I sve se čini jasnim. Prebacivanje replikacije je trivijalan zadatak ili će se prebaciti sam. Prepisivanje naziva domene u DNS-u je iz iste serije. Problem je u tome što kad takav projekt propadne, počinje panika kojoj mogu biti podložni i najjači, bradati admini. Bez jasnih uputa "otvorite terminal, dođite ovamo, adresa našeg poslužitelja je još uvijek ovakva", teško je ispuniti 5-minutno vremensko ograničenje dodijeljeno za reanimaciju. Pa, plus, kada koristimo ove propise, lako je zabilježiti neke promjene u infrastrukturi, na primjer, i promijeniti propise u skladu s tim.
Pa, ako je sustav rezervacija vrlo složen i u nekom trenutku smo pogriješili, onda možemo uništiti svoju rezervnu stranicu, a uz to pretvoriti podatke u bundevu na obje stranice - to će biti potpuno tužno.
Primjer broj pet, potpuni hardcore
Međunarodna usluga sa stotinama milijuna korisnika diljem svijeta. Sve vremenske zone su tu, veliko opterećenje pri maksimalnoj brzini, ne možete uopće leći. Minuta - i bit će tužno. Što uraditi? Rezervirajte, opet, po punom programu. Napravili smo sve o čemu sam govorio u prethodnom primjeru, i još malo više. Idealan svijet, a naša infrastruktura je po svim konceptima IaaC devopsa. Odnosno, sve je u git-u, a vi samo pritisnete gumb.
Što nedostaje? Jedan - vježbe. Bez njih se ne može. Čini se da je kod nas sve savršeno, uglavnom imamo sve pod kontrolom. Pritisnemo dugme, sve se dogodi. Čak i ako je tako - a mi razumijemo da se to ne događa na ovaj način - naš sustav je u interakciji s nekim drugim sustavima. Na primjer, ovo je dns iz route 53, s3 storage, integracija s nekim api. U ovom spekulativnom eksperimentu nećemo moći sve predvidjeti. I dok stvarno ne povučemo prekidač, nećemo znati hoće li raditi ili ne.
To je vjerojatno sve. Nemojte biti lijeni niti pretjerivati. I neka vrijeme neprekidnog rada bude s vama!
Izvor: www.habr.com