Multaj noventreprenoj travivis ĉi tion: amasoj da novaj uzantoj registriĝas ĉiutage, kaj la disvolva teamo luktas por pluigi la servon.

Estas agrabla problemo havi, sed estas malmulte da klaraj informoj en la reto pri kiel zorge skali TTT-aplikaĵon de nenio ĝis centoj da miloj da uzantoj. Tipe ekzistas aŭ fajrosolvoj aŭ proplemkolosolvoj (kaj ofte ambaŭ). Tial homoj uzas sufiĉe kliŝitajn teknikojn por skali sian amatoran projekton en ion vere seriozan.

Ni provu filtri la informojn kaj noti la bazan formulon. Ni skalos nian novan fotokundividan retejon Graminsta paŝon post paŝo de 1 ĝis 100 uzantoj.

Ni skribu, kiajn specifajn agojn necesas fari kiam la spektantaro pliiĝas al 10, 100, 1000, 10 kaj 000 homoj.

1 uzanto: 1 maŝino

Preskaŭ ĉiu aplikaĵo, ĉu ĝi estas retejo aŭ poŝtelefona aplikaĵo, havas tri ŝlosilajn komponentojn:

• API
• Datumbazo
• kliento (poŝtelefono mem aŭ retejo)

La datumbazo konservas konstantajn datumojn. La API servas petojn al kaj ĉirkaŭ ĉi tiuj datumoj. La kliento transdonas datumojn al la uzanto.

Mi alvenis al la konkludo, ke estas multe pli facile paroli pri skalo de aplikaĵo se, el arkitektura vidpunkto, la kliento kaj API-unuoj estas tute apartigitaj.

Kiam ni unue komencas konstrui aplikaĵon, ĉiuj tri komponantoj povas ruliĝi sur la sama servilo. Iasence, ĉi tio similas al nia evolumedio: unu inĝeniero prizorgas la datumbazon, API kaj klienton sur la sama maŝino.

En teorio, ni povus disfaldi ĝin en la nubo sur ununura DigitalOcean Droplet aŭ AWS EC2-instanco, kiel montrite sube:

Dirite, se estos pli ol unu uzanto en retejo, preskaŭ ĉiam havas sencon dediĉi datumbazan tavolon.

10 uzantoj: movante la datumbazon al aparta nivelo

Dividi la datumbazon en administritajn servojn kiel Amazon RDS aŭ Digital Ocean Managed Database bone servos al ni dum longa tempo. Ĝi estas iom pli multekosta ol mem-gastigado sur ununura maŝino aŭ EC2-instanco, sed kun ĉi tiuj servoj vi ricevas multajn utilajn etendaĵojn el la skatolo, kiuj estos utilaj estonte: plurregiona sekurkopio, legado de kopioj, aŭtomata. sekurkopioj, kaj pli.

Jen kiel aspektas la sistemo nun:

100 uzantoj: movante la klienton al aparta nivelo

Feliĉe, niaj unuaj uzantoj tre ŝatis nian aplikaĵon. Trafiko fariĝas pli stabila, do estas tempo movi la klienton al aparta nivelo. Oni notu ke disiĝo estaĵoj estas ŝlosila aspekto de konstruado de skalebla aplikaĵo. Ĉar unu parto de la sistemo ricevas pli da trafiko, ni povas dividi ĝin por kontroli kiel la servo skalas laŭ specifaj trafikaj ŝablonoj.

Jen kial mi ŝatas pensi pri la kliento kiel aparta de la API. Ĉi tio tre facilas pensi pri evoluado por pluraj platformoj: retejo, movebla retejo, iOS, Android, labortablaj aplikoj, triaj servoj, ktp. Ili ĉiuj estas nur klientoj uzantaj la saman API.

Ekzemple, nun niaj uzantoj plej ofte petas liberigi poŝtelefonan aplikaĵon. Se vi disigas la klientajn kaj API-entaĵojn, ĉi tio fariĝas pli facila.

Jen kiel tia sistemo aspektas:

1000 uzantoj: aldonu ŝarĝbalancilon

Aferoj rigardas supren. Graminsta-uzantoj alŝutas pli kaj pli da fotoj. La nombro de registriĝoj ankaŭ kreskas. Nia sola API-servilo malfacilas teni la tutan trafikon. Bezonas pli da fero!

