Mörg sprotafyrirtæki hafa gengið í gegnum þetta: fjöldi nýrra notenda skráir sig á hverjum degi og þróunarteymið á í erfiðleikum með að halda þjónustunni gangandi.
Það er gott vandamál að hafa, en það eru litlar skýrar upplýsingar á vefnum um hvernig á að vandlega skala vefforrit úr engu í hundruð þúsunda notenda. Venjulega eru annað hvort brunalausnir eða flöskuhálslausnir (og oft bæði). Þess vegna notar fólk frekar klisjukennda tækni til að skala áhugamannaverkefnið sitt í eitthvað virkilega alvarlegt.
Við skulum reyna að sía upplýsingarnar og skrifa niður grunnformúluna. Við ætlum að stækka nýju myndadeilingarsíðuna okkar Graminsta skref fyrir skref úr 1 í 100 notendur.
Skrifum niður hvaða sérstakar aðgerðir þarf að grípa til þegar áhorfendur eru orðnir 10, 100, 1000, 10 og 000 manns.
1 notandi: 1 vél
Næstum hvert forrit, hvort sem það er vefsíða eða farsímaforrit, hefur þrjá lykilþætti:
- API
- gagnasafn
- viðskiptavinur (farsímaforritið sjálft eða vefsíða)
Gagnagrunnurinn geymir viðvarandi gögn. API þjónar beiðnum til og í kringum þessi gögn. Viðskiptavinurinn sendir gögn til notandans.
Ég komst að þeirri niðurstöðu að það er miklu auðveldara að tala um stærðarstærð forrits ef, frá byggingarfræðilegu sjónarmiði, eru viðskiptavinur og API einingar algjörlega aðskilin.
Þegar við byrjum fyrst að byggja forrit er hægt að keyra alla þrjá íhlutina á sama netþjóninum. Að sumu leyti er þetta svipað þróunarumhverfi okkar: einn verkfræðingur rekur gagnagrunninn, API og biðlarann á sömu vélinni.
Fræðilega séð gætum við sett það í skýið á einum DigitalOcean Droplet eða AWS EC2 tilviki, eins og sýnt er hér að neðan:
Með því að segja, ef það verða fleiri en einn notandi á síðu, er næstum alltaf skynsamlegt að tileinka sér gagnagrunnslag.
10 notendur: færa gagnagrunninn á sérstakt stig
Að skipta gagnagrunninum í stýrða þjónustu eins og Amazon RDS eða Digital Ocean Managed Database mun þjóna okkur vel í langan tíma. Það er aðeins dýrara en sjálfhýsing á einni vél eða EC2 tilviki, en með þessari þjónustu færðu fullt af gagnlegum viðbótum úr kassanum sem munu koma sér vel í framtíðinni: öryggisafrit á mörgum svæðum, afrit af lestri, sjálfvirkt. öryggisafrit og fleira.
Svona lítur kerfið út núna:
100 notendur: færa viðskiptavininn á sérstakt stig
Sem betur fer líkaði fyrstu notendum okkar mjög vel við forritið okkar. Umferð er að verða stöðugri, svo það er kominn tími til að færa viðskiptavininn á sérstakt stig. Þess ber að geta að aðskilnaður einingar er lykilatriði í því að byggja upp skalanlegt forrit. Þar sem einn hluti kerfisins fær meiri umferð getum við skipt honum í skiptingu til að stjórna því hvernig þjónustan skalast út frá sérstökum umferðarmynstri.
Þess vegna finnst mér gaman að hugsa um viðskiptavininn sem aðskilinn frá API. Þetta gerir það mjög auðvelt að hugsa um þróun fyrir marga vettvanga: vef, farsímavef, iOS, Android, skrifborðsforrit, þjónustu þriðja aðila o.s.frv. Þetta eru allir bara viðskiptavinir sem nota sama API.
Til dæmis, nú biðja notendur okkar oftast um að gefa út farsímaforrit. Ef þú aðskilur biðlara og API einingar verður þetta auðveldara.
Svona lítur svona kerfi út:
1000 notendur: bæta við álagsjafnvægi
Hlutirnir eru að horfa upp á. Notendur Graminsta hlaða upp fleiri og fleiri myndum. Skráningum fer líka vaxandi. Eini API netþjónninn okkar á í erfiðleikum með að fylgjast með allri umferð. Vantar meira járn!
Álagsjafnari er mjög öflugt hugtak. Lykilhugmyndin er sú að við setjum álagsjafnara fyrir framan API og það dreifir umferð til einstakra þjónustutilvika. Þetta er hvernig við mælikvarða lárétt, sem þýðir að við bætum við fleiri netþjónum með sama kóða, auknum fjölda beiðna sem við getum afgreitt.
Við ætlum að setja aðskilda álagsjafnara fyrir framan vefþjóninn og fyrir framan API. Þetta þýðir að þú getur keyrt mörg tilvik sem keyra API kóða og kóða vefbiðlara. Álagsjafnari mun beina beiðnum til netþjónsins sem er minna hlaðinn.
Hér fáum við annan mikilvægan kost - offramboð. Þegar eitt tilvik mistekst (kannski ofhlaðinn eða hrun) sitjum við eftir með önnur sem halda áfram að svara beiðnum sem berast. Ef það væri aðeins eitt tilvik að virka, þá myndi allt kerfið hrynja ef bilun yrði.
Hleðslujafnari veitir einnig sjálfvirka mælingu. Við getum stillt það til að auka fjölda tilvika fyrir hámarksálag og minnka það þegar allir notendur sofa.
Með álagsjafnara er hægt að stækka API-stigið nánast endalaust, einfaldlega bæta við nýjum tilvikum eftir því sem beiðnum fjölgar.
Athugið. Núna er kerfið okkar mjög svipað því sem PaaS fyrirtæki eins og Heroku eða Elastic Beanstalk á AWS bjóða upp á úr kassanum (þess vegna eru þau svo vinsæl). Heroku setur gagnagrunninn á sérstakan hýsingaraðila, stjórnar sjálfvirkri stærðarjafnvægi og gerir þér kleift að hýsa vefþjóninn aðskilið frá API. Þetta er frábær ástæða til að nota Heroku fyrir verkefni á fyrstu stigum eða gangsetningum - þú færð alla grunnþjónustuna úr kassanum.
10 notendur: CDN
Kannski hefðum við átt að gera þetta alveg frá upphafi. Að vinna úr beiðnum og samþykkja nýjar myndir er farið að valda of miklu álagi á netþjóna okkar.
Á þessu stigi þarftu að nota skýjaþjónustu til að geyma kyrrstætt efni - myndir, myndbönd og margt fleira (AWS S3 eða Digital Ocean Spaces). Almennt séð ætti API okkar að forðast að meðhöndla hluti eins og að birta myndir og hlaða upp myndum á netþjóninn.
Annar kostur skýhýsingar er CDN (AWS kallar þessa viðbót Cloudfront, en margir skýjageymsluveitendur bjóða upp á það úr kassanum). CDN vistar myndirnar okkar sjálfkrafa í ýmsum gagnaverum um allan heim.
Þó að aðalgagnaverið okkar gæti verið staðsett í Ohio, ef einhver biður um mynd frá Japan, mun skýjaveitan gera afrit og geyma það í japanska gagnaverinu sínu. Næsti aðili sem biður um þessa mynd í Japan fær hana mun hraðar. Þetta er mikilvægt þegar við vinnum með stórar skrár, eins og myndir eða myndbönd, sem tekur langan tíma að hlaða niður og senda um jörðina.
100 notendur: skala gagnalagið
CDN hefur hjálpað mikið: umferð eykst á fullum hraða. Hinn frægi myndbandsbloggari Mavid Mobrick skráði sig hjá okkur og birti „söguna sína“ eins og sagt er. Þökk sé álagsjafnaranum er örgjörva- og minnisnotkun á API-þjónum haldið lágri (tíu API-tilvik í gangi), en við erum farin að fá mikið af tímamörkum á beiðnum... hvaðan koma þessar tafir?
Við að grafa aðeins ofan í mælikvarðana sjáum við að örgjörvinn á gagnagrunnsþjóninum er 80-90% hlaðinn. Við erum á takmörkunum.
Stærð gagnalagsins er líklega erfiðasti hluti jöfnunnar. API netþjónar þjóna ríkisfangslausum beiðnum, svo við bætum einfaldlega við fleiri API tilvikum. Nef meirihlutinn gagnagrunnar geta ekki gert þetta. Við munum tala um vinsæl tengslagagnagrunnsstjórnunarkerfi (PostgreSQL, MySQL osfrv.).
skyndiminni
Ein auðveldasta leiðin til að auka afköst gagnagrunnsins okkar er að kynna nýjan þátt: skyndiminnilagið. Algengasta skyndiminnisaðferðin er lykla-gildi plötubúð í minni, eins og Redis eða Memcached. Flest ský eru með stýrða útgáfu af þessum þjónustum: Elasticache á AWS og Memorystore á Google Cloud.
Skyndiminni er gagnlegt þegar þjónusta hringir mörg endurtekin símtöl í gagnagrunninn til að sækja sömu upplýsingar. Í meginatriðum fáum við aðeins einu sinni aðgang að gagnagrunninum, geymum upplýsingarnar í skyndiminni og snertum þær ekki aftur.
Til dæmis, í Graminsta þjónustunni okkar, í hvert skipti sem einhver fer á prófílsíðu stjörnunnar Mobrik, leitar API þjónninn í gagnagrunninn eftir upplýsingum frá prófílnum hans. Þetta gerist aftur og aftur. Þar sem prófílupplýsingar Mobrik breytast ekki við hverja beiðni eru þær frábærar fyrir skyndiminni.
Við munum geyma niðurstöðurnar úr gagnagrunninum í Redis með lykli user:id með 30 sekúndna gildistíma. Núna, þegar einhver fer á prófíl Mobrik, könnum við fyrst Redis, og ef gögnin eru til staðar flytjum við þau einfaldlega beint frá Redis. Nú hlaðast beiðnir til vinsælasta prófílsins á síðunni nánast ekki gagnagrunninum okkar.
Annar kostur flestra skyndiminniþjónustu er að auðveldara er að skala þær en gagnagrunnsþjónar. Redis er með innbyggða Redis Cluster ham. Svipað og álagsjafnari, það gerir þér kleift að dreifa Redis skyndiminni þinni yfir margar vélar (á þúsundir netþjóna ef þörf krefur).
Næstum öll stór forrit nota skyndiminni; það er algerlega óaðskiljanlegur hluti af hröðu API. Hraðari úrvinnsla beiðna og afkastameiri kóða skiptir öllu máli, en án skyndiminni er nánast ómögulegt að skala þjónustu til milljóna notenda.
Lestu eftirlíkingar
Þegar fyrirspurnum í gagnagrunninn hefur fjölgað mikið er eitt enn sem við getum gert að bæta við lesum eftirlíkingum í gagnagrunnsstjórnunarkerfið. Með stýrðu þjónustunni sem lýst er hér að ofan er hægt að gera þetta með einum smelli. Lesa eftirlíkingin verður áfram uppfærð í aðal DB og er tiltæk fyrir SELECT setningar.
Hér er kerfið okkar núna:
Næsta skref
Þegar forritið heldur áfram að stækka munum við halda áfram að aðskilja þjónustuna til að stækka hana sjálfstætt. Til dæmis, ef við byrjum að nota Websockets, þá er skynsamlegt að draga Websockets vinnslukóðann í sérstaka þjónustu. Við getum sett það á ný tilvik á bak við okkar eigin álagsjafnara, sem getur skalað upp og niður byggt á opnum Websockets tengingum og óháð fjölda HTTP beiðna.
Við munum einnig halda áfram að berjast gegn takmörkunum á gagnagrunnsstigi. Það er á þessu stigi sem það er kominn tími til að rannsaka gagnagrunnsskiptingu og sundrun. Báðar aðferðir krefjast viðbótarkostnaðar, en leyfa þér að skala gagnagrunninn nánast endalaust.
Við viljum líka setja upp vöktunar- og greiningarþjónustu eins og New Relic eða Datadog. Þetta mun hjálpa þér að bera kennsl á hægar fyrirspurnir og skilja hvar úrbóta er þörf. Þegar við stækkum, viljum við einbeita okkur að því að finna flöskuhálsa og útrýma þeim - oft með því að nota nokkrar af hugmyndunum frá fyrri köflum.
Heimildir
Þessi færsla er innblásin af einum af . Ég vildi gera greinina aðeins nákvæmari fyrir upphafsstig verkefna og leysa hana frá einum söluaðila. Vertu viss um að lesa ef þú hefur áhuga á þessu efni.
Neðanmálsgreinar
- Þó að það sé svipað hvað varðar álagsdreifingu yfir mörg tilvik, þá er undirliggjandi útfærsla Redis klasa mjög frábrugðin álagsjafnara.
Heimild: www.habr.com