Artem Denisov ( , )
Badoo je najveća svjetska stranica za upoznavanje. Trenutno imamo oko 330 milijuna registriranih korisnika diljem svijeta. Ali ono što je puno važnije u kontekstu našeg današnjeg razgovora jest da pohranjujemo oko 3 petabajta korisničkih fotografija. Svaki dan naši korisnici postavljaju oko 3,5 milijuna novih fotografija, a opterećenje čitanja je otprilike 80 tisuća zahtjeva u sekundi. To je dosta za našu pozadinu i ponekad ima poteškoća s tim.
Govorit ću o dizajnu ovog sustava, koji pohranjuje i šalje fotografije u cjelini, i dat ću pogled na njega sa stajališta programera. Bit će kratka retrospektiva o tome kako se razvijao, gdje ću navesti glavne prekretnice, ali ću samo detaljnije govoriti o rješenjima koja trenutno koristimo.
Sada počnimo.
Kao što rekoh, ovo će biti retrospektiva, a da bismo je negdje započeli, uzmimo najobičniji primjer.
Imamo zajednički zadatak, moramo prihvatiti, pohraniti i poslati fotografije korisnika. U ovom obliku, zadatak je opći, možemo koristiti bilo što:
- moderna pohrana u oblaku,
- rješenje u kutiji, kojih sada također ima puno;
- Možemo postaviti nekoliko strojeva u našem podatkovnom centru i na njih staviti velike tvrde diskove i tamo pohranjivati fotografije.
Badoo povijesno - i sada i tada (u vrijeme kada je tek bio u povojima) - živi na svojim vlastitim poslužiteljima, unutar naših vlastitih DC-ova. Stoga je ova opcija bila optimalna za nas.
Upravo smo uzeli nekoliko strojeva, nazvali ih "fotografije", i dobili smo klaster koji pohranjuje fotografije. Ali čini se kao da nešto nedostaje. Da bi sve ovo funkcioniralo, moramo nekako odrediti na kojem ćemo stroju koje fotografije pohranjivati. A ni tu ne treba otvarati Ameriku.
Dodamo neko polje u našu pohranu s podacima o korisnicima. Ovo će biti ključ za dijeljenje. U našem slučaju, nazvali smo ga place_id, a ovaj id mjesta ukazuje na mjesto gdje su pohranjene fotografije korisnika. Izrađujemo karte.
U prvoj fazi to se može učiniti čak i ručno - kažemo da će fotografija ovog korisnika s takvim mjestom sletjeti na takav poslužitelj. Zahvaljujući ovoj karti, uvijek znamo kada korisnik postavi fotografiju, gdje je spremiti i znamo odakle je dati.
Ovo je apsolutno trivijalna shema, ali ima prilično značajne prednosti. Prvo je to što je jednostavno, kao što sam rekao, a drugo je to što s ovim pristupom možemo lako skalirati horizontalno jednostavnom isporukom novih automobila i njihovim dodavanjem na kartu. Ne trebate raditi ništa drugo.
Tako nam je bilo neko vrijeme.
Bilo je to oko 2009. Isporučili su automobile, isporučili...
I u nekom smo trenutku počeli primjećivati da ova shema ima određene nedostatke. Koji su nedostaci?
Prije svega, kapacitet je ograničen. Ne možemo strpati onoliko tvrdih diskova na jedan fizički poslužitelj koliko bismo htjeli. I to je postao određeni problem tijekom vremena i s rastom skupa podataka.
I drugo. Ovo je netipična konfiguracija strojeva, budući da je takve strojeve teško ponovno koristiti u nekim drugim klasterima, dosta su specifični, tj. trebali bi biti slabi u performansama, ali u isto vrijeme s velikim tvrdim diskom.
To je bilo sve za 2009. godinu, ali u načelu ti zahtjevi važe i danas. Imamo retrospektivu, pa 2009. s ovim je sve bilo skroz loše.
I posljednja točka je cijena.
Cijena je u to vrijeme bila vrlo visoka i morali smo tražiti neke alternative. Oni. morali smo nekako bolje iskoristiti i prostor u podatkovnim centrima i fizičke servere na kojima se sve to nalazi. Naši inženjeri sustava započeli su veliku studiju u kojoj su pregledali hrpu različitih opcija. Također su pogledali klasterirane datotečne sustave kao što su PolyCeph i Luster. Bilo je problema s performansama i prilično teškog rada. Odbili su. Pokušali smo montirati cijeli skup podataka putem NFS-a na svaki automobil kako bismo ga nekako povećali. Čitanje je također išlo loše, isprobali smo različita rješenja od različitih dobavljača.
I na kraju smo se odlučili za tzv. Storage Area Network.
To su veliki SHD-ovi koji su posebno dizajnirani za pohranjivanje velikih količina podataka. To su police s diskovima koje se montiraju na konačne optičke izlazne strojeve. Da. imamo neku vrstu skupa strojeva, prilično malih, i ovih SHD-ova, koji su transparentni našoj logici slanja, tj. za naš nginx ili bilo koga drugog da posluži zahtjeve za ove fotografije.
Ova je odluka imala očite prednosti. Ovo je SHD. Namijenjen je pohrani fotografija. Ovo je jeftinije od jednostavnog opremanja strojeva tvrdim diskovima.
Drugi plus.
To je da je kapacitet postao puno veći, tj. možemo primiti mnogo više prostora za pohranu u mnogo manjem volumenu.
Ali bilo je i nedostataka koji su se vrlo brzo pojavili. Kako je broj korisnika i opterećenje ovog sustava raslo, počeli su se javljati problemi s performansama. A problem je ovdje sasvim očit - svaki SHD dizajniran za pohranjivanje mnogo fotografija u malom volumenu, u pravilu, pati od intenzivnog čitanja. Ovo zapravo vrijedi za bilo koju pohranu u oblaku ili bilo što drugo. Sada nemamo idealnu pohranu koja bi bila beskonačno skalabilna, u nju biste mogli strpati bilo što, a ona bi vrlo dobro podnosila očitavanja. Pogotovo ležerna čitanja.
Kao što je slučaj s našim fotografijama, jer se fotografije traže nedosljedno, a to će uvelike utjecati na njihovu izvedbu.
Čak i prema današnjim brojkama, ako dobijemo negdje više od 500 RPS za fotografije na stroju na koji je spojena pohrana, problemi već počinju. I bilo nam je dovoljno loše, jer broj korisnika raste, stvari će biti samo gore. Ovo treba nekako optimizirati.
Kako bismo optimizirali, odlučili smo tada, očito, pogledati profil opterećenja - što se, općenito, događa, što treba optimizirati.
I tu nam sve ide na ruku.
Već sam rekao u prvom slajdu: imamo 80 tisuća zahtjeva za čitanje u sekundi sa samo 3,5 milijuna uploada dnevno. To jest, ovo je razlika od tri reda veličine. Očito je da čitanje treba optimizirati i praktički je jasno kako.
Postoji još jedna mala točka. Specifičnosti usluge su takve da se osoba registrira, postavi fotografiju, zatim počne aktivno gledati druge ljude, sviđati im se i aktivno se prikazuje drugim ljudima. Zatim nađe ili ne nađe partnera, ovisi kako ispadne, i prestane koristiti uslugu na neko vrijeme. U ovom trenutku, kada ga koristi, njegove fotografije su jako vruće - tražene su, puno ih ljudi gleda. Čim prestane to raditi, vrlo brzo prestaje biti izložen drugim ljudima kao prije, a njegove fotografije gotovo nikad nisu tražene.
Oni. Imamo vrlo mali vrući skup podataka. Ali u isto vrijeme ima puno zahtjeva za njega. A potpuno očito rješenje ovdje je dodavanje predmemorije.
Predmemorija s LRU-om riješit će sve naše probleme. Što radimo?
Dodajemo još jedan relativno mali ispred našeg velikog klastera sa pohranom, koji se zove fotospremnici. Ovo je u biti samo proxy za predmemoriju.
Kako djeluje iznutra? Ovdje je naš korisnik, ovdje je skladište. Sve je isto kao prije. Što dodajemo između?
To je samo stroj s fizičkim lokalnim diskom, koji je brz. Ovo je na primjer sa SSD-om. I neka vrsta lokalne predmemorije pohranjena je na ovom disku.
Kako izgleda? Korisnik šalje zahtjev za fotografiju. NGINX ga prvo traži u lokalnoj predmemoriji. Ako ne, onda jednostavno proxy_pass u našu pohranu, skinite fotografiju od tamo i dajte je korisniku.
Ali ovaj je vrlo banalan i nejasno je što se unutra događa. Djeluje otprilike ovako.
Predmemorija je logično podijeljena u tri sloja. Kad kažem “tri sloja”, to ne znači da postoji neka vrsta složenog sustava. Ne, ovo su uvjetno samo tri direktorija u datotečnom sustavu:
- Ovo je međuspremnik u koji idu fotografije upravo preuzete s proxyja.
- Ovo je vruća predmemorija koja pohranjuje trenutno aktivno tražene fotografije.
- I hladna predmemorija, gdje se fotografije postupno guraju iz vruće predmemorije kada im pristigne manje zahtjeva.
Da bi ovo funkcioniralo, moramo nekako upravljati ovom predmemorijom, moramo presložiti fotografije u njoj itd. Ovo je također vrlo primitivan proces.
Nginx jednostavno piše u RAMDisk access.log za svaki zahtjev, u kojem označava putanju do fotografije koju je trenutno poslužio (relativna putanja, naravno), i koja je particija bila poslužena. Oni. može reći "fotografija 1", a zatim ili međuspremnik, ili vrući cache, ili hladni cache, ili proxy.
Ovisno o tome, moramo nekako odlučiti što ćemo s fotografijom.
Imamo mali demon koji radi na svakom računalu koji neprestano čita ovaj dnevnik i pohranjuje statistiku o korištenju određenih fotografija u svoju memoriju.
On tamo jednostavno skuplja, drži brojače i povremeno radi sljedeće. On premješta aktivno tražene fotografije, za koje postoji mnogo zahtjeva, u vruću predmemoriju, gdje god one bile.
Fotografije koje se rijetko traže, a postale su sve rjeđe, postupno se guraju iz vruće predmemorije u hladnu.
A kada nam ponestane prostora u cacheu, jednostavno počnemo bez razlike brisati sve iz hladnog cachea. I usput, ovo dobro funkcionira.
Da bi se fotografija odmah spremila prilikom proxyja u međuspremnik, koristimo direktivu proxy_store, a međuspremnik je također RAMDisk, tj. za korisnika radi vrlo brzo. To se odnosi na unutarnje dijelove samog poslužitelja za predmemoriju.
Preostalo je pitanje kako distribuirati zahtjeve po tim poslužiteljima.
Recimo da postoji klaster od dvadeset strojeva za pohranu i tri poslužitelja za predmemoriju (ovako se dogodilo).
Moramo nekako odrediti koji su zahtjevi za koje fotografije i gdje ih poslati.
Najčešća opcija je Round Robin. Ili to učiniti slučajno?
To očito ima brojne nedostatke jer bismo u takvoj situaciji predmemoriju koristili vrlo neučinkovito. Zahtjevi će sletjeti na neke nasumične strojeve: ovdje je bio spremljen u predmemoriju, ali na sljedećem više nije tamo. A ako sve ovo uspije, bit će jako loše. Čak i s malim brojem strojeva u klasteru.
Moramo na neki način nedvosmisleno odrediti kojem poslužitelju poslati koji zahtjev.
Postoji banalan način. Uzimamo hash iz URL-a ili hash iz našeg ključa za dijeljenje, koji se nalazi u URL-u, i dijelimo ga s brojem poslužitelja. Će raditi? Htjeti.
Oni. Imamo 2% zahtjev, na primjer, za neki “example_url” uvijek će sletjeti na poslužitelj s indeksom “XNUMX”, a predmemorija će se stalno odlagati što je moguće bolje.
Ali postoji problem s reshardingom u takvoj shemi. Resharding - mislim na promjenu broja poslužitelja.
Pretpostavimo da se naš klaster za predmemoriranje više ne može nositi i odlučimo dodati još jedno računalo.
Dodajmo.
Sada je sve djeljivo ne s tri, nego s četiri. Dakle, gotovo svi ključevi koje smo imali, gotovo svi URL-ovi sada žive na drugim poslužiteljima. Cijela predmemorija je samo na trenutak poništena. Svi zahtjevi su pali na naš skladišni klaster, postalo je loše, kvar usluge i nezadovoljni korisnici. Ne želim to učiniti.
Ni ova opcija nam ne odgovara.
Da. što da radimo? Moramo nekako učinkovito koristiti predmemoriju, uvijek iznova slati isti zahtjev na isti poslužitelj, ali biti otporni na ponovno dijeljenje. I postoji takvo rješenje, nije tako komplicirano. To se zove dosljedno raspršivanje.
Kako izgleda?
Uzimamo neku funkciju iz sharding ključa i širimo sve njene vrijednosti na krug. Oni. u točki 0 njegove minimalne i maksimalne vrijednosti konvergiraju. Zatim sve naše poslužitelje postavljamo u isti krug otprilike na ovaj način:
Svaki poslužitelj je definiran jednom točkom, a sektor koji ide u smjeru kazaljke na satu, prema tome, opslužuje ovaj host. Kad nam dođu zahtjevi, odmah vidimo da npr. zahtjev A - ima hash tamo - i služi ga poslužitelj 2. Zahtjev B - poslužitelj 3. I tako dalje.
Što se događa u ovoj situaciji tijekom ponovnog dijeljenja?
Ne poništavamo cijelu predmemoriju, kao prije, i ne pomičemo sve ključeve, ali pomičemo svaki sektor na malu udaljenost tako da, relativno govoreći, naš šesti poslužitelj, kojeg želimo dodati, stane u slobodan prostor, i dodamo ga tamo.
Naravno, u takvoj situaciji ključevi se također pomiču. Ali iseljavaju se puno slabiji nego prije. I vidimo da su naša prva dva ključa ostala na svojim poslužiteljima, a poslužitelj za predmemoriju se promijenio samo za posljednji ključ. Ovo radi prilično učinkovito, a ako postupno dodajete nove hostove, onda ovdje nema velikog problema. Dodajete i dodajete malo po malo, čekate da se predmemorija ponovno napuni i sve radi dobro.
Jedino pitanje ostaje s odbijanjima. Pretpostavimo da je neka vrsta automobila u kvaru.
I ne bismo baš željeli regenerirati ovu mapu u ovom trenutku, poništiti dio predmemorije i tako dalje, ako je, na primjer, stroj ponovno pokrenut, a mi trebamo nekako servisirati zahtjeve. Mi jednostavno držimo jednu pričuvnu predmemoriju fotografija na svakom mjestu, koja služi kao zamjena za bilo koji stroj koji trenutno ne radi. A ako iznenada jedan od naših poslužitelja postane nedostupan, promet odlazi tamo. Naravno, tu nemamo nikakvu predmemoriju, tj. hladno je, ali bar se obrađuju zahtjevi korisnika. Ako je to kratak interval, onda ga doživljavamo potpuno mirno. Samo je više prostora za pohranu. Ako je taj interval dug, tada već možemo donijeti odluku - ukloniti ovaj poslužitelj s karte ili ne, ili ga možda zamijeniti drugim.
Ovdje se radi o sustavu predmemoriranja. Pogledajmo rezultate.
Čini se da ovdje nema ništa komplicirano. Ali ova metoda upravljanja predmemorijom dala nam je stopu trikova od oko 98%. Oni. od ovih 80 tisuća zahtjeva u sekundi samo 1600 stigne na pohranu, i to je sasvim normalno opterećenje, oni to mirno podnose, uvijek imamo rezervu.
Postavili smo ove poslužitelje u tri naša DC-a i dobili tri točke prisutnosti - Prag, Miami i Hong Kong.
Da. manje-više su lokalno locirani na svakom od naših ciljnih tržišta.
I kao lijep bonus, dobili smo ovaj proxy za predmemoriranje, na kojem CPU zapravo miruje, jer nije toliko potreban za posluživanje sadržaja. I tu smo, koristeći NGINX+ Lua, implementirali dosta utilitarističke logike.
Na primjer, možemo eksperimentirati s webp ili progressive jpeg (to su učinkoviti moderni formati), vidjeti kako to utječe na promet, donijeti neke odluke, omogućiti ga za određene zemlje itd.; napravite dinamičku promjenu veličine ili obrežite fotografije u hodu.
Ovo je dobar slučaj kada, na primjer, imate mobilnu aplikaciju koja prikazuje fotografije, a mobilna aplikacija ne želi trošiti CPU klijenta na traženje velike fotografije i zatim joj mijenjati veličinu na određenu veličinu kako bi je gurnula u Pogled. Možemo jednostavno dinamički odrediti neke parametre u UPort uvjetnom URL-u, a predmemorija fotografija će sama promijeniti veličinu fotografije. U pravilu će odabrati veličinu koju fizički imamo na disku, što bližu traženoj, i sniziti je u određenim koordinatama.
Inače, učinili smo javno dostupnim video zapise posljednjih pet godina konferencije programera visokoopterećenih sustava . Gledajte, učite, dijelite i pretplatite se .
Tu također možemo dodati mnogo logike proizvoda. Na primjer, možemo dodati različite vodene žigove pomoću URL parametara, možemo zamutiti, zamutiti ili pikselizirati fotografije. Ovo je kada želimo pokazati fotografiju osobe, ali ne želimo pokazati njeno lice, ovo dobro funkcionira, sve je implementirano ovdje.
Što smo dobili? Dobili smo tri točke prisutnosti, dobru stopu trikova, a u isto vrijeme nemamo neaktivan CPU na ovim strojevima. Sada je, naravno, postao važniji nego prije. Moramo si dati jače automobile, ali isplati se.
Ovo se odnosi na povrat fotografija. Ovdje je sve sasvim jasno i očito. Mislim da nisam otkrio Ameriku, skoro svaki CDN radi na ovaj način.
I, najvjerojatnije, sofisticirani slušatelj mogao bi imati pitanje: zašto jednostavno ne promijeniti sve u CDN? Bilo bi otprilike isto; svi moderni CDN-ovi to mogu. A postoji niz razloga.
Prvi su fotografije.
To je jedna od ključnih točaka naše infrastrukture i trebamo je što više kontrolirati. Ako je ovo neka vrsta rješenja dobavljača treće strane, a vi nemate nikakvu moć nad njim, bit će vam prilično teško živjeti s tim kada imate veliki skup podataka i kada imate jako veliki protok korisničkih zahtjeva.
Dat ću vam primjer. Sada, s našom infrastrukturom, možemo, na primjer, u slučaju nekih problema ili podzemnih udaraca, otići do stroja i tamo, relativno rečeno, petljati. Možemo dodati kolekciju nekih metrika koje samo trebamo, možemo nekako eksperimentirati, vidjeti kako to utječe na grafikone, i tako dalje. Sada se na ovom klasteru za predmemoriju prikuplja mnogo statistika. I povremeno ga gledamo i provodimo dugo vremena istražujući neke anomalije. Da je na strani CDN-a, bilo bi ga puno teže kontrolirati. Ili, na primjer, ako se dogodi neka nezgoda, znamo što se dogodilo, znamo kako s tim živjeti i kako to prebroditi. Ovo je prvi zaključak.
Drugi zaključak je također prilično povijesni, jer se sustav razvijao dugo vremena, au različitim fazama bilo je mnogo različitih poslovnih zahtjeva, koji se ne uklapaju uvijek u koncept CDN-a.
A poanta koja proizlazi iz prethodne je
To je zato što na spremištima fotografija imamo mnogo specifične logike, koja se ne može uvijek dodati na zahtjev. Malo je vjerojatno da će vam bilo koji CDN dodati neke prilagođene stvari na vaš zahtjev. Na primjer, šifriranje URL-ova ako ne želite da klijent može nešto promijeniti. Želite li promijeniti URL na poslužitelju i šifrirati ga, a zatim poslati neke dinamičke parametre ovdje.
Kakav zaključak ovo upućuje? U našem slučaju CDN nije baš dobra alternativa.
A u vašem slučaju, ako imate neke specifične poslovne zahtjeve, onda vrlo lako sami možete implementirati ovo što sam vam pokazao. I to će savršeno funkcionirati sa sličnim profilom opterećenja.
Ali ako imate neko opće rješenje, a zadatak nije vrlo specifičan, možete apsolutno sigurno uzeti CDN. Ili ako su vam vrijeme i resursi važniji od kontrole.
A moderni CDN-ovi imaju gotovo sve o čemu sam vam sada govorio. S izuzetkom plus ili minus nekih značajki.
Ovdje se radi o poklanjanju fotografija.
Idemo sada malo naprijed u našoj retrospektivi i razgovarajmo o skladištenju.
Prolazila je 2013.
Dodani su poslužitelji za predmemoriju, problemi s performansama su nestali. Sve je u redu. Skup podataka raste. Od 2013. imali smo oko 80 poslužitelja povezanih na pohranu i oko 40 poslužitelja za predmemoriju u svakom DC-u. To je 560 terabajta podataka na svakom DC-u, tj. oko petabajta ukupno.
A s rastom skupa podataka operativni troškovi počeli su značajno rasti. Što je ovo značilo?
U ovom dijagramu koji je nacrtan - sa SAN-om, sa strojevima i predmemorijama povezanim na njega - postoji mnogo točaka kvara. Ako smo već imali posla s kvarom poslužitelja za predmemoriju, sve je bilo više-manje predvidljivo i razumljivo, ali na strani pohrane sve je bilo puno gore.
Prvo, sama Storage Area Network (SAN) koja može zakazati.
Drugo, spojen je putem optike na krajnje strojeve. Mogući su problemi s optičkim karticama i svjećicama.
Naravno, nema ih toliko kao kod samog SAN-a, ali, ipak, i to su točke kvara.
Sljedeći je sam stroj, koji je povezan sa skladištem. Može i propasti.
Ukupno imamo tri boda neuspjeha.
Nadalje, uz točke kvara, tu je i teško održavanje samog skladišta.
Ovo je složen višekomponentni sustav i sistemskim inženjerima može biti teško raditi s njim.
I posljednja, najvažnija točka. Ako se kvar dogodi na bilo kojoj od ove tri točke, imamo različite šanse od nule da izgubimo korisničke podatke jer se datotečni sustav može srušiti.
Recimo da nam je datotečni sustav pokvaren. Prvo, njegov oporavak traje dugo - može trajati tjedan dana s velikom količinom podataka. I drugo, na kraju ćemo najvjerojatnije završiti s hrpom nerazumljivih datoteka koje će trebati nekako spojiti u korisničke fotografije. I riskiramo gubitak podataka. Rizik je prilično visok. I što se takve situacije češće događaju i što se više problema pojavljuje u cijelom tom lancu, to je rizik veći.
Nešto se moralo poduzeti u vezi ovoga. I odlučili smo da samo trebamo sigurnosno kopirati podatke. Ovo je zapravo očito rješenje i dobro. Što smo učinili?
Ovako je izgledao naš poslužitelj kad je prije bio spojen na pohranu. Ovo je jedan glavni dio, to je samo blok uređaj koji zapravo predstavlja nosač za daljinsku pohranu putem optike.
Upravo smo dodali drugi odjeljak.
Uz nju smo stavili drugu pohranu (srećom, nije toliko skupa u novcu) i nazvali je backup particijom. Također je povezan putem optičkog vlakna i nalazi se na istom stroju. Ali moramo nekako sinkronizirati podatke između njih.
Ovdje jednostavno napravimo asinkroni red u blizini.
Nije puno zaposlena. Znamo da nemamo dovoljno zapisa. Red je samo tablica u MySQL-u u kojoj su napisani reci poput "morate napraviti sigurnosnu kopiju ove fotografije". S bilo kojom izmjenom ili učitavanjem, kopiramo s glavne particije u sigurnosnu pomoću asinkronog ili samo neke vrste pozadinskog radnika.
I tako uvijek imamo dva dosljedna odjeljka. Čak i ako jedan dio ovog sustava zakaže, uvijek možemo promijeniti glavnu particiju sigurnosnom i sve će nastaviti raditi.
Ali zbog toga se opterećenje čitanja znatno povećava, jer... osim klijenata koji čitaju iz glavne sekcije, jer tamo prvo pogledaju fotografiju (tamo je novija), a onda je traže na backupu, ako je nisu našli (ali NGINX samo to radi), naš sustav je također plus sigurnosna kopija sada čita s glavne particije. Nije da je ovo bilo usko grlo, ali nisam htio povećati opterećenje, u biti, samo tako.
I dodali smo treći disk, koji je mali SSD, i nazvali ga međuspremnik.
Kako sada radi.
Korisnik učitava fotografiju u međuspremnik, a zatim se događaj ubacuje u red čekanja što ukazuje da ga treba kopirati u dva odjeljka. Kopira se, a fotografija neko vrijeme (recimo, dan) živi u međuspremniku i tek onda se briše od tamo. Ovo uvelike poboljšava korisničko iskustvo, jer korisnik uploada fotografiju, u pravilu se odmah počnu nizati zahtjevi ili je sam ažurirao stranicu i osvježio je. Ali sve ovisi o aplikaciji koja vrši prijenos.
Ili, na primjer, drugi ljudi kojima se počeo pokazivati odmah šalju zahtjeve nakon ove fotografije. Još nije u predmemoriji; prvi zahtjev javlja se vrlo brzo. U biti isto kao iz cachea fotografija. Sporo skladištenje uopće nije uključeno u to. A kada se dan kasnije očisti, već je ili predmemoriran na našem sloju predmemoriranja ili, najvjerojatnije, više nikome ne treba. Oni. Korisničko iskustvo ovdje je jako dobro naraslo zahvaljujući takvim jednostavnim manipulacijama.
Pa, i najvažnije: prestali smo gubiti podatke.
Recimo samo da smo stali potencijalno izgubiti podatke, jer ih zapravo nismo izgubili. Ali postojala je opasnost. Vidimo da je ovo rješenje, naravno, dobro, ali malo je kao izglađivanje simptoma problema, umjesto da ga potpuno riješi. I tu ostaju neki problemi.
Prvo, ovo je točka neuspjeha u obliku samog fizičkog hosta na kojem se sva ova mašinerija pokreće; ona nije nestala.
Drugo, još uvijek postoje problemi sa SAN-ovima, njihovo teško održavanje itd. ostaje. Nije da je to bio kritičan čimbenik, ali htjela sam pokušati nekako živjeti bez toga.
I napravili smo treću verziju (zapravo drugu) - rezervacijsku. Kako je to izgledalo?
Ovo je bilo -
Naši glavni problemi su s činjenicom da je ovo fizički host.
Prvo, uklanjamo SAN-ove jer želimo eksperimentirati, želimo isprobati samo lokalne tvrde diskove.
Ovo je već 2014.-2015. godina i tada je situacija s diskovima i njihovim kapacitetom u jednom hostu postala puno bolja. Odlučili smo zašto ne probati.
A onda jednostavno uzmemo rezervnu particiju i fizički je prenesemo na zasebno računalo.
Dakle, dobili smo ovaj dijagram. Imamo dva automobila koji pohranjuju iste skupove podataka. Oni međusobno potpuno sigurnosno kopiraju i sinkroniziraju podatke preko mreže kroz asinkroni red u istom MySQL-u.
Ovo dobro funkcionira jer imamo malo zapisa. Oni. kad bi pisanje bilo usporedivo s čitanjem, možda bismo imali neku vrstu mrežnih troškova i problema. Malo se piše, puno se čita - ova metoda dobro funkcionira, tj. Rijetko kopiramo fotografije između ova dva poslužitelja.
Kako ovo funkcionira, ako pogledate malo detaljnije.
Učitaj. Balancer jednostavno odabire nasumične hostove s parom i postavlja ih na njih. U isto vrijeme, naravno, obavlja zdravstvene preglede i pazi da automobil ne ispadne. Oni. postavlja fotografije samo na live server, a onda se kroz asinkroni red čekanja sve to kopira na njegovog susjeda. S uploadom je sve vrlo jednostavno.
Zadatak je malo teži.
Lua nam je tu pomogla, jer može biti teško napraviti takvu logiku na vanilla NGINX-u. Prvo uputimo zahtjev prvom serveru, vidimo je li fotografija tamo, jer bi potencijalno mogla biti uploadana npr. kod susjeda, ali ovdje još nije stigla. Ako je fotografija tu, to je dobro. Odmah ga dajemo klijentu i, eventualno, keširamo.
Ako ga nema, jednostavno uputimo zahtjev susjedu i odande ćemo ga zajamčeno dobiti.
Da. opet možemo reći: može biti problema s izvedbom, jer postoje stalna povratna putovanja - fotografija je postavljena, nije ovdje, postavljamo dva zahtjeva umjesto jednog, ovo bi trebalo sporo raditi.
U našoj situaciji to ne ide sporo.
Na ovom sustavu prikupljamo hrpu metrika, a uvjetna pametna stopa takvog mehanizma je oko 95%. Oni. Kašnjenje ove sigurnosne kopije je malo i zbog toga smo gotovo zajamčeni da ćemo je nakon učitavanja fotografije prvi put uzeti u ruke i nećemo morati nikamo ići dva puta.
Dakle, što još imamo da je stvarno cool?
Ranije smo imali glavnu sigurnosnu particiju i čitali smo s njih uzastopno. Oni. Uvijek smo prvo tražili na glavnom, a onda na rezervnom. Bio je to jedan potez.
Sada koristimo čitanje s dva stroja odjednom. Distribuiramo zahtjeve koristeći Round Robin. U malom postotku slučajeva postavljamo dva zahtjeva. Ali sve u svemu, sada imamo dvostruko više lektira nego prije. I opterećenje je uvelike smanjeno i na strojevima za slanje i izravno na strojevima za skladištenje, koje smo također imali u to vrijeme.
Što se tiče tolerancije na pogreške. Zapravo, za to smo se uglavnom borili. Uz toleranciju grešaka, ovdje je sve ispalo odlično.
Jedan auto se pokvari.
Nema problema! Sistemski inženjer se možda neće ni probuditi noću, čekat će do jutra, neće se dogoditi ništa loše.
Ako čak i ako ovaj stroj zakaže, red čekanja nije u funkciji, također nema problema, jednostavno će se zapisnik prvo akumulirati na živom stroju, a zatim će se dodati u red čekanja, a zatim u automobil koji će pustiti u rad nakon nekog vremena.
Ista je stvar i s održavanjem. Jednostavno ugasimo jedan od strojeva, ručno ga izvučemo iz svih bazena, prestane primati promet, napravimo neku vrstu održavanja, uredimo nešto, onda ga vratimo u servis i ovaj backup dosta brzo stigne. Oni. dnevno, zastoj jednog automobila nadoknađuje se u roku od nekoliko minuta. Ovo je stvarno jako malo. Uz toleranciju na pogreške, opet kažem, ovdje je sve cool.
Koji se zaključci mogu izvući iz ove sheme redundantnosti?
Imamo toleranciju na pogreške.
Jednostavan za korištenje. Budući da strojevi imaju lokalne tvrde diskove, to je puno praktičnije s operativne točke gledišta za inženjere koji rade s njima.
Dobili smo dvostruku naknadu za čitanje.
Ovo je vrlo dobar bonus uz toleranciju na greške.
Ali ima i problema. Sada imamo mnogo složeniji razvoj nekih značajki povezanih s tim, jer je sustav na kraju postao 100% konzistentan.
Moramo, recimo, u nekom pozadinskom poslu stalno razmišljati: “Na kojem serveru sada radimo?”, “Ima li ovdje stvarno trenutna fotografija?” itd. Ovo je, naravno, sve zamotano, a za programera koji piše poslovnu logiku je transparentno. No, unatoč tome, pojavio se taj veliki kompleksni sloj. Ali mi smo to spremni podnijeti u zamjenu za dobrote koje smo od toga dobili.
I tu se opet javlja neki sukob.
Rekao sam na početku da je pohranjivanje svega na lokalne tvrde diskove loše. I sad kažem da nam se svidjelo.
Da, doista, s vremenom se situacija jako promijenila, a sada ovaj pristup ima mnoge prednosti. Prvo, dobivamo mnogo jednostavniji rad.
Drugo, to je produktivnije, jer nemamo te automatske kontrolere ili veze s policama diskova.
Tamo postoji ogromna količina strojeva, a ovo je samo nekoliko diskova koji su ovdje na stroju sastavljeni u napad.
Ali postoje i nedostaci.
To je otprilike 1,5 puta skuplje od korištenja SAN-ova čak i po današnjim cijenama. Stoga smo odlučili ne hrabro pretvoriti cijeli naš veliki klaster u automobile s lokalnim tvrdim diskovima i odlučili smo ostaviti hibridno rješenje.
Polovica naših strojeva radi s tvrdim diskovima (dobro, ne polovica - vjerojatno 30 posto). A ostalo su stari auti koji su imali prvu rezervacijsku shemu. Jednostavno smo ih ponovno montirali, budući da nam nisu trebali novi podaci ili bilo što drugo, jednostavno smo prebacili nosače s jednog fizičkog hosta na dva.
I sada imamo veliku zalihu lektire i proširili smo je. Ako smo ranije montirali jedno spremište na jedan stroj, sada montiramo četiri, na primjer, na jedan par. I dobro radi.
Recimo ukratko što smo postigli, za što smo se borili i jesmo li u tome uspjeli.
Rezultati
Imamo korisnika - čak 33 milijuna.
Imamo tri točke prisutnosti - Prag, Miami, Hong Kong.
Sadrže caching sloj, koji se sastoji od automobila s brzim lokalnim diskovima (SSD), na kojima se pokreću jednostavni strojevi iz NGINX-a, njegov access.log i Python demoni, koji sve to obrađuju i upravljaju cacheom.
Ako želite, u svom ste projektu, ako vam fotografije nisu kritične kao što su nama, ili ako je kontrola kompromisa u odnosu na brzinu razvoja i troškove resursa u drugom smjeru za vas, tada ga možete sigurno zamijeniti s CDN-om, moderni CDN-ovi rade dobro.
Slijedi sloj pohrane, na kojem imamo klastere parova strojeva koji međusobno rade sigurnosnu kopiju, datoteke se asinkrono kopiraju s jedne na drugu kad god se promijene.
Štoviše, neki od tih strojeva rade s lokalnim tvrdim diskovima.
Neki od tih strojeva povezani su na SAN-ove.
I, s jedne strane, praktičniji je za korištenje i malo produktivniji, s druge strane, prikladan je u smislu gustoće postavljanja i cijene po gigabajtu.
Ovo je tako kratak pregled arhitekture onoga što smo dobili i kako se sve to razvilo.
Još nekoliko savjeta od kapetana, vrlo jednostavnih.
Prvo, ako iznenada odlučite da morate hitno poboljšati sve u svojoj foto infrastrukturi, prvo izmjerite, jer možda ništa ne treba poboljšati.
Dat ću vam primjer. Imamo klaster strojeva koji šalju fotografije iz privitaka u chatovima, a shema tamo radi od 2009. i nitko od toga ne pati. Svima je dobro, svima se sve sviđa.
Da biste mjerili, prvo objesite hrpu metrika, pogledajte ih i onda odlučite čime niste zadovoljni, a što treba poboljšati. Kako bismo to izmjerili, imamo cool alat koji se zove Pinba.
Omogućuje vam prikupljanje vrlo detaljnih statistika iz NGINX-a za svaki zahtjev i kodove odgovora, te raspodjelu vremena - što god želite. Ima povezivanja sa svim vrstama različitih analitičkih sustava, a onda možete sve to lijepo pogledati.
Prvo smo ga izmjerili, a zatim poboljšali.
Unaprijediti. Optimiziramo čitanje pomoću predmemorije, pisanje pomoću dijeljenja, ali ovo je očita točka.
Unaprijediti. Ako tek sada počinjete graditi svoj sustav, puno je bolje napraviti fotografije kao nepromjenjive datoteke. Zato što odmah gubite cijeli niz problema s poništavanjem predmemorije, s time kako bi logika trebala pronaći ispravnu verziju fotografije, i tako dalje.
Recimo da ste učitali stotinu, a zatim je rotirali, učinili da bude fizički drugačija datoteka. Oni. nema potrebe razmišljati: sada ću uštedjeti malo prostora, napisati to u istu datoteku, promijeniti verziju. Ovo uvijek ne funkcionira dobro i uzrokuje mnogo glavobolja.
Sljedeća točka. O promjeni veličine u hodu.
Ranije, kada su korisnici uploadali fotografiju, odmah smo rezali hrpu veličina za sve prilike, za različite klijente, i sve su bile na disku. Sada smo ovo napustili.
Ostavili smo samo tri glavne veličine: malu, srednju i veliku. Sve ostalo jednostavno smanjimo od veličine koja je iza one koja je od nas tražena u Uportu, jednostavno napravimo smanjenje i damo korisniku.
CPU sloja za predmemoriju ovdje se pokazao mnogo jeftinijim nego da stalno regeneriramo te veličine na svakoj pohrani. Recimo da želimo dodati novi, to će trajati mjesec dana - posvuda pokrenite skriptu koja bi sve to radila uredno, bez uništavanja klastera. Oni. Ako ste sada u mogućnosti birati, bolje je napraviti što manje fizičkih veličina, ali da barem neka distribucija bude recimo tri. Sve ostalo se može jednostavno mijenjati u hodu pomoću gotovih modula. Sada je sve vrlo jednostavno i dostupno.
I inkrementalna asinkrona sigurnosna kopija je dobra.
Kao što je naša praksa pokazala, ova shema radi odlično s odgođenim kopiranjem promijenjenih datoteka.
Posljednja točka je također očita. Ako vaša infrastruktura sada nema takvih problema, ali postoji nešto što se može pokvariti, sigurno će se pokvariti kada toga bude malo više. Stoga je bolje razmišljati o tome unaprijed i ne imati problema s tim. To je sve što sam htio reći.
Kontakti
»
»
Ovo izvješće je transkript jednog od najboljih govora na konferenciji programera visokoopterećenih sustava . Do HighLoad++ 2017 konferencije ostalo je manje od mjesec dana.
Već ga imamo spremnog , sada se aktivno formira raspored.
Ove godine nastavljamo istraživati temu arhitekture i skaliranja:
- / Igor Vasiljev
- / Dmitrij Egorov
- / Anatolij Plaskovski
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Filip Delgado
Također koristimo neke od ovih materijala u našem online tečaju o razvoju sustava visokog opterećenja je lanac posebno odabranih pisama, članaka, materijala, videa. Naš udžbenik već sadrži više od 30 jedinstvenih materijala. Spojiti!
Izvor: www.habr.com