Shumë startup e kanë kaluar këtë: turma përdoruesish të rinj regjistrohen çdo ditë dhe ekipi i zhvillimit lufton për ta mbajtur shërbimin në funksion.

Është një problem i bukur të kesh, por ka pak informacion të qartë në ueb se si të shkallëzohet me kujdes një aplikacion ueb nga asgjë në qindra mijëra përdorues. Zakonisht ekzistojnë zgjidhje zjarri ose zgjidhje të ngushta (dhe shpesh të dyja). Prandaj, njerëzit përdorin teknika mjaft klishe për të shkallëzuar projektin e tyre amator në diçka vërtet serioze.

Le të përpiqemi të filtrojmë informacionin dhe të shkruajmë formulën bazë. Ne do të shkallëzojmë faqen tonë të re të ndarjes së fotografive Graminsta hap pas hapi nga 1 në 100 përdorues.

Le të shkruajmë se çfarë veprimesh specifike duhet të ndërmerren kur audienca rritet në 10, 100, 1000, 10 dhe 000 njerëz.

1 përdorues: 1 makinë

Pothuajse çdo aplikacion, qoftë një faqe interneti apo një aplikacion celular, ka tre komponentë kryesorë:

• API
• bazën e të dhënave
• klienti (vetë aplikacioni celular ose uebsajti)

Baza e të dhënave ruan të dhëna të qëndrueshme. API shërben kërkesa për dhe rreth këtyre të dhënave. Klienti i transmeton të dhënat përdoruesit.

Arrita në përfundimin se është shumë më e lehtë të flasim për shkallëzimin e një aplikacioni nëse, nga pikëpamja arkitekturore, klienti dhe entitetet API janë plotësisht të ndara.

Kur fillojmë fillimisht ndërtimin e një aplikacioni, të tre komponentët mund të ekzekutohen në të njëjtin server. Në disa mënyra, kjo është e ngjashme me mjedisin tonë të zhvillimit: një inxhinier drejton bazën e të dhënave, API dhe klientin në të njëjtën makinë.

Në teori, ne mund ta vendosim atë në re në një shembull të vetëm DigitalOcean Droplet ose AWS EC2, siç tregohet më poshtë:

Me këtë thënë, nëse do të ketë më shumë se një përdorues në një faqe, pothuajse gjithmonë ka kuptim t'i kushtohet një shtrese bazë të dhënash.

10 përdorues: zhvendosja e bazës së të dhënave në një nivel të veçantë

Ndarja e bazës së të dhënave në shërbime të menaxhuara si Amazon RDS ose Digital Ocean Managed Database do të na shërbejë mirë për një kohë të gjatë. Është pak më e shtrenjtë se vetë-strehimi në një makinë të vetme ose shembull EC2, por me këto shërbime ju merrni shumë shtesa të dobishme nga kutia që do t'ju vijnë në ndihmë në të ardhmen: kopje rezervë në shumë rajone, kopje të leximit, automatik kopje rezervë, dhe më shumë.

Kështu duket sistemi tani:

100 përdorues: zhvendosja e klientit në një nivel të veçantë

Për fat të mirë, përdoruesit tanë të parë e pëlqyen shumë aplikacionin tonë. Trafiku po bëhet më i qëndrueshëm, kështu që është koha për ta zhvendosur klientin në një nivel të veçantë. Duhet theksuar se ndarja entitetet janë një aspekt kyç i ndërtimit të një aplikacioni të shkallëzuar. Duke qenë se një pjesë e sistemit merr më shumë trafik, ne mund ta ndajmë atë për të kontrolluar shkallën e shkallës së shërbimit bazuar në modele specifike trafiku.

Kjo është arsyeja pse më pëlqen të mendoj për klientin si të ndarë nga API. Kjo e bën shumë të lehtë të mendosh për zhvillimin për platforma të shumta: ueb, ueb celular, iOS, Android, aplikacione desktop, shërbime të palëve të treta, etj. Ata janë të gjithë thjesht klientë që përdorin të njëjtin API.

Për shembull, tani përdoruesit tanë më shpesh kërkojnë të lëshojnë një aplikacion celular. Nëse ndani klientin dhe entitetet API, kjo bëhet më e lehtë.

Kështu duket një sistem i tillë:

1000 përdorues: shtoni balancuesin e ngarkesës

Gjërat po shikojnë lart. Përdoruesit e Graminsta po ngarkojnë gjithnjë e më shumë foto. Po rritet edhe numri i regjistrimeve. Serveri ynë i vetëm API po e ka të vështirë të mbajë në hap me të gjithë trafikun. Duhet më shumë hekur!

Balancuesi i ngarkesës është një koncept shumë i fuqishëm. Ideja kryesore është që ne vendosim një balancues ngarkese përpara API-së, dhe ai shpërndan trafikun në instancat individuale të shërbimit. Kjo është mënyra se si ne shkallëzojmë horizontalisht, domethënë shtojmë më shumë serverë me të njëjtin kod, duke rritur numrin e kërkesave që mund të përpunojmë.

