In protte startups hawwe dit trochmakke: skaren fan nije brûkers registrearje elke dei, en it ûntwikkelteam hat muoite om de tsjinst rinnend te hâlden.
It is in moai probleem om te hawwen, mar d'r is net folle dúdlike ynformaasje op it web oer hoe't jo in webapplikaasje soarchfâldich skaalje kinne fan neat nei hûnderttûzenen brûkers. Meastentiids binne d'r of brânoplossingen of knelpuntoplossingen (en faaks beide). Dêrom brûke minsken nochal klisjee techniken om har amateurprojekt te skaaljen yn wat echt serieus.
Litte wy besykje de ynformaasje te filterjen en de basisformule op te skriuwen. Wy sille ús nije side foar dielen fan foto's Graminsta stap foar stap skaalje fan 1 nei 100 brûkers.
Litte wy opskriuwe hokker spesifike aksjes moatte wurde nommen as it publyk ferheget nei 10, 100, 1000, 10 en 000 minsken.
1 brûker: 1 masine
Hast elke applikaasje, of it no in webside of in mobile applikaasje is, hat trije wichtige komponinten:
- API
- databank
- klant (mobile applikaasje sels as webside)
De databank bewarret persistente gegevens. De API tsjinnet oanfragen oan en om dizze gegevens. De klant stjoert gegevens nei de brûker.
Ik kaam ta de konklúzje dat it folle makliker is om te praten oer it skaalfergrutting fan in applikaasje as, út in arsjitektoanysk eachpunt, de kliïnt en API-entiteiten folslein skieden binne.
As wy earst begjinne mei it bouwen fan in applikaasje, kinne alle trije komponinten wurde útfierd op deselde tsjinner. Op guon manieren is dit gelyk oan ús ûntwikkelingsomjouwing: ien yngenieur rint de database, API en kliïnt op deselde masine.
Yn teory kinne wy it ynsette yn 'e wolk op in inkele DigitalOcean Droplet of AWS EC2 eksimplaar, lykas hjirûnder werjûn:
Mei dat sein, as d'r mear as ien brûker op in side sil wêze, makket it hast altyd sin om in databanklaach te wijen.
10 brûkers: ferpleatse de databank nei in apart nivo
It opsplitsen fan de databank yn beheare tsjinsten lykas Amazon RDS of Digital Ocean Managed Database sil ús goed tsjinje foar in lange tiid. It is in bytsje djoerder dan selshosting op ien masine as EC2-eksimplaar, mar mei dizze tsjinsten krije jo in protte nuttige tafoegings út 'e doaze dy't yn' e takomst fan pas komme: reservekopy mei meardere regio's, replika's lêze, automatysk backups, en mear.
Dit is hoe't it systeem der no útsjocht:
100 brûkers: ferpleatse de klant nei in apart nivo
Gelokkich fûnen ús earste brûkers ús applikaasje echt leuk. Ferkear wurdt stabiler, dus it is tiid om de klant nei in apart nivo te ferpleatsen. Dêrby moat opmurken wurde dat skieding entiteiten is in wichtich aspekt fan it bouwen fan in skalbere applikaasje. As ien diel fan it systeem mear ferkear ûntfangt, kinne wy it partitionearje om te kontrolearjen hoe't de tsjinst skalen op basis fan spesifike ferkearspatroanen.
Dit is wêrom ik graach tinke oan 'e klant as apart fan' e API. Dit makket it hiel maklik om te tinken oer ûntwikkeljen foar meardere platfoarms: web, mobyl web, iOS, Android, buroblêd applikaasjes, tredden tsjinsten, ensfh Se binne allegear gewoan kliïnten mei help fan deselde API.
Bygelyks, no freegje ús brûkers meast faak om in mobile applikaasje frij te litten. As jo de client- en API-entiteiten skiede, wurdt dit makliker.
Dit is hoe't sa'n systeem derút sjocht:
1000 brûkers: tafoegje load balancer
Dingen sjogge omheech. Graminsta-brûkers uploade hieltyd mear foto's. Ek it tal oanmeldingen groeit. Us iensume API-tsjinner hat it dreech om al it ferkear by te hâlden. Mear izer nedich!
Load balancer is in heul krêftich konsept. It kaai idee is dat wy sette in load balancer foar de API, en it ferspriedt ferkear nei yndividuele tsjinst eksimplaren. Dit is hoe't wy horizontaal skaalje, wat betsjuttet dat wy mear servers tafoegje mei deselde koade, wêrtroch it oantal oanfragen ferheegje dat wy kinne ferwurkje.
Wy sille aparte load balancers pleatse foar de webklient en foar de API. Dit betsjut dat jo meardere eksimplaren kinne útfiere mei API-koade en webkliïntkoade. De load balancer sil fersiken rjochtsje nei de tsjinner dy't minder laden is.
Hjir krije wy in oar wichtich foardiel - oerstalligens. As ien eksimplaar mislearret (miskien oerladen of ferûngelokke), binne wy oerbleaun mei oaren dy't trochgean te reagearjen op ynkommende fersiken. As d'r mar ien eksimplaar wurke, dan soe yn gefal fan mislearring it heule systeem crashe.
De load balancer soarget ek foar automatyske skaalfergrutting. Wy kinne it konfigurearje om it oantal eksimplaren te ferheegjen foar pykbelêsting, en it ferminderje as alle brûkers sliepe.
Mei in load balancer kin it API-nivo hast ûnbepaald wurde skalearre, gewoan nije eksimplaren tafoegje as it oantal oanfragen tanimt.
Noat. Op it stuit is ús systeem heul gelyk oan wat PaaS-bedriuwen lykas Heroku of Elastic Beanstalk op AWS út 'e doaze oanbiede (wêrtroch binne se sa populêr). Heroku set de databank op in aparte host, beheart in auto-skaalfergrutting load balancer, en lit jo de webklient apart fan 'e API hostje. Dit is in geweldige reden om Heroku te brûken foar projekten as opstarten yn 'e iere faze - jo krije alle basistsjinsten út' e doaze.
10 brûkers: CDN
Miskien hiene wy dit fan it begjin ôf moatten dwaan. It ferwurkjen fan oanfragen en it akseptearjen fan nije foto's begjint te folle spanning op ús servers te setten.
Op dit stadium moatte jo in wolktsjinst brûke foar it opslaan fan statyske ynhâld - ôfbyldings, fideo's en folle mear (AWS S3 of Digital Ocean Spaces). Yn 't algemien soe ús API dingen moatte foarkomme lykas it tsjinjen fan ôfbyldings en it uploaden fan ôfbyldings nei de server.
In oar foardiel fan wolkhosting is de CDN (AWS neamt dizze tafoeging Cloudfront, mar in protte oanbieders fan wolkopslach biede it út it fak). De CDN bewarret ús ôfbyldings automatysk yn ferskate datasintra om 'e wrâld.
Hoewol ús haaddatasintrum yn Ohio lizze kin, as immen in ôfbylding út Japan freget, sil de wolkprovider in kopy meitsje en it opslaan yn har Japanske datasintrum. De folgjende persoan dy't dizze ôfbylding freget yn Japan sil it folle rapper ûntfange. Dit is wichtich as wy wurkje mei grutte bestannen, lykas foto's of fideo's, dy't in lange tiid nimme om te downloaden en oer de planeet te ferstjoeren.
100 brûkers: skaalfergrutting fan de gegevenslaach
CDN hat in protte holpen: ferkear groeit op folle snelheid. De ferneamde fideoblogger Mavid Mobrick registrearre gewoan by ús en pleatste syn "ferhaal", sa't se sizze. Mei tank oan de load balancer wurdt de CPU en ûnthâldgebrûk op 'e API-tsjinners leech hâlden (tsien API-eksimplaren rinne), mar wy begjinne in protte timeouts te krijen op oanfragen ... wêr komme dizze fertragingen wei?
In bytsje grave yn 'e metriken, sjogge wy dat de CPU op' e databanktsjinner 80-90% laden is. Wy binne by de limyt.
Skaalfergrutting fan de gegevenslaach is wierskynlik it dreechste diel fan 'e fergeliking. API-tsjinners tsjinje steatleaze oanfragen, dus foegje wy gewoan mear API-eksimplaren ta. Noas mearderheid databanken kinne dit net dwaan. Wy sille prate oer populêre relaasje-databasebehearsystemen (PostgreSQL, MySQL, ensfh.).
caching
Ien fan 'e maklikste manieren om de prestaasjes fan ús databank te ferheegjen is in nije komponint yn te fieren: de cache-laach. De meast foarkommende cachingmetoade is in yn-geheugen kaai-wearde record store, lykas Redis of Memcached. De measte wolken hawwe in beheare ferzje fan dizze tsjinsten: Elasticache op AWS en Memorystore op Google Cloud.
In cache is nuttich as in tsjinst in protte werhelle oproppen makket nei de databank om deselde ynformaasje op te heljen. Yn essinsje hawwe wy mar ien kear tagong ta de databank, bewarje de ynformaasje yn 'e cache en reitsje it net wer oan.
Bygelyks, yn ús Graminsta-tsjinst, elke kear as immen nei de profylside fan 'e stjer Mobrik giet, freget de API-tsjinner de databank foar ynformaasje fan syn profyl. Dit bart hieltyd wer. Sûnt de profylynformaasje fan Mobrik net feroaret mei elk fersyk, is it poerbêst foar caching.
Wy sille de resultaten fan 'e database yn Redis cache troch kaai user:id mei in jildichheidsperioade fan 30 sekonden. No, as immen nei it profyl fan Mobrik giet, kontrolearje wy earst Redis, en as de gegevens der binne, oerdrage wy it gewoan direkt fan Redis. No fersiken nei it populêrste profyl op 'e side laden ús databank praktysk net.
In oar foardiel fan de measte cachingtsjinsten is dat se makliker te skaaljen binne dan databankservers. Redis hat in ynboude Redis Cluster-modus. Fergelykber mei in load balancer, It lit jo jo Redis-cache fersprieden oer meardere masines (oer tûzenen servers as nedich).
Hast alle grutskalige applikaasjes brûke caching; it is in absolút yntegraal diel fan in rappe API. Snellere query-ferwurking en mear produktive koade binne allegear wichtich, mar sûnder cache is it hast ûnmooglik om in tsjinst te skaaljen nei miljoenen brûkers.
Lês replika's
As it oantal fragen nei de databank sterk tanommen is, is ien mear ding dat wy kinne dwaan lêsreplika's ta te foegjen yn it databankbehearsysteem. Mei de hjirboppe beskreaune behearde tsjinsten kin dit mei ien klik dien wurde. De reade replika sil aktueel bliuwe yn 'e haaddatabase en is beskikber foar SELECT-útspraken.
Hjir is ús systeem no:
Folgjende stappen
As de applikaasje trochgiet te skaaljen, sille wy trochgean mei it skieden fan de tsjinsten om se selsstannich te skaaljen. As wy bygelyks Websockets begjinne te brûken, dan makket it sin om de Websockets-ferwurkingskoade yn in aparte tsjinst te lûken. Wy kinne it pleatse op nije eksimplaren efter ús eigen loadbalancer, dy't op en del kin skaalje op basis fan iepen Websockets-ferbiningen en nettsjinsteande it oantal HTTP-oanfragen.
Wy sille ek trochgean mei it bestriden fan beheiningen op databanknivo. It is op dit stadium dat it tiid is om databankferdieling en sharding te studearjen. Beide oanpak fereaskje ekstra overhead, mar tastean jo te skaaljen de databank hast ûnbepaalde tiid.
Wy wolle ek in tafersjoch- en analytyske tsjinst ynstallearje lykas New Relic of Datadog. Dit sil jo helpe om trage fragen te identifisearjen en te begripen wêr't ferbettering nedich is. Wylst wy skaalje, wolle wy ús konsintrearje op it finen fan knelpunten en it eliminearjen - faaks mei guon fan 'e ideeën út foarige seksjes.
Boarnen
Dizze post is ynspirearre troch ien fan . Ik woe it artikel wat spesifyk meitsje foar de earste fazen fan projekten en it losmeitsje fan ien ferkeaper. Wês wis te lêzen as jo ynteressearre binne yn dit ûnderwerp.
Fuotnoaten
- Hoewol ferlykber yn termen fan loadferdieling oer meardere eksimplaren, is de ûnderlizzende ymplemintaasje fan in Redis-kluster heul oars as in loadbalancer.
Boarne: www.habr.com