Artem Denisov ( , )
Badoo er verdens største datingside. Vi har for tiden rundt 330 millioner registrerte brukere over hele verden. Men det som er mye viktigere i forbindelse med samtalen vår i dag, er at vi lagrer ca. 3 petabyte med brukerbilder. Hver dag laster brukerne våre opp ca. 3,5 millioner nye bilder, og lesemengden er ca 80 tusen forespørsler per sekund. Dette er ganske mye for vår backend, og noen ganger er det vanskeligheter med dette.
Jeg vil snakke om utformingen av dette systemet, som lagrer og sender bilder generelt, og jeg vil se på det fra en utviklers synspunkt. Det vil være et kort tilbakeblikk på hvordan det utviklet seg, hvor jeg vil skissere de viktigste milepælene, men jeg vil bare snakke mer detaljert om løsningene vi bruker for øyeblikket.
La oss nå komme i gang.
Som sagt vil dette være et tilbakeblikk, og for å starte det et sted, la oss ta det vanligste eksemplet.
Vi har en felles oppgave, vi må ta imot, lagre og sende brukerbilder. I dette skjemaet er oppgaven generell, vi kan bruke hva som helst:
- moderne skylagring,
- en boksløsning, som det også er mange av nå;
- Vi kan sette opp flere maskiner i datasenteret vårt og sette store harddisker på dem og lagre bilder der.
Badoo bor historisk - både nå og da (på den tiden da det bare var i sin spede begynnelse) - på sine egne servere, inne i våre egne DC-er. Derfor var dette alternativet optimalt for oss.
Vi tok bare flere maskiner, kalte dem "bilder", og vi fikk en klynge som lagrer bilder. Men det virker som om noe mangler. For at alt dette skal fungere, må vi på en eller annen måte bestemme på hvilken maskin vi skal lagre hvilke bilder. Og her er det heller ikke nødvendig å åpne Amerika.
Vi legger til et felt til lagringen vår med informasjon om brukere. Dette vil være skjæringsnøkkelen. I vårt tilfelle kalte vi det place_id, og denne steds-IDen peker på stedet der brukerbilder er lagret. Vi lager kart.
På det første stadiet kan dette til og med gjøres manuelt - vi sier at et bilde av denne brukeren med et slikt sted vil lande på en slik server. Takket være dette kartet vet vi alltid når en bruker laster opp et bilde, hvor det skal lagres, og vi vet hvor vi skal gi det fra.
Dette er en helt triviell ordning, men den har ganske betydelige fordeler. Det første er at det er enkelt, som sagt, og det andre er at med denne tilnærmingen kan vi enkelt skalere horisontalt ved ganske enkelt å levere nye biler og legge dem til på kartet. Du trenger ikke gjøre noe annet.
Slik var det for oss en stund.
Dette var rundt 2009. De leverte biler, leverte...
Og på et tidspunkt begynte vi å legge merke til at denne ordningen har visse ulemper. Hva er ulempene?
For det første er det begrenset kapasitet. Vi kan ikke stappe så mange harddisker på én fysisk server som vi ønsker. Og dette har blitt et visst problem over tid og med veksten av datasettet.
Og for det andre. Dette er en atypisk konfigurasjon av maskiner, siden slike maskiner er vanskelige å gjenbruke i noen andre klynger; de er ganske spesifikke, dvs. de skal være svake i ytelse, men samtidig med en stor harddisk.
Dette var alt for 2009, men i prinsippet er disse kravene fortsatt aktuelle i dag. Vi har et tilbakeblikk, så i 2009 var alt helt dårlig med dette.
Og det siste punktet er prisen.
Prisen var veldig høy på den tiden, og vi måtte se etter noen alternativer. De. vi trengte på en eller annen måte å utnytte både plassen i datasentrene og de fysiske serverne som alt dette ligger på bedre. Og systemingeniørene våre startet en stor studie der de gjennomgikk en rekke forskjellige alternativer. De så også på grupperte filsystemer som PolyCeph og Luster. Det var ytelsesproblemer og ganske vanskelig drift. De nektet. Vi prøvde å montere hele datasettet via NFS på hver bil for på en eller annen måte å skalere det opp. Lesing gikk også dårlig, vi prøvde forskjellige løsninger fra forskjellige leverandører.
Og til slutt bestemte vi oss for å bruke det såkalte Storage Area Network.
Dette er store SHD-er som er spesielt designet for lagring av store datamengder. De er hyller med disker som er montert på de endelige optiske utgangsmaskinene. At. vi har en slags pool av maskiner, ganske små, og disse SHD-ene, som er gjennomsiktige for vår sendelogikk, dvs. for vår nginx eller noen andre for å betjene forespørsler om disse bildene.
Denne beslutningen hadde åpenbare fordeler. Dette er SHD. Den er rettet mot å lagre bilder. Dette fungerer billigere enn å bare utstyre maskiner med harddisker.
Andre pluss.
Dette er at kapasiteten er blitt mye større, d.v.s. vi kan ta mye mer lagringsplass i et mye mindre volum.
Men det var også ulemper som dukket opp ganske raskt. Etter hvert som antallet brukere og belastningen på dette systemet økte, begynte ytelsesproblemer å oppstå. Og problemet her er ganske åpenbart - enhver SHD som er designet for å lagre mange bilder i et lite volum, lider som regel av intensiv lesing. Dette er faktisk sant for enhver skylagring eller noe annet. Nå har vi ikke en ideell lagring som vil være uendelig skalerbar, du kan stappe hva som helst i den, og den vil tåle avlesninger veldig godt. Spesielt tilfeldige avlesninger.
Som tilfellet er med bildene våre, fordi bilder er forespurt inkonsekvent, og dette vil i stor grad påvirke ytelsen deres.
Selv i henhold til dagens tall, hvis vi får et sted mer enn 500 RPS for bilder på en maskin som lagring er koblet til, begynner problemer allerede. Og det var ille nok for oss, fordi antall brukere vokser, ting kommer bare til å bli verre. Dette må på en eller annen måte optimaliseres.
For å optimalisere bestemte vi oss på det tidspunktet, selvsagt, å se på lastprofilen - hva som generelt skjer, hva som må optimaliseres.
Og her spiller alt i våre hender.
Jeg sa allerede i det første lysbildet: vi har 80 tusen leseforespørsler per sekund med bare 3,5 millioner opplastinger per dag. Det vil si at dette er en forskjell på tre størrelsesordener. Det er åpenbart at lesing må optimaliseres, og det er praktisk talt klart hvordan.
Det er et lite poeng til. Tjenestens spesifikasjoner er slik at en person registrerer seg, laster opp et bilde, deretter begynner å aktivt se på andre mennesker, liker dem, og blir aktivt vist til andre mennesker. Så finner han en partner eller finner ikke en partner, det kommer an på hvordan det blir, og slutter å bruke tjenesten for en stund. I dette øyeblikket, når han bruker det, er bildene hans veldig varme - de er etterspurt, mange ser dem. Så snart han slutter å gjøre dette, faller han ganske raskt ut av like mye eksponering for andre mennesker som han hadde før, og bildene hans blir nesten aldri etterspurt.
De. Vi har et veldig lite hot datasett. Men samtidig er det mange forespørsler etter ham. Og en helt åpenbar løsning her er å legge til en cache.
En cache med LRU vil løse alle problemene våre. Hva gjør vi?
Vi legger til en relativt liten en foran vår store klynge med lagring, som kalles photocacher. Dette er egentlig bare en caching proxy.
Hvordan fungerer det fra innsiden? Her er brukeren vår, her er lagring. Alt er det samme som før. Hva legger vi i mellom?
Det er bare en maskin med en fysisk lokal disk, som er rask. Dette er for eksempel med en SSD. Og en slags lokal cache er lagret på denne disken.
Hvordan ser det ut? Brukeren sender en forespørsel om et bilde. NGINX ser etter det først i den lokale cachen. Hvis ikke, så bare proxy_pass til lagringen vår, last ned bildet derfra og gi det til brukeren.
Men denne er veldig banal og det er uklart hva som skjer på innsiden. Det fungerer noe sånt som dette.
Cachen er logisk delt inn i tre lag. Når jeg sier "tre lag", betyr ikke dette at det er en slags kompleks system. Nei, dette er betinget bare tre kataloger i filsystemet:
- Dette er en buffer hvor bilder nettopp lastet ned fra en proxy går.
- Dette er en hot cache som lagrer aktivt etterspurte bilder.
- Og en kald cache, hvor bilder gradvis skyves ut av den varme cachen når færre forespørsler kommer til dem.
For at dette skal fungere, må vi på en eller annen måte administrere denne cachen, vi må omorganisere bildene i den osv. Dette er også en veldig primitiv prosess.
Nginx skriver ganske enkelt til RAMDisk access.log for hver forespørsel, der den angir banen til bildet som det har servert for øyeblikket (relativ bane, selvfølgelig), og hvilken partisjon det ble servert. De. det kan stå "bilde 1" og deretter enten en buffer, eller en hot cache, eller en cold cache, eller en proxy.
Avhengig av dette, må vi på en eller annen måte bestemme hva vi skal gjøre med bildet.
Vi har en liten demon som kjører på hver maskin som konstant leser denne loggen og lagrer statistikk om bruken av visse fotografier i minnet.
Han samler rett og slett der, holder skrankene og gjør med jevne mellomrom følgende. Han flytter aktivt etterspurte bilder, som det er mange forespørsler om, til den varme cachen, uansett hvor de er.
Bilder som er forespurt sjelden og som har blitt forespurt sjeldnere, blir gradvis skjøvet ut av den varme cachen til den kalde.
Og når vi går tom for plass i cachen, begynner vi rett og slett å slette alt fra den kalde cachen uten forskjell. Og forresten, dette fungerer bra.
For at bildet skal lagres umiddelbart når det overføres til bufferen, bruker vi proxy_store-direktivet og bufferen er også en RAMDisk, dvs. for brukeren fungerer det veldig raskt. Dette gjelder innsiden av selve bufferserveren.
Det gjenværende spørsmålet er hvordan man distribuerer forespørsler på tvers av disse serverne.
La oss si at det er en klynge med tjue lagringsmaskiner og tre caching-servere (slik skjedde det).
Vi må på en eller annen måte finne ut hvilke forespørsler som er for hvilke bilder og hvor vi skal lande dem.
Det vanligste alternativet er Round Robin. Eller gjør det ved et uhell?
Dette har åpenbart en rekke ulemper fordi vi ville brukt cachen veldig ineffektivt i en slik situasjon. Forespørsler vil lande på noen tilfeldige maskiner: her ble den bufret, men på den neste er den ikke lenger der. Og hvis alt dette fungerer, blir det veldig ille. Selv med et lite antall maskiner i klyngen.
Vi må på en eller annen måte entydig bestemme hvilken server som skal lande hvilken forespørsel.
Det er en banal måte. Vi tar hashen fra URL-en eller hashen fra shading-nøkkelen vår, som er i URL-en, og deler den på antall servere. Skal jobbe? Vil.
De. Vi har en 2 % forespørsel, for eksempel for noen "example_url" vil den alltid lande på serveren med indeks "XNUMX", og cachen vil hele tiden bli kastet så godt som mulig.
Men det er et problem med omdeling i et slikt opplegg. Resharding - jeg mener å endre antall servere.
La oss anta at caching-klyngen vår ikke lenger kan klare det, og vi bestemmer oss for å legge til en annen maskin.
La oss legge til.
Nå er alt delelig ikke med tre, men med fire. Dermed, nesten alle nøklene vi pleide å ha, nesten alle URL-ene lever nå på andre servere. Hele cachen ble ugyldig bare et øyeblikk. Alle forespørsler falt på lagringsklyngen vår, det ble uvel, tjenestesvikt og misfornøyde brukere. Jeg vil ikke gjøre det.
Dette alternativet passer heller ikke oss.
At. hva skal vi gjøre? Vi må på en eller annen måte gjøre effektiv bruk av cachen, lande den samme forespørselen på den samme serveren om og om igjen, men være motstandsdyktige mot resharding. Og det er en slik løsning, den er ikke så komplisert. Det kalles konsekvent hashing.
Hvordan ser det ut?
Vi tar en funksjon fra skjæringsnøkkelen og sprer alle verdiene på sirkelen. De. ved punkt 0 konvergerer minimums- og maksimumsverdiene. Deretter plasserer vi alle våre servere på samme sirkel på omtrent denne måten:
Hver server er definert av ett punkt, og sektoren som går med klokken til den, blir følgelig betjent av denne verten. Når forespørsler kommer til oss, ser vi umiddelbart at for eksempel forespørsel A - den har en hash der - og den betjenes av server 2. Forespørsel B - av server 3. Og så videre.
Hva skjer i denne situasjonen under omdeling?
Vi ugyldiggjør ikke hele hurtigbufferen, som før, og flytter ikke alle nøklene, men vi flytter hver sektor et lite stykke slik at den sjette serveren vår, som vi ønsker å legge til, passer inn i den ledige plassen, og vi legger det til der.
Selvfølgelig, i en slik situasjon flytter også nøklene ut. Men de rykker ut mye svakere enn før. Og vi ser at de to første nøklene våre forble på deres servere, og caching-serveren endret seg bare for den siste nøkkelen. Dette fungerer ganske effektivt, og hvis du legger til nye verter trinnvis, så er det ikke noe stort problem her. Du legger til og legger til litt om gangen, venter til cachen er full igjen, og alt fungerer bra.
Det eneste spørsmålet gjenstår med avslag. La oss anta at en slags bil er ute av drift.
Og vi ville egentlig ikke ønske å regenerere dette kartet for øyeblikket, ugyldiggjøre deler av hurtigbufferen, og så videre, hvis for eksempel maskinen ble startet på nytt, og vi på en eller annen måte må betjene forespørsler. Vi holder ganske enkelt én backup bildebuffer på hvert nettsted, som fungerer som en erstatning for enhver maskin som for øyeblikket er nede. Og hvis plutselig en av våre servere blir utilgjengelig, går trafikken dit. Naturligvis har vi ingen cache der, dvs. det er kaldt, men i det minste blir brukerforespørsler behandlet. Er dette et kort intervall, så opplever vi det helt rolig. Det er bare mer belastning på lagring. Hvis dette intervallet er langt, kan vi allerede ta en beslutning - å fjerne denne serveren fra kartet eller ikke, eller kanskje erstatte den med en annen.
Dette handler om caching-systemet. La oss se på resultatene.
Det ser ut til at det ikke er noe komplisert her. Men denne metoden for å administrere cachen ga oss en lurerate på omtrent 98 %. De. av disse 80 tusen forespørslene per sekund, når bare 1600 lagring, og dette er en helt normal belastning, de tåler det rolig, vi har alltid en reserve.
Vi plasserte disse serverne i tre av våre DC-er, og mottok tre tilstedeværelsespunkter - Praha, Miami og Hong Kong.
At. de er mer eller mindre lokalisert til hvert av våre målmarkeder.
Og som en fin bonus fikk vi denne caching-proxyen, som CPU-en faktisk er inaktiv på, fordi den ikke er så nødvendig for å betjene innhold. Og der, ved å bruke NGINX+ Lua, implementerte vi mye utilitaristisk logikk.
For eksempel kan vi eksperimentere med webp eller progressiv jpeg (dette er effektive moderne formater), se hvordan det påvirker trafikken, ta noen avgjørelser, aktivere det for visse land, osv.; foreta dynamisk endring av størrelse eller beskjær bilder på farten.
Dette er et godt bruksområde når du for eksempel har en mobilapplikasjon som viser bilder, og mobilapplikasjonen ikke ønsker å kaste bort klientens CPU på å be om et stort bilde og deretter endre størrelsen på det til en viss størrelse for å presse det inn i utsikten. Vi kan ganske enkelt spesifisere noen parametere dynamisk i den betingede URL-adressen til UPort, og bildebufferen vil endre størrelsen på selve bildet. Som regel vil den velge størrelsen vi fysisk har på disken, så nær den forespurte som mulig, og selge den ned i spesifikke koordinater.
Forresten, vi har gjort offentlig tilgjengelige videoopptak fra de siste fem årene av konferansen for utviklere av høylastsystemer . Se, lær, del og abonner på .
Vi kan også legge til mye produktlogikk der. For eksempel kan vi legge til forskjellige vannmerker ved hjelp av URL-parametere, vi kan uskarpe, uskarpe eller pikselere bilder. Dette er når vi vil vise et bilde av en person, men vi vil ikke vise ansiktet hans, dette fungerer bra, alt er implementert her.
Hva fikk vi? Vi har tre tilstedeværelsespunkter, en god trikshastighet, og samtidig har vi ikke ledig CPU på disse maskinene. Nå er han selvsagt blitt viktigere enn før. Vi må gi oss selv sterkere biler, men det er verdt det.
Dette gjelder retur av fotografier. Alt her er ganske klart og tydelig. Jeg tror jeg ikke oppdaget Amerika, nesten alle CDN fungerer på denne måten.
Og mest sannsynlig kan en sofistikert lytter ha et spørsmål: hvorfor ikke bare endre alt til CDN? Det ville være omtrent det samme; alle moderne CDN-er kan gjøre dette. Og det er en rekke årsaker.
Den første er fotografier.
Dette er et av hovedpunktene i infrastrukturen vår, og vi trenger så mye kontroll over det som mulig. Hvis dette er en slags løsning fra en tredjepartsleverandør, og du ikke har noen makt over det, vil det være ganske vanskelig for deg å leve med det når du har et stort datasett, og når du har en veldig stor flyt. av brukerforespørsler.
La meg gi deg et eksempel. Nå, med vår infrastruktur, kan vi for eksempel ved noen problemer eller underjordiske støt gå til maskinen og rote rundt der, relativt sett. Vi kan legge til samlingen av noen beregninger som vi bare trenger, vi kan eksperimentere på en eller annen måte, se hvordan dette påvirker grafene, og så videre. Nå samles det inn mye statistikk om denne caching-klyngen. Og vi ser med jevne mellomrom på det og bruker lang tid på å utforske noen anomalier. Hvis det var på CDN-siden, ville det vært mye vanskeligere å kontrollere. Eller, for eksempel, hvis en slags ulykke skjer, vet vi hva som har skjedd, vi vet hvordan vi skal leve med det og hvordan vi skal overvinne det. Dette er den første konklusjonen.
Den andre konklusjonen er også ganske historisk, fordi systemet har vært under utvikling i lang tid, og det var mange ulike forretningskrav på ulike stadier, og de passer ikke alltid inn i CDN-konseptet.
Og poenget som følger av den forrige er
Dette er fordi vi på fotocacher har mye spesifikk logikk, som ikke alltid kan legges til på forespørsel. Det er usannsynlig at noen CDN vil legge til noen tilpassede ting til deg på din forespørsel. For eksempel kryptering av URL-er hvis du ikke vil at klienten skal kunne endre noe. Vil du endre URL på serveren og kryptere den, og så sende noen dynamiske parametere hit.
Hvilken konklusjon tyder dette på? I vårt tilfelle er ikke CDN et veldig godt alternativ.
Og i ditt tilfelle, hvis du har noen spesifikke forretningskrav, kan du ganske enkelt implementere det jeg viste deg selv. Og dette vil fungere perfekt med en lignende lastprofil.
Men hvis du har en slags generell løsning, og oppgaven ikke er veldig spesifikk, kan du helt trygt ta en CDN. Eller om tid og ressurser er viktigere for deg enn kontroll.
Og moderne CDN-er har nesten alt jeg fortalte deg om nå. Med unntak av pluss eller minus noen funksjoner.
Dette handler om å gi bort bilder.
La oss nå gå litt frem i tilbakeblikket og snakke om lagring.
2013 var på vei.
Bufferservere ble lagt til, ytelsesproblemer forsvant. Alt er bra. Datasettet vokser. Fra 2013 hadde vi omtrent 80 servere koblet til lagring, og omtrent 40 caching i hver DC. Dette er 560 terabyte med data på hver DC, dvs. omtrent en petabyte totalt.
Og med veksten av datasettet begynte driftskostnadene å stige betydelig. Hva betydde dette?
I dette diagrammet som er tegnet - med et SAN, med maskiner og cacher koblet til - er det mange feilpunkter. Hvis vi allerede hadde håndtert svikten i caching-servere før, var alt mer eller mindre forutsigbart og forståelig, men på lagringssiden var alt mye verre.
For det første selve Storage Area Network (SAN), som kan svikte.
For det andre kobles den via optikk til sluttmaskinene. Det kan være problemer med optiske kort og tennplugger.
Selvfølgelig er det ikke så mange av dem som med SAN selv, men ikke desto mindre er dette også feilpunkter.
Neste er selve maskinen, som er koblet til lageret. Det kan også mislykkes.
Totalt har vi tre feilpoeng.
Videre, i tillegg til feilpunkter, er det tungt vedlikehold av selve lageret.
Dette er et komplekst flerkomponentsystem, og systemingeniører kan ha det vanskelig å jobbe med det.
Og det siste, viktigste punktet. Hvis det oppstår en feil på noen av disse tre punktene, har vi en sjanse som ikke er null for å miste brukerdata fordi filsystemet kan krasje.
La oss si at filsystemet vårt er ødelagt. For det første tar gjenopprettingen lang tid - det kan ta en uke med en stor mengde data. Og for det andre, til slutt vil vi mest sannsynlig ende opp med en haug med uforståelige filer som på en eller annen måte må kombineres til brukerbilder. Og vi risikerer å miste data. Risikoen er ganske høy. Og jo oftere slike situasjoner skjer, og jo flere problemer oppstår i hele denne kjeden, jo høyere er risikoen.
Dette måtte gjøres noe med. Og vi bestemte oss for at vi bare trenger å sikkerhetskopiere dataene. Dette er faktisk en åpenbar og god løsning. Hva har vi gjort?
Slik så serveren vår ut da den var koblet til lagring før. Dette er en hoveddel, det er bare en blokkenhet som faktisk representerer et feste for ekstern lagring via optikk.
Vi har nettopp lagt til en andre seksjon.
Vi plasserte en ekstra lagringsplass ved siden av den (heldigvis er den ikke så dyr i form av penger), og kalte den en backup-partisjon. Den er også koblet til via optikk og er plassert på samme maskin. Men vi må på en eller annen måte synkronisere dataene mellom dem.
Her lager vi rett og slett en asynkron kø i nærheten.
Hun er ikke veldig opptatt. Vi vet at vi ikke har nok poster. En kø er bare en tabell i MySQL der linjer som "du må sikkerhetskopiere dette bildet" er skrevet. Med enhver endring eller opplasting kopierer vi fra hovedpartisjonen til sikkerhetskopiering ved hjelp av en asynkron eller bare en slags bakgrunnsarbeider.
Og dermed har vi alltid to konsekvente seksjoner. Selv om en del av dette systemet svikter, kan vi alltid endre hovedpartisjonen med en sikkerhetskopi, og alt vil fortsette å fungere.
Men på grunn av dette øker lesebelastningen betraktelig, fordi... i tillegg til klienter som leser fra hoveddelen, fordi de først ser på bildet der (det er nyere der), og så ser etter det på sikkerhetskopien, hvis de ikke har funnet det (men NGINX gjør bare dette), systemet vårt er også et pluss backup som nå leses fra hovedpartisjonen. Det er ikke det at dette var en flaskehals, men jeg ønsket ikke å øke belastningen, egentlig bare sånn.
Og vi la til en tredje disk, som er en liten SSD, og kalte den en buffer.
Hvordan det fungerer nå.
Brukeren laster opp et bilde til bufferen, deretter kastes en hendelse inn i køen som indikerer at den må kopieres i to seksjoner. Det kopieres, og bildet lever på bufferen i noen tid (for eksempel en dag), og først da blir det renset derfra. Dette forbedrer brukeropplevelsen betraktelig, fordi brukeren laster opp et bilde, som regel begynner forespørsler umiddelbart å følge, eller han selv oppdaterte siden og oppdatert den. Men alt avhenger av applikasjonen som laster opp.
Eller, for eksempel, andre personer som han begynte å vise seg til sender umiddelbart forespørsler etter dette bildet. Den er ennå ikke i hurtigbufferen; den første forespørselen skjer veldig raskt. I hovedsak det samme som fra en bildebuffer. Langsom lagring er ikke involvert i dette i det hele tatt. Og når det en dag senere er renset, er det allerede enten bufret på bufferlaget vårt, eller, mest sannsynlig, er det ingen som trenger det lenger. De. Brukeropplevelsen her har vokst veldig godt på grunn av slike enkle manipulasjoner.
Vel, og viktigst av alt: vi sluttet å miste data.
La oss bare si at vi stoppet potensielt miste data, fordi vi egentlig ikke mistet dem. Men det var fare. Vi ser at denne løsningen selvfølgelig er god, men det er litt som å jevne ut symptomene på problemet, i stedet for å løse det helt. Og noen problemer gjenstår her.
For det første er dette et feilpunkt i form av selve den fysiske verten som alt dette maskineriet kjører på; det har ikke forsvunnet.
For det andre er det fortsatt problemer med SAN, deres tunge vedlikehold osv. gjenstår. Det var ikke det at det var en kritisk faktor, men jeg ville prøve å leve uten det på en eller annen måte.
Og vi laget den tredje versjonen (faktisk den andre) - reservasjonsversjonen. Hvordan så det ut?
Dette er hva det var -
Våre hovedproblemer er at dette er en fysisk vert.
For det første fjerner vi SAN-er fordi vi ønsker å eksperimentere, vi vil bare prøve lokale harddisker.
Dette er allerede 2014-2015, og på den tiden ble situasjonen med disker og deres kapasitet i en vert mye bedre. Vi bestemte oss for hvorfor ikke prøve det.
Og så tar vi ganske enkelt backup-partisjonen vår og overfører den fysisk til en egen maskin.
Dermed får vi dette diagrammet. Vi har to biler som lagrer de samme datasettene. De sikkerhetskopierer hverandre fullstendig og synkroniserer data over nettverket gjennom en asynkron kø i samme MySQL.
Hvorfor dette fungerer bra er fordi vi har få poster. De. hvis skriving var sammenlignbart med lesing, ville vi kanskje hatt en slags nettverksoverhead og problemer. Det er lite skriving, mye lesing – denne metoden fungerer bra, d.v.s. Vi kopierer sjelden bilder mellom disse to serverne.
Hvordan fungerer dette, hvis du ser litt mer i detalj.
Laste opp. Balanseren velger ganske enkelt tilfeldige verter med et par og laster opp til det. Samtidig gjør han naturligvis helsesjekker og sørger for at bilen ikke faller ut. De. han laster bare opp bilder til en live-server, og gjennom en asynkron kø blir det hele kopiert til naboen. Med opplasting er alt ekstremt enkelt.
Oppgaven er litt vanskeligere.
Lua hjalp oss her, fordi det kan være vanskelig å lage slik logikk på vanilje NGINX. Vi sender først en forespørsel til den første serveren, se om bildet er der, fordi det potensielt kan lastes opp, for eksempel til en nabo, men har ennå ikke kommet hit. Hvis bildet er der, er det bra. Vi gir det umiddelbart til klienten og, muligens, cacher det.
Hvis den ikke er der, sender vi rett og slett en forespørsel til naboen vår og vil garantert motta den derfra.
At. igjen kan vi si: det kan være problemer med ytelsen, fordi det er konstante rundturer - bildet ble lastet opp, det er ikke her, vi kommer med to forespørsler i stedet for én, dette skal fungere sakte.
I vår situasjon går ikke dette sakte.
Vi samler en haug med beregninger på dette systemet, og den betingede smarthastigheten for en slik mekanisme er omtrent 95%. De. Etterslepet til denne sikkerhetskopien er liten, og på grunn av dette er vi nesten garantert, etter at bildet er lastet opp, tar vi det første gang og trenger ikke å gå noe sted to ganger.
Så hva annet har vi som er veldig kult?
Tidligere hadde vi hovedreservepartisjonen, og vi leste fra dem sekvensielt. De. Vi søkte alltid på den viktigste først, og deretter på backupen. Det var ett trekk.
Nå bruker vi lesing fra to maskiner samtidig. Vi distribuerer forespørsler ved hjelp av Round Robin. I en liten prosentandel av tilfellene sender vi to forespørsler. Men totalt sett har vi nå dobbelt så mye leselager som vi hadde før. Og belastningen ble kraftig redusert både på sendemaskinene og direkte på lagermaskinene, som vi også hadde på den tiden.
Når det gjelder feiltoleranse. Egentlig er det dette vi hovedsakelig kjempet for. Med feiltoleranse ble alt bra her.
En bil går i stykker.
Ikke noe problem! En systemingeniør våkner kanskje ikke en gang om natten, han vil vente til morgenen, ingenting vondt vil skje.
Hvis selv om denne maskinen svikter, er køen ute av drift, er det heller ingen problemer, loggen vil rett og slett samles først på den levende maskinen, og deretter legges den til i køen, og så videre til bilen som skal settes i drift etter en stund.
Samme med vedlikehold. Vi slår ganske enkelt av en av maskinene, trekker den manuelt ut av alle bassengene, den slutter å motta trafikk, vi utfører en slags vedlikehold, vi redigerer noe, så tar vi den tilbake til tjeneste, og denne sikkerhetskopien fanger opp ganske raskt. De. per dag innhenter nedetiden for én bil innen et par minutter. Dette er egentlig veldig lite. Med feiltoleranse, sier jeg igjen, alt er kult her.
Hvilke konklusjoner kan trekkes fra denne permitteringsordningen?
Vi fikk feiltoleranse.
Lett å bruke. Siden maskinene har lokale harddisker, er dette mye mer praktisk fra et driftsmessig synspunkt for ingeniørene som jobber med det.
Vi fikk dobbelt lesegodtgjørelse.
Dette er en veldig god bonus i tillegg til feiltoleranse.
Men det er også problemer. Nå har vi en mye mer kompleks utvikling av enkelte funksjoner knyttet til dette, fordi systemet etter hvert har blitt 100 % konsistent.
Vi må si, i en eller annen bakgrunnsjobb, hele tiden tenke: "Hvilken server kjører vi på nå?", "Er det virkelig et aktuelt bilde her?" etc. Dette er selvfølgelig pakket opp, og for programmereren som skriver forretningslogikk er det gjennomsiktig. Men ikke desto mindre har dette store komplekse laget dukket opp. Men vi er klare til å tåle dette i bytte mot godbitene vi fikk fra den.
Og her oppstår igjen en viss konflikt.
Jeg sa i begynnelsen at det er dårlig å lagre alt på lokale harddisker. Og nå sier jeg at vi likte det.
Ja, faktisk, over tid har situasjonen endret seg mye, og nå har denne tilnærmingen mange fordeler. For det første får vi mye enklere drift.
For det andre er det mer produktivt, fordi vi ikke har disse automatiske kontrollerene eller tilkoblinger til diskhyller.
Det er en enorm mengde maskiner der, og dette er bare noen få disker som er satt sammen her på maskinen til et raid.
Men det er også ulemper.
Dette er omtrent 1,5 ganger dyrere enn å bruke SAN selv til dagens priser. Derfor bestemte vi oss for ikke å modig konvertere hele den store klyngen vår til biler med lokale harddisker og bestemte oss for å forlate en hybridløsning.
Halvparten av maskinene våre fungerer med harddisker (vel, ikke halvparten - sannsynligvis 30 prosent). Og resten er gamle biler som før hadde den første reservasjonsordningen. Vi monterte dem ganske enkelt på nytt, siden vi ikke trengte nye data eller noe annet, flyttet vi rett og slett festene fra en fysisk vert til to.
Og vi har nå et stort lager av lesing, og vi utvidet det. Hvis vi tidligere har montert ett lager på en maskin, monterer vi nå fire, for eksempel på ett par. Og det fungerer fint.
La oss ta en kort oppsummering av hva vi oppnådde, hva vi kjempet for, og om vi lyktes.
Resultater av
Vi har brukere – hele 33 millioner.
Vi har tre punkter - Praha, Miami, Hong Kong.
De inneholder et caching-lag, som består av biler med raske lokale disker (SSD-er), som enkelt maskineri fra NGINX, access.log og Python-demoner kjører på, som behandler alt dette og administrerer cachen.
Hvis du ønsker, er du i prosjektet ditt, hvis bilder ikke er like kritiske for deg som de er for oss, eller hvis avveiningskontroll kontra utviklingshastighet og ressurskostnader er i den andre retningen for deg, så kan du trygt erstatte det med et CDN, gjør moderne CDN det bra.
Deretter kommer lagringslaget, hvor vi har klynger av par med maskiner som sikkerhetskopierer hverandre, filer blir asynkront kopiert fra den ene til den andre når de endres.
Dessuten fungerer noen av disse maskinene med lokale harddisker.
Noen av disse maskinene er koblet til SAN-er.
Og på den ene siden er den mer praktisk å bruke og litt mer produktiv, på den annen side er den praktisk med tanke på plasseringstetthet og pris per gigabyte.
Dette er en så kort oversikt over arkitekturen til hva vi fikk og hvordan det hele utviklet seg.
Noen flere tips fra kapteinen, veldig enkle.
Først, hvis du plutselig bestemmer deg for at du trenger å forbedre alt i fotoinfrastrukturen din, må du måle først, for kanskje ingenting trenger å forbedres.
La meg gi deg et eksempel. Vi har en klynge med maskiner som sender bilder fra vedlegg i chatter, og ordningen har fungert der siden 2009, og ingen lider av det. Alle har det bra, alle liker alt.
For å måle, heng først en haug med beregninger, se på dem, og avgjør deretter hva du er misfornøyd med og hva som må forbedres. For å måle dette har vi et kult verktøy som heter Pinba.
Den lar deg samle inn svært detaljert statistikk fra NGINX for hver forespørsel og svarkoder, og fordeling av tider - hva du måtte ønske. Den har bindinger til alle mulige forskjellige analysesystemer, og da kan du se vakkert på det hele.
Først målte vi det, så forbedret vi det.
Lengre. Vi optimerer lesing med cache, skriving med sharding, men dette er et åpenbart poeng.
Lengre. Hvis du akkurat nå begynner å bygge systemet ditt, er det mye bedre å lage bilder som uforanderlige filer. Fordi du umiddelbart mister en hel klasse med problemer med cache-invalidering, med hvordan logikken skal finne riktig versjon av bildet, og så videre.
La oss si at du lastet opp hundre, så roterte det, gjør det slik at det var en fysisk annen fil. De. ingen grunn til å tenke: nå skal jeg spare litt plass, skrive det til samme fil, endre versjon. Dette fungerer alltid dårlig og forårsaker mye hodepine senere.
Neste punkt. Om å endre størrelse i farten.
Tidligere, når brukere lastet opp et bilde, kuttet vi umiddelbart en hel haug med størrelser for alle anledninger, for forskjellige klienter, og de var alle på disken. Nå har vi forlatt dette.
Vi forlot bare tre hovedstørrelser: liten, medium og stor. Vi nedskalerer rett og slett alt annet fra størrelsen som står bak den som ble spurt oss på Uport, vi gjør rett og slett nedskaleringen og gir den til brukeren.
CPU-en til caching-laget her viser seg å være mye billigere enn om vi hele tiden regenererte disse størrelsene på hver lagring. La oss si at vi ønsker å legge til en ny, dette vil ta en måned – kjør et skript overalt som ville gjøre alt dette pent, uten å ødelegge klyngen. De. Hvis du har mulighet til å velge nå, er det bedre å lage så få fysiske størrelser som mulig, men slik at i det minste en viss fordeling er for eksempel tre. Og alt annet kan enkelt endres på farten ved hjelp av ferdige moduler. Det hele er veldig enkelt og tilgjengelig nå.
Og inkrementell asynkron backup er bra.
Som vår praksis har vist, fungerer denne ordningen utmerket med forsinket kopiering av endrede filer.
Det siste punktet er også åpenbart. Hvis infrastrukturen din ikke har slike problemer nå, men det er noe som kan gå i stykker, vil den garantert gå i stykker når det blir litt mer. Derfor er det bedre å tenke på dette på forhånd og ikke oppleve problemer med det. Det var alt jeg ville si.
kontakter
»
»
Denne rapporten er en utskrift av en av de beste talene på konferansen for utviklere av høylastsystemer . Det er mindre enn en måned igjen til HighLoad++ 2017-konferansen.
Vi har den allerede klar , timeplanen blir nå aktivt dannet.
I år fortsetter vi å utforske temaet arkitektur og skalering:
- / Igor Vasiliev
- / Dmitry Egorov
- / Anatoly Plaskovsky
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Philip Delgado
Vi bruker også noen av disse materialene i vårt nettbaserte kurs om utvikling av høylastsystemer er en kjede av spesielt utvalgte brev, artikler, materialer, videoer. Læreboken vår inneholder allerede mer enn 30 unike materialer. Koble!
Kilde: www.habr.com