🥇 S3 arhitektuur: 3 aastat Mail.ru Cloud Storage'i evolutsioonist

Salvestuskoridor Peterburist

Tere kõigile! Mina olen Mons Anderson, platvormi arhitekt Mail.ru Pilve Lahendused, räägin, kuidas me oma S3-salvestust ehitasime, kuidas see töötab, millised lahendused olid edukad ja mida oleks tasunud muuta, kui me oleksime sama projekti nullist alustanud.

Artikkel on koostatud põhjal doklist, @Andmebaasid Meetup Mail.ru Cloud Solutions & Tarantool. Artiklis räägime:

kuidas Mail.ru salvestus oli üles ehitatud, mille peal me S3-salvestust ehitasime;
mida me lisasime, et luua Mail.ru Cloud Storage;
kuidas objekti salvestusmudel töötab ja milliseid samme oleme teinud toodete turule toomiseks;
toodete parendustest: failover ja skaleerimine;
kuidas me shardimist ja reshardimist rakendasime;
ja samuti SSL-sertifikaatidega töötamiseks.

Kui te ei soovi lugeda, siis võite vaadata.

Kuidas Mail.ru salvestus oli üles ehitatud, mille peal me S3-salvestust ehitasime

Meie S3 arendus algas Mail.ru Cloudi salvestusel, seega on esmalt oluline rääkida, kuidas see töötab ja millised on selle võimalused.

Mail.ru pilvesalvestus koosneb serveritest, mis on varustatud ketastega. Keskmiselt on kaasaegne salvestusserver 36 ketast, mille maht on 12–14 terabaiti. Varem olid kettad väiksemad, kuid kolme aasta jooksul on ketaste mahud kasvanud ning täna on see peaaegu pool petabaiti tooreid andmeid.

Erinevate serverite kettad kombineeritakse nn "paarideks" (pair). Paar on üksik failide salvestamise üksus. Sisuliselt on see ketas, mis on kindlasse jaotusse kindlal teel mountitud, kus failid võivad olla salvestatud, tuvastatud hash'ide abil.

Paar on ajalooline nimetus, mis on säilinud tänapäevani, kuigi nüüd ei pea paaris olema tingimata ainult kaks ketast. Ketaste arv võib olla kolm ning võivad olla ka erinevad hübriidsalvestused, näiteks 3/2.

Paarid (pair) on objektide salvestamise üksused

Kõiki paare hoitakse PairDB-s – see on rakendus, mis on koostatud Tarantooli põhjal. Kõik andmebaasid meie salves, alustades esimestest, on Tarantooli alusel, teisi andmebaaside ei kasutata.

PairDB hoiab kõiki paare, nende seisundeid, vaba ruumi, tõrketõkestamise võimalusi, viimaseid vigu. Samuti suudab see ise paare aktiveerida, nende seisundeid ajakohastada, kontrollida, kas need töötavad või mitte. Seega on PairDB nagu ühine ülevaade meie süsteemi kõigi ketaste seisundist.

Pair DB: andmebaas paaride seisunditest

Seerumäest hoitakse faile ning et teada, millisel serveril mis fail asub, on vaja veel üht andmebaasi — FileDB. See salvestab kaardi, mis määrab vastavuse: see fail asub seal ja seal, ning lisaks mõned vajalikud atribuudid.

File DB: koht, kus fail asub

Veel üks oluline lüli on teenus Nylon, andmebaaside kasutamise ruuter. See on ühtne sisenemispunkt, mis võimaldab töötada läbi ühe liidese nii PairDB kui ka FileDBga. See on stateless teenus, see teostab päringute laadimist, mõistab, millisele shardile FileDB-le pöörduda ning teab, millised serverid on aktiivsed ja millised mitte.

Nylon: andmebaaside kasutamise ruuter

Samuti peab sisu hoiustama kuidagi. Selleks on olemas teenus — Streamer. See pakub kahte HTTP meetodit: PUT meetod, et sisu hoiusesse laadida ja GET meetod, et sealt sisu saada. HTTP on üsna populaarne ja mugav protokoll andmete edastamiseks.

