Arkitektur för lagring och hantering av foton på Badoo

Artem Denisov ( bo0rsh201, Badoo)

Badoo är världens största dejtingsajt. För närvarande har vi registrerat cirka 330 miljoner användare över hela världen. Men vad som är mycket viktigare i sammanhanget av vår diskussion idag, är att vi lagrar omkring 3 petabyte användarfoton. Varje dag laddar våra användare upp cirka 3,5 miljoner nya foton, och belastningen för läsning är omkring 80 000 förfrågningar per sekund. Det är ganska mycket för vår backend, och ibland uppstår det problem med det.

Jag kommer att berätta om designen av detta system som lagrar och levererar foton i stort, och jag kommer att ge en utvecklares perspektiv på det. En kort retrospektiv om hur det har utvecklats, jag kommer att markera de viktigaste milstolparna, men jag kommer att prata mer detaljerat om de lösningar vi använder nu.

Och nu låt oss börja.

Som jag redan nämnt, detta kommer att vara en retrospektiv, och för att börja någonstans, låt oss ta det mest banala exemplet.

Vi har en allmän uppgift, vi behöver ta emot, lagra och leverera användarfoton. I denna form är uppgiften allmän, vi kan använda vad som helst:

• modern molnlagring,
• färdiga lösningar, som det också finns många av;
• vi kan sätta upp flera maskiner i vårt datacenter och installera stora hårddiskar där för att lagra foton.

Badoo har historiskt sett — och nu, liksom då (på den tid när detta just hade börjat) — levt på egna servrar, inom våra egna datacenter. Så för oss var detta alternativ optimalt.

Vi tog helt enkelt några maskiner, kallade dem "photos", och vi skapade en kluster som lagrar foton. Men det verkar som om något saknas. För att allt detta ska fungera, behöver vi på något sätt avgöra vilken maskin som ska lagra vilka foton. Och här behöver vi inte uppfinna hjulet på nytt.

Vi lägger till ett fält i vårt lagringssystem med information om användarna. Det kommer att vara nyckeln för sharding. I vårt fall kallade vi det place_id, och den här id:n för platser indikerar platsen där användarfotona lagras. Vi skapar kartor.

I det första steget kan detta till och med göras manuellt — vi säger att en användares foto med en viss plats kommer att lagras på en viss server. Tack vare denna karta vet vi alltid när användaren laddar upp en bild, var den ska sparas och vet varifrån den ska levereras.

Detta är en helt trivial skiss, men den har tillräckligt många viktiga fördelar. För det första är den enkel, som jag redan nämnt, och för det andra kan vi med en sådan metod enkelt skala horisontellt genom att helt enkelt leverera nya enheter och lägga till dem i kartan. Inget mer behöver göras.

Så var det under en tid för oss.

Det var någon gång runt 2009. Vi levererade enheter, vi levererade ...

Och vid en viss tidpunkt började vi märka att denna plan hade vissa nackdelar. Vilka nackdelar?

Först och främst är det den begränsade kapaciteten. Vi kan inte stoppa så många hårddiskar i en fysisk server som vi skulle vilja. Och med tiden och tillväxten av datasetet blev det ett visst problem.

Och för det andra. Det är en atypisk konfiguration av enheter, eftersom sådana enheter är svåra att återanvända i andra kluster, de är ganska specifika, det vill säga de bör ha låg prestanda, men samtidigt ha stora hårddiskar.

Detta var allt år 2009, men i princip är dessa krav fortfarande aktuella idag. Vi har en tillbakablick, så år 2009 var allt verkligen dåligt på detta område.

Och den sista punkten är priset.

Priset då var väldigt högt och vi behövde leta efter alternativ. Det vill säga, vi behövde på något sätt bättre utnyttja både utrymmet i datacenter och de fysiska servrar som allt detta lagras på. Och våra systemingenjörer inledde en omfattande studie där de gick igenom en mängd olika alternativ. De tittade även på klusterfilsystem som PolyCeph och Lustre. Där fanns det prestandaproblem och ganska komplicerad drift. De avstod. De försökte montera hela datasetet via NFS på varje enhet för att på så vis öka skalningen. Läsningen gick dåligt, de prövade olika lösningar från olika leverantörer.

Och till slut kom vi fram till att vi började använda det så kallade Storage Area Network.

Det här är stora SHD-enheter som är avsedda för lagring av stora datamängder. De är hyllor med diskar som monteras på de slutgiltiga utdelningsmaskinerna via fiberoptik. Så vi har en pool av maskiner, som är ganska liten, och dessa SHD-enheter, som är transparenta för vår utdelningslogik, det vill säga för vår nginx eller någon annan, hanterar förfrågningarna för dessa foton.