Ne do të vendosim balancues të veçantë të ngarkesës përpara klientit të internetit dhe përpara API-së. Kjo do të thotë që ju mund të ekzekutoni instanca të shumta duke ekzekutuar kodin API dhe kodin e klientit në ueb. Balancuesi i ngarkesës do t'i drejtojë kërkesat te serveri që është më pak i ngarkuar.

Këtu kemi një avantazh tjetër të rëndësishëm - tepricë. Kur një shembull dështon (ndoshta është i mbingarkuar ose i rrëzuar), ne mbetemi me të tjerë që vazhdojnë t'u përgjigjen kërkesave në hyrje. Nëse do të funksiononte vetëm një shembull, atëherë në rast të dështimit i gjithë sistemi do të rrëzohej.

Balancuesi i ngarkesës siguron gjithashtu shkallëzim automatik. Ne mund ta konfigurojmë atë për të rritur numrin e rasteve përpara ngarkesës maksimale dhe për ta ulur atë kur të gjithë përdoruesit janë në gjumë.

Me një balancues ngarkese, niveli i API mund të shkallëzohet pothuajse pafundësisht, thjesht duke shtuar shembuj të rinj ndërsa numri i kërkesave rritet.

Shënim. Aktualisht sistemi ynë është shumë i ngjashëm me atë që kompanitë PaaS si Heroku ose Elastic Beanstalk në AWS ofrojnë jashtë kutisë (kjo është arsyeja pse ato janë kaq të njohura). Heroku vendos bazën e të dhënave në një host të veçantë, menaxhon një balancues automatik të shkallëzimit të ngarkesës dhe ju lejon të prisni klientin në internet veçmas nga API. Kjo është një arsye e shkëlqyeshme për të përdorur Heroku për projekte të fazës fillestare ose startup - ju i merrni të gjitha shërbimet bazë jashtë kutisë.

10 përdorues: CDN

Ndoshta duhet ta kishim bërë këtë që në fillim. Përpunimi i kërkesave dhe pranimi i fotove të reja po fillon të ngarkojë shumë serverët tanë.

Në këtë fazë, duhet të përdorni një shërbim cloud për ruajtjen e përmbajtjes statike - imazhe, video dhe shumë më tepër (AWS S3 ose Digital Ocean Spaces). Në përgjithësi, API-ja jonë duhet të shmangë trajtimin e gjërave si shërbimi i imazheve dhe ngarkimi i imazheve në server.

Një avantazh tjetër i pritjes në cloud është CDN (AWS e quan këtë shtesë Cloudfront, por shumë ofrues të ruajtjes së cloud e ofrojnë atë jashtë kutisë). CDN automatikisht ruan imazhet tona në qendra të ndryshme të të dhënave në mbarë botën.

Megjithëse qendra jonë kryesore e të dhënave mund të jetë e vendosur në Ohio, nëse dikush kërkon një imazh nga Japonia, ofruesi i cloud do të bëjë një kopje dhe do ta ruajë atë në qendrën e tij të të dhënave japoneze. Personi tjetër që e kërkon këtë imazh në Japoni do ta marrë atë shumë më shpejt. Kjo është e rëndësishme kur punojmë me skedarë të mëdhenj, si foto ose video, që kërkojnë shumë kohë për t'u shkarkuar dhe transmetuar në të gjithë planetin.

100 përdorues: shkallëzimi i shtresës së të dhënave

CDN ka ndihmuar shumë: trafiku po rritet me shpejtësi të plotë. Video blogeri i famshëm Mavid Mobrick sapo u regjistrua tek ne dhe postoi "historinë" e tij, siç thonë ata. Falë balancuesit të ngarkesës, përdorimi i CPU-së dhe i memories në serverët API mbahet i ulët (dhjetë raste të API-së në punë), por ne kemi filluar të marrim shumë afate kohore për kërkesat... nga vijnë këto vonesa?

Duke gërmuar pak në metrikë, shohim që CPU në serverin e bazës së të dhënave është 80-90% i ngarkuar. Jemi në kufi.

Shkallëzimi i shtresës së të dhënave është ndoshta pjesa më e vështirë e ekuacionit. Serverët API shërbejnë kërkesa pa shtetësi, kështu që ne thjesht shtojmë më shumë instanca API. Hunda nga shumica bazat e të dhënave nuk mund ta bëjnë këtë. Do të flasim për sistemet popullore të menaxhimit të bazës së të dhënave relacionale (PostgreSQL, MySQL, etj.).

caching