Kui me pöördume Streamer’i, siis see pöördub Nylon’i kaudu PairDB poole, selgitab välja, millisele serverile saab faili laadida ja edastab seejärel andmed WebDAVi kaudu sellele serverile.

Sisuliselt on iga storage server — see on nginx pluss kettad, mis on ühendatud kindlate teede kaudu. Me võime Streamer’ist faili hoiusesse laadida, kustutada, ümber nimetada või selle tükisust kontrollida. See tähendab, et see on mugav liides madala taseme взаимодействия jaoks hoiusega.

Streamer: pääsupunkt hoiusesse

Mida me lisasime, et teha S3-hoidla

Nii oleme vaadanud, milline on hoiustamise üldine struktuur hetkel, kui me olime valmis S3-hoidla käivitama. Tänu PUT meetodile saime sinna paigutada suvalist sisu ja meil oli selle andmehalduse identifikaator, mis on hash. Selle identifikaatoriga oli hiljem võimalik tulla ja algne fail tagasi saada. Kuid see ei piisa S3 rakendamiseks. S3 protokollis, peale objektide hoidmisest, on:

metainfo salvestamine — objektide lisaväärtused;
objektide ligipääsu korraldamine HTTP kaudu;
objektide rühmitamine kollektiividesse — bucketeid;
HTTP-S3 Endpoint. S3 korraldab andmed kindlates struktuurides — bucketeid, millest igaühel on faili hoidmiseks pääsupunkt.

Selle loogika rakendamiseks oli vajalik eraldi teenus. Soovisime ka kohe ette näha arhitektuuri teenuse edasiseks kasvuks, tagades lineaarsuse skaleeritavuses.

Esimese komponendid

Demon, mis rakendab S3 API. See on Amazoni standardne S3 API, mis toetab XML-i kasutamist metaandmete jaoks ja võimaldab sisu otse edastada. Me ei pidanud midagi välja mõtlema, kõik on kirjeldatud ja dokumenteeritud.

Samuti paigaldasime teenuse ette Nginxi. Kasutasime seda SSL-i lõpetamiseks, koormuse tasakaalustamiseks ja mõne loogika jaoks Lua's (mõõdikud, logimine ja jälgimine).

S3 metaandmete salvestamiseks valisime ka Tarantooli. Esimeses versioonis läks S3 demon nende metaandmete järele sellesse andmebaasi, sisu ise salvestati suuremasse salvestusse Streameri kaudu.

Nginx + S3 API + metaandmed

Objektide salvestusmudel

Vaadakem, kuidas S3 töötab. Kasutaja võib luua ämber — objektide kogumi. Ämber adresseeritakse hosti nime kaudu ja on teenuse alamdomeen. Ämbri raames saab kasutaja luua objekte. Objekti identifikaatoriks on URL. Objekti sisu on blob, binaarandmete massiiv, mida me salvestaime salvestuses. Objektil on ka atribuute: nimi — see sama URL, ACL (juurdepääsu kontrollimise nimekiri), muud lisandid või vabatahtlikud atribuudid — kõik see salvestatakse metaandmetesse.

Nende andmete normeeritud skeem võib välja näha nii: on projektid, millele kuuluvad ämbrit, millele kuuluvad objektid ja objektid võivad olla koostisosad. Kuna üks viis objektide üleslaadimiseks on osade kaupa, on üleslaadimiseks kaks abita tabelit: uploads ja chunks. Samuti on projektidel juurdepääsuandmed ja arveldamine.

Andmeskeem

Kuna tegime b2b teenuse tasulise juurdepääsuga, oli selles skeemis vajalik arveldamine.
Arvelduse teenuse realiseerime samuti Tarantoolis.

S3 salvestuse täiustamine: sammud tootmisese suunas

Me oleme juba loonud toimiva mudeli, mida saab kasutada: objektid ja metaandmed oli salvestatud, kuid tootmisse minekuks jäi puudu mõned aspektid.