Den här lösningen hade uppenbara fördelar. Det är en SHD-enhet. Den är inriktad på att lagra foton. Det blir billigare än om vi bara sätter upp maskiner med hårddiskar.

Den andra fördelen.

Det är att kapaciteten har blivit betydligt större, det vill säga att vi kan lagra mycket mer lagring på mycket mindre utrymme.

Men det fanns också nackdelar som snabbt blev uppenbara. Med ökning av antalet användare och belastningen på systemet började prestandaproblem dyka upp. Problemet är ganska uppenbart — vilken SHD-enhet som helst, som är avsedd för att lagra många foton på liten yta, lider vanligtvis av intensiv läsning. Det är faktiskt aktuellt för all form av molnlagring, och vad som helst. Det finns för närvarande ingen perfekt lagring som är oändligt skalbar, där man kan stoppa in vad som helst, och som hanterar läsning mycket väl, särskilt slumpmässig läsning.

Som i fallet med våra foton, eftersom foton efterfrågas oregelbundet, och det påverkar deras prestanda avsevärt.

Även med dagens siffror, om vi har över 500 RPS för foton på den maskin som är ansluten till lagringen, börjar problemen redan dyka upp. Och det var ganska dåligt för oss eftersom antalet användare ökar, och allt måste bara bli sämre. Vi behöver optimera detta på något sätt.

För att optimera beslutade vi då att tydligt titta på belastningsprofilen — vad händer egentligen, vad behöver optimeras.

Och här spelar allt till vår fördel.

Jag nämnde redan i den första sliden: vi har 80 000 läsförfrågningar per sekund vid endast 3,5 miljoner uppladdningar per dag. Det vill säga, det är en skillnad på tre ordningar. Uppenbart är att vi måste optimera läsningen och det är ganska klart hur.

Det finns ett litet moment till. Specifika tjänsten fungerar så att en person registrerar sig, laddar upp ett foto, börjar aktivt titta på andra människor, gilla dem, och de visas aktivt för andra. Sedan hittar han eller hon en partner eller inte, det är som det är, och slutar använda tjänsten ett tag. I det ögonblicket, när han eller hon använder det, är deras foton mycket heta - de efterfrågas, de ses av många. Så fort de slutar göra det, faller de ganska snabbt ut från de intensiva visningarna för andra, som tidigare, och deras foton efterfrågas nästan inte.

Det vill säga, vi har en mycket liten het dataset. Men det finns ändå väldigt många förfrågningar. En uppenbar lösning här är att lägga till cache.

Cache med LRU kommer att lösa alla våra problem. Vad gör vi?

Vi lägger till en relativt liten komponent framför vår stora lagringskluster, som vi kallar fotocache (photoscache). Detta är i grunden bara en cacheproxy.

Hur fungerar det inuti? Här är vår användare, här är lagringen. Allt som tidigare. Vad lägger vi till mellan dem?

Detta är bara en maskin med en snabb fysisk lokal disk. Det kan vara med SSD, till exempel. Och på denna disk lagras en lokal cache.

Hur ser detta ut? Användaren skickar en förfrågan om ett foto. NGINX letar efter det först i den lokala cachen. Om det inte finns där, gör den helt enkelt proxy_pass till vår lagring, laddar ner bilden därifrån och ger den till användaren.

Men det är väldigt banalt och oklart vad som händer inuti. Det fungerar ungefär så här.

Cache är logiskt uppdelad i tre lager. När jag säger 'tre lager', betyder det inte att det finns något komplicerat system. Nej, det är i princip bara tre kataloger i filsystemet:

1. Detta är en buffert där foton som just har laddats upp från proxy hamnar.
2. Detta är en het cache som lagrar foton som just nu aktivt efterfrågas.
3. Och en kall cache där foton gradvis trycks ut från den heta cachen när de får färre förfrågningar.

För att detta ska fungera måste vi på något sätt hantera denna cache, vi måste flytta foton i den osv. Detta är också en mycket primitiv process.

Nginx skriver helt enkelt till RAMDisken access.log för varje förfrågan, där den anger sökvägen till fotot som den just nu serverar (en relativ sökväg, förstås), samt vilken sektion det serverades från. Det kan stå "foto 1" och sedan antingen bufferten, den heta cachen, den kalla cachen eller proxy.

Baserat på detta måste vi på något sätt fatta ett beslut om vad vi ska göra med fotot.

Vi har en liten demon som körs på varje maskin, som ständigt läser denna logg och lagrar statistik om användningen av olika foton i sitt minne.

Den samlar helt enkelt där, håller räkning och gör regelbundet följande. Aktivt begärda foton, som får många förfrågningar, flyttar den till den heta cachen, oavsett var de ligger.

