Artem Denisov ( , )
Badoo është platforma më e madhe për takime në botë. Aktualisht, kemi rreth 330 milion përdorues të regjistruar në mbarë botën. Por, çka është edhe më e rëndësishme në kontekstin e diskutimit tonë sot, është se ruajmë rreth 3 petabyte fotografish nga përdoruesit. Çdo ditë, përdoruesit tanë ngarkojnë rreth 3.5 milion fotografi të reja dhe ngarkesa e leximit arrin rreth 80 mijë kërkesa në sekondë. Kjo është mjaft për back-end-in tonë dhe ndonjëherë na hasim në disa vështirësi.
Do flas për dizajnin e këtij sistemi, i cili ruan dhe ofron fotografi në përgjithësi, dhe do e shpjegoj nga këndvështrimi i zhvilluesit. Mund të ketë një retrospektivë të shkurtër mbi zhvillimin e saj, ku do të përmend disa pika kryesore, por do flas më në detaje vetëm për zgjidhjet që po përdorim aktualisht.
Tani le të fillojmë.
Siç e thashë, kjo do të jetë një retrospektivë, dhe për ta filluar nga diçka, le të marrim një shembull të thjeshtë.
Kemi një detyrë të përgjithshme; na nevojitet të pranojmë, ruajmë dhe ofrojmë fotografitë e përdoruesve. Në këtë formë, detyra është e përgjithshme, ne mund të përdorim gjithçka:
- storage moderne në cloud,
- çdo zgjidhje të çertifikuar, të cilat ka shumë tani;
- mund të vendosim disa makina në qendrën tonë të të dhënave dhe t'i pajisim me disqe të mëdhenj për të ruajtur fotografitë aty.
Badoo historikisht ka qenë — dhe tani, ashtu si në atë kohë kur gjithçka po fillonte — në serverat tanë të pronarit, brenda qendrave tona të të dhënave. Prandaj, ky opsion ishte optimal për ne.
Thjesht morëm disa makina, i quajtëm "fotografitë", dhe formuam një klaster që ruan fotografitë. Por, duket se diçka i mungon. Për ta bërë këtë të funksionojë, duhet dikush të përcaktojë se në cilin server do ruajmë cilat fotografi. Dhe këtu nuk kemi nevojë të rihapim Amerikën.
Shtojmë në storage-in tonë me informacionin e përdoruesve një fushë të re. Kjo do të jetë çelësi i sharding-ut. Në rastin tonë, e quajtëm place_id, dhe ky id i vendit tregon vendin ku ruhet fotografia e përdoruesit. Ne krijojmë harta.
Në fazën fillestare, mund ta bëjmë madje edhe me duar — themi se fotografia e këtij përdoruesi me këtë vend do të përfundojë në këtë server. Falë kësaj harte, ne gjithmonë e dimë ku duhet ta ruajmë fotografinë kur përdoruesi e ngarkon, dhe e dimë se nga ku duhet ta ofrojmë.
Kjo është një skemë shumë e thjeshtë, por ka disa avantazhe të rëndësishme. E para, është e thjeshtë, siç e thashë, dhe e dyta është se me këtë qasje ne mund të rritemi lehtësisht në mënyrë horizontale, thjesht duke shtuar makina të reja dhe duke i shtuar ato në hartë. Nuk ka nevojë për asgjë më shumë.
Kështu ishte për një kohë të gjatë për ne.
Ishte diku në vitin 2009. Shtonim makina, po sillnim...
Dhe në një moment filluam të vëzim se kjo skemë kishte disa disavantazhe. Çfarë disavantazhesh?
E para, është kapaciteti i kufizuar. Në një server fizik, nuk mund të vendosim aq shumë disqe të ngurtë sa do të donim. Kjo, me kalimin e kohës dhe rritjen e dataset-it, u bë një problem.
E dyta. Kjo është një konfigurim i pazakonshëm për makinat, pasi të tilla makina është e vështirë të ripërdoren në klastere të tjera, janë mjaft specifike, dmth, duhet të jenë të dobëta në performancë, por po ashtu me disqe të mëdhenj.
Kjo ishte situata në vitin 2009, por megjithatë këto kërkesa janë të rëndësishme edhe sot. Ne kemi një retrospektivë, prandaj në vitin 2009, gjithçka ishte keq lidhur me këto.
Dhe pika e fundit — është çmimi.
Çmimi atëherë ishte mjaft i lartë, dhe na duhej të kërkonim disa alternativa. Duhet të gjendeshim më mirë me menaxhimin e hapësirës në qendrat e të dhënave dhe po ashtu me serverët fizikë ku ruhej gjithçka. Ingjinerët tanë sistemikë filluan një hulumtim të madh, ku rishikuan shumë opsione të ndryshme. Ata shqyrtuan gjithashtu sisteme të skedarëve të klasterit, si PolyCeph dhe Lustre. Kishte probleme me performancën dhe ishte shumë e vështirë për t'u operuar. Hoqën dorë. Provuan të lidhin të gjithë dataset-in përmes NFS në çdo makinë, në mënyrë që ta zgjidhnin këtë çështje. Leximi gjithashtu doli i vështirë; provuan zgjidhje të ndryshme nga ofrues të ndryshëm.
Në përfundim, ne vendosëm që të fillonim të përdornim ashtuquajturin Storage Area Network.
Këto janë SHD shumë të mëdha, të cilat janë të orientuara për të ruajtur sasi të mëdha të të dhënave. Ato përbëjnë rafte me disqe që janë montuar në makinat përfundimtare të dhënies përmes optikës. Kështu, ne kemi një grup të caktuar makinash, mjaft të vogël, dhe këto SHD, të cilat janë transparente për logjikën tonë të dhënies, pra për nginx-in tonë ose për ndonjë tjetër, shërbejnë kërkesat për këto fotografi.
Ky zgjidhje kishte përparësi evidente. Ky është SHD. Ai është orientuar për të ruajtur fotografi. Kjo rezulton më e lirë se sa të vendosim thjesht makina me disqe të ngurtë.
Përfitimi i dytë.
Kjo është se kapaciteti është rritur ndjeshëm, pra ne mund të ruajmë shumë më tepër storage me një volum shumë më të vogël.
Por pati dhe disavantazhe që u zbuluan mjaft shpejt. Me rritjen e numrit të përdoruesve dhe ngarkesës në këtë sistem, filluan të shfaqen probleme me performancën. Dhe problemi është mjaft i qartë — çdo SHD, e destinuar për të ruajtur shumë fotografi në një volum të vogël, zakonisht vuan nga një lexim intensiv. Kjo është në të vërtetë e vërtetë për çdo storage në cloud, dhe çdo gjë tjetër. Aktualisht nuk kemi një storage ideal, që do të ishte pafundësisht i zgjerueshëm, ku mund të fusnim gjithçka dhe ai do të përballonte shumë mirë leximet, sidomos leximet rastësore.
Siç ndodh me fotografitë tona, sepse fotografitë kërkohen në mënyrë të paqëndrueshme dhe kjo ndikojnë shumë në performancën e tyre.
Dhe deri në sot, nëse ne kemi më shumë se 500 RPS për fotografi në makinë, me të cilën lidhet storage, fillojnë problemet. Dhe kjo ishte mjaft e keqe për ne, sepse numri i përdoruesve po rritet, gjithçka duhet të bëhet vetëm më keq. Duhet ta optimizojmë këtë ndonjëherë.
Për të optimizuar, në atë kohë ne vendosëm, mjaft qartë, të shohim profilin e ngarkesës — çfarë po ndodh, çfarë duhet të optimizohet.
Dhe këtu gjithçka punon në favorin tonë.
Unë në sliden e parë kam thënë: ne kemi 80 mijë kërkesa në sekondë për lexim me vetëm 3.5 milionë uploads në ditë. Pra, kjo është një diferencë prej tre rendesh. Mjaft e qartë se duhet të optimizojmë leximin dhe është pothuajse e qartë se si.
Ka një moment tjetër të vogël. Speficika e shërbimit është e tillë që përdoruesi regjistrohet, ngarkon një fotografi, pastaj fillon të shikojë aktivisht të tjerët, t'i pëlqejë ata, ai shfaqet aktivisht për të tjerët. Pastaj ai gjen një çift ose jo, si do dalë, dhe për një kohë të caktuar ndalon së përdoruri shërbimin. Në këtë moment, kur ai përdor, fotografitë e tij janë shumë të nxehta — ato kërkohen nga shumë njerëz. Pasi ai ndalon, ai shpejt rënkon nga shfaqja intensive për të tjerët siç bënte më parë, dhe fotografitë e tij pothuajse nuk kërkohen.
Pra, kemi një dataset shumë të vogël të nxehtë. Por, përkundrazi, ka shumë kërkesa për të. Një solucion i qartë këtu është të shtojmë një cache.
Cache me LRU do të zgjidhte të gjitha problemet tona. Çfarë bëjmë ne?
Ne shtojmë para klasterit tonë të madh me storage një tjetër relativisht të vogël, i cili quhet fotokashë (photoscache). Kjo, në thelb, është thjesht një proxy caches.
Si funksionon nga brenda? Ky është përdoruesi ynë, ky është storage. Të gjitha, si më parë. Çfarë shtojmë ndërmjet tyre?
Kjo është thjesht një makinë me një disk lokal fizik, që është i shpejtë. Ky është një SSD, për shembull. Dhe në këtë disk ruhet një cache lokal.
Si duket kjo? Përdoruesi dërgon një kërkesë për një fotografi. NGINX e kërkon atë fillimisht në cache lokal. Nëse nuk e gjen, atëherë bën thjesht proxy_pass në storage tonë, shkarkon fotografinë nga aty dhe ia jep përdoruesit.
Por është mjaft e thjeshtë dhe e paqartë se çfarë ndodh brenda. Funksionon më para në këtë mënyrë.
Cache është ndarë logjikisht në tri nivele. Kur flas për "tri nivele", nuk do të thotë se ndonjëherë ka një sistem të ndërlikuar. Jo, kjo është thjesht tre direktori në sistemin e skedarëve:
- Ky është bufferi, ku shkojnë fotografitë e sapo ngarkuara nga proxy.
- Ky është cache i ngrohtë, ku ruhen fotografitë që kërkohen aktivisht tani.
- Dhe ky është cache i ftohtë, ku fotografitë gradualisht çohen nga ai i ngrohti, kur po i vijnë më pak kërkesa.
Për ta bërë këtë të funksionojë, duhet të menaxhojmë në njëfarë mënyre këtë cache, duhet të zhvendosim fotografitë atje dhe tjerë. Ky është një proces gjithashtu shumë primitiv.
Nginx thjesht shkruan në RAMDisk access.log për çdo kërkesë, ku specifikohet rruga për fotografinë që po shërben aktualisht (rruga relative, natyrisht) dhe se cila seksion e ka shërbyer. D.m.th., aty mund të ketë një shënim si 'foto 1' dhe më tej ose buferi, ose cache-i i ngrohtë, ose cache-i i ftohtë, ose proxy.
Varësisht nga kjo, na nevojitet një vendim për çfarë të bëjmë me fotografinë.
Në secilën makinë kemi një demon të vogël që vazhdimisht lexon këtë log dhe ruan statistikën për përdorimin e fotografive të ndryshme në memorien e tij.
Ai thjesht mbledh aty, mban numëruesit dhe herë pas here bën këtë. Fotografi të kërkuara aktivisht, për të cilat vijnë shumë kërkesa, ai i zhvendos në cache-in e ngrohtë, pavarësisht se ku ndodhen.
Fotografitë që kërkohen rrallë dhe kanë filluar të kërkohen më rrallë, ai gradualisht i dëbon nga cache-i i ngrohtë në atë të ftohtë.
Dhe kur kemi vend të mbaruar në cache, thjesht fillojmë të fshijmë gjithçka nga cache-i i ftohtë pa ndonjë përzgjedhje. Dhe kjo, për të qenë e saktë, funksionon shumë mirë.
Për sigurimin që fotografia ruhet menjëherë kur bëhet proxy në bufer, ne përdorim direktivën proxy_store dhe buferi është gjithashtu RAMDisk, domethënë për përdoruesin funksionon shumë shpejt. Kjo është ajo që lidhet me brendësinë e serverit që cache.
Ka mbetur çështja se si të shpërndajmë kërkesat për këto servera.
Supozoni se kemi një kluster me përbërje nga njëzet makina storage dhe tre servera që cache (ka ndodhur kështu).
Na nevojitet një mënyrë për të përcaktuar se cilat kërkesa shkojnë pas cilave fotografi dhe ku duhet të zbarkojnë.
Mënyra më e thjeshtë — është Round Robin. Apo ta bëjmë këtë rastësisht?
Kjo, natyrisht, ka disa disavantazhe, sepse do të përdorim shumë joefikasht cache-in në një situatë të tillë. Kërkesat do të zbarkojnë në disa makina rastësore: këtu është cache-uar, në përkrah nuk ka më. Dhe gjithçka do të funksionojë, nëse ndodhi, shumë keq. Edhe kur numri i makinave në kluster është i vogël.
Na nevojitet ndonjë mënyrë për të përcaktuar qartë se në cilin server duhet të zbarkojë cila kërkesë.
Ka një mënyrë banale. Ne marrim hash nga URL-ja ose hash nga çelësi ynë të sharding, i cili është në URL, dhe e ndajmë atë me numrin e serverëve. A do të funksionojë? Po.
D.m.th., kemi një kërkesë 100% për një 'example_url' gjithmonë do të zbarkojë në serverin me indeks '2', dhe cache do të shfrytëzohet vazhdimisht sa më mirë.
Por lind problemi me reshardoing në një skemë të tillë. Resharding — kam parasysh ndryshimin e numrit të serverëve.
Të supozosh se klustra jonë e caching ka pushuar së funksionuari dhe vendosëm të shtojmë një makinë tjetër.
E shtojmë.
Tani ndarja e gjitha bëhet jo me tre, por me katër. Në këtë mënyrë, pothuajse të gjitha çelësat që kishim më parë, pothuajse të gjitha URL-të tani jetojnë në serverë të ndryshëm. I gjithë cache-u u invalidua menjëherë. Të gjitha kërkesat e furishme shkaktuan kaos te klusteri ynë storage, ai u braktis dhe përdoruesit e pakënaqur. Kjo nuk dëshirohet.
Ky variant gjithashtu nuk na përshtatet.
Pra, çfarë duhet të bëjmë? Duhet të përdorim disa mënyra efektive për të shfrytëzuar cache-in, duke zbarkuar vazhdimisht një kërkesë në të njëjtin server, por duke qenë të qëndrueshëm ndaj reshardimit. Dhe një zgjidhje e tillë ekziston, nuk është aq e komplikuar. Quhet hashing i qëndrueshëm.
Si duket kjo?
Ne marrim ndonjë funksion nga çelësi i sharding dhe e shtrijmë të gjitha vlerat e saj rreth një rrethi. D.m.th., në pikën 0 ne kemi vlerat e saj minimale dhe maksimale të sigluara. Më pas, ne vendosim në të njëjtin rreth të gjithë serverët tanë në këtë mënyrë:
Çdo server përcaktohet nga një pikë, dhe sektori që shkon deri tek ai në drejtim të akrepëve është, gjithmonë, shërbyer nga ky host. Kur na vijnë kërkesat, ne menjëherë shohim se, për shembull, kërkesa A — ka një hash të tillë — dhe shërbehet nga serveri 2. Kërkesa B — nga serveri 3. Dhe kështu me radhë.
Çfarë ndodh në këtë situatë gjatë reshardimit?
Ne nuk invalidojmë të gjithë cache-in, si më parë, dhe nuk zhvendosim të gjithë çelësat, por zhvendosim secilin sektor në një distancë të vogël në atë mënyrë, që në vendin e lirë, siç thonë, të vendoset serveri ynë i gjashtë, që duam ta shtojmë.
Sigurisht, në një situatë të tillë çelësat gjithashtu lëvizin. Por ata lëvizin shumë më pak se më parë. Dhe ne shohim se dy çelësat tanë të parë kanë mbetur në serverët e tyre, ndërsa është ndryshuar vetëm serveri që cache për çelësin e fundit. Kjo funksionon mjaft efektivisht, dhe nëse shtoni serverë të rinj gradualisht, nuk ka ndonjë problem të madh këtu. Ju pak nga pak shtoni, prisni që cache të mbushet sërish dhe gjithçka funksionon mirë.
Një pyetje mbetet e hapur në rastet e refuzimit. Le të themi se kemi ndonjë makinë që ka dalë jashtë funksionit.
Dhe nuk do të donim shumë të rinovonim këtë hartë, të inaktivizonim një pjesë të caches dhe kështu me radhë, nëse, për shembull, makina u ributua, dhe ne duam të shërbejmë ndonjë mënyrë kërkesat. Thjesht mbajmë një fotokash rezervë në çdo vend, e cila shërben si zëvendësim për çdo makinë që aktualisht ka dalë jashtë funksionit. Nëse ndonjëherë ndonjë server bëhet i paaksesueshëm, trafiku shkon atje. Në këtë rast, sigurisht, nuk kemi asnjë cache atje, dmth. është i ftohtë, por të paktën kërkesat e përdoruesve përpunohen. Nëse është një interval i shkurtër, ne e kalojmë atë mjaft qetë. Thjesht ka më shumë ngarkesë në ruajtje. Nëse është një interval i gjatë, atëherë ne mund të marrim një vendim — të heqim këtë server nga harta apo jo, ose ndoshta ta zëvendësojmë me një tjetër.
Kjo është për sistemin e caching. Le të shikojmë rezultatet.
Duket siç nuk ka asgjë të komplikuar këtu. Por ky mënyrë e menaxhimit të caches na dha një hit rate prej rreth 98%. Dmth. nga këto 80 mijë kërkesa në sekondë, vetëm 1600 arrijnë në ruajtje, dhe kjo është një ngarkesë krejt normale, ata e përballojnë qetë, gjithmonë kemi rezerva.
Kemi vendosur këta serverë në tre qendrat tona të të dhënave dhe kemi marrë tre pika pranisë — Pragë, Miami dhe Hong Kong.
Kështu, ato janë më shumë-më pak lokalisht të vendosura për çdo një nga tregjet tona të synuara.
Dhe si një bonus të këndshëm, kemi marrë këtë proxy caching, ku CPU realisht është në gjumë, sepse për dorëzimin e përmbajtjes, nuk është kaq i nevojshëm. Dhe atje me NGINX+ Lua kemi realizuar shumë logjikë utilitare.
Për shembull, mund të eksperimentohet me webp apo progressive jpeg (këto janë formate moderne efektive), të shikojmë se si ndikon në trafik, të marrim ndonjë vendim, të aktivizojmë për vende të caktuara, etj.; të kryejmë ripërmasim dinamik apo prerje fotografish në fluks.
Kjo është një përdorim i mirë, kur p.sh., keni një aplikacion mobil që shfaq fotografi, dhe aplikacioni mobil nuk dëshiron të shpenzojë CPU-në e klientit për të kërkuar një fotografi të madhe dhe pastaj ta ripërmasojë atë në një madhësi të caktuar për ta vendosur në pamje. Ne mund të specifikojmë thjesht dinamik në URL ndonjë parametër në UPort të supozuar, dhe fotokasha vetë do ta ripërmasojë fotografinë. Në përgjithësi, ai do të zgjedhë madhësinë që e kemi fizikisht në disk, sa më afër që të jetë kërkesës, dhe do ta reduktojë në koordinatat specifike.
Për më tepër, kemi publikuar në dispozitë të hapur videot e pesë viteve të fundit të konferencës së zhvilluesve të sistemeve me ngarkesë të lartë. . Shikoni, studio, ndani dhe abonohuni në .
Gjithashtu, ne mund të shtojmë shumë logjikë produkti atje. Për shembull, mund të shtojmë watermark të ndryshëm sipas parametrave të URL-së, mund të blurrojmë fotografitë, t'i zbehim ose t'i pixelojmë. Kjo është kur duam të tregojmë fotografinë e një personi, por nuk duam të tregojmë fytyrën e tij, funksionon mirë, është realizuar gjithçka këtu.
Çfarë kemi marrë? Kemi marrë tri pika pranisë, një hit rate të mirë, dhe në të njëjtën kohë CPU nuk është në gjumë në këto makina. Ai tani ka ngjallur sigurisht më shumë rëndësi se më parë. Na nevojitet të vendosim makina më të fuqishme, por ia vlen.
Kjo është për dorëzimin e fotografive. Këtu gjithçka është mjaft e qartë dhe e dukshme. Mendoj se nuk kam zbuluar Amerikën, kështu funksionon praktikisht çdo CDN.
Dhe, me siguri, një dëgjues i sofistikuar mund të ketë një pyetje: pse thjesht të mos e ndërroni gjithçka në CDN? Do të ishte përafërsisht e njëjtë, të gjitha CDN moderne e bëjnë këtë. Dhe këtu janë disa arsye.
E para — janë fotografitë.
Kjo është një nga momentet kyçe të infrastrukturës tonë, dhe na nevojitet sa më shumë kontroll mbi to. Nëse është një zgjidhje nga një shitës i palës së tretë, dhe ju nuk keni asnjë pushtet mbi atë, do të jetë mjaft e vështirë të jetoni me të, kur keni një dataset të madh, dhe kur keni një fluks shumë të madh të kërkesave nga përdoruesit.
Të jap një shembull. Tani, në infrastrukturën tonë, mund të hyjmë në një makinë për të bërë debugging, në rast se ka ndonjë problem apo ndonjë zhurmë nga nëntoka. Mund të shtojmë grumbullimin e disa metricave që na nevojiten, mund të eksperimentojmë dhe të shohim si ndikojnë ato në grafikat, etj. Tani po grumbullohet shumë statistikë nga ky klaster caching. Dhe ne herë pas here e shqyrtojmë atë dhe studiojmë me kujdes ndonjë anomali. Nëse kjo do të ishte në anën e CDN-së, do të ishte shumë më e vështirë për ta kontrolluar. Ose, për shembull, nëse ndodh ndonjë aksident, ne e dimë se çfarë ka ndodhur, dimë si të jetojmë me të dhe si ta përballojmë. Ky është përfundimi i parë.
Përfundimi i dytë është gjithashtu historik, sepse sistemi është duke u zhvilluar prej kohësh dhe shumë kërkesa të ndryshme biznesi në etapa të ndryshme kanë qenë, dhe nuk gjithmonë ato përshtaten në konceptin e CDN-së.
Dhe pika që rrjedh nga e kaluara –
Është se në fotoklashet tona kemi shumë logjikë specifike, të cilën nuk mund ta shtojmë gjithmonë me porosi. Nuk ka gjasa që ndonjë CDN të shtojë ndonjë gjë të personalizuar sipas kërkesës tuaj. Për shembull, nëse dëshironi të encryptoni URL-të, nëse nuk doni që klienti të mund të ndryshojë ndonjë gjë. Dëshironi ta ndryshoni URL-në në server dhe ta encryptoni atë, dhe pastaj të dorëzoni disa parametra dinamikë këtu.
Cili është përfundimi i arsyeshëm? Në rastin tonë, CDN nuk është një alternativë shumë e mirë.
Por në rastin tuaj, nëse keni kërkesa specifike biznesi, mund ta realizoni të gjithë atë që ju tregova. Dhe kjo do të punojë shkëlqyer me një profil ngarkese të ngjashëm.
Por nëse keni një zgjidhje të përgjithshme, dhe detyra nuk është shumë e veçantë, mund të përdorni qetësisht CDN. Ose nëse për ju është shumë më e rëndësishme koha dhe burimet, sesa kontrolli.
Dhe CDN-të moderne kanë pothuajse të gjitha ato që ju tregova tani. Përveç ndonjë funksioni të veçantë.
Kjo ka të bëjë me dorëzimin e fotografive.
Le të kalojmë tani pak më përpara në retrospektivën tonë dhe të flasim për ruajtjen.
Viti 2013 ishte.
Serverët caching u shtuan, problemet me performancën u zhdukën. Gjithçka është në rregull. Dataset-i po rritet. Në vitin 2013 kishim rreth 80 serverë të lidhur me storage-të dhe rreth 40 caching në çdo Qendër të Dhënash. Kjo është rreth 560 terabajt të dhënash në çdo Qendër të Dhënash, pra rreth një petabajt në total.
Dhe me rritjen e dataset-it, kostot operacionale filluan të rriten në mënyrë të konsiderueshme. Në çfarë shprehej kjo?
Në këtë skemë, e cila është vizatuar — me SAN, me makinat e lidhura dhe cache-të — ka shumë pika dështimi. Nëse me dështimin e serverëve caching më parë u përballëm, aty gjithçka është relativisht e parashikueshme dhe e qartë, në anën e storage-it ishte shumë më keq.
Së pari, vetë Storage Area Network (SAN) mund të dështojë.
Së dyti, ai është i lidhur me optikë në makinat përfundimtare. Mund të ketë probleme me kartat optike, switch-at.
Sigurisht, numri i tyre nuk është kaq i madh sa ai i SAN-së, por megjithatë, janë gjithashtu pika dështimi.
Më pas, vetë makina që është e lidhur me storage-in. Ajo gjithashtu mund të dështojë.
Pra, kemi tre pika dështimi.
Përveç pikave të dështimit, kjo është një mirëmbajtje e rëndë e vetë storage-eve.
Kjo është një sistem i ndërlikuar shumëkomponent, dhe inxhinierët sistemik shpesh hasin vështirësi me të.
Dhe pika e fundit, më e rëndësishmja. Nëse ndonjë prej këtyre tre pikave ndodh të dështojë, kemi një probabilitet jo zero për të humbur të dhënat e përdoruesit, pasi mund të dështojë sistemi i skedarëve.
Le të supozojmë se sistemi i skedarëve ka dështuar. Restaurimi i tij merr, përveç kësaj, shumë kohë — mund të zgjasë një javë nëse ka një volum të madh të të dhënave. Dhe për më tepër, në fund mund të kemi një numër të madh skedarësh të paqartë, që duhet të përshtatën ndonjë mënyrë me fotografitë e përdoruesve. Dhe rrezikojmë të humbim të dhënat. Rreziku është mjaft i lartë. Dhe sa më shpesh që ndodhin situata të tilla, dhe sa më shumë probleme paraqiten në të gjithë këtë zinxhir, aq më i lartë është ky rrezik.
Duhej të bëjmë diçka për këtë. Dhe ne vendosëm që thjesht të bëjmë një kopje rezervë të të dhënave. Kjo në të vërtetë është një zgjidhje e qartë dhe e mirë. Çfarë bëmë?
Kështu dukej serveri ynë, i cili ishte i lidhur me storage-in më parë. Ky është një ndarje kryesore, ky është thjesht një pajisje bllokimi që përfaqëson në të vërtetë një mount në storage-in e largët përmes optikës.
Ne thjesht shtuam një ndarje të dytë.
Vendosëm një storage të dytë pranë (fatmirësisht, ekonomikisht nuk është aq e shtrenjtë), dhe e quajtëm atë ndarje backup. Ai gjithashtu është i lidhur me optikë, ndodhet në të njëjtin server. Por na nevojitet një mënyrë për të sinkronizuar të dhënat midis tyre.
Këtu ne thjesht vendosim një radhë asinkrone ngjitur.
Nuk është shumë e ngarkuar. E dimë që kemi pak regjistrime. Rradha është thjesht një tabelë në MySQL, në të cilën shkruhen rreshta si "duhet të bëjmë backup të kësaj fotografie". me ndonjë ndryshim ose me ngarkimin, ne kopjojmë nga ndarja kryesore në backup me një worker asinkron ose thjesht ndonjë background worker.
Dhe kështu ne gjithmonë kemi dy ndarje konsistente. Edhe nëse një pjesë e këtij sistemi dështon, ne gjithmonë mund të ndërronim ndarjen kryesore me backup-in, dhe gjithçka do të vazhdojë të funksionojë.
Por për shkak të kësaj, ngarkesa për leximin rritet ndjeshëm, sepse përveç klientëve që lexojnë nga ndarja kryesore, sepse ata së pari shohin fotografinë atje (ajo është më e freskët atje), dhe më pas kërkojnë në backup nëse nuk e gjejnë (por kjo e bën thjesht NGINX), ka dhe sistemi ynë i backup-it që tani lexon nga ndarja kryesore. Nuk ishte se kjo ishte pika e ngushtë, por nuk doja të rrisja ngarkesën, esencialisht, thjesht kështu.
Dhe ne shtuam një disk të tretë, i cili është një SSD i vogël, dhe e quajtëm buffer.
Si funksionon tani.
Përdoruesi ngarkon një foto në buffer, më pas dërgohet një event në radhë që thotë se duhet ta kopjojmë në dy ndarje. Ajo kopjohet, dhe fotografia për një periudhë të caktuar (le të themi, një ditë) jeton në buffer, dhe vetëm atëherë hiqet. Kjo e përmirëson ndjeshëm përvojën e përdoruesit, sepse përdoruesi zakonisht ngarkon një foto dhe menjëherë pas saj fillojnë të vijnë kërkesa, ose ai vetë refresh-on faqen. Por gjithçka varion nga aplikacioni që bën ngarkimin.
Ose, për shembull, njerëz të tjerë që fillojnë ta shohin atë foto, menjëherë pas saj dërgojnë kërkesa. Në cache nuk është akoma, kërkesa e parë ndodh shumë shpejt. Në thelb, ashtu si me fotokeshin. Storage i ngadaltë nuk angazhohet fare në këtë. Dhe kur pas një dite ajo do të hiqet, ajo tashmë është ose e cached në pjesën tonë të caching, ose për shumë të gjithë, ndoshta, nuk është më e nevojshme. Pra, përvoja e përdoruesit ka përmirësuar ndjeshëm falë këtyre manipulimeve të thjeshta.
Dhe, më e rëndësishmja: ne kemi ndaluar të humbasim të dhëna.
Ne, le të themi, kemi ndaluar potencialisht të humbasim të dhëna, sepse veçse nuk i humbnim. Por rreziku ishte. Ne shohim se kjo zgjidhje, natyrisht, është e mirë, por është pak si një sistem për të zbutur simptomat e problemit, në vend që ta zgjidhte atë deri në fund. Dhe disa probleme mbetën këtu.
Së pari, kjo është pika e dështimit në formën e vet fizik të hostit, në të cilin funksionon e gjithë kjo makineri, ajo nuk ka ikur askund.
Së dyti, mbeten problemet me SAN-të, ka mbetur mirëmbajtja e tyre e rëndë, etj. Kjo nuk ishte ndonjë faktor kritik, por do të doja ta provoja të jetojmë ndryshe.
Dhe ne bëmë një version të tretë (në themel, në të vërtetë versionin e dytë) - versionin e rezervimit. Si dukej kjo?
Kjo është ajo që ishte -
Problem kryesor për ne ishte se ky është një host fizik.
Së pari, ne heqim SAN-të, sepse duam të eksperimentojmë, duam të provosh thjesht disqe lokale.
Kjo është tashmë 2014-2015, dhe në atë kohë gjendja me disqet dhe kapacitetin e tyre në një host u përmirësua ndjeshëm. Vendosëm, pse të mos e provojmë.
Dhe më pas ne thjesht marrim ndarjen tonë të backup-it dhe e transferojmë fizikisht në një makinë të veçantë.
Kështu, kemi një skemë të tillë. Ne kemi dy makina, të cilat ruajnë dataset të njëjtë. Ato rezervojnë plotësisht njëra-tjetrën dhe sinkronizojnë të dhënat përmes rrjetit përmes një rradhe asinkrone në të njëjtin MySQL.
Pse kjo funksionon mirë - sepse kemi pak regjistrime. Nëse regjistrimi do të ishte në përpjesëtim me leximin, ndoshta do të kishim ndonjë overhead rrjeti dhe probleme. Ka pak regjistrime, shumë lexim - ky mënyrë punon mirë, dmth ne mjaft rrallë kopjojmë fotografitë mes këtyre dy serverëve.
Si funksionon nëse shohim pak më në detaje.
Ngarkimi. Balancuesi thjesht zgjedh host të rastësishëm me çiftin dhe e bën ngarkimin atje. Në këtë rast, ai natyrisht bën kontrollime shëndetësore, shikon që makina të mos kishte rënë. Pra, ai ngarkon fotografitë vetëm në serverin e gjallë, dhe më pas përmes rradhe asinkrone kjo gjithçka kopjohet në fqinjine e tij. Me ngarkimin gjithçka është shumë e thjeshtë.
Me detyrat është pak më e komplikuar.
Këtu na ndihmoi Lua, sepse në NGINX-in e zakonshëm është e vështirë të bësh një logjikë të tillë. Ne së pari bëjmë kërkesën në serverin e parë, shikojmë nëse fotografia është atje, sepse potencialisht ajo mund të jetë ngarkuar, për shembull, tek fqinj, dhe këtu ende nuk ka arritur. Nëse fotografia është atje, kjo është mirë. Ne e japim menjëherë atë klientit dhe, ndoshta, e cache-ojmë.
Nëse nuk është aty, ne thjesht bëjmë një kërkesë për fqinj dhe nga aty e marrim garantuar.
Pra ndaj, përsëri mund të themi: mund të ketë probleme me performancën, për shkak të udhëtimeve të vazhdueshme - foto të ngarkuara, këtu nuk është, ne bëjmë dy kërkesa në vend të një, kjo duhet të funksionojë ngadalë.
Në situatën tonë, kjo nuk funksionon ngadalë.
Ne mbledhim një sasi të madhe metrikash për këtë sistem, dhe norma e goditjeve të tillë është rreth 95%. Pra, vonesa e këtij backup-i është e vogël, dhe për shkak të kësaj ne praktikisht garantuar, pas ngarkimit të fotos, e marrim atë që hera e parë dhe nuk shkojmë dy herë.
Pra, çfarë kemi fituar, dhe çfarë është shumë e bukur?
Më parë kishim një seksion kryesor backup-i, dhe ne lexonim prej tij në mënyrë të rregullt. Kështu që gjithmonë fillonim me kryesorin dhe pastaj me backup-in. Kjo ishte njëra udhë.
Tani ne po shfrytëzojmë leximin nga dy makina në të njëjtën kohë. Shpërndajmë kërkesat në mënyrë Round Robin. Në një përqindje të vogël rastesh, ne bëjmë dy kërkesa. Por tashmë kemi dy herë më shumë kapacitete për lexim se më parë. Dhe ngarkesa ka rënë ndjeshëm për makinat që japin shërbim, si dhe për ruajtësit që kishim në atë kohë.
Sa i përket qëndrueshmërisë. Në fakt, për këtë ne luftonim kryesisht. Këtu qëndrueshmëria është arritur shkëlqyer.
Një makinë del jasht funksionit.
Asnjë problem! Inxhinieri sistemik nuk ka nevojë të zgjohesh natën, mund të presë deri në mëngjes, asgjë e keqe nuk do të ndodhë.
Nëse edhe pas dështimit të kësaj makine del jashtë funksionit rendi, asnjë problem, thjesht logu do të grumbullohet fillimisht në makinën aktive, pastaj do të përpiqet të hyjë në rend, e më pas në atë makinë që do të rikthehet në punë pas një kohe.
E njëjta gjë ndodh edhe me mirëmbajtjen. Thjesht fikim një nga makinat, e heqim dorazi nga të gjitha grupet, ndalon trafikimin, bëjmë ndonjë mirëmbajtje, ndonjë rregullim dhe pastaj e rikthejmë në punë, dhe ky backup arrin mjaft shpejt. Pra, një ditë downtime për një makinë kalohet brenda disa minutash. Kjo është shumë pak. Sa për qëndrueshmërinë, përsëris, këtu gjithçka është në rregull.
Çfarë përfundimesh mund të nxjerrim nga kjo skemë e rezervimit?
Arritëm qëndrueshmërinë.
Eksplorim i thjeshtë. Pasi që në makinat janë disqet e forta lokale, kjo është shumë më e përshtatshme nga perspektiva e inxhinierëve që punojnë me të.
Kemi fituar një kapacitet të dyfishtë për lexim.
Kjo është një bonus shumë i mirë për qëndrueshmërinë.
Por ka edhe probleme. Tani kemi një zhvillim shumë më të ndërlikuar të disa karakteristikave të lidhura me këtë, sepse sistemi ka kaluar në 100% qëndrueshmëri eventuale.
Ne duhet, le të themi, në ndonjë punë mbrapa të mendojmë vazhdimisht: "Cili server është ai tani?", "A është me të vërtetë një foto përkatëse këtu?" etj. Kjo, natyrisht, është e gjitha e mbështjellë në paketat, dhe për programuesin që shkruan logjikën e biznesit, kjo është e tejdukshme. Por, gjithsesi, ka një strat të madh të ndërlikuar që është shfaqur. Por ne jemi të gatshëm të pajtohemi me këtë për shkak të përfitimeve që morën nga ai.
Dhe këtu sërish ndodh njëfarë konflikti.
Në fillim thashë që të ruajtësh gjithçka në disqet e forta lokale - është keq. Tani po them se na ka pëlqyer.
Po, me të vërtetë, me kalimin e kohës situata ka ndryshuar shumë dhe tani ky qasje ka shumë përfitime. Para së gjithash, ne po arrijmë një eksplorim më të thjeshtë.
Së dyti, kjo është më efikase, sepse nuk kemi ato kontrollet automatike, lidhjet me raftet e disqeve.
Aty është një makineri e madhe, ndërsa këtu kemi thjesht disa disqe që janë konkretisht të mbledhura në raid në këtë makinë.
Por ka edhe disavantazhe.
Kjo është rreth 1.5 herë më e shtrenjtë se përdorimi i SAN-ve madje edhe me çmimet e sotme. Prandaj, ne vendosëm që të mos konvertojmë tërë klasterin tonë të madh në makina me disqe lokale dhe vendosëm të mbajmë një zgjidhje hibride.
Pjesa më e madhe e makinave punon me disqe të forta (pra, jo gjysma - ndoshta rreth 30%). Ndërsa pjesa tjetër - janë makinat e vjetra, në të cilat më parë ishte skema e parë e rezervimit. Thjesht i kemi rikozatuar, pasi na nevojiten as më shumë të dhëna asgjë tjetër, thjesht e ndryshuam montimin nga një host fizik në dy.
Dhe kemi fituar një kapacitet të madh për lexim, dhe e kemi zgjeruar. Nëse më parë ne montonim një ruajtës për një makinë, tani montojmë katër, për shembull, për një çift. Dhe kjo funksionon normalisht.
Le të përfundojmë me përmbledhjen e asaj që kemi arritur, për çfarë kemi luftuar dhe a e kemi arritur.
Përfundimet
Kemi përdorues - plot 33 milion.
Kemi tre pika pranije - Pragë, Miami, Hong Kong.
Atohet një stratifikim e shpërdorimit, që përfshin makinën që punon me disqe lokale të shpejtë (SSD), mbi të cilat funksionon një sistem i thjeshtë nga NGINX, log-un e tij të qasjes dhe demonët në Python, të cilët merren me përpunimin dhe menaxhimin e caches.
Nëse dëshironi, në projektin tuaj, nëse fotot nuk janë aq të rëndësishme sa për ne, ose nëse balancimi i kontrollit ndaj shpejtësisë së zhvillimit dhe shpenzimeve të burimeve është më i favorshëm për ju, atëherë mund ta zëvendësoni atë me CDN, të cilët e bëjnë këtë mjaft mirë.
Pas kësaj, vijon një stratifikim ruajtjeje, ku kemi grupe makinash që rezervojnë njëra-tjetrën, duke kopjuar skedarët nga njëri te tjetri asinkronisht me çdo ndryshim.
Një pjesë e këtyre makinave punon me disqe të ngurta lokale.
Një pjesë e këtyre makinave është e lidhur me SAN.
Kështu, nga njëra anë, kjo është më e lehtë për t'u menaxhuar dhe pak më e efektshme, ndërsa nga ana tjetër, është e përshtatshme për densitetin e vendosjes dhe çmimin për gigabajt.
Ky është një përmbledhje e shkurtër e arkitekturës së asaj që kemi arritur dhe si është zhvilluar gjithçka.
Disa këshilla të thjeshta nga kapo.
Së pari, nëse papritur vendosni se duhet të përmirësoni gjithçka në infrastrukturën tuaj të fotove, noshtesoni, sepse ndoshta nuk është e nevojshme të përmirësoni asgjë.
Marr një shembull. Ne kemi një grup makinash që dorëzojnë fotografitë nga bashkëngjitjet në biseda, dhe akoma funksionon një skemë që nga viti 2009, dhe askush nuk ka probleme. Të gjithë janë të lumtur, të gjithë e pelqejnë.
Për të matur, së pari vendosni shumë metrike, shikoni dhe pastaj vendosni se çfarë nuk jeni të kënaqur dhe çfarë duhet përmirësuar. Për të matur, ne kemi një mjet të shkëlqyer që quhet Pinba.
Ai lejon mbledhjen e statistikës nga NGINX shumë të hollësishme për çdo kërkesë dhe kode përgjigjesh, dhe shpërndarjen e kohëve — gjithçka që dëshironi. Ai ka lidhje me sisteme të ndryshme analitike dhe mund të shikoni gjithçka bukur.
Së pari matni — pastaj përmirësoni.
Pastaj, ne optimizojmë leximin me cache, shkrimin — me sharding, por kjo është një pikë e qartë.
Për më tepër, nëse sapo po filloni të ndërtoni sistemin tuaj, është shumë më mirë të bëni fotografitë si skedarë të pandryshueshëm. Duke e bërë këtë, humbni menjëherë një klasë tërë problemesh lidhur me invalidimin e caches, ku logjika duhet të gjejë versionin e duhur të fotografisë etj.
Për shembull, nëse ngarkoni një qindësh, pastaj e ktheni, bëni që të jetë një skedar fizikisht tjetër. Pra, nuk ka nevojë të mendoni se mund të kurseni pak hapësirë duke e shkruar në të njëjtin skedar.
Pika tjetër. Rreth resize në flutur.
Më parë, kur përdoruesit ngarkonin fotografi, ne prerë një mori formatash për çdo rast, për klientë të ndryshëm, dhe të gjithë ishin në disk. Tani, ne e kemi lënë këtë.
Tani, ne kemi mbajtur vetëm tre formate kryesore: të vogla, të mesme dhe të mëdha. Të gjitha të tjerat thjesht i ulim në madhësinë që kërkohen në Uport, thjesht bëjmë uljen dhe i dorëzojmë përdoruesit.
CPU i stratifikimit të caches këtu rezulton shumë më i lirë sesa nëse do të ripërftoheshim vazhdimisht këto formate në çdo ruajtje. Po, nëse duam të shtojmë një të ri, kjo është një punë që zgjat një muaj — për të ngarkuar një skript në të gjitha këto që ta bëjmë me kujdes, pa rënë grupin. Pra, nëse tani keni mundësinë të zgjidhni, është më mirë të krijoni sa më pak madhësi fizike, por të keni një shpërndarje të ndonjë forme, le të themi tre. Të gjitha të tjerat thjesht t’i rregullojmë në flutur duke përdorur module të gatshme. Tani kjo është shumë e lehtë dhe e aksesueshme.
Dhe backup-incremental asinkron është i mirë.
Siç ka treguar praktika jonë, një skemë e tillë funksionon mirë me kopjimin e vonuar të skedarëve të ndryshuar.
Pika e fundit gjithashtu është e qartë. Nëse në infrastrukturën tuaj tani nuk ka probleme të tilla, por ka diçka që mund të dështojë, ajo do të dështojë patjetër, kur të bëhet pak më shumë. Pra, është më mirë të mendoni për këtë paraprakisht dhe të mos përballeni me probleme. Kjo është e gjitha.
Kontakte
»
»
Ky raport është një transkript i një nga performancave më të mira në konferencën e zhvilluesve të sistemeve me ngarkesë të lartë. . Ka mbetur më pak se një muaj deri në konferencën HighLoad++ 2017.
Ne kemi përgatitur tashmë , tani po formohet aktivisht orari.
Këtë vit vazhdojmë të eksplorojmë temën e arkitekturave dhe përmirësimeve:
- / Игорь Васильев
- / Дмитрий Егоров
- / Анатолий Пласковский
- / Роман Шеховцов, Алексей Громатчиков
- / Филипп Дельгядо
Disa nga këto materiale përdoren gjithashtu në kursin tonë online të trajnimit për zhvillimin e sistemeve me ngarkesë të lartë — është një seri letrash, artikujsh, materialesh dhe videosh të seleksionuara me kujdes. Tani e kemi më shumë se 30 materiale unike në manualin tonë. Bashkohuni!
Burimi: habr.com