Esiteks on reitingute süsteem. Kui käivitada teenus ilma selleta, võime tipnakkumise ajal ettearvamatult üle koormata mõne süsteemi ala. Reitingu limiit peab toimima järgmiselt: iga S3-päring tuleb konkreetsele hostile, see host on ämber, ja ämber kuulub mingile kliendile. Peame määrama teatud funktsiooni ämberest, mis võimaldaks arvutada reitingu limiidi.

Lisaks peab reitingute süsteem olema piisavalt jõuline, et taluda S3-le tulevat koormust.

Siin kasutasime jälle Tarantooli. Reitingud on 21 instantsist koosnev klaster, instantsid on jagatud gruppidesse, laiali kolme füüsilise sõlme vahel ja ühendatud suureks topoloogiliseks klastriks. Sellele levitatakse automaatselt konfigureerimis muudatused: määratakse reitingu limiidid, vaikeseaded ja konfiguratsioon. Iga ämber teenindatakse rangelt ühe instantsiga. Kui konkreetsele ämbrile saadetakse päring, arvutatakse välja instants, mis vastutab selle ämber eest. Selle sõlme raames toimub päringute praeguse reitingu arvestamine algoritmi abil, mis sarnaneb Token Bucket'ile. Edasi teatab reitingute süsteem, tuginedes praegusele koormuse näitajale ja konkreetse ämber jaoks seatud omadustele, kas päringut saab täita või mitte. Limiteerimise kontroll toimub S3-päringu täitmise kõige varasemas etapis, kaitstes kõiki süsteemi teisi elemente liigse koormuse eest.

Samuti on koormuse all üsna keeruline hakkama saada ilma vahemäluta. S3 eeldab, et sama objektiga pöördutakse mitu korda, see tähendab, et tegemist on kuuma salvestusruumiga. Tavalises olukorras teenindatakse üksik faili päring kogu ahela kaudu: Streamer, FileDB, PairDB, Storage. Kuid failile mitu korda pöördudes optimeerime juurdepääsu sellele sisule kohaliku vahemälu abil.

Vahemälu on mitmekihiline ja rakendatud nginx'i, kohalike SSD ja RAM-kettade abil. Siin me Tarantool'i ei kasutanud, sest objekte on mugavam edastada failisüsteemist, nii saame teha vahemälu kihtimist. Lisaks on meil suured objektid maksimaalse suurusega 32 gigabaiti, samas kui Tarantool'is saab vahemäluda ainult väikesi objekte.

See esimene süsteem, millega me alustasime, omas teatud arvutatud mahutavust, mis oli piisav, et toote uurimiseks ja mõistmiseks ning selle toimimise kinnitamiseks.

Sõjalise süsteemi täiustused: failide üleandmine ja skaaleerimine

Süsteem oli juba kasutuses, kuid alguses jätsime me midagi olulist tähelepanuta — oleks pidanud lisama failide üleandmise ja skaaleerimise.

Meie S3-deemon kogus metaandmeid protokolli Tarantool kaudu. Originaalse andmebaasi asemele paigaldasime Tarantooli, mis toimis metaandmete päringute proxy-suunajana. Rakenduse poolest, mis realiseerib API-d, ei muutunud midagi — see jätkas andmebaasi pöördumist Tarantooli protokolli kaudu, kuid suunaja suutis tagada aktiivse failide üleandmise. See tähendab, et saime kontrollida sõlme kättesaadavust, taluda pause üleminekute ja tõrgete ajal jne. Samas me rakendust ei modifitseerinud.

Rohkem teavet selle kohta, kuidas me shardingut rakendasime

Järgmine küsimus, millega tuli tegeleda — sharding. Süsteem kasvas, objektide arv suurenes ja pidime tagama võimalused edasiseks kasvuks.

