Artem Denisov ( , )
Badoo është faqja më e madhe e takimeve në botë. Aktualisht kemi rreth 330 milionë përdorues të regjistruar në mbarë botën. Por ajo që është shumë më e rëndësishme në kontekstin e bisedës sonë të sotme është se ruajmë rreth 3 petabajt fotografi të përdoruesve. Çdo ditë përdoruesit tanë ngarkojnë rreth 3,5 milionë fotografi të reja, dhe ngarkesa e leximit arrin në 80 mijë kërkesa në sekondë. Kjo është mjaft shumë për backend-in tonë dhe ndonjëherë sjell vështirësi.
Do të flas për dizajnin e kësaj sistemi që ruan dhe shpërndan fotografitë në tërësi, si edhe do ta paraqes nga këndvështrimi i një zhvilluesi. Për mënyrën se si ka evoluar, do të bëj një retrospektivë të shkurtër, ku do të shënoj etapat kryesore, por më në detaje do të ndalem vetëm te zgjidhjet që përdorim tani.
Tani le të fillojmë.
Siç e thashë tashmë, kjo do të jetë një retrospektivë, dhe që ta nisim nga diku, le të marrim shembullin më të thjeshtë.
Kemi një detyrë të përgjithshme: duhet të pranojmë, ruajmë dhe shpërndajmë fotografitë e përdoruesve. Në këtë formë, detyra është e përgjithshme dhe mund të përdorim çfarëdo:
- storage modern në cloud,
- një zgjidhje të gatshme, prej të cilave sot ka gjithashtu shumë;
- mund të konfigurojmë disa makina në data center-in tonë dhe të vendosim në to disqe të mëdha të forta, duke i ruajtur fotografitë atje.
Badoo historikisht — si tani, ashtu edhe atëherë (në kohën kur gjithçka sapo po niste) — funksionon në serverët e vet, brenda DC-ve tona. Prandaj, për ne ky variant ishte optimal.
Thjesht morëm disa makina, i quajtëm «photos» dhe na doli një lloj klasteri që ruan fotografitë. Por duket se diçka mungon. Që e gjithë kjo të funksionojë, duhet të përcaktojmë disi se në cilën makinë do të ruajmë cilat fotografi. Edhe këtu nuk ka nevojë të shpikim diçka të re.
Ne shtojmë në ruajtjen tonë me informacionin për përdoruesit një fushë. Kjo do të jetë çelësi i sharding-ut. Në rastin tonë e quajtëm place_id, dhe pikërisht ky ID i lokacionit tregon vendin ku ruhen fotografitë e përdoruesve. Ne përpilojmë harta.
Në fazën e parë këtë mund ta bënim edhe manualisht — përcaktonim që fotografia e këtij përdoruesi me këtë vendosje do të ruhej në këtë server. Falë kësaj harte, ne e dimë gjithmonë se ku ta ruajmë fotografinë kur përdoruesi e ngarkon dhe nga ku ta dorëzojmë më pas.
Kjo është një skemë krejtësisht e thjeshtë, por ka disa avantazhe të rëndësishme. Së pari, është e thjeshtë, siç e thashë tashmë, dhe së dyti, me këtë qasje mund të shkallëzohemi lehtësisht horizontalisht duke shtuar thjesht makina të reja dhe duke i futur në hartë. Nuk duhet bërë asgjë tjetër.
Për njëfarë kohe, kështu funksiononte edhe te ne.
Kjo ishte diku rreth vitit 2009. Shtonim makina, shtonim...
Dhe në një moment filluam të vërenim se kjo skemë kishte disa mangësi. Cilat ishin këto mangësi?
Së pari, kapaciteti ishte i kufizuar. Në një server fizik nuk mund të vendosnim aq shumë disqe të forta sa do të donim. Me kalimin e kohës dhe me rritjen e dataset-it, kjo u bë një problem i qartë.
Dhe së dyti, kjo ishte një konfigurim jo tipik i makinave, sepse këto makina vështirë se mund të ripërdoren në klasterë të tjerë, pasi janë mjaft specifike; pra, duhet të kenë performancë të ulët, por njëkohësisht një disk të fortë me kapacitet të madh.
E gjithë kjo i përket vitit 2009, por në thelb këto kërkesa mbeten актуale edhe sot. Duke qenë se po bëjmë një retrospektivë, në vitin 2009 situata në këtë drejtim ishte vërtet e dobët.
Dhe pika e fundit ishte çmimi.
Në atë kohë çmimi ishte shumë i lartë dhe na duhej të kërkonim alternativa. Pra, duhej të shfrytëzonim më mirë si hapësirën në data center, ashtu edhe vetë serverët fizikë ku vendosej e gjithë kjo. Inxhinierët tanë të sistemeve nisën një studim të gjerë, në të cilin shqyrtuan shumë variante të ndryshme. Analizuan edhe sistemet e skedarëve në klaster, si PolyCeph dhe Lustre. Aty kishte probleme me performancën dhe operimi ishte mjaft i ndërlikuar, ndaj u hoqën dorë. Provuan gjithashtu të montonin të gjithë dataset-in përmes NFS në çdo makinë, për t'u shkallëzuar në këtë mënyrë. As leximi nuk dha rezultat të mirë; u testuan zgjidhje të ndryshme nga furnitorë të ndryshëm.
Dhe në fund vendosëm të përdorim të ashtuquajturin Storage Area Network.
Këto janë SHD të mëdha, të projektuara pikërisht për ruajtjen e sasive të mëdha të të dhënave. Në thelb janë rafte me disqe, të lidhura me makinat fundore të shpërndarjes përmes fibrës optike. Pra, kemi një grup relativisht të vogël makinash dhe këto SHD, që janë transparente për logjikën tonë të shpërndarjes, domethënë për nginx-in tonë ose çfarëdo zgjidhjeje tjetër, përpunojnë kërkesat për këto fotografi.
Kjo zgjidhje kishte përparësi të qarta. Janë SHD. Janë të orientuara pikërisht për ruajtjen e fotove. Dhe kjo rezulton më ekonomike sesa thjesht të konfigurojmë makina me hard disqe.
Përparësia e dytë.
Kapaciteti u rrit ndjeshëm, domethënë në shumë më pak hapësirë mund të vendosnim shumë më tepër storage.
Por pati edhe mangësi, të cilat u zbuluan mjaft shpejt. Me rritjen e numrit të përdoruesve dhe të ngarkesës mbi këtë sistem, filluan të shfaqeshin probleme me performancën. Dhe problemi këtu është mjaft i qartë: çdo SHD, e projektuar për të ruajtur shumë fotografi në pak hapësirë, zakonisht vuan nga leximi intensiv. Në fakt, kjo vlen edhe për çdo cloud storage apo çfarëdo zgjidhjeje të ngjashme. Sot nuk ekziston një storage ideal, pafundësisht i shkallëzueshëm, ku mund të fusësh çfarë të duash dhe që ta përballojë në mënyrë të shkëlqyer leximin. Sidomos leximin e rastësishëm.
Ashtu si në rastin e photos tona, sepse fotografitë kërkohen në mënyrë jo sekuenciale dhe kjo ndikon shumë në performancën e tyre.
Edhe sipas shifrave të sotme, nëse kemi diku më shumë se 500 RPS për foto për një makinë të lidhur me storage, problemet fillojnë menjëherë. Dhe kjo ishte mjaft keq për ne, sepse numri i përdoruesve po rritet dhe gjithçka vetëm sa do të përkeqësohej. Duhej ta optimizonim disi.
Për ta optimizuar, në atë kohë vendosëm, natyrisht, të shihnim profilin e ngarkesës: çfarë po ndodh në të vërtetë dhe çfarë duhet optimizuar.
Dhe këtu gjithçka punon në favorin tonë.
Siç e thashë tashmë në slajdin e parë: kemi 80 mijë kërkesa leximi në sekondë, ndërsa vetëm 3,5 milionë ngarkime në ditë. Pra, diferenca është me tre rende madhësie. Është e qartë se duhet optimizuar leximi dhe praktikisht është e qartë edhe si.
Ka edhe një moment të vogël. Specifika e shërbimit është e tillë që përdoruesi regjistrohet, ngarkon një fotografi, pastaj fillon të shohë aktivisht njerëz të tjerë, t’i pëlqejë ata, dhe profili i tij u shfaqet aktivisht përdoruesve të tjerë. Më pas ai gjen ose nuk gjen një partner, sipas rastit, dhe për njëfarë kohe ndalon së përdoruri shërbimin. Pikërisht në periudhën kur është aktiv, fotot e tij janë shumë të kërkuara — ato shikohen nga shumë njerëz. Sapo ndalon së bëri këtë, ai del mjaft shpejt nga këto shfaqje intensive te përdoruesit e tjerë që kishte më parë, dhe fotot e tij pothuajse nuk kërkohen më.
Pra, ne kemi një dataset shumë të vogël hot. Por mbi të ka jashtëzakonisht shumë kërkesa. Dhe zgjidhja më e dukshme këtu është të shtojmë cache.
Cache me LRU do t’i zgjidhë të gjitha problemet tona. Çfarë bëjmë?
Para cluster-it tonë të madh me storage shtojmë edhe një cluster tjetër, relativisht të vogël, që quhet photoscache. Në thelb, ky është thjesht një proxy cache.
Si funksionon kjo nga brenda? Këtu është përdoruesi ynë, këtu është storage. Gjithçka si më parë. Çfarë shtojmë mes tyre?
Kjo është thjesht një makinë me disk fizik lokal, të shpejtë. Për shembull, me SSD. Dhe në këtë disk ruhet një cache lokale.
Si duket kjo? Përdoruesi dërgon një kërkesë për një foto. NGINX e kërkon fillimisht në cache lokale. Nëse nuk gjendet, bën thjesht proxy_pass te storage ynë, e shkarkon fotografinë prej andej dhe ia jep përdoruesit.
Por kjo është shumë banale dhe nuk është e qartë se çfarë ndodh brenda. Në praktikë funksionon afërsisht kështu.
Cache është e ndarë logjikisht në tre shtresa. Kur them “tre shtresa”, kjo nuk do të thotë se aty ka ndonjë sistem të ndërlikuar. Jo, kushtimisht janë thjesht tre direktori në file system:
- Ky është buffer-i ku përfundojnë fotografitë e sapongarkuara nga proxy.
- Ky është cache hot, ku ruhen fotografitë që po kërkohen aktivisht tani.
- Dhe cache cold, ku fotografitë zhvendosen gradualisht nga cache hot kur marrin më pak request-e.
Që kjo të funksionojë, duhet ta menaxhojmë disi këtë cache, të lëvizim fotografitë brenda saj, e kështu me radhë. Edhe ky është një proces shumë primitiv.
Nginx për çdo kërkesë thjesht shkruan në RAMDisk një access.log, ku tregon rrugën drejt fotos që sapo ka shërbyer (rrugë relative, natyrisht) dhe nga cili segment është shërbyer. Pra, aty mund të shkruhet «photo 1» dhe më pas ose buffer, ose cache i nxehtë, ose cache i ftohtë, ose proxy.
Në varësi të kësaj, duhet të marrim një vendim se çfarë të bëjmë me foton.
Në çdo makinë kemi një daemon të vogël që punon vazhdimisht, lexon këtë log dhe mban në memorien e vet statistika për përdorimin e fotove të ndryshme.
Ai thjesht mbledh të dhënat aty, mban numëruesit dhe periodikisht bën sa vijon. Fotot që kërkohen shpesh, për të cilat vijnë shumë request-e, i zhvendos në cache-in e nxehtë, pavarësisht se ku ndodhen.
Fotot që kërkohen rrallë dhe kanë filluar të kërkohen edhe më rrallë, i zhvendos gradualisht nga cache-i i nxehtë në atë të ftohtë.
Dhe kur në cache na mbaron hapësira, thjesht fillojmë të fshijmë gjithçka nga cache-i i ftohtë pa asnjë përzgjedhje. Dhe, meqë ra fjala, kjo funksionon mirë.
Që fotoja të ruhet menjëherë gjatë proxy-im në buffer, ne përdorim direktivën proxy_store dhe buffer-i është gjithashtu RAMDisk, pra për përdoruesin kjo funksionon shumë shpejt. Kjo sa i përket pjesës së brendshme të vetë serverit të cache-it.
Mbetet pyetja se si t’i shpërndajmë request-et nëpër këta serverë.
Ta zëmë se kemi një cluster me njëzet makina storage dhe tre serverë cache (kështu ndodhi).
Duhet të përcaktojmë disi cilat request-e për cilat foto dhe ku duhet të drejtohen.
Varianti më i thjeshtë është Round Robin. Apo ta bëjmë këtë rastësisht?
Kjo, qartazi, ka një sërë mangësish, sepse në këtë situatë do ta përdorim cache-in shumë joefikasisht. Kërkesat do të përfundojnë në makina të rastësishme: këtu është ruajtur në cache, ndërsa në tjetrën pranë nuk është më. Dhe nëse gjithë kjo do të funksionojë, do të funksionojë shumë keq. Edhe me një numër të vogël makinash në cluster.
Duhet të përcaktojmë në mënyrë të qartë se në cilin server duhet të përfundojë secili request.
Ka një mënyrë të thjeshtë. Marrim hash-in e URL-së ose hash-in e çelësit tonë të sharding-ut që ndodhet në URL dhe e pjesëtojmë pa mbetje me numrin e serverëve. A do të funksionojë? Po, do të funksionojë.
Pra, kemi një request 100% të përcaktuar: për shembull, për një «example_url» të caktuar ai do të përfundojë gjithmonë në serverin me indeks «2», dhe cache do të shfrytëzohet vazhdimisht sa më mirë që të jetë e mundur.
Por në këtë skemë lind një problem me risharding-un. Me risharding nënkuptoj ndryshimin e numrit të serverëve.
Le të supozojmë se klasteri ynë i cache nuk po e përballon më ngarkesën dhe vendosëm të shtojmë edhe një makinë.
E shtojmë.
Tani gjithçka nuk pjesëtohet më saktësisht me tre, por me katër. Si rezultat, pothuajse të gjithë çelësat që kishim më parë, pothuajse të gjitha URL-të, tani ndodhen në serverë të tjerë. I gjithë cache u invalidua menjëherë. Të gjitha request-et u derdhën te klasteri ynë storage, ai u mbingarkua, shërbimi dështoi dhe përdoruesit mbetën të pakënaqur. Kështu nuk duam të veprojmë.
Edhe ky variant nuk na përshtatet.
Pra, çfarë duhet të bëjmë? Duhet disi ta përdorim cache në mënyrë efikase, ta çojmë vazhdimisht të njëjtin request te i njëjti server, por njëkohësisht të jemi rezistentë ndaj risharding-ut. Dhe një zgjidhje e tillë ekziston; nuk është ndonjë gjë e ndërlikuar. Quhet consistent hashing.
Si duket kjo?
Marrim një funksion të caktuar të çelësit të sharding-ut dhe i shpërndajmë të gjitha vlerat e tij përgjatë një rrethi. Pra, në pikën 0 bashkohen vlerat e tij minimale dhe maksimale. Më pas, në po këtë rreth vendosim të gjithë serverët tanë afërsisht në këtë mënyrë:
Secili server përcaktohet nga një pikë, dhe sektori që shtrihet deri te ai në drejtim të akrepave të orës shërbehet pikërisht nga ky host. Kur na vijnë request-et, e shohim menjëherë se, për shembull, request A — me atë hash-in e vet — shërbehet nga serveri 2. Request B — nga serveri 3. E kështu me radhë.
Çfarë ndodh në këtë situatë gjatë risharding-ut?
Ne nuk e invaliduojmë të gjithë cache, si më parë, dhe nuk i zhvendosim të gjithë çelësat; përkundrazi, zhvendosim secilin sektor për një distancë të vogël, në mënyrë që në hapësirën e liruar, në mënyrë figurative, të futet serveri ynë i gjashtë që duam të shtojmë, dhe e vendosim aty.
Sigurisht, në një situatë të tillë edhe çelësat zhvendosen. Por zhvendosen shumë më pak se më parë. Dhe shohim që dy çelësat tanë të parë mbetën në serverët e tyre, ndërsa serveri i cache-it ndryshoi vetëm për çelësin e fundit. Kjo funksionon mjaft efektivisht dhe, nëse shtoni hoste të rinj në mënyrë inkrementale, këtu nuk ka ndonjë problem të madh. I shtoni gradualisht, prisni derisa cache-i të mbushet sërish, dhe gjithçka funksionon mirë.
Pyetja e vetme mbetet në rast dështimesh. Le të supozojmë se na ka dalë jashtë funksionit një makinë.
Dhe nuk do të donim aspak që në atë moment ta rigjeneronim këtë hartë, të invalidonim një pjesë të cache-it e kështu me radhë, nëse, për shembull, makina u rebootua dhe ne duhet disi t’i shërbejmë kërkesat. Ne thjesht mbajmë në secilin lokacion një photo cache rezervë, i cili shërben si zëvendësim për çdo makinë që ka dalë aktualisht jashtë funksionit. Dhe nëse papritur një server bëhet i padisponueshëm, trafiku shkon atje. Natyrisht, aty nuk ka asnjë cache, pra është i ftohtë, por të paktën kërkesat e përdoruesve përpunohen. Nëse ky është një interval i shkurtër, e përballojmë krejtësisht pa problem. Thjesht rritet ngarkesa mbi storage. Nëse intervali është i gjatë, atëherë mund të marrim një vendim — ta heqim këtë server nga harta ose jo, ose ndoshta ta zëvendësojmë me një tjetër.
Kaq sa i përket sistemit të cache-it. Le të shohim rezultatet.
Në pamje të parë, këtu nuk ka asgjë të ndërlikuar. Por një mënyrë e tillë e menaxhimit të cache-it na dha një hit rate rreth 98%. Pra, nga këto 80 mijë request-e në sekondë, vetëm 1600 arrijnë te storage-et, dhe kjo është një ngarkesë krejt normale; ato e përballojnë pa problem dhe ne kemi gjithmonë rezervë.
Këta serverë i vendosëm në tre DC-të tona dhe morëm tre pika pranie — Pragë, Miami dhe Hong Kong.
Kështu, ato janë të vendosura pak a shumë lokalisht pranë secilit prej tregjeve tona të synuara.
Dhe si një bonus i këndshëm, morëm këtë proxy cache, ku CPU në fakt qëndron kryesisht pa ngarkesë, sepse për shpërndarjen e përmbajtjes nuk nevojitet aq shumë. Dhe aty, me ndihmën e NGINX + Lua, kemi implementuar shumë logjikë utilitare.
Për shembull, mund të eksperimentojmë me webp ose progressive jpeg (këto janë formate moderne dhe efikase), të shohim si ndikon kjo te trafiku, të marrim vendime të caktuara, t’i aktivizojmë për vende të veçanta etj.; të bëjmë resize dinamik ose crop të fotografive në kohë reale.
Ky është një use case i mirë kur, për shembull, keni një aplikacion mobil që shfaq foto, dhe aplikacioni nuk dëshiron të shpenzojë CPU-në e pajisjes së klientit për të kërkuar një foto të madhe dhe më pas për ta bërë resize në një madhësi të caktuar që të futet në view. Ne mund të specifikojmë thjesht disa parametra dinamikë në URL në një UPort hipotetik, dhe photo cache do ta bëjë vetë resize foton. Si rregull, ai zgjedh madhësinë që ekziston fizikisht në disk dhe që është sa më afër asaj të kërkuar, pastaj e downscale-on sipas koordinatave të përcaktuara.
Meqë ra fjala, kemi publikuar me qasje të hapur regjistrimet video të pesë viteve të fundit të konferencës së zhvilluesve të sistemeve me ngarkesë të lartë . Shikoni, mësoni, ndani dhe abonohuni në .
Gjithashtu, mund të shtojmë aty shumë logjikë produkti. Për shembull, sipas parametrave të URL-së mund të shtojmë watermark-e të ndryshme, mund të bëjmë blur të fotografive, t’i turbullojmë ose t’i pikselizojmë. Kjo përdoret kur duam të shfaqim fotografinë e një personi, por nuk duam t’i tregojmë fytyrën; funksionon shumë mirë, dhe e gjithë kjo është e implementuar këtu.
Çfarë morëm? Morëm tre pika pranisë, një hit rate të mirë, dhe në të njëjtën kohë CPU-ja në këto makina nuk rri më kot. Tani, sigurisht, ajo është bërë më e rëndësishme se më parë. Duhet të përdorim makina më të fuqishme, por ia vlen.
Sa i përket shpërndarjes së fotografive, këtu gjithçka është mjaft e qartë dhe e dukshme. Mendoj se nuk po zbuloj diçka të re; kështu funksionon praktikisht çdo CDN.
Dhe ka shumë gjasa që një dëgjues me përvojë të ketë bërë pyetjen: pse të mos e zëvendësojmë thjesht gjithçka me CDN? Do të ishte afërsisht e njëjta gjë, sepse të gjitha CDN-të moderne i mbështesin këto funksione. Dhe këtu ka disa arsye.
E para janë fotografitë.
Ky është një nga elementët kyç të infrastrukturës sonë dhe na duhet sa më shumë kontroll mbi to. Nëse bëhet fjalë për një zgjidhje nga një vendor i jashtëm dhe ju nuk keni asnjë kontroll mbi të, do ta keni mjaft të vështirë ta menaxhoni këtë kur keni një dataset të madh dhe një fluks shumë të lartë kërkesash nga përdoruesit.
Do të jap një shembull. Tani, në infrastrukturën tonë, për shembull, në rast problemesh apo zhurmash të dyshimta “nga poshtë”, ne mund të hyjmë në makinë dhe të bëjmë debug aty, nëse mund të themi kështu. Mund të shtojmë mbledhjen e metrikeve që na duhen vetëm neve, mund të eksperimentojmë dhe të shohim se si kjo do të ndikojë në grafikë, e kështu me radhë. Aktualisht mblidhen shumë statistika për këtë klaster cache, dhe ne i shqyrtojmë periodikisht duke hetuar për një kohë të gjatë anomali të ndryshme. Nëse kjo do të ishte në anën e CDN, do të ishte shumë më e vështirë për t’u kontrolluar. Ose, për shembull, nëse ndodh një incident, ne e dimë çfarë ka ndodhur, dimë si të punojmë me të dhe si ta zgjidhim. Ky është përfundimi i parë.
Përfundimi i dytë është gjithashtu më tepër historik, sepse sistemi po zhvillohet prej kohësh dhe në faza të ndryshme ka pasur shumë kërkesa të ndryshme biznesi, të cilat jo gjithmonë përshtaten me konceptin e CDN.
Dhe pika që del nga e mëparshmja është –
Te photo cache ne kemi shumë logjikë specifike, e cila jo gjithmonë mund të shtohet sipas kërkesës. Nuk ka shumë gjasa që ndonjë CDN, me kërkesën tuaj, të shtojë gjëra të personalizuara për ju. Për shembull, enkriptimin e URL-ve, nëse nuk doni që klienti të mund të ndryshojë diçka. Mund të doni të ndryshoni URL-në në server dhe ta enkriptoni, e më pas të dërgoni këtu disa parametra dinamikë.
Çfarë përfundimi del vetvetiu? Në rastin tonë, CDN nuk është një alternativë shumë e mirë.
Ndërsa në rastin tuaj, nëse keni kërkesa specifike biznesi, mund ta zbatoni vetë fare qetësisht atë që ju tregova. Dhe me një profil të ngjashëm ngarkese, kjo do të funksionojë shkëlqyeshëm.
Por nëse ju duhet një zgjidhje e përgjithshme dhe detyra nuk është shumë specifike, mund të zgjidhni fare qetësisht një CDN. Ose nëse për ju koha dhe burimet kanë shumë më tepër rëndësi sesa kontrolli.
Dhe CDN-të moderne kanë pothuajse gjithçka për të cilën ju tregova tani, me përjashtim të pak a shumë disa veçorive.
Kaq sa i përket shpërndarjes së fotografive.
Tani le të ecim pak më tej në retrospektivën tonë dhe të flasim për ruajtjen.
Ishte viti 2013.
Serverët e cache-it u shtuan dhe problemet me performance u zhdukën. Gjithçka shkonte mirë. Dataset po rritej. Në vitin 2013 kishim rreth 80 serverë të lidhur me storage-et dhe rreth 40 serverë cache në secilin DC. Kjo përbënte 560 terabajt të dhënash në çdo DC, pra afërsisht një petabajt në total.
Dhe me rritjen e dataset-it nisën të rriteshin ndjeshëm edhe kostot operative. Si shfaqej kjo?
Në këtë skemë të paraqitur — me SAN, me makinat e lidhura me të dhe me cache-in — ka shumë pika dështimi. Nëse me dështimet e serverëve cache ishim marrë më parë dhe aty gjithçka ishte pak a shumë e parashikueshme dhe e qartë, atëherë në anën e storage-it situata ishte shumë më e keqe.
Së pari, vetë Storage Area Network (SAN), i cili mund të dështojë.
Së dyti, ai është i lidhur me makinat fundore përmes fibrës optike. Mund të ketë probleme me kartat optike dhe me switch-et.
Sigurisht, këto nuk janë aq të shpeshta sa problemet me vetë SAN-in, por megjithatë edhe këto janë pika dështimi.
Më tej është vetë makina që është e lidhur me storage-in. Edhe ajo mund të dalë jashtë funksionit.
Pra, në total kemi tre pika dështimi.
Përveç pikave të dështimit, mirëmbajtja e vetë storage-eve është e rëndë.
Kjo është një sistem kompleks me shumë komponentë dhe inxhinierët e sistemeve shpesh e kanë të vështirë ta menaxhojnë.
Dhe pika e fundit, më e rëndësishmja. Nëse ndodh një dështim në cilëndo nga këto tre pika, ekziston një probabilitet real që të humbasim të dhënat e përdoruesit, sepse sistemi i skedarëve mund të korruptohet.
Le të supozojmë se sistemi i skedarëve është korruptuar. Rikuperimi i tij, së pari, zgjat shumë — me vëllime të mëdha të dhënash kjo mund të marrë një javë. Dhe së dyti, në fund ka shumë gjasa të marrim një grumbull skedarësh të paqartë, të cilët pastaj duhet t’i përputhim disi me fotografitë e përdoruesve. Dhe ne rrezikojmë të humbasim të dhëna. Rreziku është mjaft i lartë. Dhe sa më shpesh të ndodhin situata të tilla, sa më shumë probleme të ketë në gjithë këtë zinxhir, aq më i lartë bëhet ky rrezik.
Diçka duhej bërë për këtë. Dhe vendosëm që thjesht duhej të rezervonim të dhënat. Në fakt, kjo ishte një zgjidhje e qartë dhe e mirë. Çfarë bëmë?
Kështu dukej serveri ynë që më parë ishte i lidhur me storage-in. Ky ishte një particion kryesor, thjesht një pajisje blloku, që në thelb ishte një mount në një storage të largët përmes fibrës optike.
Thjesht shtuam një particion të dytë.
Vendosëm pranë një storage të dytë (fatmirësisht, nga ana e kostos kjo nuk ishte aq e shtrenjtë) dhe e quajtëm seksioni i backup-it. Edhe ai është i lidhur me fibër dhe ndodhet në të njëjtën makinë. Por na duhej të sinkronizonim disi të dhënat mes tyre.
Këtu thjesht krijojmë pranë tij një radhë asinkrone.
Ajo nuk është shumë e ngarkuar. E dimë që kemi pak shkrime. Radha është thjesht një tabelë në MySQL, ku shkruhen rreshta të tipit «duhet bërë backup i kësaj fotografie». Me çdo ndryshim ose gjatë upload-it, ne kopjojmë nga seksioni kryesor te backup-i në mënyrë asinkrone ose thjesht me ndonjë background worker.
Dhe në këtë mënyrë kemi gjithmonë dy seksione konsistente. Edhe nëse një pjesë e këtij sistemi del jashtë funksionit, ne gjithmonë mund ta ndërrojmë seksionin kryesor me backup-in dhe gjithçka do të vazhdojë të punojë.
Por për shkak të kësaj rritet ndjeshëm ngarkesa e leximit, sepse përveç klientëve që lexojnë nga seksioni kryesor, pasi fillimisht e kërkojnë fotografinë aty (sepse aty është më e freskët), dhe vetëm më pas e kërkojnë te backup-i nëse nuk e gjejnë (por këtë e bën thjesht NGINX), sistemi ynë i backup-it tani lexon gjithashtu nga seksioni kryesor. Jo se kjo ishte ndonjë ngushticë, por nuk donim të rrisnim ngarkesën, në thelb, kot së koti.
Dhe shtuam një disk të tretë, një SSD të vogël, dhe e quajtëm buffer.
Si funksionon tani kjo.
Përdoruesi e bën upload foton në buffer, më pas hidhet një event në radhë që ajo duhet të kopjohet në dy seksione. Ajo kopjohet, dhe fotografia për njëfarë kohe (ta zëmë, një ditë) qëndron në buffer, e vetëm më pas pastrohet prej andej. Kjo e përmirëson shumë user experience, sepse përdoruesi e ngarkon fotografinë dhe, si rregull, menjëherë pas kësaj fillojnë request-et, ose ai vetë e përditëson faqen, bën refresh. Por e gjithë kjo varet nga aplikacioni që bën upload-in.
Ose, për shembull, persona të tjerë të cilëve ai sapo ka filluar t'ua tregojë, menjëherë pas kësaj fotografie dërgojnë request-e. Ajo ende nuk është në cache, por kërkesa e parë ndodh shumë shpejt. Në thelb, njësoj si me cache-in e fotove. Storage-i i ngadaltë nuk përfshihet fare këtu. Dhe kur pas një dite ajo të pastrohet, ose tashmë është cache-uar në shtresën tonë të caching-ut, ose me shumë gjasë nuk i duhet më askujt. Pra, user experience këtu u përmirësua ndjeshëm falë këtyre veprimeve të thjeshta.
Dhe, më e rëndësishmja: ne ndaluam së humburi të dhëna.
Le të themi kështu, ne ndaluam e mundshme të humbnim të dhëna, sepse në fakt pothuajse nuk i humbnim fare. Por rreziku ekzistonte. E shohim që një zgjidhje e tillë, sigurisht, është e mirë, por i ngjan disi zbutjes së simptomave të problemit, në vend që ta zgjidhë atë plotësisht. Dhe këtu mbetën ende disa probleme.
Së pari, pika e dështimit në formën e vetë host-it fizik, mbi të cilin punon e gjithë kjo infrastrukturë, nuk u zhduk askund.
Së dyti, mbetën problemet me SAN-et, mbeti mirëmbajtja e tyre e rëndë etj. Kjo nuk ishte domosdoshmërisht një faktor kritik, por donim të provonim të jetonim disi edhe pa këtë.
Dhe ne bëmë versionin e tretë (në thelb, të dytin në fakt) — versionin me rezervim. Si dukej kjo?
Kjo është ajo që kishim –
Problemet kryesore i kishim nga fakti që ky është një host fizik.
Së pari, ne heqim SAN-et, sepse duam të eksperimentojmë, duam të provojmë thjesht disqe lokale.
Kjo ishte tashmë periudha 2014-2015, dhe në atë kohë situata me disqet dhe me kapacitetin e tyre brenda një host-i ishte përmirësuar ndjeshëm. Vendosëm: pse të mos e provojmë.
Dhe më pas thjesht marrim ndarjen tonë të backup-it dhe e zhvendosim fizikisht në një makinë të veçantë.
Kështu, marrim një skemë të tillë. Kemi dy makina që ruajnë të njëjtat dataset-e. Ato e rezervojnë plotësisht njëra-tjetrën dhe sinkronizojnë të dhënat përmes rrjetit nëpërmjet një radhe asinkrone në të njëjtin MySQL.
Pse kjo funksionon mirë? Sepse kemi pak shkrime. Domethënë, nëse shkrimet do të ishin të krahasueshme me leximet, ndoshta do të kishim ndonjë overhead rrjeti dhe probleme. Ka pak shkrime, shumë lexime — kjo mënyrë funksionon mirë, pra ne kopjojmë fotografi midis këtyre dy serverëve mjaft rrallë.
Si funksionon kjo, nëse e shohim pak më në detaje.
Upload. Balancuesi thjesht zgjedh host-e të rastësishëm nga çifti dhe bën upload tek ai. Natyrisht, ai kryen health checks, kontrollon që makina të mos ketë rënë. Pra, ai bën upload të fotove vetëm në një server aktiv, e më pas përmes një radhe asinkrone e gjithë kjo kopjohet te serveri fqinj. Me upload-in gjithçka është maksimalisht e thjeshtë.
Me task-un është pak më e ndërlikuar.
Këtu na ndihmoi Lua, sepse në NGINX-in vanilla një logjikë e tillë është e vështirë të zbatohet. Fillimisht bëjmë një request te serveri i parë dhe kontrollojmë nëse fotografia ndodhet aty, sepse potencialisht mund të jetë ngarkuar, për shembull, te nyja fqinje, ndërsa këtu ende të mos ketë mbërritur. Nëse fotografia është aty, kjo është shumë mirë. E dorëzojmë menjëherë te klienti dhe, nëse duhet, e ruajmë në cache.
Nëse nuk është aty, thjesht bëjmë një kërkesë te nyja fqinje dhe e marrim prej andej me garanci.
Pra, sërish mund të thuhet se mund të ketë probleme me performancën, sepse round trip-et e vazhdueshme — fotografia u ngarkua, këtu nuk është, ndaj bëjmë dy kërkesa në vend të njërës — teorikisht duhet ta ngadalësojnë punën.
Në rastin tonë, kjo nuk funksionon ngadalë.
Ne mbledhim shumë metrika për këtë sistem, dhe hit rate-i i këtij mekanizmi është rreth 95%. Kjo do të thotë se vonesa e këtij backup-i është e vogël dhe, falë kësaj, pothuajse gjithmonë, pasi fotografia është ngarkuar, e marrim që në përpjekjen e parë pa bërë dy kërkesa diku tjetër.
Pra, çfarë tjetër fituam dhe çfarë është kaq e bukur këtu?
Më parë kishim ndarjen kryesore dhe backup për ruajtje, dhe lexonim prej tyre në mënyrë sekuenciale. Domethënë, gjithmonë kërkonim fillimisht në kryesoren dhe më pas në backup. Ky ishte një skenar i vetëm leximi.
Tani shfrytëzojmë leximin nga dy makina njëkohësisht. Kërkesat i shpërndajmë me Round Robin. Në një përqindje të vogël rastesh bëjmë dy kërkesa. Por në përgjithësi tani kemi dyfish më shumë rezervë për lexim sesa kishim më parë. Dhe ngarkesa është ulur ndjeshëm si te makinat që shërbejnë për dorëzim, ashtu edhe te storage-et që kishim në atë kohë.
Sa i përket fault tolerance. Në fakt, pikërisht për këtë po luftonim kryesisht. Dhe këtu fault tolerance doli vërtet shkëlqyeshëm.
Një makinë del jashtë funksioni.
Asnjë problem! Inxhinieri i sistemit madje nuk ka pse të zgjohet natën, mund të presë deri në mëngjes, nuk do të ndodhë asgjë e keqe.
Edhe nëse, gjatë dështimit të kësaj makine, bie edhe radha, përsëri nuk ka asnjë problem: log-u fillimisht do të grumbullohet në makinën që mbetet aktive, më pas do të futet në radhë dhe më vonë do të dërgohet te ajo makinë që do të rikthehet në punë pas njëfarë kohe.
E njëjta gjë vlen edhe për maintenance. Thjesht fikim një nga makinat, e heqim manualisht nga të gjitha pool-et, trafiku ndalon së shkuari tek ajo, bëjmë ndonjë maintenance, rregullojmë çfarë duhet dhe më pas e rikthejmë në punë; ky backup sinkronizohet sërish mjaft shpejt. Pra, humbja e një makine për një ditë rikuperohet brenda pak minutash. Kjo është vërtet shumë pak. Sa i përket fault tolerance, po e them sërish, këtu gjithçka është shumë mirë.
Çfarë përfundimesh mund të nxjerrim nga kjo skemë rezervimi?
Fituam fault tolerance.
Operim i thjeshtë. Meqenëse makinat kanë disqe lokale, kjo është shumë më e përshtatshme nga pikëpamja e inxhinierëve që punojnë me to.
Fituam një rezervë të dyfishtë për lexim.
Ky është një bonus shumë i mirë, përveç fault tolerance.
Por ka edhe probleme. Tani zhvillimi i disa feature-ve që lidhen me këtë është bërë shumë më kompleks, sepse sistemi është bërë 100% eventually consistent.
Duhet, fjala vjen, që në ndonjë background job të mendojmë vazhdimisht: “Në cilin server po ekzekutohemi tani?”, “A është vërtet këtu fotografia më e përditësuar?” e kështu me radhë. Natyrisht, e gjithë kjo është mbështjellë me wrapper-a dhe për programuesin që shkruan logjikën e biznesit kjo është transparente. Por, megjithatë, është shfaqur një shtresë e madhe dhe komplekse. Gjithsesi, jemi të gatshëm ta pranojmë këtë në këmbim të përfitimeve që morëm prej saj.
Edhe këtu lind sërish një lloj konflikti.
Në fillim thashë se ruajtja e gjithçkaje në disqe lokale është gjë e keqe. Ndërsa tani po them se kjo na pëlqeu.
Po, vërtet, me kalimin e kohës situata ka ndryshuar shumë dhe tani kjo qasje ka fituar shumë avantazhe. Së pari, ne përfitojmë një operim shumë më të thjeshtë.
Së dyti, është më performante, sepse nuk kemi këta kontrollues automatikë dhe lidhjet me raftet e disqeve.
Atje ka një infrastrukturë gjigante, ndërsa këtu janë thjesht disa disqe të montuara në RAID direkt në këtë makinë.
Por ka edhe mangësi.
Kjo është afërsisht 1,5 herë më e shtrenjtë sesa përdorimi i SAN-ve, edhe me çmimet e sotme. Prandaj vendosëm të mos e konvertojmë me aq guxim të gjithë klasterin tonë të madh në makina me disqe lokale dhe të ruajmë një zgjidhje hibride.
Rreth gjysma e makinave tona punojnë me disqe të ngurtë (epo, jo tamam gjysma — ndoshta rreth 30%). Pjesa tjetër janë makina të vjetra, ku më parë përdorej skema e parë e rezervimit. Thjesht i rikonfiguruam, sepse nuk na duheshin as të dhëna të reja, as diçka tjetër — vetëm zhvendosëm mount-et nga një host fizik në dy.
Kështu fituam një rezervë të madhe në lexim dhe e zgjeruam shkallën. Nëse më parë në një makinë montonim një storage, tani në një palë montojmë katër, për shembull. Dhe kjo funksionon normalisht.
Le të bëjmë një përmbledhje të shkurtër të asaj që arritëm, për çfarë luftuam dhe nëse ia dolëm.
Përfundime
Kemi përdorues — plot 33 milionë.
Kemi tre pika prezence — Pragë, Miami, Hong Kong.
Aty ndodhet shtresa e cache-it, e përbërë nga makina me disqe lokale të shpejta (SSD), ku funksionon një mekanizëm i thjeshtë me NGINX, access.log-un e tij dhe daemonë në Python që e përpunojnë gjithë këtë dhe menaxhojnë cache-in.
Nëse dëshironi, në projektin tuaj, nëse fotot nuk janë aq kritike sa për ne, ose nëse për ju balanca mes kontrollit dhe shpejtësisë së zhvillimit e kostos së burimeve anon nga ana tjetër, atëherë mund ta zëvendësoni pa problem me një CDN — CDN-të moderne e bëjnë këtë shumë mirë.
Më pas vjen shtresa e ruajtjes, ku kemi klastera me çifte makinash që rezervojnë njëra-tjetrën; skedarët kopjohen në mënyrë asinkrone nga njëra te tjetra sa herë që ka ndryshim.
Një pjesë e këtyre makinave punojnë me disqe të ngurtë lokalë.
Një pjesë e këtyre makinave janë të lidhura me SAN-e.
Nga njëra anë, kjo është më e përshtatshme për operim dhe pak më performuese; nga ana tjetër, është e leverdishme për nga dendësia e vendosjes dhe çmimi për gigabajt.
Ky është një përmbledhje e shkurtër e arkitekturës që morëm dhe e mënyrës si u zhvillua e gjithë kjo.
Edhe disa këshilla të tjera të thjeshta, fare bazike.
Së pari, nëse një ditë vendosni se duhet urgjentisht të përmirësoni gjithçka në infrastrukturën tuaj të fotove, mateni fillimisht, sepse ka shumë mundësi që në fakt të mos ketë nevojë për asnjë përmirësim.
Po jap një shembull. Kemi një klaster makinash që shpërndan fotografi nga attachment-i në biseda, dhe aty ende funksionon skema që nga viti 2009, dhe askush nuk vuan prej kësaj. Të gjithë janë mirë, të gjithëve u pëlqen.
Që të mund ta matni, fillimisht vendosni sa më shumë metrika, analizojini dhe më pas vendosni saktësisht me çfarë nuk jeni të kënaqur dhe çfarë duhet përmirësuar. Për këto matje, ne kemi një mjet shumë të mirë që quhet Pinba.
Ai ju lejon të grumbulloni statistika shumë të detajuara nga NGINX për çdo request, kodet e përgjigjeve dhe shpërndarjen e kohëve — gjithçka që ju nevojitet. Ka bindings për sisteme të ndryshme analitike, kështu që më pas mund t’i shikoni të gjitha këto në mënyrë të qartë dhe komode.
Së pari mateni — pastaj përmirësojeni.
Më tej. Leximin e optimizojmë me cache, shkrimin me sharding, por kjo është pjesa e qartë.
Më tej. Nëse sapo po filloni të ndërtoni sistemin tuaj, është shumë më mirë t’i ruani fotot si skedarë immutable. Kështu eliminoni menjëherë një klasë të tërë problemesh me invalidimin e cache, me mënyrën se si logjika duhet të gjejë versionin e saktë të fotos e kështu me radhë.
Për shembull, ngarkuat një foto, pastaj e rrotulluat — bëjeni në mënyrë që kjo të jetë fizikisht një skedar tjetër. Pra, mos mendoni: tani do të kursej pak hapësirë, do ta ruaj në të njëjtin skedar dhe do t’i ndryshoj versionin. Kjo pothuajse gjithmonë funksionon keq dhe më pas sjell shumë dhimbje koke.
Pika tjetër. Për resize në kohë reale.
Më parë, kur përdoruesit uploadonin një foto, ne krijonim menjëherë një numër të madh dimensionesh për çdo rast përdorimi, për klientë të ndryshëm, dhe të gjitha ruheshin në disk. Tani kemi hequr dorë nga kjo qasje.
Kemi lënë vetëm tre madhësi kryesore: të vogël, të mesme dhe të madhe. Gjithçka tjetër thjesht e downscale-ojmë nga madhësia që vjen menjëherë pas asaj që është kërkuar në Uport, thjesht bëjmë downscale dhe ia dorëzojmë përdoruesit.
CPU i shtresës së cache këtu rezulton shumë më i lirë sesa të rigjeneronim vazhdimisht këto madhësi në çdo storage. Për shembull, nëse duam të shtojmë një të re, kjo është punë për një muaj — të ekzekutosh kudo një skript që ta bëjë gjithë këtë me kujdes, pa e rrëzuar cluster-in. Pra, nëse keni mundësi të zgjidhni tani, është më mirë të krijoni sa më pak madhësi fizike, por gjithsesi të keni njëfarë shpërndarjeje, le të themi tre. Dhe gjithçka tjetër thjesht ta ndryshoni në madhësi në kohë reale me ndihmën e moduleve të gatshme. Sot kjo është shumë e lehtë dhe e arritshme.
Ndërsa backup inkremental asinkron është një zgjidhje e mirë.
Siç ka treguar praktika jonë, një skemë e tillë funksionon shkëlqyeshëm me kopjimin e vonuar të skedarëve të ndryshuar.
Pika e fundit është po aq e qartë. Nëse në infrastrukturën tuaj tani nuk ka probleme të tilla, por ka diçka që mund të prishet, ajo patjetër do të prishet sapo ngarkesa të rritet qoftë edhe pak. Prandaj është më mirë ta mendoni këtë paraprakisht dhe të mos përballeni me probleme. Kaq kisha.
Kontakte
»
»
Ky raport është transkriptimi i një prej prezantimeve më të mira në konferencën e zhvilluesve të sistemeve me ngarkesë të lartë . Deri në konferencën HighLoad++ 2017 ka mbetur më pak se një muaj.
Ne e kemi tashmë gati , dhe tani po formohet në mënyrë aktive programi.
Edhe këtë vit vazhdojmë të eksplorojmë temën e arkitekturave dhe shkallëzimit:
- / Игорь Васильев
- / Дмитрий Егоров
- / Анатолий Пласковский
- / Роман Шеховцов, Алексей Громатчиков
- / Филипп Дельгядо
Gjithashtu, disa nga këto materiale i përdorim në kursin tonë online për zhvillimin e sistemeve me ngarkesë të lartë — është një seri e përzgjedhur posaçërisht emailesh, artikujsh, materialesh dhe videosh. Që tani, në tekstin tonë mësimor ka më shumë se 30 materiale unike. Bashkohuni!
Burimi: habr.com