Foton som begärs sällan och har blivit ännu mer sällan begärda, trycker den gradvis ut från den heta cachen till den kalla.

Och när vi får slut på plats i cacharna börjar vi helt enkelt ta bort från den kalla cachen utan att göra några urval. Och detta fungerar för övrigt riktigt bra.

För att fotot ska sparas direkt vid proxying i bufferten använder vi direktivet proxy_store och bufferten — det är också RAMDisk, alltså fungerar det väldigt snabbt för användaren. Det här gäller den interna funktionen hos själva cache-servern.

Frågan kvarstår om hur man ska fördela förfrågningarna mellan dessa servrar.

Anta att det finns en kluster av tjugo lagringsmaskiner och tre cache-servrar (så blev det).

Vi behöver på något sätt definiera vilka förfrågningar som gäller vilka foton och var de ska landa.

Det mest grundläggande alternativet är Round Robin. Eller ska vi göra det slumpmässigt?

Det har uppenbarligen sina nackdelar, eftersom vi i en sådan situation kommer att använda cachen på ett mycket ineffektivt sätt. Förfrågningarna kommer att landa på olika slumpmässiga maskiner: här har den cachats, på grannservern finns den inte längre. Och allt kommer att fungera, om det ens gör det, väldigt dåligt. Även med ett litet antal maskiner i klustret.

Vi behöver på något sätt entydigt bestämma på vilken server varje förfrågan ska landa.

Det finns ett enkelt sätt. Vi tar hash från URL:en eller hash från vår shardnyckel, som finns i URL:en, och delar den helt på antalet servrar. Kommer det att fungera? Ja.

Alltså, vi har en hundraprocentig begäran, till exempel för en "example_url" kommer alltid att hamna på server med index "2", och cachen kommer att utnyttjas så bra som möjligt.

Men det uppstår ett problem med resurshantering i ett sådant schema. Resurshantering — jag menar förändring av antalet servrar.

Anta att vår cachekluster har slutat klara av belastningen, och vi har beslutat att lägga till en ytterligare maskin.

Vi lägger till.

Nu delar vi inte längre upp det i tre, utan i fyra. Således lever praktiskt taget alla nycklar som vi tidigare hade, praktiskt taget alla URL:er nu på andra servrar. Hela cachen har invalidiserats åtskilliga gånger. Alla begärningar strömmade till vårt klusterlagring, det mådde dåligt, misslyckade tjänster och missnöjda användare. Det vill vi inte ha.

Det alternativet passar oss inte heller.

Vad ska vi då göra? Vi måste på något sätt effektivt använda cachen, ständigt dirigera en begäran till samma server, men samtidigt vara motståndskraftiga mot resurshantering. Och det finns en sådan lösning, den är inte direkt komplicerad. Den kallas för konsekvent hashning.

Hur ser det ut?

Vi tar en funktion från shardnyckeln och sprider ut alla dess värden på en cirkel. Det vill säga, vid punkt 0 möts dess minimala och maximala värden. Vidare placerar vi alla våra servrar på samma cirkel på ungefär detta sätt:

Varje server definieras av en punkt, och sektorn som går till den medurs, betjänas av denna värd. När begärningar kommer in ser vi genast att till exempel begäran A — har en sådan hash — och den betjänas av server 2. Begäran B — av server 3. Och så vidare.

Vad händer i denna situation vid resurshantering?

Vi invalidiserar inte hela cachen, som förut, och flyttar inte alla nycklar, utan vi flyttar varje sektor en liten bit så att den lediga platsen, så att säga, kan rymma vår sjätte server som vi vill lägga till och lägger till den där.

Självklart, i en sådan situation kan nycklarna också strula. Men de fungerar mycket bättre än tidigare. Vi ser att våra två första nycklar har stannat kvar på sina servrar, och endast den cache-server som förändrats rör den senaste nyckeln. Det fungerar tillräckligt effektivt, och om du lägger till nya värdar gradvis, finns det inget stort problem. Du lägger till lite i taget, väntar tills cachen fylls på igen, och allt fungerar bra.

Den enda frågan som kvarstår vid fel är vad som händer om någon maskin går sönder.

Och vi skulle inte gärna vilja behöva regenerera den här kartan, ogiltigförklara en del av cachen och så vidare, om en maskin exempelvis skulle starta om och vi måste hantera förfrågningar. Vi har bara en reservfotovärd på varje plats som fungerar som en ersättning för vilken maskin som helst som just nu är ur funktion. Och om plötsligt någon server blir otillgänglig, går trafiken dit. Vi har, naturligtvis, ingen cache där, dvs. den är kall, men åtminstone hanteras användarnas förfrågningar. Om detta är en kort tidsperiod klarar vi det helt enkelt. Det blir bara mer belastning på lagringen. Om det är en längre period kan vi fatta beslut — att ta bort den servern från kartan eller inte, eller kanske ersätta den med en annan.