Naaseme andmeskeemi juurde: on projektid, on koppad, õigused ja arveldamine. Need on objektid, mis tõenäoliselt ei ületa lähitulevikus ühe instantsi mahutavust ega päringute arvu. Seega ei ole mõtet neid shardeerida, ning me tõstsime need eraldi instantsile, mis jääb mitte-sharditud. See võimaldab projektide ja koppade haldamist konsistendsemalt, kuna on olemas üks mitte-sharditud punkt.

Samuti on skeemis objekte, mis kasvavad lineaarselt — alguses oli neid sadu tuhandeid, nüüd mõõdetakse arvu mitmete miljarditega. Sellised objektid koos oma osadega tuli viia sharded klastrisse.

Me jagasime skeemi, kuid objektid peavad töötama koppadega: objekt kuulub alati konkreetsele koppale, lisaks töötab kopa peal ACL. Seetõttu hoiame iga objekti jaoks, mis on sharditud, iga kopa varukoopia. Lisaks tuleb objektide modifitseerimise ja päringute täitmise ajal arvestada mahtu arveldamiseks, seetõttu on igas shardis arvestid arveldamise jaoks.

Lisaks lisasime veel paar tabelit ja komponenti:

prügikasti, et hävitada vanu projekte, mis kustutatakse või külmutatakse;
taustaprotsesside järjekord, see tähendab, et peamine salvestus võib täita taustaprotsesse, mida on vaja klastris teha;
elutsükli toetamine — mehhanism, mis võimaldab töötada objektidega ja hallata nende elutsüklit.

Kuna osa andmeid transportisime sharde, vajasime shardimisproksi. Oleks olnud võimalik kasutada ruuterit selle ülesande täitmiseks, kuid eraldi shardimisproksi, mis vastutab ainult andmete shardimise eest, võimaldab ruuteril andmeid tervikuna otsida, mitte mõelda shardimisele.

Selgitan eraldi, miks me ei valinud valmis lahendust, vaid soovisime luua kohandatud shardimise funktsiooni.

Vaadakem, kuidas see on üles ehitatud. Meil on 256 saadaval olevat shard'i. Iga baketi jaoks eraldame vahemiku mingi järjepideva funktsiooni abil. See on lihtne — nagu järjepideva funktsiooni abil määrate kuuluvuse ühe shard'i alla, määrate ka algse shard'i ja eraldate vahemiku:

f(bucket, shards) = subset

Seega, kui võtta baket, siis võib öelda, et see ja selle andmed paiknevad alati konkreetses alamkogus kõigist shard'idest. See vähendab ühe baketi mõju teistele ja lihtsustab map-reduce päringute tööd, kui on vaja näiteks koostada baketi objektide loend. Selleks tuleb küsitleda kõiki sharde, kus need objektid asuvad. Kui objektid asuksid kõigis shard'ides, mõjutaks iga loetelu süsteemi tervikuna, aga siin mõjutab see ainult konkreetset alamkogust.

Lisaks kuulub iga objekt konkreetsele baketile, seetõttu, kui me pöördume objekti poole, pöördume objekti poole nime kaudu konkreetse baketi sees. See tähendab, et saame määrata objekti funktsiooni mitte kõigist saadaval olevatest shard'idest, vaid ainult tema baketi alamkogust:

f(object, subset) = shard

Võtame konkreetsed objektid, funktsiooni argumentidena edastame mitte kõik shard'id, vaid ainult tema baketi alamkoguse — ja saame konkreetse shard'i.

Nii et shardimine on rakendatud, on olemas shardimisproksi. Edasi jääb ruuterist ja metainfobaasist minna shardimisproksisse. Näiteks varjuka lubade loomiseks — kui me loome baketi, peab peamine salvestus looma selle baketi esindaja kõigis shard'ides, kus see peab olema.

Kuidas me rakendasime uuesti shardimist

Suurim probleem shardimis on ümbershardimine. Meile oli oluline selle teostamine ilma seisakuteta, kuna süsteem oli juba tootmises. Näitan, kuidas me lahendasime probleemi sarnase ülesande näitel, kus andmete elu migreerimine toimus ühelt projektilt teisele.

