Startup asko pasatu dira hau: erabiltzaile berrien pilaketak erregistratzen dira egunero, eta garapen taldeari ahalegina egiten zaio zerbitzua martxan mantentzeko.
Arazo polita da edukitzea, baina sarean informazio argi gutxi dago web-aplikazio bat ezerezean izatetik ehunka mila erabiltzailera nola eskalatzeari buruz. Normalean, su-konponbideak edo botila-lepoko irtenbideak daude (eta askotan biak). Hori dela eta, jendeak nahiko topiko teknikak erabiltzen ditu bere afizionatu-proiektua benetan serio bihurtzeko.
Saia gaitezen informazioa iragazten eta idatzi oinarrizko formula. Graminsta argazkiak partekatzeko gune berria 1etik 100 erabiltzailera eskalatuko dugu urratsez urrats.
Idatz ditzagun zein ekintza zehatz egin behar diren audientzia 10, 100, 1000, 10 eta 000 pertsonara igotzen denean.
1 erabiltzaile: 1 makina
Ia aplikazio guztiek, webgune bat edo mugikorretarako aplikazio bat izan, hiru osagai nagusi dituzte:
- API
- datu-basea
- bezeroa (aplikazio mugikorra bera edo webgunea)
Datu-baseak datu iraunkorrak gordetzen ditu. APIak datu hauetarako eta inguruko eskaerak eskaintzen ditu. Bezeroak erabiltzaileari datuak transmititzen dizkio.
Ondorioztatu nuen askoz errazagoa dela aplikazio bat eskalatzeaz hitz egitea, arkitekturaren ikuspuntutik bezeroa eta API entitateak guztiz bereizten badira.
Aplikazio bat eraikitzen hasten garenean, hiru osagaiak zerbitzari berean exekutatu daitezke. Nolabait, gure garapen-ingurunearen antzekoa da: ingeniari batek datu-basea, APIa eta bezeroa exekutatzen ditu makina berean.
Teorian, hodeian zabaldu genezake DigitalOcean Droplet edo AWS EC2 instantzia bakar batean, behean erakusten den moduan:
Hori esanda, gune batean erabiltzaile bat baino gehiago egongo bada, ia beti zentzuzkoa da datu-base geruza bat eskaintzea.
10 erabiltzaile: datu-basea maila ezberdin batera eraman
Datu-basea Amazon RDS edo Digital Ocean Managed Database bezalako kudeatutako zerbitzuetan banatzeak denbora luzez balioko digu. Makina bakarrean edo EC2 instantzian auto-ostatatzea baino apur bat garestiagoa da, baina zerbitzu hauekin etorkizunean erabilgarriak izango diren luzapen erabilgarri asko ateratzen dituzu kutxatik: eskualde anitzeko babeskopia, erreplikak irakurri, automatikoak. babeskopiak, eta abar.
Hau da orain sistemaren itxura:
100 erabiltzaile: bezeroa beste maila batera eraman
Zorionez, gure lehenengo erabiltzaileei asko gustatu zitzaien gure aplikazioa. Trafikoa egonkorragoa da, beraz, bezeroa maila bereizi batera eramateko garaia da. Kontuan izan behar da bereizketa entitateak aplikazio eskalagarria eraikitzeko funtsezko alderdia da. Sistemaren zati batek trafiko gehiago jasotzen duenez, zatitu dezakegu zerbitzua trafiko-eredu zehatzetan oinarrituta nola eskalatzen den kontrolatzeko.
Horregatik gustatzen zait bezeroa APItik bereizita dagoela pentsatzea. Horri esker, oso erraza da hainbat plataformatarako garatzea pentsatzea: web, web mugikorra, iOS, Android, mahaigaineko aplikazioak, hirugarrenen zerbitzuak, etab. Guztiak API bera erabiltzen duten bezeroak besterik ez dira.
Adibidez, orain gure erabiltzaileek gehienetan eskatzen dute mugikorretarako aplikazio bat kaleratzeko. Bezeroa eta API entitateak bereizten badituzu, hori errazagoa izango da.
Hau da sistema hori nolakoa den:
1000 erabiltzaile: gehitu karga-orekatzailea
Gauzak gora begira daude. Graminsta erabiltzaileak gero eta argazki gehiago igotzen ari dira. Matrikula kopurua ere hazten ari da. Gure API zerbitzari bakartiak zailtasunak ditu trafiko guztiari eustea. Burdina gehiago behar!
Karga-orekatzailea oso kontzeptu indartsua da. Funtsezko ideia da karga-orekatzailea jartzen dugula APIaren aurrean, eta trafikoa banakako zerbitzu-instantziaetara banatzen duela. Horrela eskalatzen dugu horizontalki, hau da, kode bera duten zerbitzari gehiago gehitzen ditugu, prozesatu ditzakegun eskaerak handituz.
Karga-orekatzaile bereiziak jarriko ditugu web bezeroaren aurrean eta APIaren aurrean. Horrek esan nahi du hainbat instantzia exekutatu ditzakezula API kodea eta web bezeroaren kodea exekutatzen. Karga-orekatzaileak eskaera gutxiago kargatuta dagoen zerbitzarira zuzenduko ditu.
Hemen beste abantaila garrantzitsu bat lortzen dugu: erredundantzia. Instantzia batek huts egiten duenean (agian gainkargatuta edo huts eginda), sarrerako eskaerei erantzuten jarraitzen duten beste batzuekin geratzen gara. Instantzia bakarra funtzionatzen badu, hutsegite kasuan sistema osoa huts egingo litzateke.
Karga-orekatzaileak eskalatze automatikoa ere eskaintzen du. Konfiguratu dezakegu karga gailurra baino lehen instantzia kopurua handitzeko eta erabiltzaile guztiak lo daudenean murrizteko.
Karga-orekatzaile batekin, API maila ia mugagabean eskalatu daiteke, eskaera kopurua handitzen den heinean instantzia berriak gehituz.
Ohar. Oraintxe bertan gure sistema Heroku edo Elastic Beanstalk-en AWS-ko PaaS konpainiek eskaintzen dutenaren oso antzekoa da (horregatik dira hain ezagunak). Herokuk datu-basea ostalari bereizi batean jartzen du, eskalatze automatikoko karga-orekatzailea kudeatzen du eta web-bezeroa APItik bereizita ostatatzeko aukera ematen du. Arrazoi bikaina da Heroku hasierako proiektuetarako edo startupetarako erabiltzeko: oinarrizko zerbitzu guztiak ateratzen dituzu.
10 erabiltzaile: CDN
Beharbada hori hasiera-hasieratik egin beharko genuke. Eskaerak prozesatzea eta argazki berriak onartzea tentsio handiegia jartzen hasi da gure zerbitzarietan.
Fase honetan, hodeiko zerbitzu bat erabili behar duzu eduki estatikoa gordetzeko: irudiak, bideoak eta askoz gehiago (AWS S3 edo Digital Ocean Spaces). Oro har, gure APIak irudiak hornitzea eta zerbitzarian irudiak kargatzea bezalako gauzak kudeatzea saihestu behar du.
Hodeiko ostalaritzaren beste abantaila bat CDN da (AWS-k Cloudfront deitzen dio gehigarri honi, baina hodeiko biltegiratze hornitzaile askok kaxatik kanpo eskaintzen dute). CDN-k automatikoki gordetzen ditu gure irudiak mundu osoko hainbat datu-zentrotan.
Gure datu-zentro nagusia Ohion egon daitekeen arren, norbaitek Japoniari irudi bat eskatzen badio, hodeiko hornitzaileak kopia bat egingo du eta bere Japoniako datu-zentroan gordeko du. Irudi hau Japonian eskatzen duen hurrengoak askoz azkarrago jasoko du. Hau garrantzitsua da planeta osoan deskargatzeko eta transmititzeko denbora luzea behar duten fitxategi handiekin lan egiten dugunean, argazkiak edo bideoak adibidez.
100 erabiltzaile: datu-geruza eskalatzea
CDNk asko lagundu du: trafikoa abiadura osoan hazten ari da. Mavid Mobrick bideo blogari famatuak gurekin erregistratu eta bere βistorioaβ argitaratu berri du, esaten duten moduan. Karga-orekatzaileari esker, API zerbitzarietako CPU eta memoriaren erabilera baxua mantentzen da (hamar API instantzia martxan), baina eskaeretan denbora-muga asko jasotzen hasiak gara... nondik datoz atzerapen horiek?
Neurrietan pixka bat sakonduz, datu-basearen zerbitzariko CPUa % 80-90 kargatuta dagoela ikusten dugu. Mugan gaude.
Datu-geruza eskalatzea da ziurrenik ekuazioaren zatirik zailena. API zerbitzariek estaturik gabeko eskaerak betetzen dituzte, beraz, API instantzia gehiago gehitzen ditugu. Sudurra gehiengoa datu-baseek ezin dute hori egin. Datu-base erlazionalak kudeatzeko sistema ezagunei buruz hitz egingo dugu (PostgreSQL, MySQL, etab.).
cachean gordetzea
Gure datu-basearen errendimendua handitzeko modurik errazenetako bat osagai berri bat sartzea da: cache geruza. Cachean gordetzeko metodo ohikoena memorian dagoen gako-balioen erregistro-biltegia da, hala nola Redis edo Memcached. Hodei gehienek zerbitzu hauen bertsio kudeatua dute: Elasticache AWS-n eta Memorystore Google Cloud-en.
Cachea erabilgarria da zerbitzu batek datu-basera dei asko egiten dituenean informazio bera berreskuratzeko. Funtsean, datu-basera behin bakarrik sartzen gara, informazioa cachean gordetzen dugu eta ez dugu berriro ukitzen.
Esaterako, gure Graminsta zerbitzuan, norbait Mobrik izarraren profilera joaten den bakoitzean, API zerbitzariak datu-baseari galdetzen dio bere profileko informazioa. Hau behin eta berriz gertatzen da. Mobrik-en profilaren informazioa eskaera bakoitzean aldatzen ez denez, ezin hobea da cachean gordetzeko.
Datu-baseko emaitzak Redis-en gordeko ditugu gakoaren arabera user:id 30 segundoko balio-epearekin. Orain, norbait Mobrik-en profilera joaten denean, lehenik Redis egiaztatzen dugu, eta datuak hor badaude, Redistik zuzenean transferitzen ditugu. Orain guneko profil ezagunenari egindako eskaerak ia ez du gure datu-basea kargatzen.
Cache zerbitzu gehienen beste abantaila bat datu-base zerbitzariak baino errazagoak direla da. Redis-ek Redis Cluster modua dauka. Karga-orekatzaile baten antzekoa, zure Redis cachea hainbat makinatan banatzeko aukera ematen du (behar izanez gero milaka zerbitzaritan).
Eskala handiko aplikazio ia guztiek cachea erabiltzen dute; API azkar baten erabateko zati bat da. Kontsulten prozesamendu azkarragoa eta kode produktiboagoa garrantzitsuak dira, baina cacherik gabe ia ezinezkoa da zerbitzu bat milioika erabiltzailetara eskalatzea.
Irakurri Erreplikak
Datu-baserako kontsulta-kopurua asko handitu denean, egin dezakegun beste gauza bat datu-basearen kudeaketa sisteman irakurritako erreplikak gehitzea da. Goian deskribatutako zerbitzu kudeatuekin, klik bakarrean egin daiteke. Irakurritako erreplika datu-base nagusian unean geratuko da eta SELECT instrukzioetarako eskuragarri dago.
Hona hemen gure sistema orain:
Hurrengo pausoak
Aplikazioak eskalatzen jarraitzen duen heinean, zerbitzuak bereizten jarraituko dugu modu independentean eskalatzeko. Adibidez, Websockets erabiltzen hasten bagara, orduan zentzuzkoa da Websockets prozesatzeko kodea zerbitzu bereizi batera eramatea. Instantzia berrietan jar dezakegu gure karga-orekatzailearen atzean, Websockets konexio irekietan oinarrituta eta HTTP eskaera kopurua kontuan hartu gabe eskala daitekeena.
Datu-base mailan ere murrizketen aurka borrokatzen jarraituko dugu. Fase honetan datu-baseen zatiketa eta zatiketa aztertzeko garaia da. Bi ikuspegiek gainkostu gehigarriak behar dituzte, baina datu-basea ia mugagabean eskalatzeko aukera ematen dute.
New Relic edo Datadog bezalako monitorizazio eta analisi zerbitzu bat ere instalatu nahi dugu. Horrek kontsulta motelak identifikatzen lagunduko dizu eta hobekuntza non beharrezkoa den ulertzen lagunduko dizu. Eskalatzen goazen heinean, botikak aurkitzen eta horiek ezabatzean zentratu nahi dugu, askotan aurreko ataletako ideia batzuk erabiliz.
iturri
Post hau horietako batean inspiratuta dago . Artikulua apur bat zehatzagoa egin nahi nuen proiektuen hasierako faseetarako eta saltzaile batetik askatu. Ziurtatu irakurtzen duzula gai hau interesatzen bazaizu.
Oin-oharrak
- Instantzia anitzetan karga-banaketari dagokionez antzekoa bada ere, Redis kluster baten azpian dagoen inplementazioa oso desberdina da karga-orekatzaile baten aldean.
Iturria: www.habr.com