Artem Denisov ( , )
Badoo is 's werelds grootste datingsite. Momenteel hebben we wereldwijd ongeveer 330 miljoen geregistreerde gebruikers. Maar wat veel belangrijker is in de context van ons gesprek van vandaag, is dat we ongeveer 3 petabytes aan gebruikersfoto's opslaan. Elke dag uploaden onze gebruikers ongeveer 3,5 miljoen nieuwe foto's, en de leeslast is ongeveer 80 verzoeken per seconde. Dit is best veel voor onze backend, en soms zijn hier problemen mee.
Ik zal het hebben over het ontwerp van dit systeem, dat foto's in het algemeen opslaat en verzendt, en ik zal het vanuit het perspectief van een ontwikkelaar bekijken. Er zal een korte terugblik zijn op hoe het zich heeft ontwikkeld, waarin ik de belangrijkste mijlpalen zal schetsen, maar ik zal alleen in meer detail praten over de oplossingen die we momenteel gebruiken.
Laten we nu beginnen.
Zoals ik al zei, dit zal een terugblik zijn, en om ergens mee te beginnen, laten we het meest voorkomende voorbeeld nemen.
We hebben een gemeenschappelijke taak: we moeten gebruikersfoto's accepteren, opslaan en verzenden. In deze vorm is de taak algemeen, we kunnen alles gebruiken:
- moderne cloudopslag,
- een boxed-oplossing, waarvan er nu ook veel zijn;
- We kunnen meerdere machines in ons datacenter plaatsen en er grote harde schijven op plaatsen en daar foto's opslaan.
Historisch gezien leeft Badoo - zowel nu als toen (toen het nog maar in de kinderschoenen stond) - op zijn eigen servers, in onze eigen DC's. Daarom was deze optie voor ons optimaal.
We hebben zojuist verschillende machines genomen, ze ‘foto’s’ genoemd, en we hebben een cluster waarin foto’s zijn opgeslagen. Maar het lijkt alsof er iets ontbreekt. Om dit allemaal te laten werken, moeten we op de een of andere manier bepalen op welke machine we welke foto's gaan opslaan. En ook hier is het niet nodig Amerika te openen.
We voegen een veld toe aan onze opslag met informatie over gebruikers. Dit wordt de sharding-sleutel. In ons geval noemden we dit place_id, en deze place-ID verwijst naar de plaats waar gebruikersfoto's zijn opgeslagen. Wij maken kaarten.
In de eerste fase kan dit zelfs handmatig worden gedaan - we zeggen dat een foto van deze gebruiker met zo'n plek op zo'n server terechtkomt. Dankzij deze kaart weten we altijd wanneer een gebruiker een foto uploadt, waar we deze moeten opslaan en waar we deze vandaan kunnen geven.
Dit is een absoluut triviaal schema, maar het heeft behoorlijk aanzienlijke voordelen. De eerste is dat het eenvoudig is, zoals ik al zei, en de tweede is dat we met deze aanpak gemakkelijk horizontaal kunnen schalen door simpelweg nieuwe auto's te leveren en ze aan de kaart toe te voegen. U hoeft verder niets te doen.
Zo was het bij ons een tijdje.
Dit was rond 2009. Ze leverden auto's, leverden...
En op een gegeven moment begonnen we te merken dat dit schema bepaalde nadelen heeft. Wat zijn de nadelen?
In de eerste plaats is er sprake van een beperkte capaciteit. We kunnen niet zoveel harde schijven op één fysieke server proppen als we zouden willen. En dit is in de loop van de tijd en met de groei van de dataset een bepaald probleem geworden.
En ten tweede. Dit is een atypische configuratie van machines, aangezien dergelijke machines in sommige andere clusters moeilijk opnieuw te gebruiken zijn; ze zijn vrij specifiek, d.w.z. ze zouden zwak moeten zijn qua prestaties, maar tegelijkertijd met een grote harde schijf.
Dit gold allemaal voor 2009, maar in principe zijn deze eisen vandaag de dag nog steeds relevant. We hebben een terugblik, dus in 2009 was alles hiermee helemaal slecht.
En het laatste punt is de prijs.
De prijs was destijds erg hoog en we moesten op zoek naar alternatieven. Die. we moesten op de een of andere manier zowel de ruimte in de datacenters als de fysieke servers waarop dit allemaal staat beter benutten. En onze systeemingenieurs begonnen een groot onderzoek waarin ze een aantal verschillende opties beoordeelden. Ze keken ook naar geclusterde bestandssystemen zoals PolyCeph en Luster. Er waren prestatieproblemen en een vrij moeilijke bediening. Ze weigerden. We hebben geprobeerd de volledige dataset via NFS op elke auto te koppelen om deze op de een of andere manier op te schalen. Ook het lezen ging slecht, we hebben verschillende oplossingen van verschillende leveranciers geprobeerd.
En uiteindelijk hebben we gekozen voor het zogenaamde Storage Area Network.
Dit zijn grote SHD's die speciaal zijn ontworpen voor het opslaan van grote hoeveelheden gegevens. Het zijn planken met schijven die op de uiteindelijke optische uitvoermachines worden gemonteerd. Dat. we hebben een soort verzameling machines, vrij klein, en deze SHD's, die transparant zijn voor onze verzendlogica, d.w.z. voor onze nginx of iemand anders om verzoeken voor deze foto's in te dienen.
Deze beslissing had duidelijke voordelen. Dit is SHD. Het is gericht op het opslaan van foto's. Dit komt goedkoper uit dan simpelweg machines uitrusten met harde schijven.
Tweede pluspunt.
Dit is dat de capaciteit veel groter is geworden, d.w.z. we kunnen veel meer opslagruimte huisvesten in een veel kleiner volume.
Maar er waren ook nadelen die vrij snel naar voren kwamen. Naarmate het aantal gebruikers en de belasting van dit systeem toenamen, begonnen er prestatieproblemen te ontstaan. En het probleem hier is vrij duidelijk: elke SHD die is ontworpen om veel foto's in een klein volume op te slaan, heeft in de regel last van intensief lezen. Dit geldt eigenlijk voor elke cloudopslag of iets anders. Nu hebben we geen ideale opslag die oneindig schaalbaar zou zijn, je zou er van alles in kunnen stoppen, en het zou de metingen heel goed verdragen. Vooral gewone lectuur.
Zoals het geval is met onze foto's, omdat foto's inconsistent worden opgevraagd en dit de prestaties enorm zal beïnvloeden.
Zelfs volgens de cijfers van vandaag beginnen de problemen al als we ergens meer dan 500 RPS halen voor foto's op een machine waarop opslag is aangesloten. En het was al erg genoeg voor ons, omdat het aantal gebruikers groeit, zullen de zaken alleen maar erger worden. Dit moet op de een of andere manier worden geoptimaliseerd.
Om te optimaliseren hebben we destijds uiteraard besloten om naar het belastingsprofiel te kijken: wat er in het algemeen gebeurt, wat er geoptimaliseerd moet worden.
En hier speelt alles ons in de kaart.
Ik zei al in de eerste slide: we hebben 80 leesverzoeken per seconde met slechts 3,5 miljoen uploads per dag. Dat wil zeggen, dit is een verschil van drie ordes van grootte. Het is duidelijk dat het lezen moet worden geoptimaliseerd en het is praktisch duidelijk hoe.
Er is nog een klein punt. De specifieke kenmerken van de service zijn zodanig dat een persoon zich registreert, een foto uploadt, vervolgens actief naar andere mensen begint te kijken, zoals zij, en actief aan andere mensen wordt getoond. Dan vindt hij een partner of vindt hij geen partner, het hangt ervan af hoe het afloopt, en stopt hij een tijdje met het gebruik van de dienst. Op dit moment, wanneer hij het gebruikt, zijn zijn foto's erg populair - er is veel vraag naar, veel mensen bekijken ze. Zodra hij hiermee stopt, valt hij al snel uit de blootstelling aan andere mensen als voorheen, en er wordt bijna nooit om zijn foto's gevraagd.
Die. We hebben een zeer kleine, hete dataset. Maar tegelijkertijd zijn er veel verzoeken voor hem. En een volkomen voor de hand liggende oplossing hier is het toevoegen van een cache.
Een cache met LRU zal al onze problemen oplossen. Wat doen we?
We voegen nog een relatief kleine toe voor ons grote cluster met opslag, dat fotocaches wordt genoemd. Dit is in wezen slechts een caching-proxy.
Hoe werkt het van binnenuit? Hier is onze gebruiker, hier is opslag. Alles is hetzelfde als voorheen. Wat voegen we ertussen toe?
Het is gewoon een machine met een fysieke lokale schijf, die snel is. Dit is bijvoorbeeld bij een SSD. En er wordt een soort lokale cache op deze schijf opgeslagen.
Hoe ziet het eruit? De gebruiker stuurt een verzoek om een foto. NGINX zoekt het eerst in de lokale cache. Als dat niet het geval is, gaat u eenvoudigweg proxy_pass naar onze opslag, downloadt u de foto daar en geeft u deze aan de gebruiker.
Maar deze is heel banaal en het is onduidelijk wat er binnen gebeurt. Het werkt ongeveer zo.
De cache is logisch verdeeld in drie lagen. Als ik ‘drie lagen’ zeg, betekent dit niet dat er sprake is van een soort complex systeem. Nee, dit zijn voorwaardelijk slechts drie mappen in het bestandssysteem:
- Dit is een buffer waar foto's die zojuist van een proxy zijn gedownload, naartoe gaan.
- Dit is een hot cache waarin momenteel actief aangevraagde foto's worden opgeslagen.
- En een koude cache, waarbij foto's geleidelijk uit de warme cache worden geduwd naarmate er minder verzoeken binnenkomen.
Om dit te laten werken, moeten we deze cache op de een of andere manier beheren, moeten we de foto's erin herschikken, enz. Dit is ook een heel primitief proces.
Nginx schrijft eenvoudigweg voor elk verzoek naar de RAMDisk access.log, waarin het het pad aangeeft naar de foto die het momenteel heeft aangeboden (relatief pad natuurlijk), en op welke partitie het is geserveerd. Die. er kan "foto 1" staan en dan een buffer, of een warme cache, of een koude cache, of een proxy.
Afhankelijk hiervan moeten we op de een of andere manier beslissen wat we met de foto gaan doen.
We hebben op elke machine een kleine daemon draaien die voortdurend dit logboek leest en statistieken over het gebruik van bepaalde foto's in zijn geheugen opslaat.
Hij verzamelt daar eenvoudigweg, houdt de tellers bij en doet periodiek het volgende. Hij verplaatst actief aangevraagde foto's, waarvoor veel verzoeken zijn, naar de hot cache, waar ze zich ook bevinden.
Foto's die zelden worden opgevraagd en minder vaak worden opgevraagd, worden geleidelijk uit de warme cache naar de koude geduwd.
En als we geen ruimte meer hebben in de cache, beginnen we gewoon zonder onderscheid alles uit de koude cache te verwijderen. En dit werkt overigens goed.
Om ervoor te zorgen dat de foto onmiddellijk wordt opgeslagen wanneer deze naar de buffer wordt geproxy, gebruiken we de proxy_store-richtlijn en de buffer is ook een RAMDisk, d.w.z. voor de gebruiker werkt het heel snel. Dit betreft de interne onderdelen van de cachingserver zelf.
De resterende vraag is hoe verzoeken over deze servers kunnen worden verdeeld.
Laten we zeggen dat er een cluster is van twintig opslagmachines en drie cachingservers (zo is het gebeurd).
We moeten op de een of andere manier bepalen welke verzoeken voor welke foto's gelden en waar we deze kunnen plaatsen.
De meest voorkomende optie is Round Robin. Of doe je het per ongeluk?
Dit heeft uiteraard een aantal nadelen, omdat we in een dergelijke situatie de cache zeer inefficiënt zouden gebruiken. Verzoeken komen op sommige willekeurige machines terecht: hier werd het in de cache opgeslagen, maar op de volgende is het er niet meer. En als dit allemaal werkt, zal het heel erg zijn. Zelfs met een klein aantal machines in het cluster.
We moeten op de een of andere manier ondubbelzinnig bepalen welke server welk verzoek moet indienen.
Er is een banale manier. We nemen de hash van de URL of de hash van onze shardingsleutel, die zich in de URL bevindt, en delen deze door het aantal servers. Zal werken? Zullen.
Die. We hebben bijvoorbeeld een 2% verzoek, voor een bepaalde “example_url” zal deze altijd op de server met index “XNUMX” terechtkomen, en de cache zal voortdurend zo goed mogelijk worden verwijderd.
Maar er is een probleem met herharden in een dergelijk schema. Resharding - Ik bedoel het veranderen van het aantal servers.
Laten we ervan uitgaan dat ons cachingcluster het niet meer aankan en we besluiten nog een machine toe te voegen.
Laten we toevoegen.
Nu is alles niet deelbaar door drie, maar door vier. Dus bijna alle sleutels die we vroeger hadden, bijna alle URL's staan nu op andere servers. De hele cache werd voor een moment ongeldig gemaakt. Alle verzoeken vielen op ons opslagcluster, het werd onwel, servicestoringen en ontevreden gebruikers. Dat wil ik niet doen.
Deze optie past ook niet bij ons.
Dat. wat moeten we doen? We moeten op de een of andere manier efficiënt gebruik maken van de cache, hetzelfde verzoek keer op keer op dezelfde server plaatsen, maar bestand zijn tegen herharding. En er is zo'n oplossing, het is niet zo ingewikkeld. Het heet consistent hashen.
Hoe ziet dit eruit?
We nemen een functie van de sharding-sleutel en verspreiden al zijn waarden over de cirkel. Die. op punt 0 convergeren de minimum- en maximumwaarden. Vervolgens plaatsen we al onze servers op ongeveer deze manier in dezelfde cirkel:
Elke server wordt gedefinieerd door één punt, en de sector die er met de klok mee naartoe gaat, wordt dienovereenkomstig bediend door deze host. Als er verzoeken bij ons binnenkomen, zien we meteen dat bijvoorbeeld verzoek A - daar een hash staat - en wordt geserveerd door server 2. Verzoek B - door server 3. Enzovoorts.
Wat gebeurt er in deze situatie tijdens het herharden?
We maken niet de hele cache ongeldig, zoals voorheen, en verschuiven niet alle sleutels, maar we verplaatsen elke sector over een korte afstand zodat, relatief gezien, onze zesde server, die we willen toevoegen, in de vrije ruimte past, en wij voegen het daar toe.
Uiteraard bewegen in zo'n situatie ook de toetsen naar buiten. Maar ze vertrekken veel zwakker dan voorheen. En we zien dat onze eerste twee sleutels op hun servers bleven staan, en dat de caching-server alleen voor de laatste sleutel veranderde. Dit werkt behoorlijk efficiënt, en als je stapsgewijs nieuwe hosts toevoegt, is er hier geen groot probleem. Je voegt beetje bij beetje toe, wacht tot de cache weer vol is en alles werkt goed.
De enige vraag blijft bij weigeringen. Laten we aannemen dat een of andere auto defect is.
En we zouden deze kaart op dit moment niet echt opnieuw willen genereren, een deel van de cache ongeldig willen maken, enzovoort, als de machine bijvoorbeeld opnieuw is opgestart en we op de een of andere manier serviceverzoeken moeten doen. We bewaren eenvoudigweg één back-upfotocache op elke locatie, die fungeert als vervanging voor elke machine die momenteel niet beschikbaar is. En als een van onze servers plotseling niet meer beschikbaar is, gaat het verkeer daar naartoe. Uiteraard hebben we daar geen cache, d.w.z. het is koud, maar gebruikersverzoeken worden tenminste verwerkt. Als dit een korte pauze is, ervaren we het volkomen rustig. Er is gewoon meer belasting op de opslag. Als dit interval lang is, kunnen we al een beslissing nemen: deze server wel of niet van de kaart verwijderen, of misschien vervangen door een andere.
Dit gaat over het cachingsysteem. Laten we naar de resultaten kijken.
Het lijkt erop dat hier niets ingewikkelds is. Maar deze methode om de cache te beheren leverde ons een trickrate op van ongeveer 98%. Die. van deze 80 verzoeken per seconde bereiken slechts 1600 de opslag, en dit is een volkomen normale belasting, ze verdragen het rustig, we hebben altijd een reserve.
We hebben deze servers in drie van onze DC's geplaatst en drie aanwezigheidspunten ontvangen: Praag, Miami en Hong Kong.
Dat. ze zijn min of meer lokaal gevestigd in elk van onze doelmarkten.
En als leuke bonus hebben we deze caching-proxy, waarop de CPU feitelijk inactief is, omdat deze niet zo nodig is om inhoud aan te bieden. En daar hebben we met behulp van NGINX+ Lua veel utilitaire logica geïmplementeerd.
We kunnen bijvoorbeeld experimenteren met webp of progressieve jpeg (dit zijn effectieve moderne formaten), kijken hoe dit het verkeer beïnvloedt, een aantal beslissingen nemen, het voor bepaalde landen inschakelen, enz.; maak dynamisch formaatwijzigingen of snij foto's direct bij.
Dit is een goed gebruiksscenario wanneer u bijvoorbeeld een mobiele applicatie heeft die foto's weergeeft, en de mobiele applicatie de CPU van de klant niet wil verspillen aan het opvragen van een grote foto en deze vervolgens naar een bepaalde grootte wil aanpassen om deze in de foto te kunnen plaatsen. weergave. We kunnen eenvoudigweg enkele parameters dynamisch opgeven in de voorwaardelijke URL van UPort, en de fotocache zal het formaat van de foto zelf aanpassen. In de regel selecteert het de grootte die we fysiek op de schijf hebben, zo dicht mogelijk bij de gevraagde, en verkoopt deze in specifieke coördinaten.
Overigens hebben we video-opnamen van de afgelopen vijf jaar van de conferentie van ontwikkelaars van systemen met hoge belasting openbaar gemaakt . Kijk, leer, deel en abonneer je .
We kunnen daar ook veel productlogica toevoegen. We kunnen bijvoorbeeld verschillende watermerken toevoegen met behulp van URL-parameters, we kunnen foto's vervagen, vervagen of pixeleren. Dit is wanneer we een foto van een persoon willen laten zien, maar we willen zijn gezicht niet laten zien, dit werkt goed, het is hier allemaal geïmplementeerd.
Wat hebben we gekregen? We hebben drie aanwezigheidspunten, een goede trick rate, en tegelijkertijd hebben we geen inactieve CPU op deze machines. Hij is nu natuurlijk belangrijker geworden dan voorheen. We moeten onszelf sterkere auto's geven, maar het is het waard.
Het betreft hier het retourneren van foto's. Alles is hier vrij duidelijk en duidelijk. Ik denk dat ik Amerika niet heb ontdekt, bijna elk CDN werkt op deze manier.
En hoogstwaarschijnlijk heeft een ervaren luisteraar misschien een vraag: waarom veranderen we niet gewoon alles naar CDN? Het zou ongeveer hetzelfde zijn; alle moderne CDN’s kunnen dit doen. En er zijn een aantal redenen.
De eerste zijn foto's.
Dit is een van de belangrijkste punten van onze infrastructuur, en we hebben er zoveel mogelijk controle over nodig. Als dit een soort oplossing is van een externe leverancier, en je hebt er geen enkele macht over, zal het behoorlijk moeilijk voor je zijn om ermee te leven als je een grote dataset hebt, en als je een hele grote stroom hebt. van gebruikersverzoeken.
Laat me je een voorbeeld geven. Nu kunnen we met onze infrastructuur bijvoorbeeld, in het geval van problemen of ondergrondse schokken, naar de machine gaan en daar relatief gezien wat rommelen. We kunnen de verzameling van enkele statistieken toevoegen die we alleen nodig hebben, we kunnen op de een of andere manier experimenteren, kijken hoe dit de grafieken beïnvloedt, enzovoort. Nu worden er veel statistieken verzameld over dit cachingcluster. En we kijken er af en toe naar en besteden veel tijd aan het onderzoeken van enkele afwijkingen. Als het aan de CDN-kant zou liggen, zou het veel moeilijker te controleren zijn. Of als er bijvoorbeeld een ongeluk gebeurt, weten we wat er is gebeurd, weten we hoe we ermee moeten leven en hoe we het kunnen overwinnen. Dit is de eerste conclusie.
De tweede conclusie is ook nogal historisch, omdat het systeem zich al lange tijd aan het ontwikkelen is en er in verschillende stadia veel verschillende zakelijke vereisten waren, en deze passen niet altijd in het CDN-concept.
En het punt dat volgt uit het vorige is
Dit komt omdat we bij fotocaches veel specifieke logica hebben, die niet altijd op verzoek kan worden toegevoegd. Het is onwaarschijnlijk dat een CDN op uw verzoek een aantal aangepaste dingen aan u zal toevoegen. Bijvoorbeeld het versleutelen van URL's als je niet wilt dat de client iets kan veranderen. Wilt u de URL op de server wijzigen en versleutelen, en stuur dan hier enkele dynamische parameters.
Welke conclusie suggereert dit? In ons geval is CDN geen heel goed alternatief.
En als u in uw geval specifieke zakelijke vereisten heeft, kunt u vrij eenvoudig implementeren wat ik u zelf heb laten zien. En dit werkt perfect met een vergelijkbaar belastingprofiel.
Maar als u een algemene oplossing heeft en de taak niet erg specifiek is, kunt u absoluut veilig een CDN nemen. Of als tijd en middelen voor u belangrijker zijn dan controle.
En moderne CDN's hebben bijna alles waarover ik je nu heb verteld. Met uitzondering van plus of min sommige functies.
Het gaat hier om het weggeven van foto's.
Laten we nu een beetje verder gaan in onze terugblik en het hebben over opslag.
2013 ging voorbij.
Er werden cachingservers toegevoegd en de prestatieproblemen verdwenen. Alles is in orde. De dataset groeit. In 2013 hadden we ongeveer 80 servers aangesloten op opslag, en ongeveer 40 cacheservers in elke DC. Dit is 560 terabyte aan data op elke DC, d.w.z. in totaal ongeveer een petabyte.
En met de groei van de dataset begonnen de bedrijfskosten aanzienlijk te stijgen. Wat betekende dit?
In dit diagram dat is getekend - met een SAN, met machines en caches eraan verbonden - zijn er veel faalpunten. Als we al eerder te maken hadden gehad met het falen van caching-servers, was alles min of meer voorspelbaar en begrijpelijk, maar aan de opslagkant was alles veel erger.
Ten eerste het Storage Area Network (SAN) zelf, dat kan falen.
Ten tweede is het via optica verbonden met de eindmachines. Er kunnen problemen zijn met optische kaarten en bougies.
Natuurlijk zijn er niet zoveel als bij het SAN zelf, maar toch zijn dit ook faalpunten.
Het volgende is de machine zelf, die is verbonden met de opslag. Het kan ook mislukken.
In totaal hebben we drie faalpunten.
Verder is er, naast de storingspunten, sprake van groot onderhoud aan de opslag zelf.
Dit is een complex systeem dat uit meerdere componenten bestaat en systeemingenieurs kunnen er moeite mee hebben om ermee te werken.
En het laatste, belangrijkste punt. Als er op een van deze drie punten een fout optreedt, is de kans kleiner dat we gebruikersgegevens verliezen omdat het bestandssysteem kan crashen.
Laten we zeggen dat ons bestandssysteem kapot is. Ten eerste duurt het herstel lang: bij een grote hoeveelheid gegevens kan het een week duren. En ten tweede zullen we uiteindelijk hoogstwaarschijnlijk eindigen met een aantal onbegrijpelijke bestanden die op de een of andere manier moeten worden gecombineerd tot gebruikersfoto's. En we lopen het risico gegevens te verliezen. Het risico is vrij hoog. En hoe vaker dergelijke situaties voorkomen, en hoe meer problemen er ontstaan in deze hele keten, hoe groter dit risico.
Hier moest iets aan gedaan worden. En we hebben besloten dat we alleen een back-up van de gegevens hoeven te maken. Dit is eigenlijk een voor de hand liggende oplossing en een goede. Wat hebben we gedaan?
Zo zag onze server eruit toen deze eerder op de opslag was aangesloten. Dit is één hoofdgedeelte, het is slechts een blokapparaat dat feitelijk een houder vertegenwoordigt voor externe opslag via optica.
We hebben zojuist een tweede sectie toegevoegd.
We hebben er een tweede opslagplaats naast geplaatst (gelukkig is dat qua geld niet zo duur) en noemden het een back-uppartitie. Het is ook via optica verbonden en bevindt zich op dezelfde machine. Maar we moeten de gegevens op de een of andere manier onderling synchroniseren.
Hier maken we eenvoudigweg een asynchrone wachtrij in de buurt.
Ze heeft het niet erg druk. We weten dat we niet genoeg gegevens hebben. Een wachtrij is slechts een tabel in MySQL waarin regels als "je moet een back-up van deze foto maken" zijn geschreven. Bij elke wijziging of upload kopiëren we van de hoofdpartitie naar de back-up met behulp van een asynchrone of gewoon een soort achtergrondwerker.
En dus hebben we altijd twee consistente secties. Zelfs als een deel van dit systeem uitvalt, kunnen we altijd de hoofdpartitie wijzigen met een back-up, en alles blijft werken.
Maar hierdoor neemt de leeslast enorm toe, want... naast klanten die uit het hoofdgedeelte lezen, omdat ze daar eerst naar de foto kijken (daar is deze recenter) en deze vervolgens zoeken op de back-up, als ze deze niet hebben gevonden (maar NGINX doet dit gewoon), Ons systeem is ook een plus-back-up die nu wordt gelezen vanaf de hoofdpartitie. Het is niet dat dit een knelpunt was, maar ik wilde de belasting in essentie niet zomaar verhogen.
En we hebben een derde schijf toegevoegd, een kleine SSD, en deze een buffer genoemd.
Hoe het nu werkt.
De gebruiker uploadt een foto naar de buffer, waarna er een gebeurtenis in de wachtrij wordt geplaatst die aangeeft dat deze in twee secties moet worden gekopieerd. Het wordt gekopieerd en de foto blijft enige tijd (bijvoorbeeld een dag) in de buffer staan, en wordt pas daarna van daaruit verwijderd. Dit verbetert de gebruikerservaring aanzienlijk, omdat de gebruiker een foto uploadt, in de regel beginnen verzoeken onmiddellijk te volgen, of hijzelf heeft de pagina bijgewerkt en vernieuwd. Maar het hangt allemaal af van de applicatie die de upload maakt.
Of bijvoorbeeld andere mensen aan wie hij zichzelf begon te laten zien, sturen na deze foto onmiddellijk verzoeken. Het staat nog niet in de cache; het eerste verzoek gebeurt heel snel. In wezen hetzelfde als uit een fotocache. Langzame opslag is hier helemaal niet bij betrokken. En als het een dag later wordt opgeschoond, staat het al in de cache op onze caching-laag, of heeft waarschijnlijk niemand het meer nodig. Die. De gebruikerservaring hier is dankzij zulke eenvoudige manipulaties heel goed gegroeid.
Nou ja, en het allerbelangrijkste: we zijn gestopt met het verliezen van gegevens.
Laten we zeggen dat we gestopt zijn mogelijk gegevens verliezen, omdat we deze niet echt kwijt zijn. Maar er dreigde gevaar. We zien dat deze oplossing natuurlijk goed is, maar het lijkt een beetje op het wegnemen van de symptomen van het probleem, in plaats van het volledig op te lossen. En er blijven hier enkele problemen bestaan.
Ten eerste is dit een punt van falen in de vorm van de fysieke host zelf waarop al deze machines draaien; het is niet verdwenen.
Ten tweede zijn er nog steeds problemen met SAN's, het zware onderhoud ervan, enz. blijft bestaan. Het was niet zo dat het een cruciale factor was, maar ik wilde proberen op de een of andere manier zonder te leven.
En we hebben de derde versie gemaakt (in feite de tweede) - de reserveringsversie. Hoe zag het eruit?
Dit is wat het was -
Onze grootste problemen zijn het feit dat dit een fysieke host is.
Ten eerste verwijderen we SAN's omdat we willen experimenteren, we willen alleen lokale harde schijven proberen.
Dit is al 2014-2015, en in die tijd werd de situatie met schijven en hun capaciteit in één host veel beter. We hebben besloten waarom we het niet proberen.
En dan nemen we eenvoudigweg onze back-uppartitie en zetten deze fysiek over naar een aparte machine.
Zo krijgen we dit diagram. We hebben twee auto's die dezelfde datasets opslaan. Ze maken volledige back-ups van elkaar en synchroniseren gegevens via het netwerk via een asynchrone wachtrij in dezelfde MySQL.
Waarom dit goed werkt, is omdat we weinig records hebben. Die. als schrijven vergelijkbaar zou zijn met lezen, zouden we misschien een soort netwerkoverhead en -problemen hebben. Er wordt weinig geschreven, veel gelezen - deze methode werkt goed, d.w.z. We kopiëren zelden foto's tussen deze twee servers.
Hoe werkt dit, als je wat gedetailleerder kijkt.
Uploaden. De balancer selecteert eenvoudig willekeurige hosts met een paar en uploadt ernaar. Tegelijkertijd doet hij uiteraard gezondheidscontroles en zorgt hij ervoor dat de auto niet uitvalt. Die. hij uploadt foto's alleen naar een liveserver en vervolgens via een asynchrone wachtrij wordt alles naar zijn buurman gekopieerd. Met uploaden is alles uiterst eenvoudig.
De taak is iets moeilijker.
Lua heeft ons hier geholpen, omdat het moeilijk kan zijn om dergelijke logica te maken op vanilla NGINX. We doen eerst een verzoek aan de eerste server, kijken of de foto daar staat, want eventueel kan deze geüpload worden naar bijvoorbeeld een buurman, maar is hier nog niet aangekomen. Als de foto er is, is dat goed. Wij geven het direct aan de opdrachtgever en cachen het eventueel.
Als het er niet is, doen we gewoon een verzoek aan onze buurman en krijgen we het gegarandeerd van daar.
Dat. opnieuw kunnen we zeggen: er kunnen problemen zijn met de prestaties, omdat er voortdurend heen en weer wordt gereden - de foto is geüpload, deze is er niet, we doen twee verzoeken in plaats van één, dit zou langzaam moeten werken.
In onze situatie werkt dit niet langzaam.
We verzamelen een heleboel statistieken over dit systeem en het voorwaardelijke slimme percentage van een dergelijk mechanisme is ongeveer 95%. Die. De vertraging van deze back-up is klein en hierdoor zijn we vrijwel gegarandeerd dat we, nadat de foto is geüpload, deze de eerste keer zullen maken en niet twee keer ergens heen hoeven.
Dus wat hebben we nog meer dat echt cool is?
Voorheen hadden we de hoofdback-uppartitie, en we lazen ze opeenvolgend. Die. We zochten altijd eerst op de hoofdpagina en daarna op de back-up. Het was één beweging.
Nu gebruiken we het lezen van twee machines tegelijk. Wij distribueren verzoeken via Round Robin. In een klein percentage van de gevallen doen wij twee verzoeken. Maar over het geheel genomen hebben we nu twee keer zoveel leesvoorraad als voorheen. En de belasting werd aanzienlijk verminderd, zowel op de verzendende machines als rechtstreeks op de opslagmachines, die we destijds ook hadden.
Wat betreft fouttolerantie. Eigenlijk is dit waar we vooral voor gevochten hebben. Met fouttolerantie is hier alles geweldig verlopen.
Eén auto gaat kapot.
Geen probleem! Een systeemingenieur wordt 's nachts misschien niet eens wakker, hij wacht tot de ochtend, er zal niets ergs gebeuren.
Als zelfs als deze machine uitvalt, de wachtrij niet in orde is, zijn er ook geen problemen. Het logboek wordt eenvoudigweg eerst op de levende machine verzameld en vervolgens aan de wachtrij toegevoegd, en vervolgens naar de auto die dat wel zal doen. na enige tijd in bedrijf gaan.
Hetzelfde met onderhoud. We zetten gewoon een van de machines uit, halen hem handmatig uit alle pools, hij ontvangt geen verkeer meer, we doen wat onderhoud, we bewerken iets, en dan zetten we hem weer in gebruik, en deze back-up wordt vrij snel ingehaald. Die. per dag wordt de stilstand van één auto binnen een paar minuten ingehaald. Dit is echt heel weinig. Met fouttolerantie zeg ik nogmaals: alles is hier cool.
Welke conclusies kunnen uit deze afvloeiingsregeling worden getrokken?
We hebben fouttolerantie.
Makkelijk te gebruiken. Omdat de machines lokale harde schijven hebben, is dit vanuit operationeel oogpunt veel handiger voor de engineers die ermee werken.
Wij kregen een dubbele leesvergoeding.
Dit is een zeer goede bonus naast de fouttolerantie.
Maar er zijn ook problemen. Nu hebben we een veel complexere ontwikkeling van sommige functies die hiermee verband houden, omdat het systeem uiteindelijk 100% consistent is geworden.
We moeten bijvoorbeeld bij een of andere achtergrondbaan voortdurend denken: "Op welke server draaien we nu?", "Is hier echt een actuele foto?" enz. Dit is natuurlijk allemaal afgerond, en voor de programmeur die bedrijfslogica schrijft, is het transparant. Maar toch is deze grote complexe laag verschenen. Maar we zijn bereid dit te verdragen in ruil voor het lekkers dat we ervan hebben ontvangen.
En hier ontstaat opnieuw een conflict.
Ik zei in het begin dat het slecht is om alles op lokale harde schijven op te slaan. En nu zeg ik dat we het leuk vonden.
Ja, inderdaad, in de loop van de tijd is de situatie veel veranderd, en nu heeft deze aanpak veel voordelen. Ten eerste krijgen we een veel eenvoudiger bediening.
Ten tweede is het productiever, omdat we niet over deze automatische controllers of verbindingen met schijfplanken beschikken.
Er is daar een enorme hoeveelheid machines, en dit zijn slechts een paar schijven die hier op de machine worden samengevoegd tot een inval.
Maar er zijn ook nadelen.
Dit is ongeveer 1,5 keer duurder dan het gebruik van SAN's, zelfs tegen de huidige prijzen. Daarom hebben we besloten om ons hele grote cluster niet stoutmoedig om te bouwen tot auto's met lokale harde schijven, maar hebben we besloten om een hybride oplossing achterwege te laten.
De helft van onze machines werkt met harde schijven (nou ja, niet de helft - waarschijnlijk 30 procent). En de rest zijn oude auto's die vroeger de eerste reserveringsregeling hadden. We hebben ze eenvoudigweg opnieuw gemonteerd, omdat we geen nieuwe gegevens of iets anders nodig hadden. We hebben de koppelingen eenvoudigweg van één fysieke host naar twee verplaatst.
En we hebben nu een grote voorraad lectuur, en die hebben we uitgebreid. Als we eerder één opslag op één machine monteerden, monteren we er nu bijvoorbeeld vier op één paar. En het werkt prima.
Laten we een korte samenvatting geven van wat we hebben bereikt, waar we voor hebben gevochten en of het ons is gelukt.
Resultaten van
We hebben gebruikers - maar liefst 33 miljoen.
We hebben drie aanwezigheidspunten: Praag, Miami, Hong Kong.
Ze bevatten een cachinglaag, die bestaat uit auto's met snelle lokale schijven (SSD's), waarop eenvoudige machines van NGINX, zijn access.log en Python-daemons draaien, die dit allemaal verwerken en de cache beheren.
Als u dat wenst, als u deel uitmaakt van uw project, als foto's voor u niet zo belangrijk zijn als voor ons, of als de afweging tussen controle en ontwikkelingssnelheid en resourcekosten voor u de andere kant op gaat, kunt u deze veilig vervangen met een CDN doen moderne CDN's het goed.
Vervolgens komt de opslaglaag, waarop we clusters van machineparen hebben die een back-up van elkaar maken. Bestanden worden asynchroon van de ene naar de andere gekopieerd wanneer ze veranderen.
Bovendien werken sommige van deze machines met lokale harde schijven.
Sommige van deze machines zijn verbonden met SAN's.
En aan de ene kant is het handiger in gebruik en iets productiever, aan de andere kant is het handig in termen van plaatsingsdichtheid en prijs per gigabyte.
Dit is zo'n kort overzicht van de architectuur van wat we hebben gekregen en hoe het zich allemaal heeft ontwikkeld.
Nog een paar tips van de kapitein, hele simpele.
Ten eerste: als je plotseling besluit dat je dringend alles in je foto-infrastructuur moet verbeteren, meet dan eerst, want misschien hoeft er niets verbeterd te worden.
Laat me je een voorbeeld geven. We hebben een cluster van machines die foto's uit bijlagen in chats verzenden, en het systeem werkt daar sinds 2009 en niemand heeft er last van. Met iedereen gaat het goed, iedereen vindt alles leuk.
Om te kunnen meten, hangt u eerst een aantal statistieken op, bekijkt u ze en besluit u vervolgens waar u niet tevreden mee bent en wat er verbeterd moet worden. Om dit te meten hebben we een coole tool genaamd Pinba.
Hiermee kunt u zeer gedetailleerde statistieken van NGINX verzamelen voor elke aanvraag- en responscode en de verdeling van de tijden - wat u maar wilt. Het heeft koppelingen met allerlei verschillende analysesystemen, en dan kun je het allemaal prachtig bekijken.
Eerst hebben we het gemeten, daarna hebben we het verbeterd.
Verder. We optimaliseren het lezen met cache en schrijven met sharding, maar dit is een voor de hand liggend punt.
Verder. Als u net begint met het bouwen van uw systeem, is het veel beter om foto's als onveranderlijke bestanden te maken. Omdat je meteen een hele reeks problemen verliest met cache-invalidatie, met hoe de logica de juiste versie van de foto moet vinden, enzovoort.
Laten we zeggen dat je er honderd hebt geüpload en het vervolgens hebt geroteerd, zodat het een fysiek ander bestand is. Die. je hoeft niet na te denken: nu ga ik wat ruimte besparen, naar hetzelfde bestand schrijven, de versie wijzigen. Dit werkt altijd niet goed en veroorzaakt later veel hoofdpijn.
Volgende punt. Over het direct wijzigen van het formaat.
Als gebruikers voorheen een foto uploadden, knipten we meteen een hele reeks formaten uit voor alle gelegenheden, voor verschillende klanten, en ze stonden allemaal op de schijf. Nu hebben wij dit verlaten.
We hebben slechts drie hoofdformaten achtergelaten: klein, middelgroot en groot. We verkleinen eenvoudigweg al het andere vanaf de grootte die achter de maat zit die ons bij Uport is gevraagd, we doen eenvoudigweg de schaalvergroting en geven deze aan de gebruiker.
De CPU van de cachinglaag blijkt hier veel goedkoper te zijn dan wanneer we deze formaten op elke opslag voortdurend opnieuw zouden genereren. Laten we zeggen dat we een nieuwe willen toevoegen, dit zal een maand duren - voer overal een script uit dat dit allemaal netjes zou doen, zonder het cluster te vernietigen. Die. Als je nu de mogelijkheid hebt om te kiezen, is het beter om zo min mogelijk fysieke maten te maken, maar zodat er tenminste een bepaalde verdeling is, bijvoorbeeld drie. En al het andere kan eenvoudigweg worden aangepast met behulp van kant-en-klare modules. Het is nu allemaal heel gemakkelijk en toegankelijk.
En incrementele asynchrone back-up is goed.
Zoals onze praktijk heeft aangetoond, werkt dit schema uitstekend bij het uitgesteld kopiëren van gewijzigde bestanden.
Ook het laatste punt ligt voor de hand. Als uw infrastructuur nu niet zulke problemen heeft, maar er is iets dat kapot kan gaan, dan zal het zeker kapot gaan als het wat meer wordt. Daarom is het beter om hier van tevoren over na te denken en er geen problemen mee te ervaren. Dat is alles wat ik wilde zeggen.
Contacten
»
»
Dit rapport is een transcriptie van een van de beste toespraken op de conferentie van ontwikkelaars van systemen met hoge belasting . Nog minder dan een maand tot de HighLoad++ 2017 conferentie.
Wij hebben het al klaar , het schema wordt nu actief gevormd.
Dit jaar blijven we het onderwerp architecturen en schaalvergroting onderzoeken:
- / Igor Vasiliev
- / Dmitri Egorov
- / Anatoly Plaskovsky
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Filips Delgado
Sommige van deze materialen gebruiken we ook in onze online training over het ontwikkelen van systemen met hoge belasting is een keten van speciaal geselecteerde brieven, artikelen, materialen, video's. Ons leerboek bevat al meer dan 30 unieke materialen. Aansluiten!
Bron: www.habr.com