Allpool on meie klastriskeem, mis kujunes pärast shardimise rakendamist. Meil on nginx, S3 API, marsruuter, peamine andmebaas projektidega, shardiva proksi ja ise shardid.

Eelnevalt jätsin mainimata, et projekti teatud etapis oli tooteülesanne: "Käivitada veel üks salvestus, Icebox, mis toimiks nagu Hotbox, aga külmade andmete jaoks." Tegelikult on see sama salvestus, kuid erinevate URL-ide ja ilma vahemäludeta.

Iceboxi kasutati vähem kui Hotboxi, seetõttu toimumas ei toimunud mingit shardingut üsna pikalt. Lõpuks otsustasime sellest loobuda ja ühendada Hotbox ja Icebox üheks teenuseks, jagades lihtsalt salvestusklassid.

Salvestustes ei kattunud baketid, neid sai hõlpsasti ühte liita ja ümber liigutada, kuid kliendid kasutasid nii ühte kui teist salvestust, seega oli vaja lahendada probleem, et mitte tekkida seisakut. Ei olnud võimalik lihtsalt välja lülitada ja kopeerida. Raeime migreerimise mitme etapi jooksul.

Esiteks sünkroniseerisime peamised salvestused. Meil oli Tarantool ja saime objekti loomisel teha järgmist:

andmebaas saab baketi loomise päringu, näiteks Hotboxis;
Tarantool kontrollib teises andmebaasis (antud juhul Iceboxis), et sellist baketi ei ole;
kui baket on olemas, teatab andmebaas, et seda ei saa luua, ja see sünkroniseeriti olemasolevana.

Bakettide sünkroniseerimine

Sel salvestusel, mis pidid vastu võtma kõik andmed, lisati projektide ja bakettide jaoks tunnus, mis näitas, kus see objekt paikneb. See võis asuda lokaalselt, st Hotboxis, Iceboxis — siis ei olnud uues salvestuses selle kohta mingeid andmeid, või siis võis see olla migreerimise olekus.

Kui projektil või baketil oli määratud Migrating, siis migreerimise ajal tehti päring algselt uude salvestusse, kuhu andmed pidid minema, ja kui seal ei olnud, siis suunati päringud alternatiivsele salvestusele.

Seejärel suunasime liikluse. Kuna API suutis teenindada nii Iceboxi kui ka Hotboxi päringuid, suudame liikluse suunata ilma seisaku, lihtsalt hostide ümberkolimise ja sobivate kirjeid lisamisega Nginxisse.

Pärast liikluse suunamist saime eemaldada Nginxi ja Iceboxi API.
Seejärel eemaldasime Iceboxi Nginxi ja S3 API — ja kõik toimis:

Edasi käivitasime taustaprotsessi migreerimiseks, mis töötab andmebaasis — läbib kõik projektid ja nende baketid elemendi kaupa, määrab neile staatuse Migrating, kannab andmed üle ja lõpetamisel määrab staatuse Local.

Pärast andmete ülekandmist ei vajanud me enam vana salvestusruumi ning eemaldasime allesjäänud osad vanast süsteemist ning eemaldame koodist ka migreerimise staatuse toe.

Sarnaste põhimõtete alusel viidi läbi ka reharding vana salvestusruumi ja sharded-i vahel:

Märgistasime kõik baketid kui Non-sharded. Kõik päringud suundusid algsesse, mitte sharded salvestusruumi.
Uued baketid loodi kohe staatusega Sharded.
. Üksikuid baketeid võeti, seadistati nende staatuseks Migrating ja andmed kanti üle.

Päringud teenindati järgmiselt:

Lugesime uuest, seejärel vanast.
Loome ainult uuest.
Uuendame kahefoolselt: kui uuest ei ole, kanname vanast uude, seejärel uuendame.

Töö SSL-sertifikaatidega

Eesliideses kasutame Nginxi. Meie puhul ei ole see tavapärane Nginx, vaid OpenResty, Nginx LuaJIT toega.