Detta gäller cachesystemet. Låt oss titta på resultaten.

Det verkar som om det inte finns något komplicerat här. Men den här metoden för att hantera cachen har gett oss en träffsäkerhet på cirka 98%. Det betyder att av de 80 000 förfrågningarna per sekund når endast 1 600 lagringarna, och det är helt normal belastning, de klarar det lugnt, vi har alltid en buffert.

Vi har placerat dessa servrar i tre av våra datacenter och har fått tre närvaropunkter — Prag, Miami och Hongkong.

Därmed är de mer eller mindre lokaliserade till var och en av våra målmarknader.

Och som en trevlig bonus fick vi den här caching-proxy, där CPU:n faktiskt är relativt inaktiv, eftersom den inte behövs i så stor utsträckning för att leverera innehållet. Och där har vi med hjälp av NGINX + Lua implementerat mycket användbar logik.

Till exempel kan vi experimentera med webp eller progressive jpeg (detta är moderna, effektiva format), se hur det påverkar trafiken, fatta vissa beslut, aktivera för vissa länder osv.; göra dynamisk storleksändring eller beskärning av bilder i realtid.

Det här är ett bra användningsfall, när du, till exempel, har en mobilapp som visar bilder, och mobilappen inte vill använda klientens CPU för att begära en stor bild och sedan ändra dess storlek till en viss storlek för att passa i vyn. Vi kan helt enkelt dynamiskt ange vissa parametrar i URL:en i UPort, och bildcachet kommer automatiskt att ändra storlek på bilden. Vanligtvis kommer det att välja den storlek som vi fysiskt har på disken, så nära den begärda storleken som möjligt, och downsizza den till de specifika koordinaterna.

Förresten har vi publicerat videoinspelningar från de senaste fem åren av konferenser för utvecklare av högbelastade system. HighLoad++. Titta, lär er, dela och prenumerera på YouTube-kanalen..

Vi kan också lägga till mycket produktlogik där. Till exempel kan vi baserat på URL-parametrarna lägga till olika vattenstämplar, vi kan sudda bilder, oskarpa eller pixla dem. Detta är när vi vill visa en bild av en person men inte vill visa deras ansikte, vilket fungerar bra; allt detta är implementerat här.

Vad har vi fått? Vi har fått tre punkter för närvaro, en bra hitrate, och samtidigt står inte CPU:n stilla på dessa maskiner. Den har nu blivit viktigare än tidigare. Vi behöver installera kraftfullare maskiner, men det är värt det.

Detta handlar om bildutbyte. Här är allt ganska klart och uppenbart. Jag tror att jag inte har avslöjat något nytt - så här fungerar praktiskt taget alla CDN.

Och det är troligt att den kräsna lyssnaren kan ha undrat: varför inte bara ta och byta allt till CDN? Det skulle vara ungefär samma sak, alla moderna CDN kan göra detta. Och här är flera orsaker.

Första — det handlar om bilder.

Detta är en av de nyckelpunkter i vår infrastruktur, och vi behöver så mycket kontroll som möjligt över dem. Om det är en lösning från en extern leverantör, och du har ingen makt över det, kommer det att bli ganska svårt att leva med detta när du har en stor datamängd och en mycket hög användarförfrågningsström.

Låt mig ge ett exempel. Just nu kan vi på vår infrastruktur, till exempel om det uppstår några problem eller underjordiska knackningar, gå in på maskinen och debugga där, så att säga. Vi kan lägga till insamling av vissa mätvärden som endast vi behöver, vi kan experimentera och se hur det påverkar graferna och så vidare. Just nu samlas det in mycket statistik om denna cache-kluster. Och vi tittar periodiskt på den och undersöker länge vissa anomalier. Om det hade varit på CDN-sidan skulle det ha varit mycket svårare att kontrollera. Eller till exempel, om en olycka inträffar, vet vi vad som har hänt, vi vet hur vi ska leva med det och hur vi ska övervinna det. Det är den första slutsatsen.

Den andra slutsatsen är också snarare historisk eftersom systemet har utvecklats länge, och det har funnits många olika affärskrav vid olika tidpunkter, och de passar sällan in i konceptet för CDN.

Och punkten som följer av den föregående –

