nga St-Pete
Përshëndetje të gjithëve! Unë jam Mons Anderson, arkitekt i platformës , do të flas se si ndërtuam ruajtjen tonë S3, si funksionon, cilat zgjidhje u dëshmuan të suksesshme dhe cilat do të ishin ndryshuar nëse do ta fillonim një projekt të tillë nga e para tani.
Artikulli është përgatitur në bazë të një raporti në nga Mail.ru Cloud Solutions & Tarantool. Në artikull do të flasim për:
- si ishte e organizuar ruajtja e Mail.ru, mbi të cilën ndërtuam ruajtjen S3;
- çfarë shtuam për ta bërë Mail.ru Cloud Storage;
- si funksionon modeli i objekteve të ruajtjes dhe cilat hapa u bënë për të dalë në prodhim;
- për përmirësimet e sistemit të prodhimit: pavarsitë dhe shkallëzimi;
- si e realizuam sharding dhe reshards;
- si dhe për punën me certifikatat SSL.
Nëse nuk dëshironi të lexoni, mund të .
Si ishte e organizuar ruajtja e Mail.ru, mbi të cilën ndërtuam ruajtjen S3
Zhvillimi i S3 tonë filloi mbi ruajtjen e Cloud Mail.ru, prandaj është e rëndësishme të tregojmë se si është organizuar dhe çfarë mund të bëjë.
Ruajtja e Cloud Mail.ru përbëhet nga serverë me disqe. Mesatarisht, një server storage modern përbëhet nga 36 disqe me 12-14 terabajt. Më parë disqet ishin më të vogla, por në tri vitet e fundit kapacitetet e disqeve janë rritur dhe sot kjo është pothuajse gjysmë petabajti të dhëna të papërpunuara.
Disqet nga serverët e ndryshëm të ruajtjes kombinohen në ato që quhen 'çiftet' (pair). Një çift është një njësia e vetme e ruajtjes së skedarëve. Në thelb, kjo është një disk i montuar në një pjesë të caktuar në një rrugë të caktuar, ku mund të jenë skedarë që identifikohen me hash-et.
Ăifti Ă«shtĂ« njĂ« emĂ«r historik, Ă«shtĂ« ruajtur deri sot, megjithatĂ« tani nĂ« njĂ« çift nuk Ă«shtĂ« e nevojshme tĂ« ketĂ« vetĂ«m dy disqe. Mund tĂ« ketĂ« tre disqe, si dhe mund tĂ« ketĂ« ruajtje hibrid, pĂ«r shembull 3/2.
Ăiftet (pair) janĂ« njĂ«sitĂ« e ruajtjes sĂ« objekteve
TĂ« gjitha çifti ruajnĂ« nĂ« PairDB â kjo Ă«shtĂ« njĂ« aplikacion i bazuar nĂ« Tarantool. TĂ« gjitha bazat nĂ« ruajtjen tonĂ«, duke filluar nga tĂ« parat, janĂ« Tarantool, nuk pĂ«rdorim baza tĂ« tjera.
PairDB ruan të gjitha çiftet, gjendjet e tyre, hapësirën e lirë, mundësitë e dështimit, gabimet më të fundit. Ajo gjithashtu mund të vizitojë çiftet, për të përditësuar gjendjen e tyre, për të kontrolluar nëse ato funksionojnë ose jo. Pra, PairDB është një pamje e përgjithshme e gjendjes së të gjitha disqeve të sistemit tonë.
Pair DB: databaza me gjendjen e çifteve
Në pika ruhen skedarët dhe, për të ditur se në cilën pikë ndodhet cili skedar, ne kemi nevojë për një bazë tjetër - FileDB. Ajo ruan mapimin, përcaktimin e përputhjes: skedari i tillë ruhet në pikën e tillë, si dhe një sasi të vogël atributesh të nevojshme.
File DB: vendi ku ruhen skedarët
Një lidhje e rëndësishme është shërbimi Nylon, ruter për të punuar me bazat e të dhënave. Ai është pika e vetme e hyrjes, e cila lejon të punojmë përmes një ndërfaqeje të vetme si me PairDB ashtu edhe me FileDB. Ky është një shërbim stateless, ai ekzekuton balancimin e kërkesave, kupton se në cilin shard FileDB duhet të shkojë, di se cilat pika janë aktive dhe cilat jo.
Nylon: ruter për të punuar me bazat e të dhënave
Po ashtu, në depo kërkohet një mënyrë për të vendosur përmbajtje. Për këtë ka shërbimin - Streamer. Ai ofron dy metoda HTTP: metoda PUT, për të ngarkuar përmbajtjen në depo, dhe metoda GET, për ta marrë atë. HTTP është një protokoll mjaft popullor dhe i përshtatshëm për transferimin e të dhënave.
Kur ne i qasemi Streamer-it, ai nëpërmjet Nylon i qaset PairDB, zbardh se në cilën pikë mund të ngarkohet skedari, pas së cilës kalon të dhënat përmes WebDAV në këtë pikë.
Në thelb, çdo server storage është nginx plus disqet që janë të montuar në rrugët e caktuara. Ne mund të ngarkojmë një skedar në depo nga Streamer, ta fshijmë atë, ta riformatojmë ose ta kontrollojmë për integritet. Pra, kjo është një ndërfaqe e përshtatshme për ndërveprimin me nivel të ulët me depo.
Streamer: pika e hyrjes në depo
ĂfarĂ« kemi shtuar pĂ«r tĂ« krijuar depo S3
Pra, ne shqyrtuam strukturën e përgjithshme bazë të depozitës në momentin kur filluam të aktivizojmë depo S3. Me metodën PUT mund të vendosnim përmbajtje të rastit atje dhe të merrnim si identifikues i këtyre të dhënave hash-in. Me këtë identifikues më pas mund të shkonim dhe të merrnim skedarin e origjinës. Por kjo nuk mjafton për zbatimin e S3. Në protokollin S3, përveç ruajtjes së vet objekteve, ka:
- ruajtja e metadatanave - karakteristika shtesë të objekteve;
- organizimi i aksesit në objekte përmes HTTP;
- grupimi i objekteve në koleksione - buckets;
- HTTP-S3 Endpoint. S3 organizon të dhënat në struktura të caktuara - buckets, secili prej të cilëve ofron një pikë hyrjeje për ruajtjen e skedarëve.
Për të realizuar këtë logjikë, ishte e nevojshme një shërbim i veçantë. Gjithashtu, dëshirohej që të parashikohet struktura për rritjen e mëtejshme të shërbimit me shkallëzim linear.
Komponentët e parë
Demon që realizon API-në S3. Ky është API standard S3 i Amazon, i cili mbështet punën përmes XML për metadatën dhe lejon transferimin e drejtpërdrejtë të përmbajtjes. Nuk na duhej të shpiknim diçka, gjithçka është e përshkruar dhe e dokumentuar.
Gjithashtu, para shërbimit vendosëm Nginx. E përdorëm për terminimin e SSL, balancimin e ngarkesës, si dhe për disa logjikë në Lua (metrika, regjistrimi dhe ndjekja).
Për ruajtjen e metadatatëve S3, zgjodhëm gjithashtu Tarantool. Në versionin e parë, për metadatat demon S3 shkonte në këtë bazë, ndërsa përmbajtja vetë ruhej në një depo të madhe përmes Streamer.
Nginx + API S3 + metadatatë
Modeli objektor i ruajtjes
Le tĂ« shohim se si funksionon S3. PĂ«rdoruesi mund tĂ« krijojĂ« njĂ« enĂ« â njĂ« koleksion objektesh. EnĂ« adresohet me emrin e hostit dhe Ă«shtĂ« njĂ« subdomain i shĂ«rbimit. Brenda enĂ«s, pĂ«rdoruesi mund tĂ« krijojĂ« objekte. Identifikuesi i objektit do tĂ« jetĂ« URL. PĂ«rmbajtja e objektit Ă«shtĂ« njĂ« blob, njĂ« array tĂ« dhĂ«nash binare, tĂ« cilat ne do t'i ruajmĂ« nĂ« depo. Gjithashtu, objekti ka atribute: emri â ai URL, ACL (lista e kontrollit tĂ« aksesit), atribute tĂ« tjera shtesĂ« ose tĂ« rastĂ«sishme â e gjithĂ« kjo ruhet nĂ« metadatĂ«n.
Schema e normalizuar e këtyre të dhënave mund të duket kështu: ka projekte që i përkasin enëve, të cilat i përkasin objekteve dhe objektet mund të jenë të përbëra. Duke qenë se një nga mënyrat për të ngarkuar objektin është përmes pjesëve, për ngarkimin ka dy tabela ndihmëse: uploads dhe chunks. Gjithashtu, projektet kanë të dhëna të aksesit dhe faturimit.
Schema e të dhënave
Duke qenë se ne po bënim një shërbim b2b me akses të paguar, në këtë skemë ishte e nevojshme faturimi.
Shërbimi i faturimit e implementuam gjithashtu në Tarantool.
Përmirësimet e depo S3: hapat drejt prodhimit
Ne tashmë kemi realizuar një model funksional që mund të përdoret: objektet dhe metadatët ishin ruajtur, por për të dalë në prodhim na mungonin disa momente.
Në radhë të parë, sistemi i kufizimit të normave. Nëse fillojmë sistemin pa të, mund të mbingarkohet ndonjë pjesë e sistemit në rast të një ngarkese maksimale. Kufizimi i normës duhet të funksionojë kështu: çdo kërkesë S3 vjen në një host të caktuar, ky host është identifikuesi i kovës, dhe kjo kova i përket ndonjë klienti. Na nevojitet të përcaktojmë një funksion të caktuar nga kova, i cili do të lejojë llogaritjen e kufizimit të normës.
Për më tepër, sistemi i kufizimit të normave duhet të jetë mjaft efikas për të përballuar ngarkesën që vjen në S3.
KĂ«tu e pĂ«rdorĂ«m pĂ«rsĂ«ri Tarantool. Kufizimet e normĂ«s janĂ« njĂ« klaster prej 21 instancash, instancat janĂ« tĂ« ndara nĂ« grupe, tĂ« shpĂ«rndara nĂ« tri nyje fizike dhe tĂ« bashkuara nĂ« njĂ« klaster tĂ« madh topologjik. Ndryshimet nĂ« konfigurim shpĂ«rndahen automatikisht nĂ«pĂ«r tĂ«: vendosen kufizimet e normave, parametrat standard dhe konfigurimi. Ădo kovĂ« trajtohet vetĂ«m nga njĂ« instancĂ«. Kur njĂ« kĂ«rkesĂ« vjen pĂ«r njĂ« kova tĂ« caktuar, llogaritet instanca qĂ« Ă«shtĂ« pĂ«rgjegjĂ«se pĂ«r atĂ« kova. Brenda kĂ«saj nyjeje, llogaritet normĂ«n aktuale tĂ« hyrjeve sipas njĂ« algoritmi tĂ« ngjashĂ«m me Token Bucket. MĂ« pas, sistemi i kufizimit tĂ« normave, bazuar nĂ« nivelet aktuale tĂ« ngarkesĂ«s dhe karakteristikave tĂ« vendosura pĂ«r atĂ« kova tĂ« caktuar, thotĂ« nĂ«se mund tĂ« ekzektohet kĂ«rkesa apo jo. Kontrolli i kufizimeve bĂ«het nĂ« fazĂ«n mĂ« tĂ« hershme tĂ« realizimit tĂ« kĂ«rkesĂ«s S3, duke mbrojtur tĂ« gjitha elementet e tjera tĂ« sistemit nga mbingarkesa e tepĂ«rt.
Gjithashtu, nën ngarkesë është mjaft e vështirë të kalosh pa cache. Në S3 nënkuptohet qasje e shumëfishtë në objektet e njëjta, domethënë kjo është një ruajtje e nxehtë. Në rastin normal, qasja në një skedë të vetme shërbehet nga e gjithë zinxhirin: Streamer, FileDB, PairDB, Storage. Por kur ka qasje të shumëfishta në skedën, ne optimizojmë qasjen në këtë përmbajtje përmes një cache lokale.
Cache është me disa nivele dhe realizohet me anë të nginx, disqe lokale, SSD dhe RAM. Këtu nuk përdorëm Tarantool, sepse është më e lehtë të dorëzosh objektet nga sistemi i skedarëve, kështu mund të realizojmë një strukture të cache. Për më tepër, kemi objekte të mëdha me një madhësi maksimale prej 32 gigabajt, dhe në Tarantool mund të ruajmë vetëm objekte të vogla.
Ky ishte sistemi i parë me të cilin u lançuam, i cili kishte një kapacitet të llogaritur, i mjaftueshëm për të eksploruar dhe kuptuar produktin, se si do të funksiononte.
Përmirësimet e sistemit të luftës: dështimi dhe shkallëzimi
Sistemi ishte tashmĂ« nĂ« pĂ«rdorim, por nĂ« fillim humbĂ«m disa detaje â duhej tĂ« shtonim dĂ«shtimin dhe shkallĂ«zimin.
DemonĂ«t tanĂ« S3 merrnin tĂ« dhĂ«nat nga metadata pĂ«rmes protokollit Tarantool. NĂ« vend tĂ« bazĂ«s origjinale, vendosĂ«m Tarantool, i cili shĂ«rbente si njĂ« router proxy pĂ«r kĂ«rkesat e metadatas. Nga kĂ«ndvĂ«shtrimi i aplikacionit qĂ« implementon API-nĂ«, asgjĂ« nuk ndryshoi â ai vazhdoi tĂ« lidhet me bazĂ«n pĂ«rmes protokollit Tarantool, por routeri doli t'i ofronte dĂ«shtim aktiv. Pra, ishim nĂ« gjendje tĂ« kontrollonim disponueshmĂ«rinĂ« e nodit, tĂ« bĂ«nim njĂ« shkĂ«putje gjatĂ« kalimeve dhe dĂ«shtimeve e kĂ«shtu me radhĂ«. NdĂ«rkohĂ«, vetĂ« aplikacioni nuk e modifikuam.
Më shumë mbi mënyrën si e implementuam shardingun
Pyetja tjetër për të cilën duhej të shqetësoheshim ishte shardingu. Sistema po rritej, numri i objekteve po rritej dhe duhej të sigurohej mundësitë për rritje të mëtejshme.
Le të kthehemi në skemën e të dhënave: ka projekte, ka kube, kredite dhe faturim. Këto janë objekte që me shumë mundësi nuk do të rriten në të ardhmen afatshkurtër as në volum dhe as në kërkesa. Pra, nuk ka kuptim t'i shardojmë, dhe i kemi sjellë ato në një instancë të veçantë, e cila do të mbetet e pa sharduar. Kjo lejon një menaxhim më të konsoliduar të projekteve dhe kubeve, pasi ka një pikë të vetme të pa sharduar.
Gjithashtu, nĂ« skemĂ« ka objekte qĂ« rriten nĂ« mĂ«nyrĂ« lineare â fillimisht kishim qindra mijĂ«ra, tani numri i tyre matet nĂ« disa miliarda. KĂ«to objekte, sĂ« bashku me pjesĂ«t e tyre, duhej tĂ« ishin tĂ« vendosura nĂ« njĂ« klasĂ« tĂ« sharduar.
Ne e ndamë skemën, por objektet duhen të punojnë me kube: një objekt gjithmonë i takon një kube të caktuar, për më tepër, mbi kubin funksionon ACL. Prandaj, për çdo shard me objekte, mbajmë një kopje hije të çdo kube. Përveç kësaj, gjatë modifikimit të objekteve dhe ekzekutimit të kërkesave, duhet të llogarisim volumet për kryerjen e faturimit, ndaj në çdo shard ka numërues për faturimin.
Gjithashtu, kemi shtuar disa tabela dhe komponentë të tjerë:
- koshin, për shkatërrimin e projekteve të vjetra që fshihen ose ngrihen;
- një radhë për detyrat në sfond, domethënë, ruajtja kryesore mund të kryejë detyrat në sfond që nevojiten për të bërë në klaster;
- mbështetje për lifecycle - mekanizmi që lejon punë me objekte, menaxhimin e ciklit të jetës së tyre.
Pasi që një pjesë e të dhënave e shmangëm në sharda, nevoja për një proxy sharding u shfaq. Do të ishte e mundur të ripërdorej routeri për këtë rol, por një proxy sharding e ndarë, e cila është përgjegjëse vetëm për sharding të të dhënave, lejon që routeri të shkojë për të dhënat në tërësi, pa menduar për sharding.
Më pas do të flas për arsyen se pse ne nuk morëm një zgjidhje të gatshme, por donim të krijonim një funksion të personalizuar të sharding.
Le të shohim si është e organizuar. Ne kemi 256 sharda të disponueshme. Për çdo bucket ndalim një gamë duke përdorur një funksion konsistent. Kjo është e thjeshtë - siç e përcaktoni përkatësinë në një shard duke përdorur një funksion konsistent, ju përcaktoni shardin fillestar dhe ndani gamën:
f(bucket, shards) = nëngrup
Kështu që nëse marrim një bucket, mund të themi se ai dhe të dhënat e tij do të jenë gjithmonë në një nëngrup të caktuar nga të gjitha shardat. Kjo ndihmon në reduktimin e ndikimit të disa buckets mbi të tjerët dhe thjeshton punën e kërkesave map-reduce, kur është e nevojshme, për shembull, të bëni një listim të objekteve të bucket-it. Për këtë, është e nevojshme të anketoni të gjitha shardat ku këto objekte ruhen. Nëse objektet do të ishin në të gjitha shardat, çdo listim do të godiste sistemin në tërësi, por këtu ai godet vetëm një nëngrup të caktuar.
Më pas - çdo objekt i përket një bucket-i të caktuar, prandaj kur ne i qasemi një objekti, ne i qasemi atij objekti sipas emrit në bucket-in e caktuar. Domethënë, ne mund të përcaktojmë një funksion për objektin jo nga të gjitha gamat e disponueshme të shardave, por vetëm nga nëngrupi i bucket-it të tij:
f(object, subset) = shard
Ne marrim një objekt të caktuar, në cilësimet e funksionit i kalojmë atje jo të gjithë shardat, por nëngrupin e bucket-it të tij - dhe marrim shardin specifik.
Pra, sharding është realizuar, ka një proxy sharding. Tani mbetet që nga routeri dhe baza me metadat të shkojë në proxy sharding. Për shembull, për krijimin e objekteve të kopjave të ashtuquajtura - kur krijojmë një bucket, ruajtja kryesore duhet të krijojë një përfaqësues të këtij bucket-i në të gjitha shardat ku ai duhet të jetë prezent.
Si e realizuam reshuffling
Problemi më i madh i sharding-ut është resharding. Ishte e rëndësishme për ne ta bënim atë pa ndalesa, pasi sistemi tashmë ishte në prodhim. Do të tregoj se si e zgjidhëm këtë problem duke marrë si shembull një detyrë të ngjashme me migrimin e drejtpërdrejt të të dhënave nga një projekt në një tjetër.
Më poshtë është skema e klasterit tonë, e cila u krijua pas implementimit të sharding-ut. Kemi nginx, S3 API, router, bazën primare me projektet, proxy-në sharding dhe pikërisht shard-et.
Më sipër kam lënë jashtë një detaj, që në një fazë të caktuar të projektit kishte një detyrë produkti: "Të nisnim gjithashtu një ruajtje, Icebox, si Hotbox, por vetëm për të dhëna të ftohta". Në thelb, ajo është një ruajtje e ngjashme, por me URL të tjera dhe pa cache.
Icebox-u u përdor më pak se Hotbox, prandaj ai kaloi një kohë të gjatë pa ndonjë sharding. Në fund të fundit, ne vendosëm të heqim dorë nga ai dhe të bashkojmë Hotbox-in dhe Icebox-in në një shërbim të vetëm, thjesht duke ndarë klasat e ruajtjes.
Bucket-at në ruajtje nuk ishin të përzierë, ata mund të merren lehtësisht dhe të transferohen, por klientët përdornin të dyja ruajtjet, kështu që duhej të zgjidhej problemi i mungesës së ndalesave. Nuk mund të thoshim thjesht se do të fiknim dhe do të kopjonim. Ne bëmë migrimin në disa faza.
Së pari, ne synchronizuam ruajtjet primare. Kishim Tarantool dhe mund të bënim diçka të tillë kur krijonim një objekt:
- një kërkesë për krijimin e një bucket-i, për shembull në Hotbox, arrin në bazë;
- Tarantool kontrollon nĂ« njĂ« bazĂ« tjetĂ«r (nĂ« kĂ«tĂ« rast â nĂ« Icebox), qĂ« njĂ« bucket i tillĂ« nuk ekziston;
- nëse bucket-i ekziston, baza thotë se nuk mund të krijohet, dhe ai është synchronizuar si ekzistues.
Synchronizimi i bucket-eve
NĂ« ruajtjen qĂ« duhej tĂ« priste tĂ« gjitha tĂ« dhĂ«nat, u fut njĂ« shenjĂ« pĂ«r projektet dhe bucket-at qĂ« tregon se ku ndodhet ky objekt. Ai mund tĂ« ruhej lokalisht, pra nĂ« Hotbox, nĂ« Icebox â atĂ«herĂ« nuk ka tĂ« dhĂ«na nga ai nĂ« ruajtjen e re, ose mund tĂ« ishte nĂ« gjendje migrimi.
Nëse një projekt ose bucket kishte shenjën Migrating, atëherë gjatë migrimit kërkesa kryhej fillimisht në ruajtjen e re, në të cilën duhej të ishin të dhënat, dhe nëse ato nuk ishin aty, kërkesat dërgoheshin në ruajtjen alternative.
Më pas ne kaluam trafikun. Duke qenë se API mund të shërbente për kërkesat si të Icebox, ashtu edhe të Hotbox, ne arritëm të kalonim trafikun pa ndalesa, thjesht duke transferuar host-at dhe shtuar shënime përkatëse në Nginx.
Pas këtij, kur trafiku u drejtua, mund të hiqnim Nginx dhe API nga Icebox.
MĂ« pas, ne hoqĂ«m Nginx nga Icebox dhe S3 API â dhe gjithçka funksionoi:
MĂ« pas nisĂ«m njĂ« proces migrazioni nĂ« sfond, i cili punon brenda bazĂ«s â duke kaluar nĂ«pĂ«r çdo projekt dhe tavat e tyre, duke u vendosur shenjĂ«n Migrating, duke transferuar tĂ« dhĂ«nat dhe, pas pĂ«rfundimit tĂ« transferimit, duke vendosur shenjĂ«n Local.
Pas transferimit të të dhënave, nuk na nevojitet më depoja e vjetër, dhe ne heqim pjesët e mbetura të sistemit të vjetër, si dhe heqim mbështetje për statusin e migrazionit nga kodi.
Me të njëjtat parime, u realizua edhe rishearding nga depoja e vjetër në të sharduar:
- E shënuam të gjitha tavat si
Non-sharded. Të gjitha kërkesat për to shkuan në depozita origjinale, të pa sharduar. - Tavat e reja krijoheshin menjëherë në statusin
Sharded. - Merrnim tavat një nga një, vendosnim statusin
Migratingdhe transferonim të dhënat.
Kërkesat gjatë kësaj trajtoheshin në parimin:
- Lexojmë në të rejat, pastaj në ato të vjetra.
- Krijojmë vetëm në të reja.
- Përditësojmë në dy faza: nëse në të reja nuk ka, transferojmë nga të vjetra në të reja, pastaj përditësojmë.
Puna me certifikatat SSL
Në frontend ne përdorim Nginx. Në rastin tonë, ky nuk është një Nginx i zakonshëm, por OpenResty, Nginx me mbështetje për LuaJIT.
NjĂ« pjesĂ« tjetĂ«r e sistemit â puna me certifikatat SSL. NĂ« depozitat S3 mund tĂ« vendosni njĂ« domen tĂ« vet, pĂ«r tĂ« aksesuar njĂ« tavĂ« specifike, thjesht duke pĂ«rdorur CNAME. Por pa HTTPS sot nuk bĂ«het: domeni i vet nĂ«nkupton njĂ« certifikat SSL tĂ« vet.
Siç kam thënë më parë, për balancimin dhe terminimin e SSL, na përgjigjet Nginx. Në rastin tonë, ky nuk është një Nginx i zakonshëm, por OpenResty, Nginx me mbështetje për LuaJIT.
Kjo na mundësoi ta mësojmë Nginx-in tonë të ofronte certifikata të rastësishme. Dhe na duhej të ofronim certifikata dinamikisht (pa nevojën për t'i shkruar ato në skedarin e konfigurimit). Ne përdorëm zgjerimin ssl_certificate_by_lua, e cila lejon të lexosh certifikatën nga një burim të rastësishëm pikërisht gjatë hëndshakut TLS. Si depozita e certifikatave ne gjithashtu morëm Tarantool: kjo lejon të menaxhosh certifikatat nga jashtë dhe siguron kthimin jashtëzakonisht të shpejtë.
Ishte realizuar gjithashtu njĂ« demon i veçantĂ«, i cili ka pĂ«r detyrĂ« tĂ« pĂ«rditĂ«sojĂ« rregullisht certifikatat qĂ« janĂ« lĂ«shuar me Letâs Encrypt.
ĂfarĂ« do tĂ« ruaja, dhe çfarĂ« do tĂ« bĂ«ja ndryshe nĂ«se do tĂ« zhvilloja njĂ« ruajtje nga e para
ĂfarĂ« duhej pĂ«rdorur qĂ« nĂ« fillim
Shardimi nga fillimi. ShumĂ« probleme i solli rikthimi nĂ« sharding. ĂshtĂ« e lehtĂ« ta bĂ«sh, por megjithatĂ«, nĂ«se fillon projekte qĂ« duhet tĂ« shkallĂ«zohen, mĂ« mirĂ« Ă«shtĂ« tĂ« marrĂ«sh menjĂ«herĂ« njĂ« klaster tĂ« sharduar, madje edhe me numrin minimal tĂ« nyjeve. Implementimi i shardimit nĂ« fillim Ă«shtĂ« pothuajse falas nĂ« krahasim me zbatimin e shardimit nĂ« njĂ« sistem funksional.
Puna me Tarantool përmes balancuesve. Tani ne menjëherë i lidhim të gjitha bazat e reja në punë përmes balancuesve. Kjo lejon zgjerimin e funksionalitetit, duke arritur një qëndresë më të lartë ndaj mungesave.
Autofailover. Do të instaloja të gjitha mjetet që kërkohen për autofailover, pasi dështimet e para pas lançimit ishin të lidhura me mungesën e tij. Pas përvojës me S3, të gjitha produktet e mëpasshme u lançuan duke marr parasysh këtë.
Karakteristika S3 "Versionimi". Në fillim dukej se kjo funkcionalitet nuk kishte shumë kërkesë. Të integronit këtë mundësi në arkitekturën e një sistemi funksional është shumë e vështirë.
Biling i veçantë. Ajo mënyrë sesi e integruam billing në sistemin tonë, u tregua e suksesshme në fillim, por më vonë filloi të pengojë, do të ishte më mirë ta kishim si një shërbim tërësisht të veçantë.
ĂfarĂ« ishte njĂ« zgjidhje e suksesshme
Modeli i të dhënave. Historia tregoi se me zhvillimin e shërbimit ne përputheshim mjaft saktë me modelin e të dhënave të Amazon, prandaj mund të realizonim ato funksionalitete që ekzistojnë aty.
Skema e shardimit. Do të mbështesja po të njëjtat sharding të intervaleve sipas baketeve, pasi kjo lejon të shpërndahen mirë kërkesat nga bakete të ndryshme në një klaster të madh.
Përdorimi i Tarantool. Tarantool ndihmoi shumë në zhvillimin dhe modifikimin e shërbimit, ne punuam me të dhënat lehtësisht, i transformuam dhe i sharduam ruajtjen, dhe nuk ishte nevoja të kalonim në layer-in e aplikacionit.
Ky raport u paraqit për herë të parë në nga Mail.ru Cloud Solutions&Tarantool. Shikoni prezentime të tjera dhe abonohuni në njoftimet e ngjarjeve në Telegram .
Po ashtu mund të shikoni raportin tim të vjetër mbi S3 ose të lexoni artikullin e kolegut tim mbi ruajtjen me bllok.
- .
- .
Burimi: habr.com