Ŝarĝbalancilo estas tre potenca koncepto. La ŝlosila ideo estas, ke ni metas ŝarĝan ekvilibron antaŭ la API, kaj ĝi distribuas trafikon al individuaj servaj petskriboj. Tiel ni skalas horizontale, tio signifas, ke ni aldonas pli da serviloj kun la sama kodo, pliigante la nombron da petoj, kiujn ni povas procesi.

Ni metos apartajn ŝarĝbalancilojn antaŭ la TTT-kliento kaj antaŭ la API. Ĉi tio signifas, ke vi povas ruli plurajn okazojn kurante API-kodon kaj retklientkodon. La ŝarĝbalancilo direktos petojn al la servilo, kiu estas malpli ŝarĝita.

Ĉi tie ni ricevas alian gravan avantaĝon - redundon. Kiam unu kazo malsukcesas (eble troŝarĝita aŭ kraŝinta), ni restas kun aliaj, kiuj daŭre respondas al envenantaj petoj. Se ekzistus nur unu kazo funkcianta, tiam en kazo de fiasko la tuta sistemo kraŝos.

La ŝarĝbalancilo ankaŭ disponigas aŭtomatan skalon. Ni povas agordi ĝin por pliigi la nombron da okazoj antaŭ pinta ŝarĝo, kaj malpliigi ĝin kiam ĉiuj uzantoj dormas.

Kun ŝarĝbalancilo, la API-nivelo povas esti skalita preskaŭ senfine, simple aldonante novajn okazojn kiam la nombro da petoj pliiĝas.

Notu. Ĝuste nun nia sistemo estas tre simila al tio, kion PaaS-kompanioj kiel Heroku aŭ Elastic Beanstalk sur AWS proponas el la skatolo (pro tio ili estas tiel popularaj). Heroku metas la datumbazon sur apartan gastiganton, administras aŭtomatan ŝarĝan ekvilibron kaj permesas vin gastigi la retklienton aparte de la API. Ĉi tio estas bonega kialo por uzi Heroku por komencaj projektoj aŭ noventreprenoj - vi ricevas ĉiujn bazajn servojn el la skatolo.

10 uzantoj: CDN

Eble ni devus fari tion de la komenco mem. Prilabori petojn kaj akcepti novajn fotojn komencas tro streĉi niajn servilojn.

En ĉi tiu etapo, vi devas uzi nuban servon por stoki senmovan enhavon - bildojn, filmetojn kaj multe pli (AWS S3 aŭ Digital Ocean Spaces). Ĝenerale, nia API devus eviti pritrakti aferojn kiel servi bildojn kaj alŝuti bildojn al la servilo.

Alia avantaĝo de nuba gastigado estas la CDN (AWS nomas ĉi tiun aldonaĵon Cloudfront, sed multaj provizantoj de nuba stokado proponas ĝin el la skatolo). La CDN aŭtomate konservas niajn bildojn en diversaj datumcentroj tra la mondo.

Kvankam nia ĉefa datumcentro povas troviĝi en Ohio, se iu petas bildon el Japanio, la nuba provizanto faros kopion kaj stokos ĝin en sia japana datumcentro. La sekva persono, kiu petos ĉi tiun bildon en Japanio, ricevos ĝin multe pli rapide. Ĉi tio gravas kiam ni laboras kun grandaj dosieroj, kiel fotoj aŭ filmetoj, kiuj bezonas longan tempon por elŝuti kaj transdoni tra la planedo.

100 uzantoj: skalo de la datumtavolo

CDN multe helpis: trafiko kreskas plenrapide. La fama videobloganto Mavid Mobrick ĵus registris ĉe ni kaj afiŝis sian "rakonton", kiel oni diras. Danke al la ŝarĝobalancilo, la CPU- kaj memoruzo sur la API-serviloj estas konservitaj malaltaj (dek API-okazaroj funkcias), sed ni komencas ricevi multajn tempodaŭrojn pri petoj... de kie venas ĉi tiuj prokrastoj?

Fosi iomete en la metrikojn, ni vidas, ke la CPU sur la datumbaza servilo estas 80-90% ŝarĝita. Ni estas ĉe la limo.

Skali la datumtavolon estas verŝajne la plej malfacila parto de la ekvacio. API-serviloj servas sennaciajn petojn, do ni simple aldonas pliajn API-okazojn. Nazo de la plimulto datumbazoj ne povas fari tion. Ni parolos pri popularaj rilataj datumbazaj administradsistemoj (PostgreSQL, MySQL, ktp.).

kaŝmemoro

