ProHoster > Blogs > Administrācija > Kā mērogot no 1 līdz 100 000 lietotāju

Kā mērogot no 1 līdz 100 000 lietotāju

Daudzi jaunizveidotie uzņēmumi to ir piedzÄ«vojuÅ”i: katru dienu reÄ£istrējas daudz jaunu lietotāju, un izstrādes komanda cÄ«nās, lai pakalpojums darbotos.

Tā ir jauka problēma, taču tÄ«meklÄ« ir maz skaidras informācijas par to, kā rÅ«pÄ«gi mērogot tÄ«mekļa lietojumprogrammu no nekā lÄ«dz simtiem tÅ«kstoÅ”u lietotāju. Parasti ir vai nu ugunsdzēsÄ«bas risinājumi, vai vājās vietas risinājumi (un bieži vien abi). Tāpēc cilvēki izmanto diezgan kliÅ”ejiskus paņēmienus, lai savu amatieru projektu pārvērstu par kaut ko patieŔām nopietnu.

Mēģināsim filtrēt informāciju un pierakstÄ«sim pamatformulu. Mēs soli pa solim paplaÅ”ināsim mÅ«su jauno fotoattēlu koplietoÅ”anas vietni Graminsta no 1 lÄ«dz 100 000 lietotāju.

Uzrakstīsim, kādas konkrētas darbības ir jāveic, kad auditorija palielinās līdz 10, 100, 1000, 10 000 un 100 000 cilvēku.

1 lietotājs: 1 maŔīna

Gandrīz katrai lietojumprogrammai, neatkarīgi no tā, vai tā ir vietne vai mobilā lietojumprogramma, ir trīs galvenie komponenti:

  • API
  • datubāze
  • klients (paÅ”a mobilā lietojumprogramma vai vietne)

Datu bāzē tiek glabāti pastāvÄ«gi dati. API apkalpo pieprasÄ«jumus Å”iem datiem un ap tiem. Klients pārsÅ«ta datus lietotājam.

Nonācu pie secinājuma, ka ir daudz vieglāk runāt par lietojumprogrammas mērogoÅ”anu, ja no arhitektÅ«ras viedokļa klients un API entÄ«tijas ir pilnÄ«bā nodalÄ«tas.

Kad mēs pirmo reizi sākam veidot lietojumprogrammu, visus trÄ«s komponentus var palaist vienā serverÄ«. Dažos veidos tas ir lÄ«dzÄ«gs mÅ«su izstrādes videi: viens inženieris palaiž datu bāzi, API un klientu tajā paŔā maŔīnā.

Teorētiski mēs to varētu izvietot mākonī vienā DigitalOcean Droplet vai AWS EC2 instancē, kā parādīts zemāk:
Kā mērogot no 1 līdz 100 000 lietotāju
Ņemot to vērā, ja vietnē būs vairāk nekā viens lietotājs, gandrīz vienmēr ir jēga veltīt datu bāzes slāni.

10 lietotāji: datu bāzes pārvietoŔana uz atseviŔķu līmeni

Datu bāzes sadalÄ«Å”ana pārvaldÄ«tos pakalpojumos, piemēram, Amazon RDS vai Digital Ocean Managed Database, mums ilgi kalpos. Tas ir nedaudz dārgāks nekā paÅ”mitināŔana vienā datorā vai EC2 instancē, taču, izmantojot Å”os pakalpojumus, jÅ«s saņemat daudz noderÄ«gu paplaÅ”inājumu, kas noderēs nākotnē: vairāku reÄ£ionu dublÄ“Å”ana, lasāmas kopijas, automātiska. dublējumkopijas un daudz kas cits.

Tagad sistēma izskatās Ŕādi:
Kā mērogot no 1 līdz 100 000 lietotāju

100 lietotāji: klienta pārvietoŔana uz atseviŔķu līmeni

Par laimi mÅ«su pirmajiem lietotājiem mÅ«su lietojumprogramma ļoti patika. Satiksme kļūst stabilāka, tāpēc ir pienācis laiks pārcelt klientu uz atseviŔķu lÄ«meni. Jāpiebilst, ka atdalÄ«Å”ana entÄ«tijas ir galvenais mērogojamas lietojumprogrammas izveides aspekts. Tā kā viena sistēmas daļa saņem lielāku trafiku, mēs varam to sadalÄ«t, lai kontrolētu, kā pakalpojums tiek mērogots, pamatojoties uz konkrētiem trafika modeļiem.