Një nga mënyrat më të lehta për të rritur performancën e bazës së të dhënave është futja e një komponenti të ri: shtresa e cache. Metoda më e zakonshme e ruajtjes në memorie është një dyqan regjistrimi me vlerë kyçe në memorie, si Redis ose Memcached. Shumica e reve kanë një version të menaxhuar të këtyre shërbimeve: Elasticache në AWS dhe Memorystore në Google Cloud.

Një cache është e dobishme kur një shërbim bën shumë thirrje të përsëritura në bazën e të dhënave për të marrë të njëjtin informacion. Në thelb, ne hyjmë në bazën e të dhënave vetëm një herë, ruajmë informacionin në cache dhe nuk e prekim më.

Për shembull, në shërbimin tonë Graminsta, sa herë që dikush shkon në faqen e profilit të yllit Mobrik, serveri API kërkon informacion në bazën e të dhënave nga profili i tij. Kjo ndodh përsëri dhe përsëri. Meqenëse informacioni i profilit të Mobrik nuk ndryshon me çdo kërkesë, ai është i shkëlqyeshëm për memorie.

Ne do t'i ruajmë rezultatet nga baza e të dhënave në Redis me çelës user:id me një periudhë vlefshmërie prej 30 sekondash. Tani, kur dikush shkon në profilin e Mobrikut, ne fillimisht kontrollojmë Redis, dhe nëse të dhënat janë aty, thjesht i transferojmë ato direkt nga Redis. Tani kërkesat për profilin më të njohur në sit praktikisht nuk ngarkojnë bazën e të dhënave tona.

Një avantazh tjetër i shumicës së shërbimeve të memorizimit është se ato janë më të lehta për t'u shkallëzuar sesa serverët e bazës së të dhënave. Redis ka një modalitet të integruar Redis Cluster. Ngjashëm me balancuesin e ngarkesës1, ju lejon të shpërndani cache-in tuaj Redis nëpër makina të shumta (nëpër mijëra serverë nëse është e nevojshme).

Pothuajse të gjitha aplikacionet në shkallë të gjerë përdorin caching; është një pjesë absolutisht integrale e një API të shpejtë. Përpunimi më i shpejtë i pyetjeve dhe kodi më produktiv janë të gjitha të rëndësishme, por pa një memorie të fshehtë është pothuajse e pamundur të shkallëzohet një shërbim për miliona përdorues.

Lexoni kopjet

Kur numri i pyetjeve në bazën e të dhënave është rritur shumë, një gjë tjetër që mund të bëjmë është të shtojmë kopje të lexuara në sistemin e menaxhimit të bazës së të dhënave. Me shërbimet e menaxhuara të përshkruara më sipër, kjo mund të bëhet me një klik. Replika e lexuar do të mbetet aktuale në bazën e të dhënave kryesore dhe është e disponueshme për deklaratat SELECT.

Këtu është sistemi ynë tani:

Hapat e ardhshëm

Ndërsa aplikacioni vazhdon të shkallëzohet, ne do të vazhdojmë të ndajmë shërbimet për t'i shkallëzuar ato në mënyrë të pavarur. Për shembull, nëse fillojmë të përdorim Websockets, atëherë ka kuptim të tërheqim kodin e përpunimit të Websockets në një shërbim të veçantë. Ne mund ta vendosim atë në raste të reja pas balancuesit tonë të ngarkesës, i cili mund të rritet e zvogëlohet bazuar në lidhjet e hapura të Websockets dhe pavarësisht nga numri i kërkesave HTTP.

Ne gjithashtu do të vazhdojmë të luftojmë kufizimet në nivelin e bazës së të dhënave. Është në këtë fazë që është koha për të studiuar ndarjen dhe ndarjen e bazës së të dhënave. Të dyja qasjet kërkojnë shpenzime shtesë, por ju lejojnë të shkallëzoni bazën e të dhënave pothuajse për një kohë të pacaktuar.

Ne duam gjithashtu të instalojmë një shërbim monitorimi dhe analitik si New Relic ose Datadog. Kjo do t'ju ndihmojë të identifikoni pyetjet e ngadalta dhe të kuptoni se ku nevojitet përmirësim. Ndërsa shkallëzojmë, ne duam të përqendrohemi në gjetjen e pengesave dhe eliminimin e tyre—shpesh duke përdorur disa nga idetë nga seksionet e mëparshme.

burime

Ky postim është frymëzuar nga një prej Postimet e mia të preferuara rreth shkallëzueshmërisë së lartë. Doja ta bëja artikullin pak më specifik për fazat fillestare të projekteve dhe ta zgjidhja atë nga një shitës. Sigurohuni që të lexoni nëse jeni të interesuar për këtë temë.

Shënimet në fund të faqes

1. Edhe pse i ngjashëm për sa i përket shpërndarjes së ngarkesës nëpër instanca të shumta, zbatimi themelor i një grupi Redis është shumë i ndryshëm nga një balancues i ngarkesës. [kthimi]

Burimi: www.habr.com