Det är att vi har mycket specifik logik i våra foto-cachar som inte alltid kan läggas till på begäran. Det är osannolikt att något CDN kommer att lägga till några anpassade funktioner på din begäran. Till exempel, kryptering av URL:er, om du inte vill att kunden ska kunna ändra något. Vill du byta URL på servern och kryptera den, och sedan överlämna vissa dynamiska parametrar här.

Vilken slutsats dras? I vårt fall är CDN inte en särskilt bra alternativ.

Men i ert fall, om ni har några specifika affärskrav, kan ni själva enkelt genomföra det jag har visat er. Och när det gäller en liknande belastningsprofil kommer det att fungera utmärkt.

Men om ni har en allmän lösning, och uppgiften inte är särskilt specifik, kan ni lugnt använda CDN. Eller om tiden och resurserna är mycket viktigare för er än kontroll.

Och moderna CDN har praktiskt taget allt det jag just har berättat om. Med undantag för vissa funktioner.

Detta gäller fotoleveransen.

Låt oss nu gå framåt i vår retrospektiv och prata om lagring.

År 2013.

Cache-servrar har lagts till, prestandaproblem har försvunnit. Allt är bra. Datasetet växer. År 2013 hade vi omkring 80 servrar som var kopplade till lagringssystem och cirka 40 cache-servrar i varje datacenter. Det handlar om 560 terabyte data per datacenter, alltså nästan ett petabyte totalt.

Med tillväxten av datasetet ökade driftskostnaderna kraftigt. Hur manifesterade detta sig?

I den här diagrammet, som visar SAN-systemet med anslutna maskiner och cacher, finns det många felpunkter. Vi har hanterat problem med cache-servrar tidigare, där är allt mer eller mindre förutsägbart och klart, men på lagringssidan var det mycket värre.

För det första, själva Storage Area Network (SAN) kan misslyckas.

För det andra är den ansluten via fiber till slutmaskinerna. Det kan uppstå problem med fiberkorten och switcharna.

Det finns naturligtvis inte så många felpunkter som med själva SAN:et, men det är ändå potentiella felpunkter.

Sedan är det själva maskinen som är kopplad till lagringssystemet. Den kan också gå sönder.

Så vi har totalt tre felpunkter.

Förutom felpunkterna är det också en tung underhållsbelastning av lagringssystemen.

Det är en komplex multikomponentsystem, och systemingenjörer kan ha det svårt med det.

Och den sista, mest viktiga punkten. Om något av dessa tre punkter misslyckas, finns det en icke-noll sannolikhet att förlora användardata, eftersom filsystemet kan skadas.

Anta att vårt filsystem har skadats. Återställningen tar, för det första, lång tid - det kan ta en vecka vid stora datamängder. För det andra kommer vi troligen att få en massa oklara filer, som på något sätt måste matchas med användarnas bilder. Och vi riskerar att förlora data. Risken är ganska hög. Ju oftare sådana situationer inträffar och ju fler problem som uppstår i hela denna kedja, desto högre blir denna risk.

Vi måste göra något åt det. Och vi beslutade att helt enkelt säkerhetskopiera data. Det är faktiskt en uppenbar och bra lösning. Vad gjorde vi?

Så här såg vår server ut som var ansluten till lagringssystemet tidigare. Det är en huvudpartition, det är helt enkelt en blocenhet som i praktiken representerar en montering på ett avlägset lagringssystem via fiber.

Vi lade helt enkelt till en andra partition.

Vi installerade en andra lagring bredvid (lyckligtvis är det inte så dyrt), och kallade den för backup-partition. Den är också ansluten via fiber, samma maskin. Men vi behöver på något sätt synkronisera data mellan dem.

Här gör vi bara en asynkron kö bredvid.

Den är inte så belastad. Vi vet att vi har få poster. Kön är bara en tabell i MySQL där rader skrivs in som "behöver säkerhetskopiera den här bilden". Vid vilket ändring eller vid uppladdning kopierar vi från huvudpartitionen till backup med asynkron eller helt enkelt en bakgrundsprocess.

Så på detta sätt har vi alltid två konsekventa partitioner. Även om en del av systemet går ner kan vi alltid byta huvudsidan med backup, och allt fortsätter att fungera.

Men på grund av detta ökar belastningen på läsning kraftigt, eftersom förutom kunder som läser från huvudpartitionen, eftersom de först ser bilden där (den är ju nyare där), och sedan letar på backup om de inte hittade den (men det gör NGINX), så läser även vårt backupsystem nu från huvudpartitionen. Det var inte riktigt en flaskhals, men vi ville inte öka belastningen, i stort sett, helt i onödan.

Och vi lade till en tredje disk, som är en liten SSD, och kallade den för buffert.

Så här fungerar det nu.