Tāpēc man patÄ«k domāt, ka klients ir noŔķirts no API. Tādējādi ir ļoti viegli domāt par izstrādi vairākām platformām: tÄ«meklim, mobilajam tÄ«meklim, iOS, Android, darbvirsmas lietojumprogrammām, treÅ”o puÅ”u pakalpojumiem utt. Tie visi ir tikai klienti, kas izmanto vienu un to paÅ”u API.

Piemēram, tagad mÅ«su lietotāji visbiežāk lÅ«dz atbrÄ«vot mobilo aplikāciju. Atdalot klienta un API entÄ«tijas, tas kļūst vienkārŔāk.

Šāda sistēma izskatās Ŕādi:

Kā mērogot no 1 līdz 100 000 lietotāju

1000 lietotāju: pievienojiet slodzes balansētāju

Lietas virzās uz augÅ”u. Graminsta lietotāji augÅ”upielādē arvien vairāk fotoattēlu. Pieaug arÄ« reÄ£istrāciju skaits. MÅ«su vienÄ«gajam API serverim ir grÅ«ti sekot lÄ«dzi visai trafikai. Vajag vairāk dzelzs!

Slodzes balansētājs ir ļoti spēcÄ«gs jēdziens. Galvenā ideja ir tāda, ka mēs ievietojam slodzes lÄ«dzsvarotāju API priekŔā, un tas sadala trafiku atseviŔķām pakalpojumu instancēm. Tādā veidā mēs mērogojam horizontāli, tas nozÄ«mē, ka mēs pievienojam vairāk serveru ar vienu un to paÅ”u kodu, palielinot apstrādāto pieprasÄ«jumu skaitu.

Mēs ievietosim atseviŔķus slodzes balansētājus tÄ«mekļa klienta un API priekŔā. Tas nozÄ«mē, ka varat palaist vairākas instances, kurās darbojas API kods un tÄ«mekļa klienta kods. Slodzes lÄ«dzsvarotājs novirzÄ«s pieprasÄ«jumus uz serveri, kas ir mazāk noslogots.

Å eit mēs iegÅ«stam vēl vienu svarÄ«gu priekÅ”rocÄ«bu - atlaiÅ”anu. Ja viena instance neizdodas (iespējams, ir pārslogota vai avarējusi), mums paliek citi, kas turpina atbildēt uz ienākoÅ”ajiem pieprasÄ«jumiem. Ja darbotos tikai viens gadÄ«jums, tad kļūmes gadÄ«jumā visa sistēma avarētu.

Slodzes balansētājs nodroÅ”ina arÄ« automātisku mērogoÅ”anu. Mēs varam to konfigurēt, lai palielinātu gadÄ«jumu skaitu pirms maksimālās slodzes un samazinātu to, kad visi lietotāji guļ.

Izmantojot slodzes lÄ«dzsvarotāju, API lÄ«meni var mērogot gandrÄ«z bezgalÄ«gi, vienkārÅ”i pievienojot jaunus gadÄ«jumus, palielinoties pieprasÄ«jumu skaitam.

Kā mērogot no 1 līdz 100 000 lietotāju

PiezÄ«me. Å obrÄ«d mÅ«su sistēma ir ļoti lÄ«dzÄ«ga tai, ko PaaS uzņēmumi, piemēram, Heroku vai Elastic Beanstalk, piedāvā AWS (tāpēc tie ir tik populāri). Heroku ievieto datubāzi atseviŔķā resursdatorā, pārvalda automātiskās mērogoÅ”anas slodzes balansētāju un ļauj mitināt tÄ«mekļa klientu atseviŔķi no API. Tas ir lielisks iemesls, lai izmantotu Heroku agrÄ«nās stadijas projektiem vai jaunizveidotiem uzņēmumiem ā€” jÅ«s saņemat visus pamatpakalpojumus no kastes.

10 000 lietotāju: CDN

VarbÅ«t mums tas bija jādara jau paŔā sākumā. PieprasÄ«jumu apstrāde un jaunu fotoattēlu pieņemÅ”ana sāk radÄ«t pārāk lielu slodzi mÅ«su serveriem.

