Baie opstarters het hierdeur gegaan: skares nuwe gebruikers registreer elke dag, en die ontwikkelingspan sukkel om die diens aan die gang te hou.
Dit is 'n lekker probleem om te hê, maar daar is min duidelike inligting op die web oor hoe om 'n webtoepassing versigtig te skaal van niks tot honderdduisende gebruikers. Tipies is daar óf brandoplossings óf bottelnekoplossings (en dikwels albei). Daarom gebruik mense nogal cliched-tegnieke om hul amateurprojek in iets werklik ernstig te skaal.
Kom ons probeer om die inligting te filter en die basiese formule neer te skryf. Ons gaan ons nuwe foto-deelwebwerf Graminsta stap vir stap van 1 tot 100 000 gebruikers skaal.
Kom ons skryf neer watter spesifieke aksies geneem moet word wanneer die gehoor tot 10, 100, 1000, 10 000 en 100 000 mense toeneem.
1 gebruiker: 1 masjien
Byna elke toepassing, of dit nou 'n webwerf of 'n mobiele toepassing is, het drie sleutelkomponente:
- API
- databasis
- kliënt (mobiele toepassing self of webwerf)
Die databasis stoor aanhoudende data. Die API dien versoeke na en rondom hierdie data. Die kliënt stuur data aan die gebruiker.
Ek het tot die gevolgtrekking gekom dat dit baie makliker is om oor die skaal van 'n toepassing te praat as, vanuit 'n argitektoniese oogpunt, die kliënt en API-entiteite heeltemal geskei is.
Wanneer ons eers 'n toepassing begin bou, kan al drie komponente op dieselfde bediener uitgevoer word. In sekere opsigte is dit soortgelyk aan ons ontwikkelingsomgewing: een ingenieur bestuur die databasis, API en kliënt op dieselfde masjien.
In teorie kan ons dit in die wolk ontplooi op 'n enkele DigitalOcean Droplet of AWS EC2-instansie, soos hieronder getoon:
Met dit gesê, as daar meer as een gebruiker op 'n webwerf sal wees, is dit byna altyd sinvol om 'n databasislaag toe te wy.
10 gebruikers: skuif die databasis na 'n aparte vlak
Die verdeling van die databasis in bestuurde dienste soos Amazon RDS of Digital Ocean Managed Database sal ons vir 'n lang tyd goed dien. Dit is 'n bietjie duurder as self-gasheer op 'n enkele masjien of EC2-instansie, maar met hierdie dienste kry jy baie nuttige uitbreidings uit die boks wat handig te pas sal kom in die toekoms: multi-streek rugsteun, lees replikas, outomaties rugsteun, en meer.
Dit is hoe die stelsel nou lyk:
100 gebruikers: skuif die kliënt na 'n aparte vlak
Gelukkig het ons eerste gebruikers baie van ons toepassing gehou. Verkeer word meer stabiel, so dit is tyd om die kliënt na 'n aparte vlak te skuif. Daar moet kennis geneem word dat skeiding entiteite is 'n sleutelaspek van die bou van 'n skaalbare toepassing. Aangesien een deel van die stelsel meer verkeer ontvang, kan ons dit verdeel om te beheer hoe die diens skaal op grond van spesifieke verkeerspatrone.
Dit is hoekom ek daarvan hou om aan die kliënt te dink as apart van die API. Dit maak dit baie maklik om te dink oor ontwikkeling vir verskeie platforms: web, mobiele web, iOS, Android, rekenaartoepassings, derdeparty-dienste, ens. Hulle is almal net kliënte wat dieselfde API gebruik.
Byvoorbeeld, nou vra ons gebruikers meestal om 'n mobiele toepassing vry te stel. As jy die kliënt- en API-entiteite skei, word dit makliker.
Dit is hoe so 'n stelsel lyk:
1000 gebruikers: voeg lasbalanseerder by
Dinge kyk op. Graminsta-gebruikers laai al hoe meer foto's op. Die aantal registrasies groei ook. Ons enigste API-bediener sukkel om tred te hou met al die verkeer. Het meer yster nodig!
Load balancer is 'n baie kragtige konsep. Die sleutelgedagte is dat ons 'n lasbalanseerder voor die API plaas, en dit versprei verkeer na individuele diensgevalle. Dit is hoe ons horisontaal skaal, wat beteken dat ons meer bedieners met dieselfde kode byvoeg, wat die aantal versoeke wat ons kan verwerk, verhoog.
Ons gaan aparte lasbalanseerders voor die webkliënt en voor die API plaas. Dit beteken dat jy veelvuldige gevalle kan laat loop wat API-kode en webkliëntkode gebruik. Die lasbalanseerder sal versoeke rig na die bediener wat minder gelaai is.
Hier kry ons nog 'n belangrike voordeel - oortolligheid. Wanneer een instansie misluk (miskien oorlaai of neergestort), sit ons met ander wat aanhou reageer op inkomende versoeke. As daar net een geval was wat gewerk het, sou die hele stelsel in die geval van mislukking ineenstort.
Die lasbalanseerder verskaf ook outomatiese skaal. Ons kan dit instel om die aantal gevalle voor pieklading te verhoog, en dit te verminder wanneer alle gebruikers slaap.
Met 'n lasbalanseerder kan die API-vlak byna onbepaald afgeskaal word, deur eenvoudig nuwe gevalle by te voeg namate die aantal versoeke toeneem.
Let wel. Op die oomblik is ons stelsel baie soortgelyk aan wat PaaS-maatskappye soos Heroku of Elastic Beanstalk op AWS uit die boks bied (dit is hoekom hulle so gewild is). Heroku plaas die databasis op 'n aparte gasheer, bestuur 'n outo-skaal lasbalanseerder en laat jou toe om die webkliënt apart van die API te huisves. Dit is 'n goeie rede om Heroku te gebruik vir vroeë stadium projekte of opstart - jy kry al die basiese dienste uit die boks.
10 000 gebruikers: CDN
Miskien moes ons dit van die begin af gedoen het. Die verwerking van versoeke en die aanvaarding van nuwe foto's begin te veel druk op ons bedieners plaas.
Op hierdie stadium moet jy 'n wolkdiens gebruik om statiese inhoud te berg - beelde, video's en nog baie meer (AWS S3 of Digital Ocean Spaces). Oor die algemeen moet ons API vermy om dinge soos die bediening van beelde en die oplaai van beelde na die bediener te hanteer.
Nog 'n voordeel van wolkgasheer is die CDN (AWS noem hierdie byvoeging Cloudfront, maar baie wolkbergingsverskaffers bied dit uit die boks aan). Die CDN kas ons beelde outomaties in verskeie datasentrums regoor die wêreld.
Alhoewel ons hoofdatasentrum in Ohio geleë kan wees, sal die wolkverskaffer 'n kopie maak en dit in hul Japannese datasentrum stoor as iemand 'n prent van Japan versoek. Die volgende persoon wat hierdie beeld in Japan aanvra, sal dit baie vinniger ontvang. Dit is belangrik wanneer ons met groot lêers werk, soos foto's of video's, wat lank neem om af te laai en oor die planeet te versend.
100 000 gebruikers: skaal die datalaag
CDN het baie gehelp: verkeer groei met volle spoed. Die bekende videoblogger Mavid Mobrick het sopas by ons geregistreer en sy “storie”, soos hulle sê, geplaas. Danksy die lasbalanseerder word die SVE en geheuegebruik op die API-bedieners laag gehou (tien API-instansies loop), maar ons begin baie time-outs kry op versoeke... waar kom hierdie vertragings vandaan?
Deur 'n bietjie in die statistieke, sien ons dat die SVE op die databasisbediener 80-90% gelaai is. Ons is by die limiet.
Om die datalaag te skaal is waarskynlik die moeilikste deel van die vergelyking. API-bedieners dien staatlose versoeke, so ons voeg eenvoudig meer API-gevalle by. Neus die meerderheid databasisse kan dit nie doen nie. Ons sal praat oor gewilde relasionele databasisbestuurstelsels (PostgreSQL, MySQL, ens.).
kas
Een van die maklikste maniere om die werkverrigting van ons databasis te verhoog, is om 'n nuwe komponent bekend te stel: die kaslaag. Die mees algemene kasmetode is 'n sleutelwaarde-rekordwinkel in die geheue, soos Redis of Memcached. Die meeste wolke het 'n bestuurde weergawe van hierdie dienste: Elasticache op AWS en Memorystore op Google Cloud.
'n Kas is nuttig wanneer 'n diens baie herhaalde oproepe na die databasis maak om dieselfde inligting te herwin. In wese het ons slegs een keer toegang tot die databasis, stoor die inligting in die kas en raak dit nie weer nie.
Byvoorbeeld, in ons Graminsta-diens, elke keer as iemand na die profielbladsy van die ster Mobrik gaan, vra die API-bediener die databasis vir inligting vanaf sy profiel. Dit gebeur weer en weer. Aangesien Mobrik se profielinligting nie met elke versoek verander nie, is dit uitstekend vir cache.
Ons sal die resultate van die databasis in Redis per sleutel kas user:id met 'n geldigheidstydperk van 30 sekondes. Nou, wanneer iemand na Mobrik se profiel gaan, gaan ons eers Redis na, en as die data daar is, dra ons dit eenvoudig direk van Redis af. Nou laai versoeke na die gewildste profiel op die webwerf feitlik nie ons databasis nie.
Nog 'n voordeel van die meeste kasdienste is dat dit makliker is om te skaal as databasisbedieners. Redis het 'n ingeboude Redis Cluster-modus. Soortgelyk aan 'n lasbalanseerder, dit laat jou toe om jou Redis-kas oor verskeie masjiene te versprei (oor duisende bedieners indien nodig).
Byna alle grootskaalse toepassings gebruik caching; dit is 'n absoluut integrale deel van 'n vinnige API. Vinniger navraagverwerking en meer produktiewe kode is alles belangrik, maar sonder 'n kas is dit byna onmoontlik om 'n diens na miljoene gebruikers te skaal.
Lees Replikas
Wanneer die aantal navrae na die databasis baie toegeneem het, is nog een ding wat ons kan doen om lees replikas in die databasisbestuurstelsel by te voeg. Met die bestuurde dienste wat hierbo beskryf word, kan dit met een klik gedoen word. Die lees-replika sal in die hoofdatabasis op datum bly en is beskikbaar vir SELECT-stellings.
Hier is ons stelsel nou:
Volgende stappe
Soos die toepassing aanhou skaal, sal ons voortgaan om die dienste te skei om hulle onafhanklik te skaal. As ons byvoorbeeld Websockets begin gebruik, maak dit sin om die Websockets-verwerkingskode in 'n aparte diens te trek. Ons kan dit op nuwe gevalle agter ons eie lasbalanseerder plaas, wat op en af kan skaal op grond van oop Websockets-verbindings en ongeag die aantal HTTP-versoeke.
Ons sal ook voortgaan om beperkings op databasisvlak te beveg. Dit is op hierdie stadium dat dit tyd is om databasispartisionering en -sharding te bestudeer. Beide benaderings vereis bykomende oorhoofse koste, maar laat jou toe om die databasis byna onbepaald te skaal.
Ons wil ook 'n moniterings- en ontledingsdiens soos New Relic of Datadog installeer. Dit sal jou help om stadige navrae te identifiseer en te verstaan waar verbetering nodig is. Soos ons skaal, wil ons daarop fokus om knelpunte te vind en dit uit te skakel—dikwels deur sommige van die idees uit vorige afdelings te gebruik.
bronne
Hierdie pos is geïnspireer deur een van . Ek wou die artikel 'n bietjie meer spesifiek maak vir die beginstadiums van projekte en dit van een verkoper losmaak. Maak seker dat jy lees as jy belangstel in hierdie onderwerp.
Voetnote
- Alhoewel soortgelyk in terme van vragverspreiding oor verskeie gevalle, is die onderliggende implementering van 'n Redis-kluster baie anders as 'n lasbalanseerder.
Bron: will.com