Användaren laddar upp en bild till bufferten, sedan skickas en händelse till kön om att den bör kopieras till de två partitionerna. Den kopieras, och bilden lever ett tag (låt oss säga en dag) i bufferten, och först efter det rensas den. Det förbättrar användarupplevelsen avsevärt, eftersom användaren laddar upp en bild, och som regel börjar förfrågningar omedelbart komma in, eller att användaren uppdaterar sidan, gör en refresh. Men allt beror på applikationen som gör uppladdningen.

Eller, till exempel, andra personer som börjar se bilden skickar omedelbart förfrågningar för den. Den finns ännu inte i cachen, den första förfrågan går väldigt snabbt. I princip är det samma som med bildcachen. Den långsamma lagringen deltar överhuvudtaget inte i detta. Och när den rensats efter en dag är den antingen cachad på vårt cachelager, eller så är den antagligen ingen längre behövlig. Det vill säga att användarupplevelsen här har förbättrats kraftigt tack vare sådana enkla manipulationer.

Och viktigast av allt: vi har slutat förlora data.

Vi kan säga att vi har slutat potentiellt att förlora data, eftersom vi faktiskt inte förlorade dem. Men risken fanns. Vi ser att en sådan lösning så klart är bra, men den liknar något av en symtomlindring av problemet, snarare än att lösa det helt. Och vissa problem kvarstår här.

För det första, det är en felpunkt i form av den fysiska värd som all denna maskinvara körs på, den har inte försvunnit.

För det andra, det kvarstår problem med SAN, dess tunga underhåll etc. Det var inte direkt en kritisk faktor, men vi ville pröva att leva utan det på något sätt.

Och vi gjorde tredje versionen (i praktiken är det egentligen den andra) — en version för redundans. Hur såg det ut?

Det var som följande —

De största problemen vi har är med det fysiska värden.

För det första tar vi bort SAN, eftersom vi vill experimentera, vi vill försöka med lokala hårddiskar.

Detta är redan år 2014-2015, och vid den tidpunkten hade situationen med hårddiskar och deras lagringskapacitet på en värd blivit mycket bättre. Vi beslutade, varför inte prova.

Och därefter tar vi helt enkelt vår backup-partition och flyttar den fysiskt till en separat maskin.

Således får vi en sådan schema. Vi har två maskiner som lagrar identiska dataset. De backar helt upp varandra och synkroniserar data över nätverket via en asynkron kö i samma MySQL.

Varför detta fungerar bra — eftersom vi har få skrivningar. Dvs. om skrivningen var jämförbar med läsningen, kanske vi skulle få någon nätverksöverbelastning och problem. Få skrivningar, mycket läsningar — denna metod fungerar bra, dvs. vi kopierar relativt sällan bilder mellan dessa två servrar.

Hur detta fungerar, om man tittar lite mer detaljerat.

Upload. Lastbalanseraren väljer helt enkelt slumpmässiga värdar med ett par och gör upload till dem. Under tiden gör den självklart hälsokontroller, ser till att maskinen inte har fallit ut. Dvs. den laddar upp bilder bara till en levande server, och sedan kopieras allt det genom en asynkron kö till dess granne. Med upload är det extremt enkelt.

Uppgiften är något mer komplex.

Här hjälpte Lua oss, eftersom det är ganska svårt att skapa en sådan logik med vanilla NGINX. Först gör vi en begäran till den första servern, kollar om bilden finns där, eftersom den potentiellt kan ha laddats upp till en granne och ännu inte nått hit. Om bilden finns där är det bra. Vi ger den genast till kunden och kanske cachar den.

Om den inte finns, gör vi helt enkelt en begäran till grannen och får den garanterat därifrån.

Således kan vi återigen säga: det kan uppstå problem med prestanda, eftersom ständiga round trips — bilden som laddades upp, här finns den inte, vi gör två förfrågningar istället för en, detta bör fungera långsamt.

I vår situation fungerar det inte långsamt.

Vi samlar massor av mätningar på detta system, och den hypotetiska träfffrekvensen för denna mekanism ligger på ungefär 95%. Det vill säga, lagget på denna backup är litet, och tack vare detta får vi praktiskt taget garanterat, efter att en bild har laddats upp, den redan vid första försöket och går aldrig dit två gånger.

Så på så sätt, vad har vi också fått, och vad är verkligen coolt?

Tidigare hade vi en huvudbackup-sektion och läste sekventiellt från dem. Det vill säga, vi sökte alltid först på huvudservern och sedan på backupen. Det var ett steg.