Å ajā posmā jums ir jāizmanto mākoņpakalpojums statiska satura - attēlu, video un daudz ko citu - glabāŔanai (AWS S3 vai Digital Ocean Spaces). Parasti mÅ«su API vajadzētu izvairÄ«ties no tādu darbÄ«bu veikÅ”anas kā attēlu rādÄ«Å”ana un attēlu augÅ”upielāde serverÄ«.

Vēl viena mākoņa mitināŔanas priekÅ”rocÄ«ba ir CDN (AWS Å”o papildinājumu sauc par Cloudfront, taču daudzi mākoņu krātuves pakalpojumu sniedzēji to piedāvā jau no kastes). CDN automātiski saglabā mÅ«su attēlus keÅ”atmiņā dažādos datu centros visā pasaulē.

Lai gan mÅ«su galvenais datu centrs var atrasties Ohaio Å”tatā, ja kāds pieprasa attēlu no Japānas, mākoņa pakalpojumu sniedzējs izveidos kopiju un saglabās to savā Japānas datu centrā. Nākamā persona, kas pieprasÄ«s Å”o attēlu Japānā, to saņems daudz ātrāk. Tas ir svarÄ«gi, ja strādājam ar lieliem failiem, piemēram, fotoattēliem vai videoklipiem, kuru lejupielāde un pārsÅ«tÄ«Å”ana uz planētas aizņem ilgu laiku.

Kā mērogot no 1 līdz 100 000 lietotāju

100 000 lietotāju: datu slāņa mērogoÅ”ana

CDN ir daudz palÄ«dzējis: satiksme pieaug pilnā ātrumā. Slavenais video emuāru autors Mavids Mobriks tikko reÄ£istrējās pie mums un ievietoja savu ā€œstāstuā€, kā saka. Pateicoties slodzes lÄ«dzsvarotājam, CPU un atmiņas lietojums API serveros tiek uzturēts zems (darbojas desmit API gadÄ«jumi), taču mēs sākam saņemt daudz pieprasÄ«jumu noildzes... no kurienes rodas Ŕādas aizkaves?

Nedaudz iedziļinoties metrikā, redzam, ka CPU datu bāzes serverī ir noslogots par 80-90%. Mēs esam pie robežas.

Datu slāņa mērogoÅ”ana, iespējams, ir vissarežģītākā vienādojuma daļa. API serveri apkalpo bezvalsts pieprasÄ«jumus, tāpēc mēs vienkārÅ”i pievienojam vairāk API gadÄ«jumu. Deguns vairākums datu bāzes to nevar izdarÄ«t. Runāsim par populārām relāciju datu bāzes pārvaldÄ«bas sistēmām (PostgreSQL, MySQL u.c.).

keÅ”atmiņa

Viens no vienkārŔākajiem veidiem, kā palielināt mÅ«su datu bāzes veiktspēju, ir ieviest jaunu komponentu: keÅ”atmiņas slāni. VisizplatÄ«tākā keÅ”atmiņas saglabāŔanas metode ir atmiņā esoÅ”s atslēgu vērtÄ«bu ierakstu veikals, piemēram, Redis vai Memcached. Lielākajai daļai mākoņu ir Å”o pakalpojumu pārvaldÄ«ta versija: Elasticache pakalpojumā AWS un Memorystore pakalpojumā Google Cloud.

KeÅ”atmiņa ir noderÄ«ga, ja pakalpojums veic daudzus atkārtotus zvanus uz datu bāzi, lai izgÅ«tu to paÅ”u informāciju. BÅ«tÄ«bā mēs piekļūstam datubāzei tikai vienu reizi, saglabājam informāciju keÅ”atmiņā un vairs nepieskaramies tai.

Piemēram, mÅ«su Graminsta servisā katru reizi, kad kāds dodas uz zvaigznes Mobrika profila lapu, API serveris datu bāzē pieprasa informāciju no viņa profila. Tas notiek atkal un atkal. Tā kā Mobrika profila informācija nemainās ar katru pieprasÄ«jumu, tas ir lieliski piemērots keÅ”atmiņai.