Veel üks süsteemi osa — töö SSL-sertifikaatidega. S3 salvestusruumis saate määrata oma domeeni konkreetse baketi juurdepääsuks, lihtsalt kasutades CNAME. Kuid tänapäeval ei saa ilma HTTPS-ita: oma domeen tähendab oma SSL-sertifikaati.

Nagu ma juba ütlesin, vastutab Nginx meie jaoks tasakaalustamise ja SSL-i terminaatori eest. Meie puhul ei ole see tavaline Nginx, vaid OpenResty, Nginx LuaJIT toega.

See võimaldas meil üsna lihtsalt õpetada meie Nginx-i jagama juhuslikke sertifikaate. Samuti oli meil vajalik sertifikaate anda dünaamiliselt (ilma vajaduseta neid konfigureerimisfailidesse kirjutada). Kasutasime laiendust ssl_certificate_by_lua, mis võimaldab sertifikaati lugeda juhuslikust allikast otse TLS-käepigistuse ajal. Sertifikaatide hoidmiseks kasutasime ka Tarantool-i: see võimaldab hallata sertifikaate väljastpoolt ja tagab äärmiselt kiire edastamise.

Samuti on rakendatud eraldi deemon, mille ülesanne on regulaarselt uuendada sertifikaate, mis on väljastatud Let’s Encrypt-i kaudu.

Mida ma säilitaksin ja mida teeksin teisiti, kui arendada salvestust uuesti?

Mida oleks pidanud algusest peale kasutama

Shardimine kohe. Üsna palju probleeme põhjustas shardi ümberpaigutamine. Seda on lihtne teha, kuid kui alustada projekte, mis vajavad skaleerimist, on parem kohe võtta sharditud klaster, isegi kui node'e on minimaalselt. Shardimise rakendamine alguses on peaaegu tasuta võrreldes shardimise rakendamisega töötavas süsteemis.

Tarantooliga töötamine läbi koormuse tasakaalustajate. Hetkel ühendame kõik uued andmebaasid kohe koormuse tasakaalustajate kaudu. See võimaldab laiendada funktsionaalsust ja saavutada suuremat tõrkekindlust.

Automaalne tõrke taastumine. Oleksin paigaldanud kõik vajalikud tööriistad automaatse tõrke taastumise jaoks, kuna esimesed ebaõnnestumised käivitamise ajal olid seotud selle puudumisega. Pärast kogemust S3-ga käivitati kõik järgnevad tooted arvesse võttes.

S3 funktsioon „Versioonimine”. Alguses tundus, et see pole väga nõutud funktsionaalsus. Selle võimaluse integreerimine töötava süsteemi arhitektuuri on äärmiselt keeruline.

Eraldiseisev arveldamine. See, kuidas integraator arveldamise meie süsteemi, jäi alguses hästi tööle, kuid hiljem hakkas see segama, oleks parem, kui see oleks täiesti eraldi teenusena.

Mis oli õige otsus

Andmemudel. Ajalugu näitab, et teenuse arengu jooksul ütleme üsna täpselt Amazon'i andmemudeli, seetõttu suudame ellu viia samu funktsioone, mis seal eksisteerivad.

Shardimise skeem. Toetaksin samalaadseid vahemikud shardeid kottide järgi, kuna see võimaldab hästi jaotada päringud erinevatest kottidest suurele klastrile.

Tarantooli kasutamine. Tarantool aitas oluliselt teenuse arendamisel ja muutmisel, suudame lihtsalt andmetega töötada, andmeid transformeerida ja salvestust shardida, samas ei pidanud me rakenduse tasemele tõusma.

See ettekande kuulutati esmakordselt @Andmebaasid Meetup by Mail.ru Cloud Solutions&Tarantool. Vaata video teisi ettekandeid ja jälgi ürituste teadaandeid Telegramis Kubernetesest Mail.ru Groupis.

Samuti saate vaadata minu vana ettekannet S3-st või lugeda minu kolleegi artiklit plokksalvestuse kohta.

Allikas: habr.com