Artem Denisov ( , )
Badoo on maailma suurim tutvumissait. Praeguseks on meil registreeritud umbes 330 miljonit kasutajat üle kogu maailma. Kuid, mis on meie tänase arutelu kontekstis palju tähtsam, on see, et säilitame umbes 3 petabaiti kasutajate fotosid. Igal päeval laevad meie kasutajad üles umbes 3,5 miljonit uut fotot ja lugemise koormus on umbes 80 tuhat päringut sekundis. See on meie tagaplaanile piisavalt suur koormus ja vahel tekivad sellega probleemid.
Räägin sellest süsteemi disainist, mis hoiab ja jagab fotosid, ja annan selle kohta arendaja vaate. Kuidas see on arenenud, kirjeldan ma lühidalt ajaloosus, kus ma peamised etapid märkida, kuid hakkan juba põhjalikumalt rääkima ainult neist lahendustest, mida me praegu kasutame.
Aga nüüd alustame.
Nagu ma juba ütlesin, see on tagasiulatuv ülevaade, ja et seda millegagi alustada, võtame kõige lihtsama näite.
Meil on üldine ülesanne, peame vastu võtma, säilitama ja jagama kasutajate fotosid. Sel viisil on ülesanne üldine, saame kasutada, mida iganes:
- kaasaegset pilvesalvestust,
- karbile lahendust, mida on praegu samuti palju;
- võime seadistada mitu masinat oma andmekeskuses ja paigaldada neile suured kõvakettad ja hoida seal fotosid.
Badoo on ajalooliselt — nii praegu kui ka siis (ajal, mil see alles algas) — elanud oma serverites, meie enda andmekeskustes. Seetõttu oli see variant meie jaoks optimaalseim.
Me lihtsalt võtsime mitu masinat, nimetasime need "photos" ja meil tekkis selline kluster, mis hoiab fotosid. Kuid tundub, et midagi on puudu. Selleks, et kõik see toimiks, on vajalik kuidagi määrata, millistel masinatel millised fotod peavad olema. Ja siin ei ole vaja Ameerikat avastama.
Lisame meie kasutajainfoga salvestusse mingi välja. See on jagamise võti. Meie puhul nimetasime selle place_id-ks, ja see id kohtade määrab, kus hoitakse kasutajate fotosid. Koostame kaardid.
Esimese sammuna saab seda isegi manuaalselt teha — me ütleme, et selle kasutaja foto sellel platvormil maandub sellele serverile. Tänu sellele kaardile teame alati, kui kasutaja foto üles laadib, kuhu see salvestada ja kust see anda.
See on täiesti triviaalne skeem, kuid sellel on piisavalt olulised eelised. Esimene on see, et see on lihtne, nagu ma juba ütlesin, ja teine on see, et sellise lähenemisega saame hõlpsasti horisontaalselt skaleeruda, lihtsalt toimetades uusi seadmeid ja lisades need kaardile. Rohkem ei ole vaja midagi teha.
Nii oligi meil mõnda aega.
See oli umbes 2009. aastal. Toimetasime masinaid, toimetasime...
Ja mingil hetkel hakkasime märkama, et see skeem omab teatud puudusi. Millised puudused?
Esiteks on see piiratud mahutavus. Ühele füüsilisele serverile ei saa me mahutada nii palju kõvakettaid, kui sooviksime. Ja see on aja jooksul ja andmekogumi kasvu tõttu muutunud teatud probleemiks.
Ja teine. See on ebatüüpiline masinakujundus, kuna selliseid masinaid on raske kasutada teiste klastrite puhul, nad on piisavalt spetsiifilised, st nad peavad olema vähese jõudlusega, kuid samas suure kõvakettaga.
See kõik oli 2009. aastal, kuid tegelikult on need nõuded endiselt aktuaalsed. Meil on retrospektiiv, seega oli 2009. aastal kõik sellega halvasti.
Ja viimane punkt — see on hind.
Hind oli siis väga krõbe ja meil oli vaja leida mõni alternatiiv. St me pidime kuidagi paremini kasutama nii andmekeskustes olevat ruumi kui ka füüsilisi servereid, millel kõik see asub. Ja meie süsteemiinsenerid alustasid suurt uuringut, kus nad vaatasid läbi palju erinevaid variante. Nad vaatasid ka klastrifailisüsteeme, nagu PolyCeph ja Lustre. Seal olid probleemid jõudlusega ja piisavalt keeruline töö. Nad loobusid. Proovisime monteerida kogu andmestiku NFS kaudu igale seadmele, et niimoodi mingil moel skaleerida. Lugemine ei läinud ka hästi, proovisime erinevaid lahendusi erinevatelt müüjatelt.
Ja lõpuks otsustasime, et hakkasime kasutama nn Storage Area Networki.
Need on suured SHDed, mis on suunatud suurte andmehulkade salvestamisele. Nad esindavad riiuleid, kus on kettad, mis on ühendatud lõpptoimingumasinatega optika kaudu. Nii et meil on mingi väike masinapool, ja need SHDed, mis on läbipaistvad meie edastamisloogikale, st meie nginxile või kellelegi muule, teenindavad neid piltide päringute järgi.
Sellel lahendusel oli ilmselgeid plusse. Need on SHDed. Need on suunatud fotode salvestamisele. See on odavam, kui me lihtsalt seadistame masinaid kõvaketastega.
Teine pluss.
See, et mahutavus on muutunud palju suuremaks, st me saame palju rohkem salvestust paljuski väiksemas mahus paigutada.
Aga olid ka miinused, mis ilmnesid üsna kiiresti. Kasutajate arvu ja koormuse kasvades hakkasid süsteemis esinema jõudlusprobleemid. Ja probleem on siin piisavalt ilmne — ükskõik milline SHD, mis on ette nähtud paljude piltide salvestamiseks väikeses mahus, kannatab tavaliselt intensiivse lugemise all. See on tegelikult aktuaalne ka mis tahes pilvesalvestuse puhul. Praegu pole meil olemas ideaalset salvestust, mis oleks piiramatu skaleerimisega, kuhu saaks panna kõike, ja mis taluks lugemist väga hästi. Eriti juhuslikku lugemist.
Nagu ka meie piltide puhul, kuna pilte küsitakse ebasoodsalt, ja see mõjutab nende jõudlust tohutult.
Isegi tänaste numbrite põhjal, kui meil on kuskil üle 500 RPS fotode peale masinas, mis on ühendatud salvestusega, tekivad juba probleemid. Ja see oli meile üsna halb, kuna kasutajate arv kasvab ja kõik peaks saama vaid halvemaks. Peame selle kuidagi optimeerima.
Selle optimeerimiseks otsustasime toona ilmselgelt vaadata koormuse profiili — mis üldse toimub, mida tuleb optimeerida.
Ja siin mängib kõik meie kasuks.
Ma ütlesin esimeses slaidis juba: meil on 80 000 päringut sekundis lugemisel, mille puhul on päevas vaid 3,5 miljonit üleslaadimist. See tähendab kolmekordset erinevust. On ilmne, et lugemist tuleb optimeerida ja praktiliselt on selge, kuidas.
On veel üks väike detail. Teenuse spetsiifika on selline, et inimene registreerib end, laadib üles foto, seejärel hakkab aktiivselt vaatama teisi inimesi, küsima neilt meeldimisi, tema profiili näidatakse muudele inimestele. Siis leiab ta paarilise või ei leia, see oleneb, ja mõneks ajaks lõpetab teenuse kasutamise. Just sel hetkel, kui ta teenust kasutab, on tema fotod väga populaarsed — neid vaatavad väga paljud inimesed. Niipea, kui ta lõpetab, kaob ta kiiresti sellistest intensiivsetest näitamistest, nagu varem, ja tema fotosid küsitakse praktiliselt mitte kunagi.
See tähendab, et meil on väga väike kuum dataset. Kuid selle taga on siiski väga palju päringuid. Siit tõukub üsna ilmne lahendus — tuleks lisada cache.
LRU cache lahendab kõik meie probleemid. Mida me teeme?
Lisame oma suure klastriga, kus on salvestust, veel ühe suhteliselt väikese, mida nimetatakse fotokd_cache'iks (photoscache). See on põhimõtteliselt lihtsalt vahemälu proxy.
Kuidas see seestpoolt töötab? Siin on meie kasutaja ja siin on salvestus. Kõik nagu varem. Mida me nende vahele lisame?
See on lihtsalt masin füüsilise kohalikuga kiirdiskiga. Näiteks SSD. Ja sellele diskile salvestatakse mingi kohalik vahemälu.
Kuidas see välja näeb? Kasutaja saadab päringu foto jaoks. NGINX otsib selle kõigepealt kohalikust vahemälust. Kui ei leia, siis teeb lihtsalt proxy_pass meie salvestusele, laadib foto sealt ja annab selle kasutajale.
Kuid see tundub väga lihtne ja pole selge, mis seestpoolt toimub. See toimib umbes nii.
Vahemälu on loogiliselt jagatud kolme kihti. Kui ma ütlen 'kolm kihti', siis ei tähenda see, et seal on mingi keeruline süsteem. Ei, see on lihtsalt kolm kausta failisüsteemis:
- See on puhvri salvestus, kuhu satuvad just proxi kaudu üles laaditud fotod.
- See on kuum vahemälu, kus salvestatakse aktiivselt küsitud fotod.
- Ja külm vahemälu, kuhu fotod järk-järgult tõukatakse kuumalt vahemälult, kui nende päringute arv väheneb.
Kuna see töötaks, peame me kuidagi selle vahemälu haldama, peame fotosid seal ümber paigutama jne. See on samuti väga primitiivne protsess.
Nginx kirjutab iga päringu jaoks RAMDisk'i access.log faili, kus ta näitab teed fotole, mida ta hetkel teenindas (loomulikult suhteline tee), ning seda, millise sektsiooni kaudu see teenindati. Seal võib olla kirjas 'foto 1' ja edasi võib olla kas puhver, kuum vahemälu, külm vahemälu või proxy.
Selle põhjal peame otsustama, kuidas fotoga edasi minna.
Igal masinal töötab väike daemon, mis pidevalt loeb seda logi ja hoiab mälu sees statistikat, kuidas erinevaid fotosid kasutatakse.
Ta lihtsalt kogub seal andmeid, peab arve ja teeb perioodiliselt järgmist. Aktiivselt nõutud fotod, mille järgi tuleb palju päringuid, liigutatakse kuuma vahemällu, kus iganes nad ka ei asu.
Fotod, mida küsitakse harva ja mille nõudlus on vähenenud, tõukab ta järk-järgult kuumast vahemälust külma.
Ja kui meie vahemälus on ruum otsa saanud, hakkame lihtsalt kühveldama külmast vahemälust asju välja ilma eristamiseta. Ja see, muide, töötab väga hästi.
Kuna fotod salvestatakse kohe vahemälus, kasutame me direktiivi proxy_store, ja vahemälu — see on samuti RAMDisk, seega töötab see kasutajale väga kiiresti. See on, mis puudutab ise küberserveri sisemust.
Küsimus on jäänud, kuidas jagada päringud nende serverite vahel.
Oletame, et meil on kakskümmend storage-masinat ja kolm vahemäluserverit (niimoodi on läinud).
Peame kuidagi määrama, millised päringud on milliste fotode jaoks ja kuhu need suunata.
Kõige lihtsam variant on Round Robin. Või peaksime seda juhuslikult tegema?
See, ilmselt, toob endaga kaasa mitmeid puudusi, kuna me kasutame sellises olukorras vahemälu väga ebatõhusalt. Päringud suunatakse mingitele juhuslikele masinatele: seal on see vahemälus, aga naabreid seda enam pole. Ja kui see peaks töötama, siis töötaks see väga halvasti. Isegi väikese arvu masinatega klastris.
Peame kuidagi ühemõtteliselt määrama, millisele serverile suunata millise päringu.
On lihtne viis. Me võtame URL-ist hash'i või meie shardimise võtme hash'i, mis on URL-is, ja jagame selle tervikuna serverite arvuga. Kas see töötab? Jah, see töötab.
See, we have a hundred percent request, for example, for some «example_url» will always land on the server with index «2», and the cache will be utilized as efficiently as possible.
But there's a problem with resharding in such a scheme. Resharding — I mean changing the number of servers.
Let's assume our caching cluster has stopped coping, and we decided to add another machine.
We add it.
Now everything is divided not into three, but into four. Thus, almost all the keys we previously had, almost all the URLs now reside on different servers. The entire cache was invalidated in a moment. All requests flooded our cluster storage, it became overwhelmed, service failed, and users were unhappy. We really don't want that to happen.
This option doesn't suit us either.
So what should we do? We need to somehow use the cache efficiently, continually landing one request on the same server, but still be resistant to resharding. And there's a solution for that; it's not overly complicated. It's called consistent hashing.
How does it look?
We take some function from the sharding key and spread all its values around a circle. That is, at point 0, we have its minimum and maximum values converging. Next, we place all our servers on this same circle approximately like this:
Each server is defined by one point, and the sector that goes to it clockwise, accordingly, is served by this host. When requests come in, we immediately see that, for example, request A — it has this hash — and it is served by server 2. Request B — by server 3. And so on.
What happens in this situation during resharding?
We do not invalidate the entire cache like before, and we do not move all the keys, but we shift each sector by a small distance so that in the freed-up space, so to speak, our sixth server, which we want to add, can fit there, and we add it.
Loomulikult, sellises olukorras võtavad võtmed samuti tuule alla. Kuid nad langevad oluliselt vähem kui varem. Ja me näeme, et meie kaks esimest võtit on jäänud oma serveritesse, ning vahetunud on ainult vahemälu server viimasest võtme jaoks. See töötab piisavalt tõhusalt, ja kui lisate uusi hoste järk-järgult, siis suurt probleemi siin ei ole. Lisate aeglaselt, ootate, kuni vahemälu taas täitub, ja kõik töötab hästi.
Ainuke küsimus on häiretega seoses. Oletame, et meil on mingi masin rikki läinud.
Ja me ei oleks just eriti ärevil, kui sellisel hetkel see kaart uuesti genereerida, vahemälu osaliselt invalideerida ja nii edasi, kui näiteks masin taaskäivitub, kuid peame kuidagi teenindama päringute. Me hoidime lihtsalt igas kohas ühte reserveeritud fotovahemälu, mis toimib asendajana igasuguste masinate jaoks, mis praegu rikki läksid. Ja kui äkki mõni meie serveritest muutub kättesaamatuks, suundub liiklus sinna. Meil ei ole seal, loomulikult, mingit vahemälu, st see on külm, kuid vähemalt saadetakse kasutajate päringud edasi. Kui see on lühike vaheaeg, saame selle täiesti rahulikult üle elada. Lihtsalt koormus storage'ile suureneb. Kui see vaheaeg on pikk, siis saame juba teha otsuse — kas eemaldada see server kaardilt või mitte, või võib-olla asendada see mõnega.
See räägib vahemälu süsteemist. Vaadakem tulemusi.
Tundub, et siin pole midagi keerulist. Kuid selline vahemälu haldamise meetod andis meile ligikaudu 98% eduvõimaluse. St. neist 80 tuhande päringust sekundis jõuab vaid 1600 storage'idesse, mis on täiesti normaalne koormus, nad taluvad seda rahulikult, meil on alati varu.
Me oleme paigutanud need serverid kolme meie andmekeskusesse, ja saime kolm kohaloleku punkti — Praha, Miami ja Hongkong.
Seega on nad enam-vähem kohalikult asetatud iga meie sihtturu lähedale.
Ja meeldiva boonusena saime selle vahemälu proxy, mille protsessor on tegelikult alakoormatud, kuna sisu edastamiseks ei ole see nii vajalik. Me oleme seal NGINX+i ja Lua abil teostanud palju utilitaarset loogikat.
Näiteks saame eksperimenteerida WebP või progressiivse JPEG-iga (need on efektiivsed ja kaasaegsed formaadid), vaadata, kuidas see mõjutab liiklust, teha otsuseid, lubada teatud riikidele jne; teostada dünaamilist resize'i või kärpimist otse piltidele.
See on hea kasutusjuht, kui teil on näiteks mobiilirakendus, mis näitab fotosid, ja mobiilirakendus ei taha kulutada kliendi CPU-d, et küsida suurt pilti ja seejärel seda mingisse suurusesse resize'ida, et see vaatesse suruda. Saame lihtsalt dünaamiliselt URL-i kaudu määrata teatud parameetrid ja pildisülearvustus ise resize'ib pildi. Tavalise praktika kohaselt valib see suuruse, mis meil füüsiliselt on kettal, mis on maksimaalselt lähedane nõutud suurusele, ja vähendab seda konkreetsetes koordinaatides.
Muide, oleme avaldanud viie viimase aasta jooksul arendajatelt kõrge koormusega süsteemide konverentside videod. . Vaadake, uurige, jagage ja tellige meie .
Samuti saame lisada sinna palju tootele äri loogikat. Näiteks saame URL-i parameetrite kaupa lisada erinevaid vesimarke, saame fotoid hägustada, udustada või piksliseerida. See on siis, kui soovime näidata inimese pilti, kuid ei soovi näidata tema nägu, see töötab hästi ning kõik see on siia ellu viidud.
Mida me saime? Saime kolm kohaloleku punkti, hea hitrate'i, ja samal ajal ei jää CPU nendel masinatel seisma. See on nüüd muidugi tähtsam kui varem. Peame endale panema võimsamaid masinaid, aga see tasub end ära.
See, mis puudutab piltide edastamist. Siin on kõik piisavalt selge ja ilmne. Arvan, et ei avastanud Ameerikat, see on nii, nagu enamik moderne CDN-e töötab.
Ja tõenäoliselt võiks kogenud kuulajatel tekkida küsimus: miks mitte lihtsalt vahetada kõik CDN-i peale? Tulemuseks oleks peaaegu sama, kõik kaasaegsed CDN-id oskavad seda teha. Ja siin on mõned põhjused.
Esiteks - need on fotod.
See on meie infrastruktuuri üks võtmeelemente ja meil on nende üle võimalikult palju kontrolli. Kui see on mingi lahendus kolmanda osapoole pakkujalt, ja te ei oma selle üle mingit võimu, siis on teil seda keeruline taluda, kui teil on suur andmestik ja väga suur kasutajate päringute voog.
To give an example. Right now, on our infrastructure, we can, for instance, in case of any issues or underground noises, access the machine, debug there, so to speak. We can add the collection of certain metrics that we need, experiment in some way, and see how it affects the graphs, and so on. A lot of statistics are currently being collected on this caching cluster. We periodically look at it and spend a lot of time investigating certain anomalies. If this were on the CDN side, it would be much harder to control. Or, for instance, if an accident occurs, we know what happened, we know how to live with it and how to deal with it. That’s the first conclusion.
The second conclusion is more historical because the system has been evolving for a long time, and there have been many different business requirements at various stages, and they don't always fit the CDN concept.
And a point that follows from the previous one –
The thing is, we have a lot of specific logic in our photo caches, which is not always possible to add upon request. It's unlikely that any CDN would add custom things at your request. For example, URL encryption, if you don't want the client to change anything. If you want to change a URL on the server and encrypt it, and then send some dynamic parameters here.
What conclusion can we draw? In our case, CDN is not a very good alternative.
But in your case, if you have specific business requirements, you can comfortably implement what I showed you yourself. And with a similar load profile, it will work great.
But if you have a general solution, and the task is not very specific, you can safely use a CDN. Or if time and resources are much more important to you than control.
And modern CDNs have virtually everything I just talked about. With the exception of plus or minus some features.
This is regarding the delivery of photos.
Now let's move a little forward in our retrospective and talk about storage.
The year was 2013.
Süsteemiüksused on juurde tulnud, jõudlusprobleemid on kadunud. Kõik on hästi. Andmestik suureneb. 2013. aastaks oli meil umbes 80 serverit, mis olid ühendatud salvestusseadmetega, ja igas andmekeskuses umbes 40 kiirendajat. See tähendab 560 terabaiti andmeid igas andmekeskuses, kokku umbes petabait.
Ja koos andmestiku kasvuga hakkasid oluliselt suurenema ka käituskulud. Kuidas see väljendus?
Selles skeemis, mis on joonistatud — koos SAN-iga, millele on ühendatud masinad ja vahemälud — on väga palju tõrkeid. Kui me oleme varasemalt suutnud toime tulla vahemäluserverite rikete ja probleemidega, mis on enam-vähem ettearvatavad ja arusaadavad, siis salvestusseadmiste poolel olid asjad palju halvemad.
Esiteks võib ebaõnnestuda ise Storage Area Network (SAN).
Teiseks on see ühendatud optilise kiirusega lõppmasinatega. Võivad olla probleemid optiliste kaartide ja lülititega.
Neid on muidugi vähem kui SAN-is, aga siiski on see ka tõrkekoht.
Seejärel on masin, mis on ühendatud salvestusseadmiega. Ka see võib rikki minna.
Kokku on meil kolm tõrkepunkti.
Lisaks tõrkekohtadele on ka ise salvestusseadmest hooldamine keeruline.
See on keeruline mitmekomponentne süsteem ning süsteemiinseneritel on selle tõttu sageli raskusi.
Ja viimane, kõige olulisem punkt. Kui mõnes neist kolmest punktist juhtub tõrge, on meil võimalus kasutaja andmeid kaotada, kuna failisüsteem võib rikki minna.
Oletame, et meil on failisüsteem katki läinud. Selle taastamine võtab aega — see võib võtta nädala, kui andmeid on palju. Ja teiseks, tõenäoliselt saame me tulemusena hunniku arusaamatuid faile, mida tuleb mingil moel sobitada kasutajate fotodele. Ja me riskime andmete kaotamisega. Risk on piisavalt kõrge. Mida sagedamini sellised olukorrad juhtuvad ja mida rohkem on probleemid kogu selles ahelas, seda kõrgem on see risk.
Sellega tuli midagi ette võtta. Ja me otsustasime, et peame lihtsalt andmed varundama. See on tegelikult ilmne ja hea lahendus. Mida me tegime?
Nii nägi välja meie server, mis oli varem ühendatud salvestusseadmega. See on üks põhiosa, see on lihtsalt plokkseade, mis esindab tegelikult mount'i kaug-salvestusseadmest optilise kiirusega.
Me lihtsalt lisasime teise osa.
Panime teise storage'i kõrvale (õnneks ei ole see rahaliselt nii kallis) ja nimetasime selle backup-osaks. See on samuti ühendatud optika kaudu ja asub samal masinal. Kuid me peame kuidagi need andmed sünkroonima.
Siin loome lihtsalt kõrval asünkroonse järjekorra.
See ei ole väga koormatud. Me teame, et meil on vähe kirjeid. Järjekord on lihtsalt tabel MySQL-is, kuhu kirjutatakse ridu tüüpi "peab selle foto varundama". Igal muudatusel või üleslaadimisel kopeerime peamisest osast backup'i asünkroonselt või lihtsalt mõne taustatöötaja abil.
Ja seega on meil alati kaks kooskõlastatud osa. Isegi kui üks osa sellest süsteemist ebaõnnestub, saame alati vahetada peamise osa backup'iga ning kõik jätkab tööd.
Kuid selle tõttu suureneb lugemise koormus oluliselt, sest peale klientide, kes loevad peamisest osast, kuna nad vaatavad fotot seal (see on ju värskem), otsivad nad siis backup'ist, kui nad ei leia (aga selle teeb juba NGINX), pluss ka meie backup-süsteem nüüd loeb peamisest osast. See ei olnud just kitsaskoht, kuid ma ei soovinud koormust lihtsalt niisama suurendada.
Ja me lisasime kolmanda ketta, mis on väike SSD ja nimetasime selle puhvriks.
Kuidas see nüüd töötab.
Kasutaja laadib foto puhvrisse, seejärel saadetakse üritus, et see tuleb kopeerida kahte ossa. See kopeeritakse ja foto elab mingiaeg (ütleme, ööpäev) puhvrisse, kuni see sealt purgitud saab. See parandab oluliselt kasutajakogemust, kuna kasutaja laadib foto üles ja tavaliselt hakkavad kohe tulema päringud, või värskendab ta ise lehte. Kuid see kõik oleneb rakendusest, mis üleslaadimise sooritab.
Või näiteks teised inimesed, kellele ta hakkas näitama, saadavad kohe pärast seda fotot päringud. Vahemälus seda veel ei ole, esimene päring toimub väga kiiresti. Õieti, see on nagu fotovahemälu. Aeglane storage ei osale selles üldse. Ja kui see ööpäeva pärast purgitakse, siis on see juba kas vahemälus või tõenäoliselt ei ole seda enam kellelegi vaja. Seega on kasutajakogemus siin oluliselt paranenud nende lihtsate manipulatsioonide tõttu.
Ja kõige tähtsam: me lõpetasime andmete kaotamise.
Noh, ütleme nii, et me lõpetasime. jäävaid andmed kaotada, kuna me ei kaotanud neid kuigi palju. Kuid oht oli olemas. Näeme, et selline lahendus on muidugi hea, kuid see sarnaneb veidi probleemi sümptomeid silumisega, selle asemel et seda täielikult lahendada. Ja probleemid on siin mõned jäänud.
Esiteks, see on tõrketegur füüsilise hosti näol, millel kogu see masinavärk töötab, see ei ole kuhugi kadunud.
Teiseks, probleemid SAN-ide osas on jäänud, nende keeruline hooldus jms. See ei olnud just kriitiline tegur, kuid oleks tahtnud proovida elada ka ilma selleta.
Ja me tegime kolmanda versiooni (tõeliselt, teise) — varundamise versiooni. Kuidas see välja nägi?
See, mis oli –
Peamised probleemid on meil selle füüsilise hostiga.
Esiteks, me eemaldame SAN-id, sest tahame katsetada, tahame proovida lihtsalt kohalikke kõvakettaid.
See oli juba 2014-2015 aasta, ja sel ajal on olukord ketaste ja nende mahutavusega ühel hostil muutunud palju paremaks. Otsustasime, et miks mitte proovida.
Ja seejärel võtame lihtsalt meie varukoopia ja kantime selle füüsiliselt eraldi masinale.
Nii saame sellise skeemi. Meil on kaks seadmeid, mis salvestavad sama andmestikku. Need varundavad üksteist täielikult ja sünkroniseerivad andmed üle võrgu asünkroonse järjekorra kaudu samas MySQL-is.
Miks see hästi töötab — sest meil on vähe kirjeid. See tähendab, kui kirje oleks võrdselt lugemisega, võiksime saada mingit võrgu ülekandmise kulu ja probleeme. Kirjeid on vähe, lugemist palju — see meetod töötab hästi, st me kopeerime fotosid nende kahe serveri vahel piisavalt harva.
Kuidas see töötab, kui vaadata veidi detailsemalt.
Upload. Tasakaalustaja valib lihtsalt juhuslikud hostid paarist ja teeb sellele uploadi. Samal ajal teeb ta loomulikult health check'e, jälgides, et masin ei kukuks välja. See tähendab, et ta upload'ib fotosid ainult elavale serverile ja seejärel kopeeritakse see kõik asünkroonse järjekorra kaudu tema naabrile. Upload'iga on kõik äärmiselt lihtne.
Ülesanne on veidi keerulisem.
Siin aitas meid Lua, kuna vanill NGINX-is on raske sellise loogika rakendamine. Esiteks teeme päringu esimesse serverisse, vaatame, kas seal on foto, kuna see võib potentsiaalselt olla üles laetud näiteks naabrile ja siia pole veel jõudnud. Kui foto on olemas, on see hea. Anname selle kohe kliendile ja võimalusel salvestame vahemälu.
Kui seda ei ole, teeme lihtsalt päringu naabrile ja sealt saadame selle garanteeritult edasi.
Seega võib jälle öelda, et võivad olla probleemid jõudlusega, kuna pidevad ringreisid - foto on üles laaditud, siin seda ei ole, teeme kaks päringut ühe asemel, see peaks töötama aeglaselt.
Meie olukorras ei toimi see aeglaselt.
Meil on selle süsteemi kohta kokku kogutud hulk mõõdikuid ja sellise mehhanismi tinglik hitt määr on umbes 95%. See tähendab, et selle varukoopia viivitus on väike ja seetõttu saame peaaegu garanteeritult, pärast seda, kui foto on üles laetud, selle esmakordselt kätte ja ei pea kaks korda minema.
Nii et mis veel me saanud oleme ja mis on väga lahe?
Varem oli meil peamine varukoopia ja lugesime neid järk-järgult. St. otsisime alati esmalt põhjas ja siis varukoopias. See oli üks käik.
Nüüd kasutame me lugemist kahest masinast korraga. Jagame päringud Round Robin'i meetodil. Väikese protsendi juhtudel teeme kaks päringut. Aga nüüd on meil kokku kaks korda rohkem lugemisvaru, kui oli varem. Koormus on tõeliselt vähenenud ning andmete edastamise masinatel ja ka sellel salvestusel, mis meil oli, samuti.
Mis puudutab rikketalo, siis selle nimel me peamiselt kämpisime. Rikketalo osas on kõik sujuvalt välja tulnud.
Üks masin kukub välja.
Ei mingit probleemi! Süsteemi insener ei pea isegi öösel üles ärkama, ootab hommikuni, ei juhtu midagi hullu.
Kui ka selle masina ebaõnnestumise korral järjekord välja kukkus, siis samuti pole probleeme, lihtsalt logi hakkab kogunema esmalt elusoleva masina peale ja seejärel jõuab järjekorda ning siis sinna masinasse, mis tuleb teenistusse mõne aja pärast.
Sama kehtib ka hoolduse kohta. Me lihtsalt lülitame ühe masina välja, tõmbame ta käsitsi kõigist puulidest välja, ta ei saa enam liiklust, teeme teatud hooldustöid, muudame midagi ja pärast seda paneme ta tagasi tööle, ning backup jõuab üsna kiiresti järgi. St, ühe masinakaotuse seisak aeg kompenseeritakse paar minuti jooksul. See on tõesti vähe. Klienditeenindus on, nagu ma juba ütlesin, siin väga paindlik.
Milliseid järeldusi saame teha sellest varukoopiate skeemist?
Oleme saavutanud tõrke taluvuse.
Lihtne kasutamine. Kuna masinatel on kohalikud kõvakettad, on see inseneride jaoks, kes sellega töötavad, palju mugavam.
Oleme saanud kahekordse reservi lugemiseks.
See on tõeliselt hea boonus tõrke taluvuse juurde.
Kuid on ka probleeme. Nüüd on meil palju keerulisem arendada mingeid funktsioone, seoses sellega, kuna süsteem on 100% lõpuks konsistentne.
Peame näiteks mingisugustes taustatöödes pidevalt mõtlema: "Millisel serveril me praegu töötame?", "Kas siin on tõesti värske pilt?" jne. See on kõik loomulikult pakitud kihtidesse, ja arendajale, kes kirjutab äriloogikat, on see läbipaistev. Kuid siiski on see suur keeruline kiht, mis on tekkinud. Oleme valmis sellega leppima kaubaks saadud kasude nimel.
Ja siin tekib jälle teatud konflikt.
Olen alguses öelnud, et kõik lokalisatsioonid kõvakettale hoidmine on halb. Ja nüüd ütlen, et see meeldib meile.
Jah, tõepoolest, aja jooksul on olukord oluliselt muutunud ja nüüd on sellel lähenemisel palju eeliseid. Esiteks saame palju lihtsama kasutamise.
Teiseks, see on tulemuslikum, sest meil ei ole neid automaatseid kontrollerid, mis ühendatakse kettakappidega.
Seal on tohutu masin, kuid need on lihtsalt mõned kettad, mis on konkreetselt siin masinas RAID-ina kokku pandud.
Kuid on ka miinuseid.
See maksab ligikaudu 1,5 korda rohkem kui SANide kasutamine isegi tänapäeva hindade järgi. Seetõttu otsustasime, et ei muuda oma suurt klastri täielikult kohalikeks kõvaketaste masinateks ja otsustasime jääda hübriidlahendusele.
Pool masinatest töötavad meil kõvakettaga (noh, mitte pool – umbes 30 protsenti vist). Ja ülejäänud osa on vanad masinad, millel oli varem esimene varundamise skeem. Lihtsalt renoveerisime need, kuna me ei vaja uusi andmeid ega midagi muud, lihtsalt kolisime mähised ühe füüsilise hosti pealt kahele.
Ja meil on suur lugemisreserv ja me oleme suurendanud. Kui varem mountisime ühe masina peale ühe salvestuse, siis nüüd mountime ühe paari peale neli, näiteks. Ja see töötab normaalselt.
Kokkuvõtteks, vaatame lühidalt, mis meil on, mille nimel me võitlesime ja kas see läks korda.
Summary
Meil on kasutajaid – lausa 33 miljonit.
Meil on kolm kohaloleku punkti – Praha, Miami, Hongkong.
Seal on vahemälu kiht, mis koosneb masinatest kiiresti lokaliseeritud ketaste (SSD) peal, kus töötab lihtne struktuur NGINX-ist, selle access.log'ist ja Python'i deemonitest, mis kõike seda töötlevad ja haldavad.
Soovi korral võite oma projektis, kui pildid ei ole teile nii kriitilised kui meile, või kui teie jaoks on tasakaalu kontroll ja arenduse kiirus ning ressursside kulud teises suunas, siis võite rahulikult asendada selle CDN-iga, modernsed CDN-id teevad seda hästi.
Edasi tuleb salvestuskiht, kus meil on paaride klastrid masinatest, mis teineteist varundavad, sünkroonselt kopeerivad failid üksteisele igal muudatusel.
Selle juures töötavad osad neist masinatest kohalike kõvaketastega.
Osad neist masinatest on ühendatud SAN-idega.
Ühelt poolt on see käitamisel mugavam ja veidi efektiivsem, teiselt poolt on see mugav paigutuse tiheduse ja gigabaiti hindade poolest.
See on lühike ülevaade arhitektuurist, mida oleme saanud ja kuidas see kõik arenes.
Veel mõned nõuanded kaptenilt, täiesti lihtsad.
Esiteks, kui otsustate, et teil on hädasti vaja kogu oma fotoinfrastruktuuri parandada, mõõtke kõigepealt, sest võib-olla pole midagi parandada.
Tõin näiteks. Meil on masinate klaster, mis edastab pilte chat'ide attachment'ist, ja seal töötab endiselt skeem 2009. aastast, ning keegi ei kannata selle all. Kõigil on hästi, kõik on rahul.
Ette mõõta, riputage kõigepealt üles hunnik mõõdikuid, vaadake neid ning siis otsustage, millega te rahul ei ole ja mida tuleb parandada. Selle mõõtmiseks on meil suurepärane tööriist nimega Pinba.
See võimaldab koguda NGINX-i kaudu väga detailselt statistikat iga päringu ja vastuse koodide kohta, samuti ajade jaotuse kohta – kõike, mida soovite. Sellel on sidemed erinevate analüüsisüsteemidega, nii et saate hiljem kõik ilusasti vaadata.
Esiteks mõõtsime – pärast seda parandasime.
Jätkates. Optimeerime lugemise jaoks vahemälu, kirjutamise – shardingu jaoks, kuid see on ilmselge punkt.
Jätkates. Kui te alles hakkate oma süsteemi ehitama, siis on palju parem teha fotosid immutatiivsete failidena. Kuna te kaotate kohe terve klass probleeme vahemälu kehtetuks muutumisega, sellega, kuidas loogika peaks leidma õige versiooni fotost jne.
Oletame, et laadisite üles sada, siis keerutasite selle ümber, tehke nii, et see oleks füüsiliselt erinev fail. St. ei ole vaja mõelda: nüüd ma säästan natuke ruumi, kirjutan sama faili, muudan versiooni. See ei tööta kunagi hästi, sellega on hiljem palju peavalu.
Järgmine punkt. Resize reaalajas.
Varem, kui kasutajad laadisid üles foto, lõikasime kohe välja palju erinevaid suurusi igaks juhuks, erinevatele klientidele, ja need kõik olid kettale. Nüüd oleme sellest loobunud.
Oleme jätnud vaid kolm peamist suurust: väike, keskmine ja suur. Kõik muu me lihtsalt allapoole skaleerime selle suuruse põhjal, mida küsiti Uport-is, lihtsalt teeme allapoole skaleerimise ja anname selle kasutajale.
Vahemälu kihtide CPU on siin tunduvalt odavam, kui me pidevalt käivitaksime need suurused igas salvestuses ümber. Oletame, et soovime lisada uue, see on kuu töö – käivitada igal pool skript, mis kõik selle korralikult teeks, ilma et klastrisse halb läheks. St. kui on võimalus praegu valida, tehke vähem füüsilisi suurusi, kuid et oleks mingi jaotus, ütleme kolm. Ja kõik muu lihtsalt skaleerida reaalajas olemasolevate moodulite abil. See on praegu kõik väga lihtne ja kergesti kättesaadav.
Aga inkrementaalne asünkroonne varukoopia on hea.
Kuna meie praktika on näidanud, töötab selline skeem suurepäraselt muudetud failide viivitusega kopeerimisega.
Viimased punkt on samuti ilmne. Kui teie infrastruktuuris pole praegu selliseid probleeme, kuid on midagi, mis võib tõrkuda, juhtub see kindlasti siis, kui koormus veidi suureneb. Seetõttu on parem mõelda sellele ette ning mitte kogeda probleeme. Minu poolest kõik.
Kontaktid
»
»
See ettekanne on ühte parimatest esinemistest kõrge koormusega süsteemide arendajate konverentsil. . HighLoad++ 2017 konverentsini on vähem kui kuu aega.
Meil on juba valmis , praegu koostatakse aktiivselt ajakava.
Sel aastal jätkame arhitektuuride ja skaleerimise teema uurimist:
- / Игорь Васильев
- / Дмитрий Егоров
- / Анатолий Пласковский
- / Роман Шеховцов, Алексей Громатчиков
- / Филипп Дельгядо
Samuti kasutatakse mõningaid neist materjalidest meie online-kursuses kõrge koormusega süsteemide arendamiseks. — see on spetsiaalselt koostatud kirjade, artiklite, materjalide, videotega koosnevad sõnumid. Meie õpik sisaldab juba üle 30 ainulaadse materjali. Liituge!
Allikas: habr.com