Nu utnyttjar vi läsning från två maskiner samtidigt. Vi fördelar begärningarna med Round Robin. I en liten procentandel av fallen gör vi två förfrågningar. Men nu har vi helt enkelt dubbelt så mycket kapacitet för läsning som vi hade tidigare. Och belastningen har verkligen minskat både på avlämningsmaskinerna och på lagringssystemen, som också fanns vid den tidpunkten.

När det gäller hög tillgänglighet. I grund och botten var det detta vi kämpade mest för. Hög tillgänglighet här har fungerat fantastiskt.

En maskin går ner.

Inga problem! Systemingenjören kan till och med sova vidare på natten, vänta till morgonen, ingenting hemskt kommer att hända.

Om även kön går ner när denna maskin faller ut, inga problem, loggen kommer först att samlas på den levande maskinen, och sedan försöka igen till kön, och därefter till den maskin som kommer att återställas efter en tid.

Samma sak med underhåll. Vi stänger helt enkelt av en av maskinerna, plockar manuellt bort den från alla pooler, trafiken upphör, vi gör något underhåll, fixar lite där, och efter det sätter vi tillbaka den i drift, och den här backupen hinner ifatt ganska snabbt. D.v.s. en nedtid på en maskin hinner ifatt inom några minuter på ett dygn. Det är verkligen väldigt lite. Med hög tillgänglighet, som jag sagt tidigare, är allt riktigt bra här.

Vilka slutsatser kan vi dra från det här schemat med redundans?

Vi har uppnått hög tillgänglighet.

Enkel drift. Eftersom maskinerna har lokala hårddiskar är det mycket mer bekvämt ur ett driftsperspektiv för ingenjörerna som arbetar med detta.

Vi har fått dubbel marginal för läsning.

Detta är en mycket bra bonus på pluskontot för hög tillgänglighet.

Men det finns också problem. Nu har vi en betydligt mer komplex utveckling av funktioner kopplade till detta, eftersom systemet nu är 100% eventual consistent.

Vi måste, säg, tänka ständigt i något background job: "Vilken server kör vi just nu?", "Finns det verkligen en aktuell bild här?" o.s.v. Detta är naturligtvis allt inpackat i wrappers, och för programmeraren som skriver affärslogik är detta transparent. Men ändå har ett stort komplext lager tillkommit. Men vi är beredda att acceptera detta i utbyte mot de fördelar vi fått.

Och här uppstår återigen en viss konflikt.

Jag sa tidigare att det var dåligt att lagra allt på lokala hårddiskar. Nu säger jag att vi gillar det.

Ja, faktiskt, över tid har situationen förändrats avsevärt, och nu har denna metod många fördelar. För det första får vi en mycket mer enkel drift.

För det andra är det mer effektivt, eftersom vi inte har dessa automatiska kontroller, kopplingar till lagringssystem.

Det finns en enorm maskinpark där, men här handlar det bara om några hårddiskar som är samlade i RAID lokalt i maskinen.

Men det finns också nackdelar.

Det är ungefär 1,5 gånger dyrare än att använda SAN, även enligt dagens priser. Därför valde vi att inte så rått konvertera hela vår stora kluster till maskiner med lokala hårddiskar, utan istället behålla en hybridlösning.

Hälften av våra maskiner arbetar med hårddiskar (nåja, inte riktigt hälften – kanske 30 procent). Den resterande delen är gamla maskiner där den första backup-lösningen tidigare var installerad. Vi omkonfigurerade dem, eftersom vi varken behöver några nya data eller något annat, vi flyttade helt enkelt mounts från en fysisk värd till två.

Och vi fick en stor kapacitet för läsning, och vi gjorde en uppgradering. Tidigare monterade vi en lagring på en maskin, nu monterar vi till exempel fyra på ett par. Och det fungerar bra.

Låt oss sammanfatta kort vad vi har uppnått, vad vi har kämpat för, och hur det har gått.

Sammanfattning

Vi har användare – helt 33 miljoner.

Vi har tre närvaro punkter – Prag, Miami, Hongkong.

Där finns ett cache-lager, bestående av maskiner med snabba lokala diskar (SSD), där en enkel lösning med NGINX körs, dess access.log och Python-daemoner som hanterar och administrerar cache.

Om du önskar kan du i ditt projekt, om dina bilder inte är lika kritiska som de är för oss, eller om trade-off mellan kontroll och utvecklingshastighet kostnader lutar åt det andra hållet för dig, då kan du enkelt byta ut det mot en CDN, moderna CDN klarar detta bra.

Därefter kommer lagringsskiktet, där vi har kluster av par av maskiner som säkerhetskopierar varandra, asynkront kopieras filer från en till en annan vid varje ändring.

Några av dessa maskiner arbetar med lokala hårddiskar.

En del av dessa maskiner är anslutna till SAN.