Unu el la plej facilaj manieroj pliigi la rendimenton de nia datumbazo estas enkonduki novan komponenton: la kaŝmemoro-tavolon. La plej ofta kaŝmemormetodo estas enmemora ŝlosilvalora rekorda vendejo, kiel Redis aŭ Memcached. Plej multaj nuboj havas administritan version de ĉi tiuj servoj: Elasticache ĉe AWS kaj Memorystore ĉe Google Cloud.

Kaŝmemoro estas utila kiam servo faras multajn ripetajn vokojn al la datumbazo por preni la samajn informojn. Esence, ni aliras la datumbazon nur unufoje, konservas la informojn en la kaŝmemoro kaj ne tuŝas ĝin denove.

Ekzemple, en nia Graminsta servo, ĉiufoje kiam iu iras al la profilpaĝo de la stelo Mobrik, la API-servilo demandas la datumbazon por informoj de sia profilo. Ĉi tio okazas denove kaj denove. Ĉar la profilinformoj de Mobrik ne ŝanĝiĝas kun ĉiu peto, ĝi estas bonega por kaŝmemoro.

Ni konservos la rezultojn de la datumbazo en Redis per ŝlosilo user:id kun valideca periodo de 30 sekundoj. Nun, kiam iu iras al la profilo de Mobrik, ni unue kontrolas Redis, kaj se la datumoj estas tie, ni simple translokigas ĝin rekte de Redis. Nun petoj al la plej populara profilo en la retejo praktike ne ŝarĝas nian datumbazon.

Alia avantaĝo de la plej multaj kaŝmemorservoj estas ke ili estas pli facile skaleblaj ol datumbazaj serviloj. Redis havas enkonstruitan Redis Cluster-reĝimon. Simila al ŝarĝbalancilo1, ĝi permesas al vi distribui vian Redis-kaŝmemoron tra pluraj maŝinoj (tra miloj da serviloj se necese).

Preskaŭ ĉiuj grandskalaj aplikaĵoj uzas kaŝmemoron; ĝi estas absolute integra parto de rapida API. Pli rapida pritraktado de demandoj kaj pli produktiva kodo estas ĉiuj gravaj, sed sen kaŝmemoro estas preskaŭ neeble skali servon al milionoj da uzantoj.

Legu Replikojn

Kiam la nombro da demandoj al la datumbazo multe pliiĝis, unu plia afero, kiun ni povas fari, estas aldoni legitajn kopiojn en la datumbaza administradsistemo. Kun la administritaj servoj priskribitaj supre, ĉi tio povas esti farita per unu klako. La legita kopio restos aktuala en la ĉefa datumbazo kaj disponeblas por SELECT deklaroj.

Jen nia sistemo nun:

Sekvaj Paŝoj

Ĉar la aplikaĵo daŭre skalas, ni daŭre apartigos la servojn por skali ilin sendepende. Ekzemple, se ni komencas uzi Websockets, tiam havas sencon tiri la Websockets-pretigan kodon en apartan servon. Ni povas meti ĝin sur novajn okazojn malantaŭ nia propra ŝarĝbalancilo, kiu povas grimpi supren kaj malsupren surbaze de malfermitaj Websockets-konektoj kaj sendepende de la nombro da HTTP-petoj.

Ni ankaŭ daŭre batalos kontraŭ restriktoj ĉe la datumbaza nivelo. Estas en ĉi tiu etapo, ke estas tempo por studi datumbazpartigon kaj sharding. Ambaŭ aliroj postulas plian superkoston, sed permesas vin skali la datumbazon preskaŭ senfine.

Ni ankaŭ volas instali servon de monitorado kaj analizo kiel New Relic aŭ Datadog. Ĉi tio helpos vin identigi malrapidajn demandojn kaj kompreni kie necesas plibonigo. Dum ni skalas, ni volas koncentriĝi pri trovi proplempunktojn kaj forigi ilin—ofte uzante kelkajn el la ideoj de antaŭaj sekcioj.

Fontoj

Ĉi tiu afiŝo estas inspirita de unu el miaj plej ŝatataj afiŝoj pri alta skaleblo. Mi volis fari la artikolon iom pli specifa por la komencaj etapoj de projektoj kaj malligi ĝin de unu vendisto. Nepre legu se vi interesiĝas pri ĉi tiu temo.

Piednotoj

1. Kvankam simila laŭ ŝarĝa distribuo tra multoblaj okazoj, la subesta efektivigo de Redis-areto estas tre malsama de ŝarĝbalancilo. [reveno]

fonto: www.habr.com