Artem Denisov ( , )
Badoo Àr vÀrldens största dejtingsajt. Vi har för nÀrvarande cirka 330 miljoner registrerade anvÀndare över hela vÀrlden. Men vad som Àr mycket viktigare i samband med vÄrt samtal idag Àr att vi lagrar cirka 3 petabyte anvÀndarbilder. Varje dag laddar vÄra anvÀndare upp cirka 3,5 miljoner nya foton, och lÀsmÀngden Àr ungefÀr 80 tusen förfrÄgningar per sekund. Detta Àr ganska mycket för vÄr backend, och ibland finns det svÄrigheter med detta.
Jag kommer att prata om designen av detta system, som lagrar och skickar bilder i allmÀnhet, och jag kommer att titta pÄ det frÄn en utvecklares synvinkel. Det kommer att finnas en kort tillbakablick pÄ hur det utvecklades, dÀr jag kommer att beskriva de viktigaste milstolparna, men jag kommer bara att prata mer i detalj om de lösningar som vi anvÀnder för nÀrvarande.
Nu börjar vi.
Det hÀr blir som sagt en retrospektiv, och för att börja nÄgonstans ska vi ta det vanligaste exemplet.
Vi har en gemensam uppgift, vi behöver ta emot, lagra och skicka anvÀndarbilder. I det hÀr formulÀret Àr uppgiften generell, vi kan anvÀnda vad som helst:
- modern molnlagring,
- en boxad lösning, som det ocksÄ finns en hel del av nu;
- Vi kan sÀtta upp flera maskiner i vÄrt datacenter och sÀtta stora hÄrddiskar pÄ dem och lagra bilder dÀr.
Badoo lever historiskt - bÄde nu och dÄ (vid den tid dÄ det bara var i sin linda) - pÄ sina egna servrar, inne i vÄra egna DC. DÀrför var detta alternativ optimalt för oss.
Vi tog bara flera maskiner, kallade dem "foton", och vi fick ett kluster som lagrar foton. Men det verkar som om nÄgot saknas. För att allt detta ska fungera mÄste vi pÄ nÄgot sÀtt bestÀmma pÄ vilken maskin vi kommer att lagra vilka foton. Och hÀr finns det inget behov av att öppna Amerika.
Vi lÀgger till ett fÀlt i vÄrt lager med information om anvÀndare. Detta kommer att vara skÀrningsnyckeln. I vÄrt fall kallade vi det place_id, och detta plats-id pekar pÄ platsen dÀr anvÀndarfoton lagras. Vi gör kartor.
I det första skedet kan detta till och med göras manuellt - vi sÀger att ett foto av denna anvÀndare med en sÄdan plats kommer att landa pÄ en sÄdan server. Tack vare den hÀr kartan vet vi alltid nÀr en anvÀndare laddar upp ett foto, var det ska sparas och vi vet var vi ska ge det ifrÄn.
Detta Àr ett absolut trivialt schema, men det har ganska betydande fördelar. Det första Àr att det Àr enkelt, som sagt, och det andra Àr att vi med detta tillvÀgagÄngssÀtt enkelt kan skala horisontellt genom att helt enkelt leverera nya bilar och lÀgga till dem pÄ kartan. Du behöver inte göra nÄgot annat.
SÄ var det för oss ett tag.
Detta var runt 2009. De levererade bilar, levererade...
Och nÄgon gÄng började vi mÀrka att detta system har vissa nackdelar. Vilka Àr nackdelarna?
För det första Àr det begrÀnsad kapacitet. Vi kan inte klÀmma in sÄ mÄnga hÄrddiskar pÄ en fysisk server som vi skulle vilja. Och detta har blivit ett visst problem med tiden och med tillvÀxten av datamÀngden.
Och för det andra. Detta Àr en atypisk konfiguration av maskiner, eftersom sÄdana maskiner Àr svÄra att ÄteranvÀnda i vissa andra kluster; de Àr ganska specifika, d.v.s. de ska vara svaga i prestanda, men samtidigt med en stor hÄrddisk.
Detta var allt för 2009, men i princip Àr dessa krav fortfarande relevanta idag. Vi har en retrospektiv, sÄ 2009 var allt helt dÄligt med detta.
Och den sista punkten Àr priset.
Priset var mycket högt pÄ den tiden, och vi behövde leta efter nÄgra alternativ. De dÀr. vi behövde pÄ nÄgot sÀtt bÀttre utnyttja bÄde utrymmet i datacentren och de fysiska servrarna dÀr allt detta finns. Och vÄra systemingenjörer pÄbörjade en stor studie dÀr de granskade en massa olika alternativ. De tittade ocksÄ pÄ klustrade filsystem som PolyCeph och Luster. Det var prestandaproblem och ganska svÄr drift. De vÀgrade. Vi försökte montera hela datamÀngden via NFS pÄ varje bil för att pÄ nÄgot sÀtt skala upp den. LÀsningen gick ocksÄ dÄligt, vi provade olika lösningar frÄn olika leverantörer.
Och till slut bestÀmde vi oss för att anvÀnda det sÄ kallade Storage Area Network.
Dessa Àr stora SHD:er som Àr speciellt utformade för att lagra stora mÀngder data. De Àr hyllor med skivor som Àr monterade pÄ de slutliga optiska utmatningsmaskinerna. Den dÀr. vi har nÄgon slags pool av maskiner, ganska smÄ, och dessa SHD:er, som Àr transparenta för vÄr sÀndningslogik, dvs. för vÄr nginx eller nÄgon annan att skicka förfrÄgningar om dessa foton.
Detta beslut hade uppenbara fördelar. Det hÀr Àr SHD. Den syftar till att lagra foton. Detta fungerar billigare Àn att bara utrusta maskiner med hÄrddiskar.
Andra plus.
Detta Àr att kapaciteten har blivit mycket större, d.v.s. vi kan ta emot mycket mer lagring i en mycket mindre volym.
Men det fanns ocksÄ nackdelar som dök upp ganska snabbt. NÀr antalet anvÀndare och belastningen pÄ detta system ökade började prestandaproblem uppstÄ. Och problemet hÀr Àr ganska uppenbart - vilken SHD som helst som Àr utformad för att lagra mÄnga bilder i en liten volym lider som regel av intensiv lÀsning. Detta Àr faktiskt sant för alla molnlagringar eller nÄgot annat. Nu har vi inte en idealisk lagring som skulle vara oÀndligt skalbar, du kan stoppa in vad som helst i den och den skulle tÄla avlÀsningar mycket bra. SÀrskilt tillfÀlliga lÀsningar.
Som Àr fallet med vÄra bilder, eftersom foton begÀrs inkonsekvent, och detta kommer att i hög grad pÄverka deras prestanda.
Ăven enligt dagens siffror, om vi fĂ„r nĂ„gonstans mer Ă€n 500 RPS för foton pĂ„ en maskin som lagring Ă€r ansluten till, börjar problemen redan. Och det var illa nog för oss, eftersom antalet anvĂ€ndare vĂ€xer, det kommer bara att bli vĂ€rre. Detta mĂ„ste optimeras pĂ„ nĂ„got sĂ€tt.
För att optimera beslutade vi vid den tiden, uppenbarligen, att titta pÄ lastprofilen - vad som i allmÀnhet hÀnder, vad som behöver optimeras.
Och hÀr spelar allt i vÄra hÀnder.
Jag sa redan i den första bilden: vi har 80 tusen lÀsförfrÄgningar per sekund med bara 3,5 miljoner uppladdningar per dag. Det vill sÀga, detta Àr en skillnad pÄ tre storleksordningar. Det Àr uppenbart att lÀsningen behöver optimeras och det Àr praktiskt taget tydligt hur.
Det finns en liten punkt till. Det specifika med tjÀnsten Àr sÄdana att en person registrerar sig, laddar upp ett foto, börjar sedan aktivt titta pÄ andra mÀnniskor, gillar dem och visas aktivt för andra mÀnniskor. Sedan hittar han en kompis eller inte hittar en kompis, det beror pÄ hur det blir, och slutar anvÀnda tjÀnsten ett tag. I det hÀr ögonblicket, nÀr han anvÀnder det, Àr hans foton vÀldigt heta - de Àr efterfrÄgade, mÄnga tittar pÄ dem. SÄ fort han slutar göra detta, tappar han ganska snabbt lika mycket exponering för andra mÀnniskor som han hade tidigare, och hans bilder efterfrÄgas nÀstan aldrig.
De dÀr. Vi har en mycket liten het datauppsÀttning. Men samtidigt finns det mÄnga förfrÄgningar efter honom. Och en helt sjÀlvklar lösning hÀr Àr att lÀgga till en cache.
En cache med LRU kommer att lösa alla vÄra problem. Vad gör vi?
Vi lÀgger till ytterligare en relativt liten framför vÄrt stora kluster med lagring, som kallas photocacher. Detta Àr i princip bara en caching-proxy.
Hur fungerar det frÄn insidan? HÀr Àr vÄr anvÀndare, hÀr Àr lagring. Allt Àr som tidigare. Vad lÀgger vi till dÀremellan?
Det Àr bara en maskin med en fysisk lokal disk, vilket Àr snabbt. Detta Àr till exempel med en SSD. Och nÄgon form av lokal cache lagras pÄ den hÀr disken.
Vad ser det ut som? AnvÀndaren skickar en begÀran om ett foto. NGINX letar efter det först i den lokala cachen. Om inte, bara proxy_pass till vÄr lagring, ladda ner fotot dÀrifrÄn och ge det till anvÀndaren.
Men den hÀr Àr vÀldigt banal och det Àr oklart vad som hÀnder inuti. Det fungerar ungefÀr sÄ hÀr.
Cachen Àr logiskt uppdelad i tre lager. NÀr jag sÀger "tre lager" betyder det inte att det finns nÄgot slags komplext system. Nej, dessa Àr villkorligt bara tre kataloger i filsystemet:
- Detta Àr en buffert dit bilder som precis laddats ner frÄn en proxy gÄr.
- Detta Àr en het cache som lagrar för nÀrvarande aktivt efterfrÄgade foton.
- Och en kall cache, dÀr foton gradvis skjuts ut ur den heta cachen nÀr fÀrre förfrÄgningar kommer till dem.
För att detta ska fungera mÄste vi pÄ nÄgot sÀtt hantera den hÀr cachen, vi mÄste ordna om bilderna i den osv. Detta Àr ocksÄ en mycket primitiv process.
Nginx skriver helt enkelt till RAMDisk access.log för varje begÀran, dÀr den indikerar sökvÀgen till fotot som den för nÀrvarande har betjÀnat (relativ sökvÀg, naturligtvis), och vilken partition den serverades. De dÀr. det kan stÄ "foto 1" och sedan antingen en buffert eller en varm cache, eller en kall cache eller en proxy.
Beroende pÄ detta mÄste vi pÄ nÄgot sÀtt bestÀmma vad vi ska göra med fotot.
Vi har en liten demon igÄng pÄ varje maskin som stÀndigt lÀser denna logg och lagrar statistik om anvÀndningen av vissa fotografier i dess minne.
Han samlar helt enkelt dÀr, förvarar diskarna och gör med jÀmna mellanrum följande. Han flyttar aktivt efterfrÄgade bilder, som det finns mÄnga förfrÄgningar om, till den heta cachen, var de Àn Àr.
Foton som efterfrÄgas sÀllan och som har blivit efterfrÄgade mer sÀllan skjuts gradvis ut ur den heta cachen till den kalla.
Och nÀr vi fÄr ont om utrymme i cachen börjar vi helt enkelt radera allt frÄn den kalla cachen urskillningslöst. Och förresten, det hÀr fungerar bra.
För att fotot ska sparas omedelbart nÀr det proxysÀtts till bufferten anvÀnder vi proxy_store-direktivet och bufferten Àr ocksÄ en RAMDisk, d.v.s. för anvÀndaren fungerar det vÀldigt snabbt. Detta gÀller sjÀlva cachingserverns inre delar.
Den ÄterstÄende frÄgan Àr hur man distribuerar förfrÄgningar över dessa servrar.
LÄt oss sÀga att det finns ett kluster med tjugo lagringsmaskiner och tre cachningsservrar (sÄ hÀr hÀnde det).
Vi mÄste pÄ nÄgot sÀtt avgöra vilka förfrÄgningar som Àr för vilka foton och var de ska landa.
Det vanligaste alternativet Àr Round Robin. Eller gör det av misstag?
Detta har uppenbarligen ett antal nackdelar eftersom vi skulle anvĂ€nda cachen vĂ€ldigt ineffektivt i en sĂ„dan situation. FörfrĂ„gningar kommer att landa pĂ„ nĂ„gra slumpmĂ€ssiga maskiner: hĂ€r cacheades det, men pĂ„ nĂ€sta finns det inte lĂ€ngre. Och om allt detta fungerar blir det vĂ€ldigt dĂ„ligt. Ăven med ett litet antal maskiner i klustret.
Vi mÄste pÄ nÄgot sÀtt entydigt bestÀmma vilken server som ska landa vilken begÀran.
Det finns ett banalt sÀtt. Vi tar hashen frÄn URL:en eller hashen frÄn vÄr shading-nyckel, som finns i URL:en, och delar den med antalet servrar. Kommer att funka? Kommer.
De dÀr. Vi har en 2% begÀran, till exempel för vissa "example_url" kommer den alltid att landa pÄ servern med index "XNUMX", och cachen kommer stÀndigt att kasseras pÄ bÀsta sÀtt.
Men det finns ett problem med omdelning i ett sÄdant schema. Omhardning - jag menar att Àndra antalet servrar.
LÄt oss anta att vÄrt cachingkluster inte lÀngre kan hantera och vi bestÀmmer oss för att lÀgga till en annan maskin.
LÄt oss lÀgga till.
Nu Àr allt inte delbart med tre, utan med fyra. SÄledes, nÀstan alla nycklar som vi brukade ha, nÀstan alla webbadresser finns nu pÄ andra servrar. Hela cachen ogiltigförklarades helt enkelt för ett ögonblick. Alla förfrÄgningar föll pÄ vÄrt lagringskluster, det blev illamÄende, tjÀnstefel och missnöjda anvÀndare. Jag vill inte göra det.
Det hÀr alternativet passar inte oss heller.
Den dÀr. vad ska vi göra? Vi mÄste pÄ nÄgot sÀtt anvÀnda cachen effektivt, landa samma begÀran pÄ samma server om och om igen, men vara motstÄndskraftiga mot omskÀrning. Och det finns en sÄdan lösning, den Àr inte sÄ komplicerad. Det kallas konsekvent hashing.
Vad ser det ut som?
Vi tar nÄgon funktion frÄn skÀrningsnyckeln och sprider alla dess vÀrden pÄ cirkeln. De dÀr. vid punkt 0 konvergerar dess lÀgsta och högsta vÀrden. DÀrefter 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 medurs till den, betjÀnas följaktligen av denna vÀrd. NÀr förfrÄgningar kommer till oss ser vi direkt att till exempel begÀran A - den har en hash dÀr - och den serveras av server 2. BegÀran B - av server 3. Och sÄ vidare.
Vad hÀnder i den hÀr situationen under omdelning?
Vi ogiltigförklarar inte hela cachen, som tidigare, och flyttar inte alla nycklar, utan vi flyttar varje sektor en kort strÀcka sÄ att, relativt sett, vÄr sjÀtte server, som vi vill lÀgga till, passar in i det lediga utrymmet, och vi lÀgger till det dÀr.
Naturligtvis flyttar ocksÄ nycklarna i en sÄdan situation ut. Men de flyttar ut mycket svagare Àn tidigare. Och vi ser att vÄra första tvÄ nycklar fanns kvar pÄ deras servrar, och cachingservern Àndrades bara för den sista nyckeln. Detta fungerar ganska effektivt, och om du lÀgger till nya vÀrdar stegvis, sÄ finns det inga stora problem hÀr. Du lÀgger till och lÀgger till lite i taget, vÀntar tills cachen Àr full igen, och allt fungerar bra.
Den enda frÄgan ÄterstÄr med avslag. LÄt oss anta att nÄgon sorts bil Àr ur funktion.
Och vi skulle inte riktigt vilja Ă„terskapa den hĂ€r kartan i detta ögonblick, ogiltigförklara en del av cachen och sĂ„ vidare, om till exempel maskinen startades om och vi pĂ„ nĂ„got sĂ€tt behöver servicebegĂ€ran. Vi hĂ„ller helt enkelt en backup-fotocache pĂ„ varje plats, som fungerar som en ersĂ€ttning för alla maskiner som för nĂ€rvarande Ă€r nere. Och om en av vĂ„ra servrar plötsligt blir otillgĂ€nglig gĂ„r trafiken dit. Naturligtvis har vi ingen cache dĂ€r, dvs. det Ă€r kallt, men Ă„tminstone anvĂ€ndarförfrĂ„gningar bearbetas. Ăr det ett kort intervall sĂ„ upplever vi det helt lugnt. Det Ă€r bara mer belastning pĂ„ lagring. Om detta intervall Ă€r lĂ„ngt kan vi redan ta ett beslut - att ta bort den hĂ€r servern frĂ„n kartan eller inte, eller kanske ersĂ€tta den med en annan.
Det hÀr handlar om cachingsystemet. LÄt oss titta pÄ resultaten.
Det verkar som att det inte Àr nÄgot komplicerat hÀr. Men den hÀr metoden att hantera cachen gav oss en trickfrekvens pÄ cirka 98%. De dÀr. av dessa 80 tusen förfrÄgningar per sekund nÄr bara 1600 lagring, och detta Àr en helt normal belastning, de tÄl det lugnt, vi har alltid en reserv.
Vi placerade dessa servrar i tre av vÄra DC och fick tre nÀrvaropunkter - Prag, Miami och Hong Kong.
Den dÀr. de Àr mer eller mindre lokalt belÀgna för var och en av vÄra mÄlmarknader.
Och som en trevlig bonus fick vi denna caching-proxy, pÄ vilken CPU:n faktiskt Àr inaktiv, eftersom det inte behövs sÄ för att servera innehÄll. Och dÀr, med hjÀlp av NGINX+ Lua, implementerade vi en hel del utilitaristisk logik.
Till exempel kan vi experimentera med webp eller progressiv jpeg (detta Àr effektiva moderna format), se hur det pÄverkar trafiken, fatta nÄgra beslut, aktivera det för vissa lÀnder, etc.; gör dynamisk storleksÀndring eller beskÀra foton i farten.
Detta Àr ett bra anvÀndningsfall nÀr du till exempel har en mobilapplikation som visar bilder och mobilapplikationen inte vill slösa bort klientens CPU pÄ att begÀra ett stort foto och sedan Àndra storlek pÄ det till en viss storlek för att trycka in det i Vyn. Vi kan helt enkelt dynamiskt ange vissa parametrar i den villkorliga UPort-URL:n, och fotocachen kommer att Àndra storleken pÄ sjÀlva bilden. Som regel kommer den att vÀlja storleken som vi fysiskt har pÄ disken, sÄ nÀra den efterfrÄgade som möjligt, och sÀlja ner den i specifika koordinater.
Förresten, vi har gjort allmÀnt tillgÀngliga videoinspelningar frÄn de senaste fem Ären av konferensen för utvecklare av högbelastningssystem . Titta, lÀr, dela och prenumerera pÄ .
Vi kan ocksÄ lÀgga till mycket produktlogik dÀr. Till exempel kan vi lÀgga till olika vattenstÀmplar med hjÀlp av URL-parametrar, vi kan sudda ut, oskÀrpa eller pixla bilder. Det Àr nÀr vi vill visa ett foto av en person, men vi vill inte visa hans ansikte, det hÀr fungerar bra, allt Àr implementerat hÀr.
Vad fick vi? Vi har tre nÀrvaropunkter, en bra trickhastighet, och samtidigt har vi inte ledig CPU pÄ dessa maskiner. Han har nu förstÄs blivit viktigare Àn tidigare. Vi mÄste ge oss sjÀlva starkare bilar, men det Àr det vÀrt.
Det handlar om ÄterlÀmnande av fotografier. Allt hÀr Àr ganska tydligt och sjÀlvklart. Jag tror att jag inte upptÀckte Amerika, nÀstan alla CDN fungerar pÄ det hÀr sÀttet.
Och troligen kan en sofistikerad lyssnare ha en frÄga: varför inte bara Àndra allt till CDN? Det skulle vara ungefÀr detsamma; alla moderna CDN kan göra detta. Och det finns ett antal anledningar.
Det första Àr fotografier.
Detta Àr en av nyckelpunkterna i vÄr infrastruktur, och vi behöver sÄ mycket kontroll över den som möjligt. Om det hÀr Àr nÄgon slags lösning frÄn en tredjepartsleverantör, och du inte har nÄgon makt över det, kommer det att vara ganska svÄrt för dig att leva med det nÀr du har en stor datamÀngd och nÀr du har ett mycket stort flöde av anvÀndarförfrÄgningar.
LÄt mig ge dig ett exempel. Nu kan vi med vÄr infrastruktur, till exempel vid vissa problem eller underjordiska knackningar, gÄ till maskinen och röra dÀr, relativt sett. Vi kan lÀgga till samlingen av nÄgra mÀtvÀrden som vi bara behöver, vi kan experimentera pÄ nÄgot sÀtt, se hur detta pÄverkar graferna och sÄ vidare. Nu samlas mycket statistik pÄ detta cachingkluster. Och vi tittar regelbundet pÄ det och spenderar lÄng tid pÄ att utforska nÄgra anomalier. Om det var pÄ CDN-sidan skulle det vara mycket svÄrare att kontrollera. Eller, till exempel, om nÄgon sorts olycka intrÀffar, vi vet vad som hÀnde, vi vet hur vi ska leva med det och hur vi ska övervinna det. Detta Àr den första slutsatsen.
Den andra slutsatsen Àr ocksÄ ganska historisk, eftersom systemet har utvecklats under lÄng tid, och det fanns mÄnga olika affÀrskrav i olika skeden, och de passar inte alltid in i CDN-konceptet.
Och poÀngen som följer av den föregÄende Àr
Detta beror pÄ att vi pÄ fotocacher har mycket specifik logik, 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 saker till dig pÄ din begÀran. Till exempel att kryptera webbadresser om du inte vill att klienten ska kunna Àndra nÄgot. Vill du Àndra URL pÄ servern och kryptera den, och sedan skicka nÄgra dynamiska parametrar hit.
Vilken slutsats tyder detta pÄ? I vÄrt fall Àr CDN inte ett sÀrskilt bra alternativ.
Och i ditt fall, om du har nÄgra specifika affÀrskrav, kan du ganska enkelt implementera det jag visade dig sjÀlv. Och detta kommer att fungera perfekt med en liknande lastprofil.
Men om du har nÄgon form av generell lösning, och uppgiften inte Àr sÀrskilt specifik, kan du helt sÀkert ta ett CDN. Eller om tid och resurser Àr viktigare för dig Àn kontroll.
Och moderna CDN har nÀstan allt som jag berÀttade om nu. Med undantag för plus eller minus vissa funktioner.
Det hÀr handlar om att ge bort bilder.
LÄt oss nu gÄ lite framÄt i vÄr retrospektiv och prata om förvaring.
2013 höll pÄ att passera.
Cachingservrar lades till, prestandaproblem försvann. Allt Àr bra. Dataset vÀxer. FrÄn och med 2013 hade vi cirka 80 servrar anslutna till lagring och cirka 40 cachande i varje DC. Detta Àr 560 terabyte data pÄ varje DC, dvs. ungefÀr en petabyte totalt.
Och med tillvÀxten av datamÀngden började driftskostnaderna stiga avsevÀrt. Vad betydde detta?
I det hĂ€r diagrammet som Ă€r ritat - med ett SAN, med maskiner och cacher kopplade till det - finns det mĂ„nga felpunkter. Om vi ââredan hade hanterat felet med cacheservrar tidigare, var allt mer eller mindre förutsĂ€gbart och förstĂ„eligt, men pĂ„ lagringssidan var allt mycket vĂ€rre.
För det första sjÀlva Storage Area Network (SAN), som kan misslyckas.
För det andra kopplas den via optik till slutmaskinerna. Det kan vara problem med optiska kort och tÀndstift.
Naturligtvis finns det inte lika mÄnga av dem som med sjÀlva SAN, men inte desto mindre Àr dessa ocksÄ felpunkter.
NÀsta Àr sjÀlva maskinen, som Àr ansluten till förrÄdet. Det kan ocksÄ misslyckas.
Totalt har vi tre misslyckanden.
Vidare, förutom felpunkter, Àr det tungt underhÄll av sjÀlva lagringen.
Detta Àr ett komplext flerkomponentsystem och systemingenjörer kan ha svÄrt att arbeta med det.
Och den sista, viktigaste punkten. Om ett fel intrÀffar vid nÄgon av dessa tre punkter har vi en chans att förlora anvÀndardata som inte Àr lika med noll eftersom filsystemet kan krascha.
LÄt oss sÀga att vÄrt filsystem Àr trasigt. För det första tar ÄterstÀllningen lÄng tid - det kan ta en vecka med en stor mÀngd data. Och för det andra, i slutÀndan kommer vi med största sannolikhet att sluta med ett gÀng obegripliga filer som pÄ nÄgot sÀtt mÄste kombineras till anvÀndarbilder. Och vi riskerar att förlora data. Risken Àr ganska hög. Och ju oftare sÄdana situationer intrÀffar, och ju fler problem uppstÄr i hela denna kedja, desto högre Àr risken.
NÄgot mÄste göras Ät detta. Och vi bestÀmde att vi bara behöver sÀkerhetskopiera data. Detta Àr faktiskt en sjÀlvklar och bra lösning. Vad har vi gjort?
SÄ hÀr sÄg vÄr server ut nÀr den var ansluten till lagring tidigare. Detta Àr en huvudsektion, det Àr bara en blockenhet som faktiskt representerar ett fÀste för fjÀrrlagring via optik.
Vi har precis lagt till ett andra avsnitt.
Vi placerade en andra lagring bredvid den (lyckligtvis Àr det inte sÄ dyrt i form av pengar) och kallade det en backup-partition. Den Àr ocksÄ ansluten via optik och sitter pÄ samma maskin. Men vi mÄste pÄ nÄgot sÀtt synkronisera data mellan dem.
HÀr gör vi helt enkelt en asynkron kö i nÀrheten.
Hon Àr inte sÀrskilt upptagen. Vi vet att vi inte har tillrÀckligt med register. En kö Àr bara en tabell i MySQL dÀr rader som "du mÄste sÀkerhetskopiera det hÀr fotot" Àr skrivna. Med nÄgon Àndring eller uppladdning kopierar vi frÄn huvudpartitionen till sÀkerhetskopian asynkront eller helt enkelt av nÄgon sorts bakgrundsarbetare.
Och dĂ€rmed har vi alltid tvĂ„ konsekventa avsnitt. Ăven om en del av detta system misslyckas, kan vi alltid byta huvudpartition med en sĂ€kerhetskopia, och allt kommer att fortsĂ€tta att fungera.
Men pÄ grund av detta ökar lÀsbelastningen kraftigt, eftersom... förutom klienter som lÀser frÄn huvudsektionen, eftersom de först tittar pÄ fotot dÀr (det Àr nyare dÀr) och sedan letar efter det pÄ sÀkerhetskopian, om de inte har hittat det (men NGINX gör bara detta), vÄrt system Àr ocksÄ ett plus backup nu lÀser frÄn huvudpartitionen. Det Àr inte sÄ att detta var en flaskhals, men jag ville inte öka belastningen, i princip bara sÄ.
Och vi lade till en tredje disk, som Àr en liten SSD, och kallade den en buffert.
Hur det fungerar nu.
AnvÀndaren laddar upp ett foto till bufferten, sedan kastas en hÀndelse in i kön som indikerar att den mÄste kopieras i tvÄ sektioner. Det kopieras, och fotot lever pÄ bufferten under en tid (sÀg en dag), och först dÀrefter rensas det dÀrifrÄn. Detta förbÀttrar anvÀndarupplevelsen avsevÀrt, eftersom anvÀndaren laddar upp ett foto, som regel börjar förfrÄgningar följa omedelbart, eller sÄ uppdaterade han sjÀlv sidan och uppdaterade den. Men allt beror pÄ applikationen som gör uppladdningen.
Eller, till exempel, andra personer som han började visa sig för skickar omedelbart förfrÄgningar efter detta foto. Den finns Ànnu inte i cachen, den första begÀran sker mycket snabbt. I huvudsak samma som frÄn en fotocache. LÄngsam lagring Àr inte inblandad i detta alls. Och nÀr den en dag senare rensas, Àr den antingen redan cachad pÄ vÄrt cachinglager, eller, troligen, behöver ingen den lÀngre. De dÀr. AnvÀndarupplevelsen hÀr har vuxit mycket bra pÄ grund av sÄ enkla manipulationer.
Tja, och viktigast av allt: vi slutade förlora data.
LÄt oss bara sÀga att vi slutade potentiellt förlora data, eftersom vi egentligen inte förlorade den. Men det var fara. Vi ser att den hÀr lösningen förstÄs Àr bra, men det Àr lite som att jÀmna ut symtomen pÄ problemet, istÀllet för att lösa det helt. Och nÄgra problem kvarstÄr hÀr.
För det första Àr detta en punkt av misslyckande i form av sjÀlva den fysiska vÀrden som allt detta maskineri körs pÄ, det har inte försvunnit.
För det andra finns det fortfarande problem med SAN, deras tunga underhÄll etc. kvarstÄr. Det var inte sÄ att det var en kritisk faktor, men jag ville försöka leva utan det pÄ nÄgot sÀtt.
Och vi gjorde den tredje versionen (i sjÀlva verket den andra) - reservationsversionen. Vad sÄg det ut som?
Det hÀr Àr vad det var -
VÄra största problem Àr att detta Àr en fysisk vÀrd.
För det första tar vi bort SAN för att vi vill experimentera, vi vill bara prova lokala hÄrddiskar.
Detta Àr redan 2014-2015, och pÄ den tiden blev situationen med diskar och deras kapacitet i en vÀrd mycket bÀttre. Vi bestÀmde oss för varför inte prova det.
Och sedan tar vi helt enkelt vÄr backup-partition och överför den fysiskt till en separat maskin.
SÄledes fÄr vi detta diagram. Vi har tvÄ bilar som lagrar samma datamÀngder. De sÀkerhetskopierar varandra fullstÀndigt och synkroniserar data över nÀtverket genom en asynkron kö i samma MySQL.
Varför det hÀr fungerar bra beror pÄ att vi har fÄ rekord. De dÀr. om skrivande var jÀmförbart med lÀsning skulle vi kanske ha nÄgon form av nÀtverksoverhead och problem. Det Àr lite skrivning, mycket lÀsning - den hÀr metoden fungerar bra, d.v.s. Vi kopierar sÀllan foton mellan dessa tvÄ servrar.
Hur fungerar det hÀr, om man tittar lite mer i detalj.
Ladda upp. Balanseraren vÀljer helt enkelt slumpmÀssiga vÀrdar med ett par och laddar upp till det. Samtidigt gör han naturligtvis hÀlsokontroller och ser till att bilen inte ramlar ur. De dÀr. han laddar bara upp bilder till en liveserver och sedan genom en asynkron kö kopieras allt till hans granne. Med uppladdning Àr allt extremt enkelt.
Uppgiften Àr lite svÄrare.
Lua hjÀlpte oss hÀr, för det kan vara svÄrt att göra sÄdan logik pÄ vanilla NGINX. Vi gör först en förfrÄgan till den första servern, se om bilden finns dÀr, eftersom den potentiellt kan laddas upp till exempel till en granne, men har Ànnu inte kommit hit. Om bilden finns dÀr Àr det bra. Vi ger det omedelbart till klienten och, eventuellt, cachelagrar det.
Finns den inte dÀr sÄ gör vi helt enkelt en förfrÄgan till vÄr granne och fÄr den garanterat dÀrifrÄn.
Den dÀr. Äterigen kan vi sÀga: det kan finnas problem med prestanda, eftersom det finns stÀndiga rundresor - bilden laddades upp, den Àr inte hÀr, vi gör tvÄ förfrÄgningar istÀllet för en, det hÀr borde fungera lÄngsamt.
I vÄr situation gÄr detta inte lÄngsamt.
Vi samlar in ett gÀng mÄtt pÄ det hÀr systemet, och den villkorade smarta frekvensen för en sÄdan mekanism Àr cirka 95%. De dÀr. Fördröjningen av denna sÀkerhetskopia Àr liten, och pÄ grund av detta Àr vi nÀstan garanterade att efter att bilden har laddats upp kommer vi att ta den första gÄngen och kommer inte att behöva gÄ nÄgonstans tvÄ gÄnger.
SÄ vad mer har vi som Àr riktigt coolt?
Tidigare hade vi huvudpartitionen för sÀkerhetskopiering, och vi lÀste frÄn dem sekventiellt. De dÀr. Vi sökte alltid pÄ huvudet först och sedan pÄ sÀkerhetskopian. Det var ett drag.
Nu anvÀnder vi lÀsning frÄn tvÄ maskiner samtidigt. Vi distribuerar förfrÄgningar med hjÀlp av Round Robin. I en liten andel av fallen gör vi tvÄ förfrÄgningar. Men totalt sett har vi nu dubbelt sÄ mycket lÀsstock som vi hade tidigare. Och belastningen minskade kraftigt bÄde pÄ sÀndningsmaskinerna och direkt pÄ lagermaskinerna, vilket vi ocksÄ hade pÄ den tiden.
Vad gÀller feltolerans. Egentligen Àr det detta vi frÀmst kÀmpade för. Med feltolerans blev allt bra hÀr.
En bil gÄr sönder.
Inga problem! En systemingenjör kanske inte ens vaknar pÄ natten, han vÀntar till morgonen, inget dÄligt kommer att hÀnda.
Om Àven om denna maskin gÄr sönder sÄ Àr kön ur funktion, det Àr inga problem heller, loggen kommer helt enkelt att samlas först pÄ den levande maskinen, och sedan lÀggs den till i kön och sedan vidare till bilen som ska gÄ i drift efter en tid.
Samma sak med underhÄll. Vi stÀnger helt enkelt av en av maskinerna, drar ut den manuellt ur alla pooler, den slutar ta emot trafik, vi gör nÄgon form av underhÄll, vi redigerar nÄgot, sedan ÄterstÀller vi den till tjÀnst, och den hÀr backupen kommer ikapp ganska snabbt. De dÀr. per dag kommer stillestÄndstiden för en bil ikapp inom ett par minuter. Det hÀr Àr verkligen vÀldigt lite. Med feltolerans sÀger jag igen, allt Àr coolt hÀr.
Vilka slutsatser kan dras av detta uppsÀgningsschema?
Vi fick feltolerans.
LÀtt att anvÀnda. Eftersom maskinerna har lokala hÄrddiskar Àr detta mycket bekvÀmare ur driftssynpunkt för ingenjörerna som arbetar med det.
Vi fick dubbelt lÀsersÀttning.
Detta Àr en mycket bra bonus förutom feltolerans.
Men det finns ocksÄ problem. Nu har vi en mycket mer komplex utveckling av vissa funktioner relaterade till detta, eftersom systemet sÄ smÄningom har blivit 100% konsekvent.
Vi mÄste, sÀg, i nÄgot bakgrundsjobb, stÀndigt tÀnka: "Vilken server kör vi pÄ nu?", "Finns det verkligen ett aktuellt foto hÀr?" etc. Detta Àr naturligtvis helt klart, och för programmeraren som skriver affÀrslogik Àr det transparent. Men inte desto mindre har detta stora komplexa lager dykt upp. Men vi Àr redo att stÄ ut med detta i utbyte mot de godsaker som vi fÄtt frÄn det.
Och hÀr uppstÄr igen en viss konflikt.
Jag sa i början att det Àr dÄligt att lagra allt pÄ lokala hÄrddiskar. Och nu sÀger jag att vi gillade det.
Ja, faktiskt, med tiden har situationen förÀndrats mycket, och nu har detta tillvÀgagÄngssÀtt mÄnga fördelar. För det första fÄr vi mycket enklare drift.
För det andra Àr det mer produktivt eftersom vi inte har dessa automatiska kontroller eller anslutningar till diskhyllor.
Det finns en enorm mÀngd maskiner dÀr, och det hÀr Àr bara nÄgra fÄ skivor som sÀtts ihop hÀr pÄ maskinen till en raid.
Men det finns ocksÄ nackdelar.
Detta Àr ungefÀr 1,5 gÄnger dyrare Àn att anvÀnda SAN Àven till dagens priser. DÀrför bestÀmde vi oss för att inte modigt konvertera hela vÄrt stora kluster till bilar med lokala hÄrddiskar och beslutade att lÀmna en hybridlösning.
HÀlften av vÄra maskiner fungerar med hÄrddiskar (nÄja, inte hÀlften - förmodligen 30 procent). Och resten Àr gamla bilar som brukade ha det första bokningssystemet. Vi monterade helt enkelt om dem, eftersom vi inte behövde ny data eller nÄgot annat, flyttade vi helt enkelt fÀstena frÄn en fysisk vÀrd till tvÄ.
Och vi har nu ett stort lager av lĂ€sning, och vi utökade det. Om vi ââtidigare monterade ett förrĂ„d pĂ„ en maskin, monterar vi nu fyra till exempel pĂ„ ett par. Och det fungerar bra.
LÄt oss ta en kort sammanfattning av vad vi Ästadkom, vad vi kÀmpade för och om vi lyckades.
Resultat av
Vi har anvĂ€ndare â sĂ„ mĂ„nga som 33 miljoner.
Vi har tre nÀrvaropunkter - Prag, Miami, Hong Kong.
De innehÄller ett cachinglager, som bestÄr av bilar med snabba lokala diskar (SSD), pÄ vilka enkla maskiner frÄn NGINX, dess access.log och Python-demoner körs, som bearbetar allt detta och hanterar cachen.
Om du vill Àr du i ditt projekt, om foton inte Àr lika kritiska för dig som de Àr för oss, eller om avvÀgningskontroll mot utvecklingshastighet och resurskostnader Àr Ät andra hÄllet för dig, dÄ kan du sÀkert byta ut det med ett CDN, moderna CDN Àr de bra.
DÀrefter kommer lagringslagret, pÄ vilket vi har kluster av par av maskiner som sÀkerhetskopierar varandra, filer kopieras asynkront frÄn en till en annan nÀr de Àndras.
Dessutom fungerar vissa av dessa maskiner med lokala hÄrddiskar.
Vissa av dessa maskiner Àr anslutna till SAN.
Och Ä ena sidan Àr den bekvÀmare att anvÀnda och lite mer produktiv, Ä andra sidan Àr den bekvÀm nÀr det gÀller placeringstÀthet och pris per gigabyte.
Detta Àr en sÄ kort översikt över arkitekturen av vad vi fick och hur det hela utvecklades.
NÄgra fler tips frÄn kaptenen, vÀldigt enkla.
Först, om du plötsligt bestÀmmer dig för att du akut behöver förbÀttra allt i din fotoinfrastruktur, mÀt först, för kanske behöver ingenting förbÀttras.
LÄt mig ge dig ett exempel. Vi har ett kluster av maskiner som skickar bilder frÄn bilagor i chattar, och systemet har fungerat dÀr sedan 2009, och ingen lider av det. Alla mÄr bra, alla gillar allt.
För att mÀta, hÀng först ett gÀng mÀtvÀrden, titta pÄ dem och bestÀm 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 coolt verktyg som heter Pinba.
Det lÄter dig samla in mycket detaljerad statistik frÄn NGINX för varje förfrÄgan och svarskoder, och fördelning av tider - vad du vill. Den har bindningar till alla möjliga olika analyssystem, och dÄ kan du titta pÄ det hela vackert.
Först mÀtte vi det, sedan förbÀttrade vi det.
Ytterligare. Vi optimerar lÀsning med cache, skrivning med sharding, men detta Àr en sjÀlvklar poÀng.
Ytterligare. Om du just nu börjar bygga ditt system Àr det mycket bÀttre att göra foton som oförÀnderliga filer. För man tappar omedelbart en hel klass av problem med cache-invalidering, med hur logiken ska hitta rÀtt version av fotot osv.
LÄt oss sÀga att du laddade upp hundra, sedan roterade det, gör det sÄ att det var en fysiskt annorlunda fil. De dÀr. du behöver inte tÀnka: nu ska jag spara lite utrymme, skriva det till samma fil, Àndra version. Detta fungerar alltid inte bra och orsakar mycket huvudvÀrk senare.
NÀsta punkt. Om storleksÀndring i farten.
Tidigare, nÀr anvÀndare laddade upp ett foto, klippte vi omedelbart en hel massa storlekar för alla tillfÀllen, för olika kunder, och de fanns alla pÄ disken. Nu har vi övergett detta.
Vi lÀmnade bara tre huvudstorlekar: small, medium och large. Vi nedskalar helt enkelt allt annat frÄn den storlek som ligger bakom den som tillfrÄgades oss pÄ Uport, vi gör helt enkelt nedskalningen och ger den till anvÀndaren.
CPU:n för cachinglagret hÀr visar sig vara mycket billigare Àn om vi stÀndigt regenererade dessa storlekar pÄ varje lagring. LÄt oss sÀga att vi vill lÀgga till en ny, detta kommer att ta en mÄnad - kör ett skript överallt som skulle göra allt detta snyggt, utan att förstöra klustret. De dÀr. Om du har möjlighet att vÀlja nu Àr det bÀttre att göra sÄ fÄ fysiska storlekar som möjligt, men sÄ att Ätminstone en viss fördelning Àr, sÀg, tre. Och allt annat kan enkelt Àndras i storlek direkt med hjÀlp av fÀrdiga moduler. Allt Àr vÀldigt enkelt och tillgÀngligt nu.
Och inkrementell asynkron backup Àr bra.
Som vÄr praxis har visat fungerar detta schema utmÀrkt med fördröjd kopiering av Àndrade filer.
Den sista punkten Àr ocksÄ uppenbar. Om din infrastruktur inte har sÄdana problem nu, men det finns nÄgot som kan gÄ sönder, kommer det definitivt att gÄ sönder nÀr det blir lite mer. DÀrför Àr det bÀttre att tÀnka pÄ detta i förvÀg och inte uppleva problem med det. Det var allt jag ville sÀga.
kontakter
»
»
Denna rapport Àr en utskrift av ett av de bÀsta talen pÄ konferensen för utvecklare av högbelastningssystem . Det Àr mindre Àn en mÄnad kvar till konferensen HighLoad++ 2017.
Vi har det redan klart , schemat formas nu aktivt.
I Är fortsÀtter vi att utforska Àmnet arkitektur och skalning:
- / Igor Vasiliev
- / Dmitrij Egorov
- / Anatolij Plaskovskij
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Philip Delgado
Vi anvÀnder ocksÄ en del av dessa material i vÄr onlinekurs om att utveckla högbelastningssystem Àr en kedja av speciellt utvalda brev, artiklar, material, videor. VÄr lÀrobok innehÄller redan mer Àn 30 unika material. Ansluta!
KĂ€lla: will.com