Å ena sidan är det mer praktiskt att använda och något mer effektivt, å andra sidan är det bekvämt ur tätbyråns och kostnaden per gigabyte.

Detta är en kort översikt av arkitekturen som vi har fått och hur allt har utvecklats.

Här är några ytterligare tips från chefen, väldigt enkla.

För det första, om du plötsligt bestämmer dig för att du brådskande behöver förbättra alla fotoinfrastrukturer, mät först, för kanske behövs det inga förbättringar.

Låt mig ge ett exempel. Vi har ett kluster av maskiner som levererar bilder från bifogningar i chattar, och där fungerar fortfarande en lösning från 2009, och ingen lider av detta. Alla är nöjda, alla gillar det.

För att mäta, börja med att sätta upp en mängd metrik, titta på dem och avgör sedan vad du är missnöjd med och vad som behöver förbättras. För att kunna mäta detta har vi ett häftigt verktyg som heter Pinba.

Det gör att du kan samla in detaljerad statistik från NGINX för varje begäran, inklusive svarskoder och tidsfördelningar — allt du kan tänka dig. Det finns bindningar till olika analytiska system, och du kan sedan se allt detta på ett snyggt sätt.

Mät först — förbättra sedan.

Vidare. Vi optimerar läsningen med cache och skrivningen med sharding, men det är en uppenbar punkt.

Vidare. Om du just nu börjar bygga ditt system, så är det mycket bättre att göra foton som oföränderliga filer. Eftersom du genast slipper en hel klass av problem med cache-invalidering och hur logiken ska hitta rätt version av bilden, och så vidare.

Anta att du laddat upp en hundra, sedan har du roterat den, se till att det blir en fysiskt annan fil. Det vill säga, tänk inte: nu sparar jag lite plats genom att spela in i samma fil och ändra versionen. Det fungerar alltid dåligt, och det blir mycket huvudvärk senare.

Nästa punkt. Om resizing i realtid.

Tidigare, när användare laddade upp en bild, skar vi omedelbart upp ett stort antal storlekar för alla tänkbara situationer, för olika kunder, och de låg alla på disken. Nu har vi övergivit detta.

Vi har behållit endast tre grundläggande storlekar: liten, medium och stor. Allt annat downsizas från den storlek som efterfrågades i Uport, vi gör helt enkelt downsizing och ger det till användaren.

CPU:n i cache-lagret blir mycket billigare än om vi ständigt skulle regenerera dessa storlekar på varje lagring. Anta att vi vill lägga till en ny, det tar en månad — att köra ett skript överallt som skulle göra detta noggrant utan att krascha klustret. Så om det finns möjlighet att välja nu, är det bättre att göra så få fysiska storlekar som möjligt, men ändå ha någon form av fördelning, säg tre. Och allt annat kan bara resizingas i realtid med hjälp av färdiga moduler. Det är nu väldigt enkelt och tillgängligt.

Och en inkrementell asynkron backup är bra.

Som vår erfarenhet har visat fungerar en sådan schema bra med att skjuta upp kopiering av ändrade filer.

Den sista punkten är också uppenbar. Om det inte finns några sådana problem i din infrastruktur nu, men det finns något som kan gå sönder, så kommer det garanterat att gå sönder när belastningen ökar lite. Därför är det bäst att tänka på detta i förväg och slippa problem. Det var allt från min sida.

Kontakter

» bo0rsh201
» Baddoos företagsblogg

Denna rapport är en transkription av en av de bästa presentationerna på konferensen för utvecklare av högbelastade system HighLoad++. Det är mindre än en månad kvar till konferensen HighLoad++ 2017.

Vi har redan förberett Konferensprogrammet, och schemat håller just nu på att färdigställas.

I år fortsätter vi att utforska ämnet arkitekturer och skalning:

• Hur man betjänar en miljard användare och levererar terabittrafik / Игорь Васильев
• Hur man skriver om databasen för direktmeddelanden i VKontakte från grunden och migrerar till den utan nedtid / Дмитрий Егоров
• Döden av en utförsäljning: hur Yandex.Money försökte öka hastigheten inför Black Friday och klara sig / Анатолий Пласковский
• Felaktig hantering av den frontala systemarkitekturen för banken / Роман Шеховцов, Алексей Громатчиков
• Arkitekturen för betalningssystemet: nästan enterprise / Филипп Дельгядо

Även några av dessa material används av oss i vår utbildningskurs online om utveckling av högbelastade system HighLoad.Guide är en kedja av noggrant utvalda brev, artiklar, material och videor. Redan nu finns det mer än 30 unika material i vår lärobok. Anslut er!

Källa: habr.com