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ë sot është se ne ruajmë rreth 3 petabajt fotografi të përdoruesve. Çdo ditë përdoruesit tanë ngarkojnë rreth 3,5 milionë foto të reja, dhe ngarkesa e leximit është rreth 80 mijë kërkesa në sekondë. Kjo është shumë për fundin tonë, dhe ndonjëherë ka vështirësi me këtë.
Unë do të flas për dizajnin e këtij sistemi, i cili ruan dhe dërgon foto në përgjithësi, dhe do ta shikoj nga këndvështrimi i një zhvilluesi. Do të ketë një retrospektivë të shkurtër se si u zhvillua, ku do të përvijoj pikat kryesore, por do të flas vetëm në mënyrë më të detajuar për zgjidhjet që po përdorim aktualisht.
Tani le të fillojmë.
Siç thashë, kjo do të jetë një retrospektivë, dhe për ta nisur diku, le të marrim shembullin më të zakonshëm.
Ne kemi një detyrë të përbashkët, duhet të pranojmë, ruajmë dhe dërgojmë fotografi të përdoruesve. Në këtë formë, detyra është e përgjithshme, ne mund të përdorim çdo gjë:
- ruajtja moderne në renë kompjuterike,
- një zgjidhje në kuti, nga e cila ka edhe shumë tani;
- Ne mund të konfigurojmë disa makineri në qendrën tonë të të dhënave dhe të vendosim hard disqe të mëdha në to dhe të ruajmë fotot atje.
Badoo historikisht - si tani ashtu edhe atëherë (në kohën kur ishte vetëm në fillimet e tij) - jeton në serverët e tij, brenda DC-ve tona. Prandaj, ky opsion ishte optimal për ne.
Ne sapo morëm disa makina, i quajtëm "foto" dhe morëm një grup që ruan fotot. Por duket sikur diçka mungon. Në mënyrë që e gjithë kjo të funksionojë, duhet të përcaktojmë disi se në cilën makinë do të ruajmë cilat foto. Dhe këtu nuk ka nevojë të hapet Amerika.
Ne shtojmë një fushë në ruajtjen tonë me informacione për përdoruesit. Ky do të jetë çelësi i ndarjes. Në rastin tonë, ne e quajtëm atë place_id, dhe ky vend id tregon vendin ku ruhen fotot e përdoruesve. Ne bëjmë harta.
Në fazën e parë, kjo mund të bëhet edhe me dorë - themi se një foto e këtij përdoruesi me një vend të tillë do të zbresë në një server të tillë. Falë kësaj harte, ne e dimë gjithmonë kur një përdorues ngarkon një foto, ku ta ruajmë atë dhe dimë se nga ta japim.
Kjo është një skemë absolutisht e parëndësishme, por ka avantazhe mjaft domethënëse. E para është se është e thjeshtë, siç thashë, dhe e dyta është se me këtë qasje ne mund të shkallëzojmë lehtësisht horizontalisht duke ofruar thjesht makina të reja dhe duke i shtuar ato në hartë. Ju nuk keni nevojë të bëni asgjë tjetër.
Kështu ishte për ne për disa kohë.
Kjo ishte rreth vitit 2009. Ata dërguan makina, dorëzuan ...
Dhe në një moment filluam të vërejmë se kjo skemë ka disavantazhe të caktuara. Cilat janë disavantazhet?
Para së gjithash, ka kapacitet të kufizuar. Ne nuk mund të grumbullojmë aq shumë disqe të ngurtë në një server fizik sa do të dëshironim. Dhe ky është bërë një problem i caktuar me kalimin e kohës dhe me rritjen e grupit të të dhënave.
Dhe e dyta. Ky është një konfigurim atipik i makinave, pasi makina të tilla janë të vështira për t'u ripërdorur në disa grupe të tjera; ato janë mjaft specifike, d.m.th. ato duhet të jenë të dobëta në performancë, por në të njëjtën kohë me një hard disk të madh.
Kjo ishte e gjitha për vitin 2009, por, në parim, këto kërkesa janë ende të rëndësishme sot. Ne kemi një retrospektivë, kështu që në vitin 2009 gjithçka ishte krejtësisht e keqe me këtë.
Dhe pika e fundit është çmimi.
Çmimi ishte shumë i lartë në atë kohë dhe ne duhej të kërkonim disa alternativa. Ato. na duhej që disi të shfrytëzonim më mirë hapësirën në qendrat e të dhënave dhe serverët fizikë në të cilët ndodhet e gjithë kjo. Dhe inxhinierët tanë të sistemit filluan një studim të madh në të cilin shqyrtuan një sërë opsionesh të ndryshme. Ata gjithashtu shikuan sistemet e skedarëve të grumbulluar si PolyCeph dhe Luster. Kishte probleme me performancën dhe funksionim mjaft të vështirë. Ata refuzuan. Ne u përpoqëm të montonim të gjithë grupin e të dhënave nëpërmjet NFS në secilën makinë, në mënyrë që ta rrisim disi atë. Leximi gjithashtu shkoi keq, ne provuam zgjidhje të ndryshme nga shitës të ndryshëm.
Dhe në fund, ne vendosëm të përdornim të ashtuquajturin Rrjeti i Zonës së ruajtjes.
Këto janë SHD të mëdha që janë krijuar posaçërisht për ruajtjen e sasive të mëdha të të dhënave. Ato janë rafte me disqe që janë montuar në makinat përfundimtare të daljes optike. Se. ne kemi një lloj grupi makinerish, mjaft të vogla, dhe këto SHD, të cilat janë transparente për logjikën tonë të dërgimit, d.m.th. që nginx-i ynë apo dikush tjetër të shërbejë kërkesa për këto foto.
Ky vendim kishte avantazhe të dukshme. Ky është SHD. Ajo ka për qëllim ruajtjen e fotove. Kjo funksionon më lirë sesa thjesht pajisja e makinerive me hard disk.
Plus i dytë.
Kjo është se kapaciteti është bërë shumë më i madh, d.m.th. ne mund të akomodojmë shumë më tepër ruajtje në një vëllim shumë më të vogël.
Por kishte edhe disavantazhe që u shfaqën mjaft shpejt. Ndërsa numri i përdoruesve dhe ngarkesa në këtë sistem u rrit, filluan të shfaqen probleme të performancës. Dhe problemi këtu është mjaft i dukshëm - çdo SHD i krijuar për të ruajtur shumë foto në një vëllim të vogël, si rregull, vuan nga leximi intensiv. Kjo është në të vërtetë e vërtetë për çdo ruajtje të resë kompjuterike ose ndonjë gjë tjetër. Tani ne nuk kemi një ruajtje ideale që do të ishte pafundësisht e shkallëzueshme, ju mund të futni gjithçka në të dhe do të toleronte shumë mirë leximet. Sidomos leximet e rastësishme.
Siç është rasti me fotot tona, sepse fotot kërkohen në mënyrë jokonsistente dhe kjo do të ndikojë shumë në performancën e tyre.
Edhe sipas shifrave të sotme, nëse marrim diku më shumë se 500 RPS për fotot në një makinë me të cilën është lidhur memoria, problemet tashmë fillojnë. Dhe ishte mjaft keq për ne, sepse numri i përdoruesve po rritet, gjërat vetëm sa do të përkeqësohen. Kjo duhet të optimizohet disi.
Për të optimizuar, ne vendosëm në atë kohë, padyshim, të shikonim profilin e ngarkesës - çfarë, në përgjithësi, po ndodh, çfarë duhet të optimizohet.
Dhe këtu gjithçka na shkon në dorë.
E thashë tashmë në rrëshqitjen e parë: kemi 80 mijë kërkesa leximi në sekondë me vetëm 3,5 milionë ngarkime në ditë. Kjo do të thotë, kjo është një ndryshim prej tre rendesh të madhësisë. Është e qartë se leximi duhet të optimizohet dhe është praktikisht e qartë se si.
Ka edhe një pikë të vogël. Specifikat e shërbimit janë të tilla që një person regjistrohet, ngarkon një foto, pastaj fillon të shikojë në mënyrë aktive njerëzit e tjerë, si ata, dhe u tregohet në mënyrë aktive njerëzve të tjerë. Pastaj ai gjen një shok ose nuk gjen një shok, varet se si do të dalë dhe ndalon përdorimin e shërbimit për një kohë. Në këtë moment, kur ai e përdor, fotot e tij janë shumë të nxehta - ato janë të kërkuara, shumë njerëz i shikojnë ato. Sapo ai ndalon së bërëi këtë, shumë shpejt ai heq dorë nga ekspozimi ndaj njerëzve të tjerë si më parë, dhe fotot e tij pothuajse nuk kërkohen kurrë.
Ato. Ne kemi një grup të dhënash shumë të vogël të nxehtë. Por në të njëjtën kohë ka shumë kërkesa për të. Dhe një zgjidhje krejtësisht e qartë këtu është shtimi i një cache.
Një cache me LRU do të zgjidhë të gjitha problemet tona. Cfare po bejme?
Shtojmë një tjetër relativisht të vogël përpara grupit tonë të madh me ruajtje, i cili quhet fotokache. Ky është në thelb vetëm një përfaqësues i memories.
Si funksionon nga brenda? Këtu është përdoruesi ynë, këtu është ruajtja. Gjithçka është njësoj si më parë. Çfarë shtojmë në mes?
Është thjesht një makinë me një disk fizik lokal, i cili është i shpejtë. Kjo është me një SSD, për shembull. Dhe një lloj cache lokale ruhet në këtë disk.
Si duket? Përdoruesi dërgon një kërkesë për një foto. NGINX e kërkon atë së pari në cache lokale. Nëse jo, atëherë thjesht kaloni proxy_pass në ruajtjen tonë, shkarkoni foton nga atje dhe ia jepni përdoruesit.
Por kjo është shumë banale dhe është e paqartë se çfarë po ndodh brenda. Punon diçka si kjo.
Cache është logjikisht i ndarë në tre shtresa. Kur them "tre shtresa", kjo nuk do të thotë se ekziston një lloj sistemi kompleks. Jo, këto janë kushtimisht vetëm tre drejtori në sistemin e skedarëve:
- Ky është një tampon ku shkojnë fotot e sapo shkarkuara nga një përfaqësues.
- Ky është një memorie e nxehtë që ruan fotot e kërkuara aktualisht në mënyrë aktive.
- Dhe një memorie e ftohtë, ku fotot nxirren gradualisht nga cache e nxehtë kur u vijnë më pak kërkesa.
Që kjo të funksionojë, ne duhet të menaxhojmë disi këtë cache, duhet të riorganizojmë fotot në të, etj. Ky është gjithashtu një proces shumë primitiv.
Nginx thjesht shkruan në RAMDisk access.log për çdo kërkesë, në të cilën tregon shtegun drejt fotografisë që ka shërbyer aktualisht (rruga relative, natyrisht) dhe cila ndarje i është shërbyer. Ato. mund të thotë "foto 1" dhe më pas ose një buffer, ose një memorie e nxehtë, ose një memorie e ftohtë ose një përfaqësues.
Në varësi të kësaj, ne duhet të vendosim disi se çfarë të bëjmë me foton.
Ne kemi një demon të vogël që funksionon në çdo makinë që lexon vazhdimisht këtë regjistër dhe ruan statistika për përdorimin e disa fotografive në kujtesën e saj.
Ai thjesht grumbullon atje, mban sportelet dhe bën periodikisht sa vijon. Ai i zhvendos fotot e kërkuara në mënyrë aktive, për të cilat ka shumë kërkesa, në cache-in e nxehtë, kudo që ndodhen.
Fotot që kërkohen rrallë dhe janë bërë më rrallë, shtyhen gradualisht nga memoria e nxehtë në atë të ftohtë.
Dhe kur na mbaron hapësira në cache, thjesht fillojmë të fshijmë çdo gjë nga cache e ftohtë pa dallim. Dhe nga rruga, kjo funksionon mirë.
Në mënyrë që fotografia të ruhet menjëherë gjatë proksimit në buffer, ne përdorim direktivën proxy_store dhe buferi është gjithashtu një RAMDisk, d.m.th. për përdoruesin funksionon shumë shpejt. Kjo ka të bëjë me të brendshmet e vetë serverit të memorizimit.
Pyetja e mbetur është se si të shpërndahen kërkesat nëpër këta serverë.
Le të themi se ka një grup prej njëzet makinerish ruajtëse dhe tre serverë memorie (kështu ndodhi).
Ne duhet të përcaktojmë disi se cilat kërkesa janë për cilat foto dhe ku t'i vendosim ato.
Opsioni më i zakonshëm është Round Robin. Apo e bëni atë rastësisht?
Kjo padyshim ka një sërë disavantazhesh sepse ne do ta përdornim cache-në në mënyrë shumë joefikase në një situatë të tillë. Kërkesat do të vendosen në disa makineri të rastësishme: këtu u ruajt në memorie, por në tjetrën nuk është më. Dhe nëse e gjithë kjo funksionon, do të jetë shumë keq. Edhe me një numër të vogël makinash në grup.
Ne duhet të përcaktojmë në një farë mënyre në mënyrë të qartë se cili server duhet të vendosë cilën kërkesë.
Ka një mënyrë banale. Ne marrim hash-in nga URL-ja ose hash-in nga çelësi ynë i ndarjes, i cili është në URL, dhe e ndajmë atë me numrin e serverëve. A do të funksionojë? do.
Ato. Ne kemi një kërkesë 2%, për shembull, për disa "example_url" do të vendoset gjithmonë në server me indeksin "XNUMX" dhe cache do të hidhet vazhdimisht sa më mirë që të jetë e mundur.
Por ka një problem me rishardimin në një skemë të tillë. Reharding - dua të them ndryshimin e numrit të serverëve.
Le të supozojmë se grupi ynë i memorizimit nuk mund të përballojë më dhe vendosim të shtojmë një makinë tjetër.
Le të shtojmë.
Tani gjithçka ndahet jo me tre, por me katër. Kështu, pothuajse të gjithë çelësat që kishim dikur, pothuajse të gjitha URL-të tani jetojnë në serverë të tjerë. I gjithë cache u zhvlerësua thjesht për një moment. Të gjitha kërkesat ranë në grupin tonë të ruajtjes, ai u bë i sëmurë, dështimi i shërbimit dhe përdoruesit e pakënaqur. Unë nuk dua ta bëj këtë.
Ky opsion nuk na përshtatet as neve.
Se. cfare duhet te bejme? Ne duhet të përdorim disi me efikasitet cache, të vendosim të njëjtën kërkesë në të njëjtin server pa pushim, por të jemi rezistent ndaj rishardimit. Dhe ekziston një zgjidhje e tillë, nuk është aq e komplikuar. Quhet hash i qëndrueshëm.
Si duket?
Ne marrim një funksion nga çelësi i ndarjes dhe shpërndajmë të gjitha vlerat e tij në rreth. Ato. në pikën 0, vlerat minimale dhe maksimale të saj konvergjojnë. Më pas, ne vendosim të gjithë serverët tanë në të njëjtin rreth në përafërsisht këtë mënyrë:
Çdo server përcaktohet nga një pikë, dhe sektori që shkon drejt tij në drejtim të akrepave të orës, në përputhje me rrethanat, shërbehet nga ky host. Kur na vijnë kërkesat, ne shohim menjëherë se, për shembull, kërkesa A - ka një hash atje - dhe shërbehet nga serveri 2. Kërkesa B - nga serveri 3. E kështu me radhë.
Çfarë ndodh në këtë situatë gjatë rishardimit?
Ne nuk e zhvlerësojmë të gjithë cache-in, si më parë, dhe nuk i zhvendosim të gjithë çelësat, por e zhvendosim secilin sektor në një distancë të shkurtër në mënyrë që, duke folur relativisht, serveri ynë i gjashtë, të cilin duam të shtojmë, të përshtatet në hapësirën e lirë dhe e shtojmë aty.
Natyrisht, në një situatë të tillë edhe çelësat largohen. Por ata lëvizin shumë më të dobët se më parë. Dhe ne shohim që dy çelësat tanë të parë mbetën në serverët e tyre, dhe serveri i memorizimit ndryshoi vetëm për çelësin e fundit. Kjo funksionon në mënyrë mjaft efikase, dhe nëse shtoni hoste të rinj gradualisht, atëherë nuk ka asnjë problem të madh këtu. Ju shtoni dhe shtoni pak nga pak, prisni derisa cache të mbushet përsëri dhe gjithçka funksionon mirë.
Pyetja e vetme mbetet me refuzimet. Le të supozojmë se një lloj makine është jashtë funksionit.
Dhe ne nuk do të dëshironim vërtet ta rigjeneronim këtë hartë në këtë moment, të zhvlerësonim një pjesë të cache-it, e kështu me radhë, nëse, për shembull, makina ishte rindezur dhe ne kemi nevojë të bëjmë disi kërkesat e shërbimit. Ne thjesht mbajmë një memorie rezervë fotografish në çdo faqe, e cila vepron si një zëvendësim për çdo makinë që aktualisht është në funksion. Dhe nëse papritmas një nga serverët tanë bëhet i padisponueshëm, trafiku shkon atje. Natyrisht, ne nuk kemi ndonjë cache atje, d.m.th. është ftohtë, por të paktën kërkesat e përdoruesve janë duke u përpunuar. Nëse ky është një interval i shkurtër, atëherë e përjetojmë plotësisht me qetësi. Thjesht ka më shumë ngarkesë në ruajtje. Nëse ky interval është i gjatë, atëherë tashmë mund të marrim një vendim - ta heqim ose jo këtë server nga harta, ose ndoshta ta zëvendësojmë me një tjetër.
Bëhet fjalë për sistemin e memorizimit. Le të shohim rezultatet.
Duket se këtu nuk ka asgjë të komplikuar. Por kjo metodë e menaxhimit të cache-it na dha një normë mashtrimi prej rreth 98%. Ato. Nga këto 80 mijë kërkesa në sekondë, vetëm 1600 arrijnë në ruajtje dhe kjo është një ngarkesë krejtësisht normale, e durojnë me qetësi, ne kemi gjithmonë një rezervë.
Ne i vendosëm këta serverë në tre nga DC-të tona dhe morëm tre pika prezence - Pragë, Miami dhe Hong Kong.
Se. ato janë pak a shumë të vendosura në nivel lokal në secilin prej tregjeve tona të synuara.
Dhe si një bonus i mirë, ne morëm këtë përfaqësues të memories, në të cilën CPU është në të vërtetë boshe, sepse nuk është aq i nevojshëm për të shërbyer përmbajtje. Dhe atje, duke përdorur NGINX+ Lua, ne zbatuam shumë logjikë utilitare.
Për shembull, mund të eksperimentojmë me webp ose jpeg progresiv (këto janë formate moderne efektive), të shohim se si ndikon në trafik, të marrim disa vendime, ta mundësojmë atë për vende të caktuara, etj.; bëni ndryshime dinamike të përmasave ose shkurtoni fotot menjëherë.
Ky është një rast i mirë përdorimi kur, për shembull, keni një aplikacion celular që shfaq foto dhe aplikacioni celular nuk dëshiron të harxhojë CPU-në e klientit duke kërkuar një foto të madhe dhe më pas ta ndryshoni madhësinë e saj në një madhësi të caktuar në mënyrë që ta shtyjë atë në pamja. Ne thjesht mund të specifikojmë në mënyrë dinamike disa parametra në URL-në e kushtëzuar UPort dhe memoria e fotografisë do të ndryshojë madhësinë e vetë fotos. Si rregull, ai do të zgjedhë madhësinë që kemi fizikisht në disk, sa më afër që të jetë e mundur me atë të kërkuar dhe do ta zvogëlojë atë në koordinata specifike.
Nga rruga, ne kemi bërë publike regjistrimet video të pesë viteve të fundit të konferencës së zhvilluesve të sistemeve me ngarkesë të lartë . Shikoni, mësoni, shpërndani dhe abonohuni në .
Mund të shtojmë edhe shumë logjikë produkti atje. Për shembull, ne mund të shtojmë filigranë të ndryshëm duke përdorur parametrat e URL-së, mund të turbullojmë, turbullojmë ose pikselojmë fotot. Kjo është kur ne duam të tregojmë një foto të një personi, por nuk duam të tregojmë fytyrën e tij, kjo funksionon mirë, gjithçka zbatohet këtu.
Çfarë morëm? Ne morëm tre pika prezence, një shkallë të mirë mashtrimi dhe në të njëjtën kohë nuk kemi CPU boshe në këto makina. Ai tani është bërë, natyrisht, më i rëndësishëm se më parë. Ne duhet t'i japim vetes makina më të forta, por ia vlen.
Kjo ka të bëjë me rikthimin e fotografive. Gjithçka këtu është mjaft e qartë dhe e qartë. Unë mendoj se nuk e kam zbuluar Amerikën, pothuajse çdo CDN funksionon në këtë mënyrë.
Dhe, ka shumë të ngjarë, një dëgjues i sofistikuar mund të ketë një pyetje: pse të mos ndryshoni gjithçka në CDN? Do të ishte pothuajse e njëjta gjë; të gjitha CDN-të moderne mund ta bëjnë këtë. Dhe ka një sërë arsyesh.
E para janë fotografitë.
Kjo është një nga pikat kyçe të infrastrukturës sonë dhe ne kemi nevojë për sa më shumë kontroll mbi të. Nëse kjo është një lloj zgjidhjeje nga një shitës i palës së tretë dhe nuk keni asnjë fuqi mbi të, do të jetë mjaft e vështirë për ju të jetoni me të kur keni një grup të madh të dhënash dhe kur keni një fluks shumë të madh të kërkesave të përdoruesve.
Më lejoni t'ju jap një shembull. Tani, me infrastrukturën tonë, ne, për shembull, në rast të ndonjë problemi ose goditjesh nëntokësore, mund të shkojmë te makineri dhe të ngatërrohemi atje, për shembull. Mund të shtojmë koleksionin e disa metrikave që na duhen vetëm, mund të eksperimentojmë disi, të shohim se si kjo ndikon në grafikët, e kështu me radhë. Tani po mblidhen shumë statistika për këtë grup memorie. Dhe ne e shikojmë periodikisht dhe kalojmë një kohë të gjatë duke eksploruar disa anomali. Nëse do të ishte në anën e CDN-së, do të ishte shumë më e vështirë të kontrollohej. Ose, për shembull, nëse ndodh një lloj aksidenti, ne e dimë se çfarë ka ndodhur, ne dimë si të jetojmë me të dhe si ta kapërcejmë atë. Ky është përfundimi i parë.
Përfundimi i dytë është gjithashtu mjaft historik, sepse sistemi ka qenë duke u zhvilluar për një kohë të gjatë, dhe ka pasur shumë kërkesa të ndryshme biznesi në faza të ndryshme, dhe ato jo gjithmonë përshtaten në konceptin CDN.
Dhe pika që rrjedh nga ajo e mëparshme është
Kjo sepse në cache-et e fotografive kemi shumë logjikë specifike, të cilat nuk mund të shtohen gjithmonë sipas kërkesës. Nuk ka gjasa që ndonjë CDN t'ju shtojë disa gjëra të personalizuara me kërkesën tuaj. Për shembull, kodimi i URL-ve nëse nuk dëshironi që klienti të jetë në gjendje të ndryshojë diçka. Dëshironi të ndryshoni URL-në në server dhe ta enkriptoni atë dhe më pas të dërgoni disa parametra dinamikë këtu.
Çfarë përfundimi sugjeron kjo? Në rastin tonë, CDN nuk është një alternativë shumë e mirë.
Dhe në rastin tuaj, nëse keni ndonjë kërkesë specifike biznesi, atëherë mund ta zbatoni mjaft lehtë atë që ju tregova vetë. Dhe kjo do të funksionojë në mënyrë të përkryer me një profil të ngjashëm ngarkese.
Por nëse keni një lloj zgjidhjeje të përgjithshme dhe detyra nuk është shumë specifike, mund të merrni me siguri një CDN. Ose nëse koha dhe burimet janë më të rëndësishme për ju sesa kontrolli.
Dhe CDN-të moderne kanë pothuajse gjithçka që ju thashë tani. Me përjashtim të disa veçorive plus ose minus.
Bëhet fjalë për dhënien e fotove.
Tani le të ecim përpara pak në retrospektivën tonë dhe të flasim për ruajtjen.
2013 po kalonte.
U shtuan serverët e memorizimit, problemet e performancës u larguan. Cdo gje eshte ne rregull. Seti i të dhënave po rritet. Që nga viti 2013, ne kishim rreth 80 serverë të lidhur me hapësirën ruajtëse dhe rreth 40 memorie në çdo DC. Kjo është 560 terabajt të dhëna në çdo DC, d.m.th. rreth një petabajt në total.
Dhe me rritjen e grupit të të dhënave, kostot operative filluan të rriten ndjeshëm. Çfarë do të thoshte kjo?
Në këtë diagram që është vizatuar - me një SAN, me makina dhe cache të lidhura me të - ka shumë pika dështimi. Nëse do të kishim trajtuar më parë dështimin e serverëve të memorizimit, gjithçka ishte pak a shumë e parashikueshme dhe e kuptueshme, por nga ana e ruajtjes gjithçka ishte shumë më keq.
Së pari, vetë rrjeti i zonës së ruajtjes (SAN), i cili mund të dështojë.
Së dyti, ajo është e lidhur nëpërmjet optikës me makinat fundore. Mund të ketë probleme me kartat optike dhe kandelat.
Sigurisht, nuk ka aq shumë prej tyre sa me vetë SAN, por, megjithatë, këto janë gjithashtu pika dështimi.
Tjetra është vetë makina, e cila është e lidhur me ruajtjen. Mund të dështojë gjithashtu.
Në total kemi tre pikë dështimi.
Më tej, përveç pikave të dështimit, ka mirëmbajtje të rëndë të vetë ruajtjes.
Ky është një sistem kompleks me shumë komponentë dhe inxhinierët e sistemeve mund ta kenë të vështirë të punojnë me të.
Dhe pika e fundit, më e rëndësishme. Nëse ndonjë nga këto tre pika dështon, ne kemi një shans jo zero për të humbur të dhënat e përdoruesit sepse sistemi i skedarëve mund të rrëzohet.
Le të themi se sistemi ynë i skedarëve është i prishur. Së pari, rikuperimi i tij kërkon një kohë të gjatë - mund të zgjasë një javë me një sasi të madhe të dhënash. Dhe së dyti, në fund me shumë mundësi do të përfundojmë me një mori skedarësh të pakuptueshëm që do të duhet të kombinohen disi në fotot e përdoruesve. Dhe ne rrezikojmë të humbasim të dhënat. Rreziku është mjaft i lartë. Dhe sa më shpesh të ndodhin situata të tilla dhe sa më shumë probleme të lindin në të gjithë këtë zinxhir, aq më i lartë është ky rrezik.
Diçka duhej bërë për këtë. Dhe ne vendosëm që thjesht duhet të kopjojmë të dhënat. Kjo është në fakt një zgjidhje e qartë dhe e mirë. Çfarë kemi bërë?
Kështu dukej serveri ynë kur ishte i lidhur më parë me hapësirën ruajtëse. Ky është një seksion kryesor, është thjesht një pajisje bllok që në fakt përfaqëson një montim për ruajtje në distancë nëpërmjet optikës.
Sapo shtuam një seksion të dytë.
Ne vendosëm një ruajtje të dytë pranë tij (për fat të mirë, nuk është aq i shtrenjtë për sa i përket parave) dhe e quajtëm atë një ndarje rezervë. Gjithashtu lidhet me optikë dhe ndodhet në të njëjtën makinë. Por ne duhet të sinkronizojmë disi të dhënat midis tyre.
Këtu ne thjesht bëjmë një radhë asinkron pranë.
Ajo nuk është shumë e zënë. Ne e dimë se nuk kemi të dhëna të mjaftueshme. Një radhë është vetëm një tabelë në MySQL në të cilën shkruhen rreshta si "duhet të kopjoni këtë foto". Me çdo ndryshim ose ngarkim, ne kopjojmë nga ndarja kryesore në kopje rezervë duke përdorur një asinkron ose thjesht një lloj punonjësi në sfond.
Dhe kështu ne kemi gjithmonë dy seksione të qëndrueshme. Edhe nëse një pjesë e këtij sistemi dështon, ne gjithmonë mund ta ndryshojmë ndarjen kryesore me një kopje rezervë dhe gjithçka do të vazhdojë të funksionojë.
Por për shkak të kësaj, ngarkesa e leximit rritet shumë, sepse... përveç klientëve që lexojnë nga seksioni kryesor, sepse ata së pari shikojnë foton atje (aty është më e fundit), dhe më pas e kërkojnë në kopje rezervë, nëse nuk e kanë gjetur (por NGINX thjesht e bën këtë), sistemi ynë është gjithashtu një rezervë plus që tani lexohet nga ndarja kryesore. Nuk është se kjo ishte një pengesë, por nuk doja të rrisja ngarkesën, në thelb, ashtu si kjo.
Dhe ne shtuam një disk të tretë, i cili është një SSD i vogël, dhe e quajtëm atë një buffer.
Si funksionon tani.
Përdoruesi ngarkon një foto në tampon, më pas një ngjarje hidhet në radhë që tregon se ajo duhet të kopjohet në dy seksione. Ajo kopjohet, dhe fotografia jeton në tampon për ca kohë (të themi, një ditë), dhe vetëm atëherë pastrohet prej andej. Kjo përmirëson shumë përvojën e përdoruesit, sepse përdoruesi ngarkon një foto, si rregull, kërkesat fillojnë të ndjekin menjëherë, ose ai vetë e përditësoi faqen dhe e rifreskoi atë. Por gjithçka varet nga aplikacioni që bën ngarkimin.
Ose, për shembull, njerëz të tjerë të cilëve ai filloi të tregohej menjëherë dërgojnë kërkesa pas kësaj fotoje. Nuk është ende në cache; kërkesa e parë ndodh shumë shpejt. Në thelb e njëjtë si nga një cache fotografish. Ruajtja e ngadaltë nuk është e përfshirë fare në këtë. Dhe kur një ditë më vonë ajo pastrohet, ose është ruajtur në memorien tonë në shtresën tonë të memories, ose, ka shumë të ngjarë, askush nuk ka nevojë për të. Ato. Përvoja e përdoruesit këtu është rritur shumë mirë për shkak të manipulimeve të tilla të thjeshta.
Epo, dhe më e rëndësishmja: ne ndaluam së humburi të dhëna.
Le të themi se ndaluam potencialisht humbasin të dhënat, sepse ne nuk i humbëm ato. Por ekzistonte rreziku. Ne shohim që kjo zgjidhje është sigurisht e mirë, por është paksa si zbutja e simptomave të problemit, në vend që ta zgjidhë plotësisht. Dhe disa probleme mbeten këtu.
Së pari, kjo është një pikë dështimi në formën e vetë hostit fizik mbi të cilin funksionon e gjithë kjo makineri; ajo nuk është zhdukur.
Së dyti, ka ende probleme me SAN-et, mirëmbajtja e tyre e rëndë etj. Nuk ishte se ishte një faktor kritik, por doja të përpiqesha të jetoja disi pa të.
Dhe ne bëmë versionin e tretë (në fakt, i dyti në fakt) - versioni i rezervimit. Si dukej?
Kjo është ajo që ishte -
Problemet tona kryesore janë me faktin se ky është një mikpritës fizik.
Së pari, ne po heqim SAN-et sepse duam të eksperimentojmë, duam të provojmë vetëm disqet e ngurtë lokalë.
Kjo është tashmë 2014-2015, dhe në atë kohë situata me disqet dhe kapaciteti i tyre në një host u bë shumë më i mirë. Ne vendosëm pse të mos e provojmë.
Dhe pastaj ne thjesht marrim ndarjen tonë rezervë dhe e transferojmë fizikisht në një makinë të veçantë.
Kështu, marrim këtë diagram. Ne kemi dy makina që ruajnë të njëjtat grupe të dhënash. Ata kopjojnë plotësisht njëri-tjetrin dhe sinkronizojnë të dhënat përmes rrjetit përmes një radhe asinkrone në të njëjtën MySQL.
Pse kjo funksionon mirë është sepse ne kemi pak regjistrime. Ato. nëse shkrimi do të ishte i krahasueshëm me leximin, ndoshta do të kishim një lloj rrjeti dhe probleme. Ka pak shkrim, shumë lexim - kjo metodë funksionon mirë, d.m.th. Ne rrallë kopjojmë foto midis këtyre dy serverëve.
Si funksionon kjo, nëse shikoni pak më në detaje.
Ngarkoni. Balancuesi thjesht zgjedh hoste të rastësishëm me një palë dhe ngarkon në të. Në të njëjtën kohë, ai bën natyrshëm kontrolle shëndetësore dhe sigurohet që makina të mos bjerë jashtë. Ato. ai ngarkon foto vetëm në një server të drejtpërdrejtë dhe më pas përmes një radhe asinkrone të gjitha i kopjohen fqinjit të tij. Me ngarkimin gjithçka është jashtëzakonisht e thjeshtë.
Detyra është pak më e vështirë.
Lua na ndihmoi këtu, sepse mund të jetë e vështirë të bësh një logjikë të tillë në vanilje NGINX. Ne fillimisht bëjmë një kërkesë në serverin e parë, shikoni nëse fotografia është atje, sepse potencialisht mund të ngarkohet, për shembull, te një fqinj, por ende nuk ka mbërritur këtu. Nëse fotografia është atje, kjo është mirë. Ne ia japim menjëherë klientit dhe, mundësisht, e ruajmë në memorie.
Nëse nuk është aty, ne thjesht i bëjmë një kërkesë fqinjit tonë dhe jemi të garantuar ta marrim atë nga atje.
Se. përsëri mund të themi: mund të ketë probleme me performancën, sepse ka udhëtime të vazhdueshme vajtje-ardhje - fotografia është ngarkuar, nuk është këtu, ne po 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ë sërë metrikash në këtë sistem, dhe norma inteligjente e kushtëzuar e një mekanizmi të tillë është rreth 95%. Ato. Vonesa e këtij rezervimi është e vogël, dhe për këtë ne jemi pothuajse të garantuar, pasi fotoja të jetë ngarkuar, do ta marrim herën e parë dhe nuk do të duhet të shkojmë askund dy herë.
Pra, çfarë tjetër kemi që është vërtet e bukur?
Më parë, ne kishim ndarjen kryesore rezervë, dhe lexuam prej tyre në mënyrë sekuenciale. Ato. Ne gjithmonë kërkonim fillimisht në atë kryesore, dhe më pas në rezervë. Ishte një lëvizje.
Tani ne përdorim leximin nga dy makina njëherësh. Ne shpërndajmë kërkesat duke përdorur Round Robin. Në një përqindje të vogël të rasteve ne bëjmë dy kërkesa. Por në përgjithësi, tani kemi dy herë më shumë lexime se sa kishim më parë. Dhe ngarkesa u zvogëlua shumë si në makineritë dërguese ashtu edhe direkt në makineritë e magazinimit, të cilat i kishim edhe ne në atë kohë.
Sa i përket tolerancës ndaj gabimeve. Në fakt, për këtë kemi luftuar kryesisht. Me tolerancën e gabimeve, gjithçka doli mirë këtu.
Një makinë prishet.
Nuk ka problem! Një inxhinier sistemi mund të mos zgjohet as natën, ai do të presë deri në mëngjes, asgjë e keqe nuk do të ndodhë.
Nëse edhe nëse kjo makinë dështon, radha është jashtë funksionit, nuk ka as probleme, trungu thjesht do të grumbullohet fillimisht në makinën e gjallë dhe më pas do të shtohet në radhë dhe më pas në makinën që do hyjnë në funksion pas një kohe.
E njëjta gjë me mirëmbajtjen. Thjesht fikim njërën nga makinat, e nxjerrim manualisht nga të gjitha pishinat, ndalon marrjen e trafikut, bëjmë një lloj mirëmbajtjeje, modifikojmë diçka, më pas e kthejmë në shërbim dhe ky rezervë kapet mjaft shpejt. Ato. në ditë, koha e ndërprerjes së një makine arrin brenda disa minutash. Kjo është vërtet shumë pak. Me tolerancën e fajit, e them përsëri, gjithçka është e mirë këtu.
Çfarë përfundimesh mund të nxirren nga kjo skemë e tepricës?
Ne kemi tolerancë ndaj fajit.
Lehtë për t'u përdorur. Meqenëse makinat kanë hard disk lokal, kjo është shumë më e përshtatshme nga pikëpamja operacionale për inxhinierët që punojnë me të.
Ne morëm një pagesë të dyfishtë për lexim.
Ky është një bonus shumë i mirë përveç tolerancës ndaj gabimeve.
Por ka edhe probleme. Tani kemi një zhvillim shumë më kompleks të disa veçorive që lidhen me këtë, sepse sistemi është bërë 100% përfundimisht i qëndrueshëm.
Ne duhet, të themi, në ndonjë punë në sfond, të mendojmë vazhdimisht: "Në cilin server po punojmë tani?", "A ka vërtet një foto aktuale këtu?" etj. Kjo, natyrisht, është e gjitha e përfunduar, dhe për programuesin që shkruan logjikën e biznesit, është transparente. Por, megjithatë, kjo shtresë e madhe komplekse është shfaqur. Por ne jemi gati ta durojmë këtë në këmbim të të mirave që morëm prej saj.
Dhe këtu përsëri lind një konflikt.
Unë thashë në fillim se ruajtja e gjithçkaje në hard disqet lokale është e keqe. Dhe tani them që na pëlqeu.
Po, me të vërtetë, me kalimin e kohës situata ka ndryshuar shumë, dhe tani kjo qasje ka shumë përparësi. Së pari, kemi një funksionim shumë më të thjeshtë.
Së dyti, është më produktiv, sepse ne nuk i kemi këta kontrollues automatikë ose lidhje me raftet e diskut.
Ka një sasi të madhe makinerie atje, dhe këto janë vetëm disa disqe që janë mbledhur këtu në makinë në një bastisje.
Por ka edhe disavantazhe.
Kjo është afërsisht 1,5 herë më e shtrenjtë se përdorimi i SAN-ve edhe me çmimet e sotme. Prandaj, vendosëm të mos e kthenim me guxim të gjithë grupin tonë të madh në makina me hard disk lokal dhe vendosëm të lëmë një zgjidhje hibride.
Gjysma e makinerive tona punojnë me hard disk (mirë, jo gjysma - ndoshta 30 përqind). Dhe pjesa tjetër janë makina të vjetra që kanë pasur skemën e parë të rezervimit. Ne thjesht i rimontuam ato, pasi nuk kishim nevojë për të dhëna të reja apo ndonjë gjë tjetër, thjesht i zhvendosëm montimet nga një host fizik në dy.
Dhe tani kemi një rezervë të madhe leximi dhe e zgjeruam atë. Nëse më parë kemi montuar një ruajtje në një makinë, tani ne montojmë katër, për shembull, në një palë. Dhe funksionon mirë.
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.
Rezultatet e
Ne kemi përdorues - deri në 33 milionë.
Ne kemi tre pika prezence - Pragë, Miami, Hong Kong.
Ato përmbajnë një shtresë memorie, e cila përbëhet nga makina me disqe të shpejtë lokalë (SSD), në të cilat funksionojnë makineri të thjeshta nga NGINX, aksesi i tij.log dhe demonët Python, të cilët përpunojnë të gjitha këto dhe menaxhojnë cache.
Nëse dëshironi, jeni në projektin tuaj, nëse fotot nuk janë aq kritike për ju sa janë për ne, ose nëse kontrolli i shkëmbimit me shpejtësinë e zhvillimit dhe kostot e burimeve është në drejtimin tjetër për ju, atëherë mund ta zëvendësoni me siguri. me një CDN, CDN-të moderne janë të mirë.
Më pas vjen shtresa e ruajtjes, në të cilën kemi grupe çiftesh makinash që krijojnë kopje rezervë të njëra-tjetrës, skedarët kopjohen në mënyrë asinkrone nga njëri në tjetrin sa herë që ndryshojnë.
Për më tepër, disa nga këto makina punojnë me hard disk lokal.
Disa nga këto makina janë të lidhura me SAN.
Dhe, nga njëra anë, është më i përshtatshëm për t'u përdorur dhe pak më produktiv, nga ana tjetër, është i përshtatshëm për sa i përket densitetit të vendosjes dhe çmimit për gigabajt.
Kjo është një përmbledhje kaq e shkurtër e arkitekturës së asaj që kemi marrë dhe se si u zhvillua e gjitha.
Disa këshilla të tjera nga kapiteni, shumë të thjeshta.
Së pari, nëse papritmas vendosni se keni nevojë urgjente për të përmirësuar gjithçka në infrastrukturën tuaj fotografike, matni së pari, sepse ndoshta asgjë nuk duhet të përmirësohet.
Më lejoni t'ju jap një shembull. Ne kemi një grup makinerish që dërgojnë foto nga bashkëngjitjet në chat, dhe skema ka funksionuar atje që nga viti 2009 dhe askush nuk po vuan prej saj. Të gjithë janë mirë, të gjithëve u pëlqen gjithçka.
Për të matur, së pari varni një grup metrikash, shikoni ato dhe më pas vendosni me çfarë jeni të pakënaqur dhe çfarë duhet përmirësuar. Për ta matur këtë, ne kemi një mjet të lezetshëm të quajtur Pinba.
Kjo ju lejon të mbledhni statistika shumë të detajuara nga NGINX për çdo kërkesë dhe kode përgjigjeje, si dhe shpërndarjen e kohës - çfarëdo që dëshironi. Ai ka lidhje me të gjitha llojet e sistemeve të ndryshme analitike, dhe më pas mund t'i shikoni të gjitha bukur.
Fillimisht e kemi matur, më pas e kemi përmirësuar.
Me tutje. Ne optimizojmë leximin me cache, shkrimin me ndarje, por kjo është një pikë e qartë.
Me tutje. Nëse sapo po filloni të ndërtoni sistemin tuaj, atëherë është shumë më mirë të bëni fotografi si skedarë të pandryshueshëm. Sepse ju humbni menjëherë një klasë të tërë problemesh me zhvlerësimin e cache-it, me mënyrën se si logjika duhet të gjejë versionin e saktë të fotografisë, etj.
Le të themi se keni ngarkuar njëqind, pastaj e keni rrotulluar, e bëni atë në mënyrë që të ishte një skedar fizikisht i ndryshëm. Ato. nuk ka nevojë të mendoni: tani do të kursej pak hapësirë, do ta shkruaj në të njëjtin skedar, do të ndryshoj versionin. Kjo gjithmonë nuk funksionon mirë dhe shkakton shumë dhimbje koke më vonë.
Pika tjetër. Rreth ndryshimit të madhësisë në fluturim.
Më parë, kur përdoruesit ngarkonin një foto, ne prisnim menjëherë një grup të tërë madhësish për të gjitha rastet, për klientë të ndryshëm, dhe të gjitha ishin në disk. Tani e kemi braktisur këtë.
Ne lamë vetëm tre madhësi kryesore: të vogla, të mesme dhe të mëdha. Ne thjesht zvogëlojmë çdo gjë tjetër nga madhësia që është prapa asaj që na është kërkuar në Uport, ne thjesht bëjmë uljen e shkallës dhe ia japim përdoruesit.
CPU-ja e shtresës së memories këtu rezulton të jetë shumë më e lirë sesa nëse i rigjeneronim vazhdimisht këto madhësi në çdo hapësirë ruajtëse. Le të themi se duam të shtojmë një të re, kjo do të zgjasë një muaj - ekzekutoni një skript kudo që do t'i bënte të gjitha këto mjeshtërisht, pa e shkatërruar grupin. Ato. Nëse keni mundësinë të zgjidhni tani, është më mirë të bëni sa më pak madhësi fizike, por në mënyrë që të paktën një shpërndarje të jetë, të themi, tre. Dhe çdo gjë tjetër mund të ndryshohet thjesht duke përdorur module të gatshme. Gjithçka është shumë e lehtë dhe e arritshme tani.
Dhe rezervimi asinkron në rritje është i mirë.
Siç ka treguar praktika jonë, kjo skemë funksionon mirë me kopjimin e vonuar të skedarëve të ndryshuar.
Pika e fundit është gjithashtu e qartë. Nëse infrastruktura juaj nuk ka probleme të tilla tani, por ka diçka që mund të prishet, patjetër që do të prishet kur të bëhet pak më shumë. Prandaj, është më mirë të mendoni për këtë paraprakisht dhe të mos përjetoni probleme me të. Kjo është gjithçka që doja të thoja.
kontaktet
»
»
Ky raport është një transkript i një prej fjalimeve 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.
Tashmë e kemi gati , orari tani është duke u formuar në mënyrë aktive.
Këtë vit ne vazhdojmë të eksplorojmë temën e arkitekturave dhe shkallëzimit:
- / Igor Vasiliev
- / Dmitry Egorov
- / Anatoly Plaskovsky
- / Roman Shekhovtsov, Alexey Gromatchikov
- / Philip Delgado
Ne përdorim gjithashtu disa nga këto materiale në kursin tonë të trajnimit në internet për zhvillimin e sistemeve me ngarkesë të lartë është një zinxhir letrash, artikujsh, materialesh, videosh të zgjedhura posaçërisht. Teksti ynë shkollor tashmë përmban më shumë se 30 materiale unike. Lidhu!
Burimi: www.habr.com