Artem Denisov ( , )
Badoo er verdens største datingside. Vi har i øjeblikket omkring 330 millioner registrerede brugere på verdensplan. Men hvad der er meget vigtigere i forbindelse med vores samtale i dag er, at vi gemmer omkring 3 petabyte af brugerbilleder. Hver dag uploader vores brugere omkring 3,5 millioner nye billeder, og læsebelastningen er ca 80 tusinde anmodninger i sekundet. Dette er ret meget for vores backend, og nogle gange er der vanskeligheder med dette.
Jeg vil tale om designet af dette system, som gemmer og sender billeder generelt, og jeg vil se på det fra en udviklers synspunkt. Der vil være et kort tilbageblik på, hvordan det udviklede sig, hvor jeg vil skitsere de vigtigste milepæle, men jeg vil kun tale mere detaljeret om de løsninger, som vi bruger i øjeblikket.
Lad os nu komme i gang.
Som sagt vil dette være et tilbageblik, og for at starte det et sted, lad os tage det mest almindelige eksempel.
Vi har en fælles opgave, vi skal acceptere, gemme og sende brugerbilleder. I denne form er opgaven generel, vi kan bruge hvad som helst:
- moderne cloud storage,
- en kasseløsning, som der også er mange af nu;
- Vi kan sætte flere maskiner op i vores datacenter og sætte store harddiske på dem og gemme billeder der.
Badoo bor historisk - både nu og dengang (på det tidspunkt, hvor det kun var i sin vorden) - på sine egne servere, inde i vores egne DC'er. Derfor var denne mulighed optimal for os.
Vi tog bare flere maskiner, kaldte dem "fotos", og vi fik en klynge, der gemmer billeder. Men det ser ud som om der mangler noget. For at alt dette skal fungere, skal vi på en eller anden måde bestemme, på hvilken maskine vi gemmer hvilke fotos. Og her er der heller ingen grund til at åbne Amerika.
Vi tilføjer et felt til vores lager med oplysninger om brugere. Dette vil være skæringsnøglen. I vores tilfælde kaldte vi det place_id, og dette sted-id peger på det sted, hvor brugerbilleder er gemt. Vi laver kort.
På det første trin kan dette endda gøres manuelt - vi siger, at et billede af denne bruger med et sådant sted vil lande på sådan en server. Takket være dette kort ved vi altid, hvornår en bruger uploader et billede, hvor det skal gemmes, og vi ved, hvor vi skal give det fra.
Dette er en absolut triviel ordning, men den har ganske betydelige fordele. Det første er, at det som sagt er enkelt, og det andet er, at vi med denne tilgang nemt kan skalere horisontalt ved blot at levere nye biler og tilføje dem til kortet. Du behøver ikke gøre andet.
Sådan var det for os i nogen tid.
Dette var omkring 2009. De leverede biler, leverede...
Og på et tidspunkt begyndte vi at bemærke, at denne ordning har visse ulemper. Hvad er ulemperne?
Først og fremmest er der begrænset kapacitet. Vi kan ikke proppe så mange harddiske ind på én fysisk server, som vi gerne vil. Og dette er blevet et vist problem over tid og med væksten i datasættet.
Og for det andet. Dette er en atypisk konfiguration af maskiner, da sådanne maskiner er svære at genbruge i nogle andre klynger; de er ret specifikke, dvs. de skal være svage i ydeevne, men samtidig med en stor harddisk.
Det hele var for 2009, men i princippet er disse krav stadig relevante i dag. Vi har et retrospektiv, så i 2009 var alt helt galt med det her.
Og det sidste punkt er prisen.
Prisen var meget høj på det tidspunkt, og vi var nødt til at kigge efter nogle alternativer. De der. vi skulle på en eller anden måde bedre udnytte både pladsen i datacentrene og de fysiske servere, hvor alt dette er placeret. Og vores systemingeniører påbegyndte en stor undersøgelse, hvor de gennemgik en masse forskellige muligheder. De så også på klyngede filsystemer som PolyCeph og Luster. Der var præstationsproblemer og ret vanskelig betjening. De nægtede. Vi forsøgte at montere hele datasættet via NFS på hver bil for på en eller anden måde at skalere det op. Læsning gik også dårligt, vi prøvede forskellige løsninger fra forskellige leverandører.
Og til sidst besluttede vi os for at bruge det såkaldte Storage Area Network.
Det er store SHD'er, der er specielt designet til at gemme store mængder data. De er hylder med diske, der er monteret på de endelige optiske outputmaskiner. At. vi har en slags pulje af maskiner, ganske små, og disse SHD'er, som er gennemsigtige for vores sendelogik, dvs. for vores nginx eller nogen anden til at betjene anmodninger om disse billeder.
Denne beslutning havde indlysende fordele. Dette er SHD. Det er rettet mod at gemme billeder. Dette virker billigere end blot at udstyre maskiner med harddiske.
Andet plus.
Det er, at kapaciteten er blevet meget større, dvs. vi kan rumme meget mere lagerplads i et meget mindre volumen.
Men der var også ulemper, som dukkede op ret hurtigt. Efterhånden som antallet af brugere og belastningen på dette system voksede, begyndte ydeevneproblemer at opstå. Og problemet her er ret indlysende - enhver SHD designet til at gemme mange fotos i et lille volumen lider som regel af intensiv læsning. Dette gælder faktisk for enhver cloud storage eller noget andet. Nu har vi ikke et ideelt lager, der ville være uendeligt skalerbart, du kan proppe hvad som helst i det, og det ville tåle aflæsninger meget godt. Især tilfældige læsninger.
Ligesom det er tilfældet med vores billeder, fordi billeder er anmodet om inkonsekvent, og dette vil i høj grad påvirke deres ydeevne.
Selv ifølge dagens tal, hvis vi får et sted mere end 500 RPS for fotos på en maskine, som lager er tilsluttet, begynder problemerne allerede. Og det var slemt nok for os, for antallet af brugere vokser, tingene bliver kun værre. Dette skal på en eller anden måde optimeres.
For at optimere besluttede vi på det tidspunkt naturligvis at se på belastningsprofilen - hvad der generelt sker, hvad skal optimeres.
Og her spiller alt i vores hænder.
Jeg sagde allerede i det første slide: Vi har 80 tusinde læseanmodninger i sekundet med kun 3,5 millioner uploads om dagen. Det vil sige, at dette er en forskel på tre størrelsesordener. Det er indlysende, at læsning skal optimeres, og det er praktisk talt klart hvordan.
Der er endnu en lille pointe. Tjenestens specifikationer er sådan, at en person registrerer sig, uploader et billede, begynder derefter aktivt at se på andre mennesker, kan lide dem og vises aktivt til andre mennesker. Så finder han en mage eller finder ikke en mage, det afhænger af, hvordan det bliver, og holder op med at bruge tjenesten i et stykke tid. I dette øjeblik, når han bruger det, er hans billeder meget varme - de er efterspurgte, mange mennesker ser dem. Så snart han holder op med dette, falder han ret hurtigt ud af så meget eksponering for andre mennesker, som han havde før, og hans billeder bliver næsten aldrig anmodet om.
De der. Vi har et meget lille hot datasæt. Men samtidig er der rigtig mange ønsker til ham. Og en helt oplagt løsning her er at tilføje en cache.
En cache med LRU vil løse alle vores problemer. Hvad laver vi?
Vi tilføjer endnu en forholdsvis lille en foran vores store klynge med opbevaring, som kaldes photocaches. Dette er i bund og grund kun en caching-proxy.
Hvordan fungerer det indefra? Her er vores bruger, her er opbevaring. Alt er det samme som før. Hvad tilføjer vi imellem?
Det er bare en maskine med en fysisk lokal disk, som er hurtig. Dette er for eksempel med en SSD. Og en slags lokal cache er gemt på denne disk.
Hvordan ser det ud? Brugeren sender en anmodning om et billede. NGINX leder efter det først i den lokale cache. Hvis ikke, så skal du blot proxy_passe til vores lager, downloade billedet derfra og give det til brugeren.
Men denne er meget banal, og det er uklart, hvad der sker indeni. Det virker sådan noget.
Cachen er logisk opdelt i tre lag. Når jeg siger "tre lag", betyder det ikke, at der er en form for komplekst system. Nej, disse er betinget kun tre mapper i filsystemet:
- Dette er en buffer, hvor billeder, der lige er downloadet fra en proxy, går.
- Dette er en hot cache, der i øjeblikket gemmer aktivt anmodede billeder.
- Og en kold cache, hvor billeder gradvist skubbes ud af den varme cache, når der kommer færre forespørgsler til dem.
For at dette skal virke, skal vi på en eller anden måde administrere denne cache, vi skal omarrangere billederne i den osv. Dette er også en meget primitiv proces.
Nginx skriver ganske enkelt til RAMDisk access.log for hver anmodning, hvor den angiver stien til det foto, som den aktuelt har serveret (relativ sti, selvfølgelig), og hvilken partition den blev serveret. De der. der kan stå "foto 1" og derefter enten en buffer eller en varm cache, eller en kold cache eller en proxy.
Afhængigt af dette skal vi på en eller anden måde beslutte, hvad vi skal gøre med billedet.
Vi har en lille dæmon kørende på hver maskine, som konstant læser denne log og gemmer statistik om brugen af bestemte fotografier i sin hukommelse.
Han samler simpelthen der, holder tællerne og gør med jævne mellemrum følgende. Han flytter aktivt efterspurgte billeder, som der er mange anmodninger om, til den varme cache, uanset hvor de er.
Billeder, der efterspørges sjældent og er blevet efterspurgt sjældnere, skubbes gradvist ud af den varme cache til den kolde.
Og når vi løber tør for plads i cachen, begynder vi simpelthen at slette alt fra den kolde cache vilkårligt. Og det fungerer i øvrigt godt.
For at billedet kan gemmes med det samme, når det overføres til bufferen, bruger vi proxy_store-direktivet og bufferen er også en RAMDisk, dvs. for brugeren fungerer det meget hurtigt. Dette vedrører selve cachingserverens interne dele.
Det resterende spørgsmål er, hvordan man fordeler anmodninger på tværs af disse servere.
Lad os sige, at der er en klynge på tyve lagermaskiner og tre caching-servere (sådan skete det).
Vi skal på en eller anden måde bestemme, hvilke anmodninger der er til hvilke billeder, og hvor vi skal lande dem.
Den mest almindelige mulighed er Round Robin. Eller gør det ved et uheld?
Dette har naturligvis en række ulemper, fordi vi ville bruge cachen meget ineffektivt i en sådan situation. Forespørgsler vil lande på nogle tilfældige maskiner: her blev den cachelagret, men på den næste er den der ikke længere. Og hvis alt dette virker, vil det være meget slemt. Selv med et lille antal maskiner i klyngen.
Vi skal på en eller anden måde utvetydigt bestemme, hvilken server der skal lande hvilken anmodning.
Der er en banal måde. Vi tager hashen fra URL'en eller hashen fra vores sharding nøgle, som er i URL'en, og dividerer den med antallet af servere. Vil arbejde? Vilje.
De der. Vi har en 2% forespørgsel, for eksempel vil den for nogle "example_url" altid lande på serveren med indekset "XNUMX", og cachen bliver konstant bortskaffet bedst muligt.
Men der er et problem med omfordeling i sådan en ordning. Resharding - jeg mener at ændre antallet af servere.
Lad os antage, at vores caching-klynge ikke længere kan klare det, og vi beslutter os for at tilføje en anden maskine.
Lad os tilføje.
Nu er alt deleligt ikke med tre, men med fire. Således, næsten alle de nøgler, som vi plejede at have, næsten alle URL'erne lever nu på andre servere. Hele cachen blev ugyldigt blot et øjeblik. Alle anmodninger faldt på vores lagerklynge, det blev utilpas, servicefejl og utilfredse brugere. Det vil jeg ikke gøre.
Denne mulighed passer heller ikke os.
At. hvad skal vi gøre? Vi skal på en eller anden måde gøre effektiv brug af cachen, lande den samme anmodning på den samme server igen og igen, men være modstandsdygtige over for resharding. Og der er sådan en løsning, det er ikke så kompliceret. Det kaldes konsekvent hashing.
Hvordan ser det ud?
Vi tager nogle funktioner fra sharding-tasten og spreder alle dens værdier på cirklen. De der. ved punkt 0 konvergerer dens minimums- og maksimumværdier. Dernæst placerer vi alle vores servere på den samme cirkel på omtrent denne måde:
Hver server er defineret af et punkt, og den sektor, der går med uret til den, betjenes derfor af denne vært. Når der kommer forespørgsler til os, ser vi med det samme, at for eksempel anmodning A - den har en hash der - og den betjenes af server 2. Forespørgsel B - af server 3. Og så videre.
Hvad sker der i denne situation under omdeling?
Vi ugyldiggør ikke hele cachen, som før, og flytter ikke alle nøglerne, men vi flytter hver sektor en kort afstand, så relativt set vores sjette server, som vi vil tilføje, passer ind i det ledige rum, og vi tilføjer det der.
I en sådan situation rykker tasterne selvfølgelig også ud. Men de rykker meget svagere ud end før. Og vi ser, at vores første to nøgler forblev på deres servere, og cacheserveren ændrede sig kun for den sidste nøgle. Dette fungerer ret effektivt, og hvis du tilføjer nye værter trinvist, så er der ikke noget stort problem her. Du tilføjer og tilføjer lidt ad gangen, venter til cachen er fuld igen, og alt fungerer godt.
Det eneste spørgsmål er tilbage med afslag. Lad os antage, at en slags bil er ude af drift.
Og vi ønsker ikke rigtig at regenerere dette kort i øjeblikket, ugyldiggøre en del af cachen og så videre, hvis for eksempel maskinen blev genstartet, og vi på en eller anden måde er nødt til at servicere anmodninger. Vi har simpelthen en backup-fotocache på hvert websted, som fungerer som en erstatning for enhver maskine, der i øjeblikket er nede. Og hvis en af vores servere pludselig bliver utilgængelig, går trafikken dertil. Vi har naturligvis ingen cache der, dvs. det er koldt, men i det mindste bliver brugeranmodninger behandlet. Hvis det er et kort interval, så oplever vi det helt roligt. Der er bare mere belastning på lager. Hvis dette interval er langt, kan vi allerede træffe en beslutning - om at fjerne denne server fra kortet eller ej, eller måske erstatte den med en anden.
Dette handler om caching-systemet. Lad os se på resultaterne.
Det ser ud til, at der ikke er noget kompliceret her. Men denne metode til at administrere cachen gav os en trickrate på omkring 98%. De der. ud af disse 80 tusinde anmodninger i sekundet, når kun 1600 lager, og det er en helt normal belastning, de tåler det roligt, vi har altid en reserve.
Vi placerede disse servere i tre af vores DC'er og modtog tre tilstedeværelsespunkter - Prag, Miami og Hong Kong.
At. de er mere eller mindre lokalt placeret i forhold til hvert af vores målmarkeder.
Og som en fin bonus fik vi denne caching-proxy, hvor CPU'en faktisk er inaktiv, fordi den ikke er så nødvendig for at servere indhold. Og der, ved hjælp af NGINX+ Lua, implementerede vi en masse utilitaristisk logik.
For eksempel kan vi eksperimentere med webp eller progressiv jpeg (disse er effektive moderne formater), se hvordan det påvirker trafikken, træffe nogle beslutninger, aktivere det for visse lande osv.; lav dynamisk ændring af størrelse eller beskær fotos på farten.
Dette er en god usecase, når du for eksempel har en mobilapplikation, der viser billeder, og mobilapplikationen ikke ønsker at spilde klientens CPU på at anmode om et stort billede og derefter ændre størrelsen på det til en bestemt størrelse for at skubbe det ind i udsigten. Vi kan ganske enkelt dynamisk angive nogle parametre i den betingede UPort-URL, og fotocachen vil ændre størrelsen på selve billedet. Som regel vil den vælge den størrelse, som vi fysisk har på disken, så tæt som muligt på den ønskede, og nedsælge den i specifikke koordinater.
Forresten har vi lavet offentligt tilgængelige videooptagelser af de sidste fem år af konferencen for udviklere af højbelastningssystemer . Se, lær, del og abonner på .
Vi kan også tilføje en masse produktlogik der. For eksempel kan vi tilføje forskellige vandmærker ved hjælp af URL-parametre, vi kan sløre, sløre eller pixelere billeder. Det er, når vi vil vise et billede af en person, men vi ønsker ikke at vise hans ansigt, det fungerer godt, det hele er implementeret her.
Hvad fik vi? Vi fik tre point of tilstedeværelse, en god trick rate, og samtidig har vi ikke ledig CPU på disse maskiner. Han er nu selvfølgelig blevet vigtigere end før. Vi skal give os selv stærkere biler, men det er det værd.
Det drejer sig om returnering af fotografier. Alt her er helt klart og tydeligt. Jeg tror, at jeg ikke opdagede Amerika, næsten enhver CDN fungerer på denne måde.
Og højst sandsynligt kan en sofistikeret lytter have et spørgsmål: hvorfor ikke bare ændre alt til CDN? Det ville være omtrent det samme; alle moderne CDN'er kan gøre dette. Og der er en række årsager.
Den første er fotografier.
Dette er et af nøglepunkterne i vores infrastruktur, og vi har brug for så meget kontrol over det som muligt. Hvis dette er en slags løsning fra en tredjepartsleverandør, og du ikke har magt over det, vil det være ret svært for dig at leve med det, når du har et stort datasæt, og når du har et meget stort flow af brugeranmodninger.
Lad mig give dig et eksempel. Nu kan vi med vores infrastruktur, for eksempel i tilfælde af nogle problemer eller underjordiske banker, gå hen til maskinen og rode rundt der, relativt set. Vi kan tilføje samlingen af nogle målinger, som vi kun har brug for, vi kan eksperimentere på en eller anden måde, se, hvordan dette påvirker graferne, og så videre. Nu bliver der indsamlet en masse statistik om denne caching-klynge. Og vi ser med jævne mellemrum på det og bruger lang tid på at udforske nogle anomalier. Hvis det var på CDN-siden, ville det være meget sværere at kontrollere. Eller hvis der for eksempel sker en form for ulykke, ved vi, hvad der skete, vi ved, hvordan vi skal leve med det, og hvordan vi overvinder det. Dette er den første konklusion.
Den anden konklusion er også ret historisk, fordi systemet har været under udvikling i lang tid, og der var mange forskellige forretningskrav på forskellige stadier, og de passer ikke altid ind i CDN-konceptet.
Og det punkt, der følger af den foregående, er
Dette skyldes, at vi på fotocaches har en masse specifik logik, som ikke altid kan tilføjes efter anmodning. Det er usandsynligt, at nogen CDN vil tilføje nogle tilpassede ting til dig på din anmodning. For eksempel kryptering af URL'er, hvis du ikke ønsker, at klienten skal kunne ændre noget. Vil du ændre URL'en på serveren og kryptere den, og så sende nogle dynamiske parametre hertil.
Hvilken konklusion tyder dette på? I vores tilfælde er CDN ikke et særlig godt alternativ.
Og i dit tilfælde, hvis du har nogle specifikke forretningskrav, så kan du ganske nemt implementere det, jeg selv viste dig. Og dette vil fungere perfekt med en lignende belastningsprofil.
Men hvis du har en form for generel løsning, og opgaven ikke er særlig specifik, kan du helt sikkert tage et CDN. Eller hvis tid og ressourcer er vigtigere for dig end kontrol.
Og moderne CDN'er har næsten alt, hvad jeg fortalte dig om nu. Med undtagelse af plus eller minus nogle funktioner.
Det handler om at give billeder væk.
Lad os nu gå lidt frem i vores retrospektiv og tale om opbevaring.
2013 var ved at gå.
Cachingservere blev tilføjet, ydeevneproblemer forsvandt. Alt er fint. Datasættet vokser. Fra 2013 havde vi omkring 80 servere forbundet til lager og omkring 40 caching i hver DC. Dette er 560 terabyte data på hver DC, dvs. omkring en petabyte i alt.
Og med væksten i datasættet begyndte driftsomkostningerne at stige markant. Hvad betød dette?
I dette diagram, der er tegnet - med et SAN, med maskiner og caches tilsluttet - er der mange fejlpunkter. Hvis vi allerede havde håndteret fejlen i caching-servere før, var alt mere eller mindre forudsigeligt og forståeligt, men på lagersiden var alt meget værre.
For det første selve Storage Area Network (SAN), som kan fejle.
For det andet forbindes den via optik til slutmaskinerne. Der kan være problemer med optiske kort og tændrør.
Selvfølgelig er der ikke så mange af dem som med selve SAN, men ikke desto mindre er disse også fejlpunkter.
Dernæst er selve maskinen, som er forbundet med lageret. Det kan også fejle.
I alt har vi tre fejlpunkter.
Ud over fejlpunkter er der desuden omfattende vedligeholdelse af selve lageret.
Dette er et komplekst multi-komponent system, og systemingeniører kan have svært ved at arbejde med det.
Og det sidste, vigtigste punkt. Hvis der opstår en fejl på et af disse tre punkter, har vi en chance for at miste brugerdata, der ikke er nul, fordi filsystemet kan gå ned.
Lad os sige, at vores filsystem er ødelagt. For det første tager det lang tid - det kan tage en uge med en stor mængde data. Og for det andet vil vi i sidste ende højst sandsynligt ende med en masse uforståelige filer, der på en eller anden måde skal kombineres til brugerbilleder. Og vi risikerer at miste data. Risikoen er ret høj. Og jo oftere sådanne situationer sker, og jo flere problemer der opstår i hele denne kæde, jo højere er denne risiko.
Det måtte der gøres noget ved. Og vi besluttede, at vi bare skulle sikkerhedskopiere dataene. Dette er faktisk en oplagt løsning og en god en. Hvad har vi gjort?
Sådan så vores server ud, da den før var forbundet til lager. Dette er en hovedsektion, det er bare en blokenhed, der faktisk repræsenterer en montering til fjernlagring via optik.
Vi har lige tilføjet et andet afsnit.
Vi placerede et andet lager ved siden af det (heldigvis er det ikke så dyrt i form af penge), og kaldte det en backup-partition. Den er også forbundet via optisk fiber og er placeret på samme maskine. Men vi skal på en eller anden måde synkronisere dataene mellem dem.
Her laver vi simpelthen en asynkron kø i nærheden.
Hun har ikke særlig travlt. Vi ved, at vi ikke har nok rekorder. En kø er blot en tabel i MySQL, hvor linjer som "du skal tage backup af dette billede" er skrevet. Med enhver ændring eller upload kopierer vi fra hovedpartitionen til backup ved hjælp af en asynkron eller bare en slags baggrundsarbejder.
Og dermed har vi altid to sammenhængende afsnit. Selvom en del af dette system fejler, kan vi altid ændre hovedpartitionen med en sikkerhedskopi, og alt vil fortsætte med at fungere.
Men på grund af dette øges læsebelastningen meget, fordi... ud over klienter, der læser fra hovedafsnittet, fordi de først ser på billedet der (det er nyere der), og derefter kigger efter det på sikkerhedskopien, hvis de ikke har fundet det (men NGINX gør bare dette), vores system er også et plus backup læser nu fra hovedpartitionen. Det er ikke, at dette var en flaskehals, men jeg ønskede ikke at øge belastningen, i det væsentlige, bare sådan.
Og vi tilføjede en tredje disk, som er en lille SSD, og kaldte den en buffer.
Hvordan fungerer det nu.
Brugeren uploader et billede til bufferen, hvorefter en begivenhed smidt ind i køen, der indikerer, at det skal kopieres i to sektioner. Det kopieres, og billedet lever på bufferen i nogen tid (f.eks. en dag), og først derefter renses det derfra. Dette forbedrer brugeroplevelsen markant, fordi brugeren uploader et billede, som regel begynder anmodninger straks at følge, eller han har selv opdateret siden og opdateret den. Men det hele afhænger af den applikation, der laver uploaden.
Eller for eksempel andre mennesker, som han begyndte at vise sig til, sender straks anmodninger efter dette billede. Den er endnu ikke i cachen, den første anmodning sker meget hurtigt. Grundlæggende det samme som fra en fotocache. Langsom opbevaring er slet ikke involveret i dette. Og når det en dag senere er renset, er det allerede enten cachet på vores cachinglag, eller højst sandsynligt er der ingen, der har brug for det længere. De der. Brugeroplevelsen her er vokset meget godt på grund af så simple manipulationer.
Nå, og vigtigst af alt: vi holdt op med at miste data.
Lad os bare sige, at vi stoppede potentielt miste data, fordi vi ikke rigtig mistede dem. Men der var fare. Vi ser, at denne løsning selvfølgelig er god, men det er lidt ligesom at udjævne symptomerne på problemet, i stedet for at løse det helt. Og der er stadig nogle problemer her.
For det første er dette et fejlpunkt i form af selve den fysiske vært, som alt dette maskineri kører på; det er ikke forsvundet.
For det andet er der stadig problemer med SAN'er, deres tunge vedligeholdelse osv. er tilbage. Det var ikke, at det var en kritisk faktor, men jeg ville prøve at leve uden det.
Og vi lavede den tredje version (faktisk den anden) - reservationsversionen. Hvordan så det ud?
Dette er hvad det var -
Vores største problemer er med, at dette er en fysisk vært.
For det første fjerner vi SAN'er, fordi vi vil eksperimentere, vi vil bare prøve lokale harddiske.
Dette er allerede 2014-2015, og på det tidspunkt blev situationen med diske og deres kapacitet i én vært meget bedre. Vi besluttede, hvorfor ikke prøve det.
Og så tager vi simpelthen vores backup-partition og overfører den fysisk til en separat maskine.
Således får vi dette diagram. Vi har to biler, der opbevarer de samme datasæt. De sikkerhedskopierer hinanden fuldstændigt og synkroniserer data over netværket gennem en asynkron kø i samme MySQL.
Hvorfor det fungerer godt, er fordi vi har få poster. De der. hvis skrivning kunne sammenlignes med læsning, ville vi måske have en form for netværksoverhead og problemer. Der er lidt skrivning, meget læsning – denne metode fungerer godt, dvs. Vi kopierer sjældent billeder mellem disse to servere.
Hvordan fungerer det, hvis man ser lidt mere i detaljer.
Upload. Balanceren vælger blot tilfældige værter med et par og uploader til det. Samtidig laver han naturligvis sundhedstjek og sørger for, at bilen ikke falder ud. De der. han uploader kun billeder til en live server, og gennem en asynkron kø bliver det hele kopieret til hans nabo. Med upload er alt ekstremt enkelt.
Opgaven er lidt sværere.
Lua hjalp os her, for det kan være svært at lave en sådan logik på vanilla NGINX. Vi laver først en forespørgsel til den første server, se om billedet er der, for potentielt kan det uploades, for eksempel til en nabo, men er endnu ikke ankommet hertil. Hvis billedet er der, er det godt. Vi giver det straks til klienten og cacherer det muligvis.
Hvis den ikke er der, retter vi blot en henvendelse til vores nabo og modtager den med garanti derfra.
At. igen kan vi sige: der kan være problemer med ydeevnen, fordi der er konstante rundrejser - billedet blev uploadet, det er ikke her, vi laver to anmodninger i stedet for én, det burde virke langsomt.
I vores situation går det ikke langsomt.
Vi indsamler en masse målinger på dette system, og den betingede smart rate for en sådan mekanisme er omkring 95%. De der. Forsinkelsen af denne backup er lille, og på grund af dette er vi næsten garanteret, efter at billedet er blevet uploadet, henter vi det første gang og behøver ikke at gå nogen steder to gange.
Så hvad har vi ellers, der er rigtig fedt?
Tidligere havde vi den primære backup-partition, og vi læste fra dem sekventielt. De der. Vi søgte altid på den primære først og derefter på backup. Det var et træk.
Nu bruger vi læsning fra to maskiner på én gang. Vi distribuerer forespørgsler ved hjælp af Round Robin. I en lille procentdel af tilfældene fremsætter vi to anmodninger. Men samlet set har vi nu dobbelt så meget læselager, som vi havde før. Og belastningen blev stærkt reduceret både på sendemaskinerne og direkte på lagermaskinerne, som vi også havde dengang.
Hvad angår fejltolerance. Det er faktisk det, vi primært kæmpede for. Med fejltolerance viste alt sig godt her.
En bil går i stykker.
Intet problem! En systemingeniør vågner måske ikke engang om natten, han venter til morgenen, intet dårligt vil ske.
Hvis selv om denne maskine svigter, er køen ude af drift, er der heller ingen problemer, loggen bliver simpelthen samlet først på den levende maskine, og så bliver den tilføjet til køen, og så videre til bilen, der vil gå i drift efter nogen tid.
Det samme med vedligeholdelse. Vi slukker simpelthen for en af maskinerne, trækker den manuelt ud af alle pools, den holder op med at modtage trafik, vi laver en form for vedligeholdelse, vi redigerer noget, så vender vi den tilbage til service, og denne backup indhenter ret hurtigt. De der. om dagen, indhenter nedetiden for én bil inden for et par minutter. Dette er virkelig meget lidt. Med fejltolerance, siger jeg igen, alt er fedt her.
Hvilke konklusioner kan man drage af denne afskedigelsesordning?
Vi fik fejltolerance.
Let at bruge. Da maskinerne har lokale harddiske, er dette meget mere praktisk set ud fra et driftsmæssigt synspunkt for de ingeniører, der arbejder med det.
Vi fik dobbelt læsepenge.
Dette er en meget god bonus ud over fejltolerance.
Men der er også problemer. Nu har vi en meget mere kompleks udvikling af nogle funktioner relateret til dette, fordi systemet efterhånden er blevet 100% konsistent.
Vi må sige, i et eller andet baggrundsjob, konstant tænke: "Hvilken server kører vi på nu?", "Er der virkelig et aktuelt billede her?" etc. Det hele er selvfølgelig pakket ind, og for programmøren, der skriver forretningslogik, er det gennemsigtigt. Men ikke desto mindre er dette store komplekse lag dukket op. Men vi er klar til at affinde os med dette til gengæld for de lækkerier, vi har modtaget fra det.
Og her opstår der igen en vis konflikt.
Jeg sagde i begyndelsen, at det er dårligt at gemme alt på lokale harddiske. Og nu siger jeg, at vi kunne lide det.
Ja, faktisk har situationen ændret sig meget over tid, og nu har denne tilgang mange fordele. For det første får vi meget enklere betjening.
For det andet er det mere produktivt, fordi vi ikke har disse automatiske controllere eller forbindelser til diskhylder.
Der er en enorm mængde maskiner der, og det er blot nogle få diske, der er samlet her på maskinen til et raid.
Men der er også ulemper.
Dette er cirka 1,5 gange dyrere end at bruge SAN'er selv til dagens priser. Derfor besluttede vi ikke at vove at konvertere hele vores store klynge til biler med lokale harddiske og besluttede at forlade en hybridløsning.
Halvdelen af vores maskiner arbejder med harddiske (nå, ikke halvdelen - sandsynligvis 30 procent). Og resten er gamle biler, der før havde den første reservationsordning. Vi monterede dem simpelthen igen, da vi ikke havde brug for nye data eller andet, vi flyttede simpelthen monteringerne fra én fysisk vært til to.
Og vi har nu et stort lager af læsning, og vi udvidede det. Hvis vi tidligere monterede et lager på en maskine, monterer vi nu fire, for eksempel på et par. Og det fungerer fint.
Lad os tage en kort opsummering af, hvad vi opnåede, hvad vi kæmpede for, og om det lykkedes.
Resultaterne af
Vi har brugere – hele 33 mio.
Vi har tre tilstedeværelsespunkter - Prag, Miami, Hong Kong.
De indeholder et caching-lag, som består af biler med hurtige lokale diske (SSD'er), hvorpå der kører simpelt maskineri fra NGINX, dets access.log og Python-dæmoner, som behandler alt dette og administrerer cachen.
Hvis du ønsker det, er du i dit projekt, hvis billeder ikke er lige så kritiske for dig, som de er for os, eller hvis afvejningskontrol i forhold til udviklingshastighed og ressourceomkostninger er i den anden retning for dig, så kan du roligt erstatte det med et CDN, er moderne CDN'er, de klarer sig godt.
Dernæst kommer lagerlaget, hvor vi har klynger af par af maskiner, der sikkerhedskopierer hinanden, filer kopieres asynkront fra den ene til den anden, når de ændres.
Desuden arbejder nogle af disse maskiner med lokale harddiske.
Nogle af disse maskiner er forbundet til SAN'er.
Og på den ene side er den mere praktisk at bruge og lidt mere produktiv, på den anden side er den praktisk med hensyn til placeringstæthed og pris pr. gigabyte.
Dette er sådan en kort oversigt over arkitekturen af, hvad vi fik, og hvordan det hele udviklede sig.
Et par flere tips fra kaptajnen, meget enkle.
For det første, hvis du pludselig beslutter dig for, at du har brug for at forbedre alt i din fotoinfrastruktur, så mål først, for måske skal der ikke forbedres noget.
Lad mig give dig et eksempel. Vi har en klynge af maskiner, der sender billeder fra vedhæftede filer i chats, og ordningen har fungeret der siden 2009, og ingen lider under det. Alle har det godt, alle kan lide alt.
For at måle skal du først hænge en masse målinger, se på dem og derefter beslutte, hvad du er utilfreds med, og hvad der skal forbedres. For at kunne måle dette har vi et sejt værktøj kaldet Pinba.
Det giver dig mulighed for at indsamle meget detaljerede statistikker fra NGINX for hver forespørgsel og svarkoder, og fordeling af tider - hvad end du ønsker. Den har bindinger til alle mulige forskellige analysesystemer, og så kan man se smukt på det hele.
Først målte vi det, så forbedrede vi det.
Yderligere. Vi optimerer læsning med cache, skrivning med sharding, men det er en oplagt pointe.
Yderligere. Hvis du lige nu begynder at bygge dit system, så er det meget bedre at lave fotos som uforanderlige filer. For du mister med det samme en hel klasse af problemer med cache-invalidering, med hvordan logikken skal finde den korrekte version af billedet, og så videre.
Lad os sige, at du har uploadet hundrede og derefter roteret det, så det var en fysisk anderledes fil. De der. ingen grund til at tænke: nu vil jeg spare lidt plads, skrive det til den samme fil, ændre versionen. Dette virker altid ikke godt og forårsager en masse hovedpine senere.
Næste punkt. Om at ændre størrelse i farten.
Tidligere, når brugere uploadede et billede, klippede vi straks en hel masse størrelser til alle lejligheder, til forskellige klienter, og de var alle på disken. Nu har vi opgivet dette.
Vi efterlod kun tre hovedstørrelser: lille, mellem og stor. Vi nedskalerer simpelthen alt andet fra den størrelse, der står bag den, der blev bedt om til os på Uport, vi laver simpelthen nedskaleringen og giver den til brugeren.
CPU'en i cachinglaget her viser sig at være meget billigere, end hvis vi konstant regenererede disse størrelser på hvert lager. Lad os sige, at vi vil tilføje et nyt, det vil tage en måned – kør et script overalt, der ville gøre alt dette pænt uden at ødelægge klyngen. De der. Hvis du har mulighed for at vælge nu, er det bedre at lave så få fysiske størrelser som muligt, men så i det mindste en vis fordeling er f.eks. tre. Og alt andet kan nemt ændres på farten ved hjælp af færdige moduler. Det hele er meget nemt og tilgængeligt nu.
Og inkrementel asynkron backup er god.
Som vores praksis har vist, fungerer denne ordning godt med forsinket kopiering af ændrede filer.
Det sidste punkt er også indlysende. Hvis din infrastruktur ikke har sådanne problemer nu, men der er noget, der kan gå i stykker, går det helt sikkert i stykker, når det bliver lidt mere. Derfor er det bedre at tænke over dette på forhånd og ikke opleve problemer med det. Det var alt, jeg ville sige.
kontakter
»
»
Denne rapport er en udskrift af en af de bedste taler på konferencen for udviklere af højbelastningssystemer . Der er mindre end en måned tilbage til HighLoad++ 2017-konferencen.
Vi har den allerede klar , skemaet bliver nu aktivt dannet.
I år fortsætter vi med at udforske emnet arkitektur og skalering:
- / Igor Vasiliev
- / Dmitry Egorov
- / Anatoly Plaskovsky
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Philip Delgado
Vi bruger også nogle af disse materialer i vores onlinekursus om udvikling af højbelastningssystemer er en kæde af særligt udvalgte breve, artikler, materialer, videoer. Vores lærebog indeholder allerede mere end 30 unikke materialer. Forbinde!
Kilde: www.habr.com