Mēs saglabāsim rezultātus no datu bāzes Redis pēc atslēgas user:id ar derÄ«guma termiņu 30 sekundes. Tagad, kad kāds dodas uz Mobrika profilu, mēs vispirms pārbaudām Redis, un, ja dati ir, mēs tos vienkārÅ”i pārsÅ«tām tieÅ”i no Redis. Tagad vietnes populārākā profila pieprasÄ«jumi praktiski neielādē mÅ«su datu bāzi.

Vēl viena vairuma keÅ”atmiņas pakalpojumu priekÅ”rocÄ«ba ir tā, ka tos ir vieglāk mērogot nekā datu bāzes serverus. Redis ir iebÅ«vēts Redis Cluster režīms. LÄ«dzÄ«gi kā slodzes balansētājs1, tas ļauj izplatÄ«t Redis keÅ”atmiņu vairākās iekārtās (ja nepiecieÅ”ams, tÅ«kstoÅ”iem serveru).

GandrÄ«z visas liela mēroga lietojumprogrammas izmanto keÅ”atmiņu; tā ir absolÅ«ti neatņemama ātras API sastāvdaļa. Ātrāka vaicājumu apstrāde un produktÄ«vāks kods ir svarÄ«gi, taču bez keÅ”atmiņas ir gandrÄ«z neiespējami pakalpojumu mērogot miljoniem lietotāju.

Lasiet kopijas

Kad datu bāzes vaicājumu skaits ir ievērojami pieaudzis, vēl viena lieta, ko mēs varam darÄ«t, ir datu bāzes pārvaldÄ«bas sistēmā pievienot lasāmās kopijas. Izmantojot iepriekÅ” aprakstÄ«tos pārvaldÄ«tos pakalpojumus, to var izdarÄ«t ar vienu klikŔķi. LasÄ«tā kopija paliks aktuāla galvenajā datu bāzē un ir pieejama SELECT priekÅ”rakstiem.

Šeit ir mūsu sistēma tagad:

Kā mērogot no 1 līdz 100 000 lietotāju

Nākamie soļi

Tā kā lietojumprogramma turpina mērogot, mēs turpināsim atdalÄ«t pakalpojumus, lai tos mērogotu neatkarÄ«gi. Piemēram, ja mēs sākam lietot Websockets, tad ir jēga Websockets apstrādes kodu ievilkt atseviŔķā pakalpojumā. Mēs varam to ievietot jaunās instancēs aiz mÅ«su paÅ”u slodzes balansētāja, kas var palielināt un samazināt, pamatojoties uz atvērtiem Websockets savienojumiem un neatkarÄ«gi no HTTP pieprasÄ«jumu skaita.

Tāpat turpināsim cÄ«nÄ«ties ar ierobežojumiem datu bāzes lÄ«menÄ«. TieÅ”i Å”ajā posmā ir pienācis laiks izpētÄ«t datu bāzes sadalÄ«Å”anu un sadalÄ«Å”anu. Abas pieejas prasa papildu pieskaitāmās izmaksas, taču ļauj gandrÄ«z neierobežoti mērogot datubāzi.

Mēs arÄ« vēlamies instalēt uzraudzÄ«bas un analÄ«zes pakalpojumu, piemēram, New Relic vai Datadog. Tas palÄ«dzēs jums noteikt lēnus vaicājumus un saprast, kur ir nepiecieÅ”ami uzlabojumi. Veicot mērogoÅ”anu, mēs vēlamies koncentrēties uz vājo vietu atraÅ”anu un to novērÅ”anu, bieži izmantojot dažas no iepriekŔējām sadaļām sniegtajām idejām.

avoti

Å Ä« ziņa ir iedvesmota no viena no mani iecienÄ«tākie ieraksti par augstu mērogojamÄ«bu. Es gribēju padarÄ«t rakstu nedaudz precÄ«zāku projektu sākuma posmiem un atsaistÄ«t to no viena pārdevēja. Noteikti izlasiet, ja jÅ«s interesē Ŕī tēma.

Zemsvītras piezīmes

  1. Lai gan slodzes sadalÄ«juma ziņā vairākos gadÄ«jumos tas ir lÄ«dzÄ«gs, Redis klastera pamatā esoŔā ievieÅ”ana ļoti atŔķiras no slodzes balansētāja. [atgriezties]

Kā mērogot no 1 līdz 100 000 lietotāju

Avots: www.habr.com

Pievieno komentāru