Številni startupi so šli skozi to: vsak dan se registrirajo množice novih uporabnikov, razvojna ekipa pa se trudi, da bi storitev delovala.

Težavo je lepo imeti, vendar je v spletu malo jasnih informacij o tem, kako skrbno prilagoditi spletno aplikacijo od nič do več sto tisoč uporabnikov. Običajno obstajajo bodisi rešitve požara ali rešitve ozkih grl (in pogosto oboje). Zato ljudje uporabljajo precej klišejske tehnike, da svoj amaterski projekt spremenijo v nekaj res resnega.

Poskusimo filtrirati informacije in zapisati osnovno formulo. Naše novo spletno mesto za skupno rabo fotografij Graminsta bomo korak za korakom povečali z 1 na 100 uporabnikov.

Zapišimo, katere posebne ukrepe je treba sprejeti, ko se občinstvo poveča na 10, 100, 1000, 10 in 000 ljudi.

1 uporabnik: 1 stroj

Skoraj vsaka aplikacija, naj bo to spletna stran ali mobilna aplikacija, ima tri ključne komponente:

• API
• baze podatkov
• odjemalec (sama mobilna aplikacija ali spletno mesto)

Baza podatkov hrani obstojne podatke. API streže zahteve do in okoli teh podatkov. Odjemalec posreduje podatke uporabniku.

Prišel sem do zaključka, da je veliko lažje govoriti o skaliranju aplikacije, če sta z arhitekturnega vidika odjemalec in API entitete popolnoma ločeni.

Ko prvič začnemo graditi aplikacijo, lahko vse tri komponente izvajamo na istem strežniku. Na nek način je to podobno našemu razvojnemu okolju: en inženir izvaja bazo podatkov, API in odjemalca na istem računalniku.

Teoretično bi ga lahko uvedli v oblak na enem primerku DigitalOcean Droplet ali AWS EC2, kot je prikazano spodaj:

Glede na to, če bo na spletnem mestu več kot en uporabnik, je skoraj vedno smiselno nameniti sloj baze podatkov.

10 uporabnikov: premik baze podatkov na ločen nivo

Razdelitev baze podatkov na upravljane storitve, kot sta Amazon RDS ali Digital Ocean Managed Database, nam bo dobro služila dolgo časa. Je nekoliko dražje kot samostojno gostovanje na enem računalniku ali primerku EC2, vendar s temi storitvami dobite veliko uporabnih razširitev, ki vam bodo v prihodnosti prišle prav: varnostno kopiranje v več regijah, branje replik, samodejno varnostne kopije in še več.

Takole izgleda sistem zdaj:

100 uporabnikov: premik odjemalca na ločen nivo

Na srečo je bila našim prvim uporabnikom naša aplikacija zelo všeč. Promet postaja vse bolj stabilen, zato je čas, da odjemalca prestavimo na ločen nivo. Opozoriti je treba, da ločitev entitete je ključni vidik gradnje razširljive aplikacije. Ko en del sistema prejme več prometa, ga lahko razdelimo, da nadziramo, kako se storitev meri na podlagi specifičnih vzorcev prometa.

Zato rad razmišljam o odjemalcu kot ločenem od API-ja. Zaradi tega je zelo enostavno razmišljati o razvoju za več platform: splet, mobilni splet, iOS, Android, namizne aplikacije, storitve tretjih oseb itd. Vsi so samo odjemalci, ki uporabljajo isti API.

Na primer, zdaj naši uporabniki najpogosteje zahtevajo izdajo mobilne aplikacije. Če ločite entitete odjemalca in API-ja, postane to lažje.

Takole izgleda tak sistem:

1000 uporabnikov: dodajte izravnalnik obremenitve

Stvari gredo na bolje. Uporabniki Graminsta nalagajo vedno več fotografij. Narašča tudi število prijav. Naš edini strežnik API težko dohaja ves promet. Potrebujemo več železa!

Izravnalnik obremenitve je zelo močan koncept. Ključna ideja je, da postavimo izravnalnik obremenitve pred API in ta porazdeli promet posameznim primerkom storitve. Tako se skaliramo vodoravno, kar pomeni, da dodamo več strežnikov z isto kodo, s čimer povečamo število zahtev, ki jih lahko obdelamo.

Pred spletnim odjemalcem in pred API-jem bomo postavili ločena izravnalnika obremenitve. To pomeni, da lahko izvajate več primerkov, ki izvajajo kodo API in kodo spletnega odjemalca. Izravnalnik obremenitve bo zahteve usmeril na strežnik, ki je manj obremenjen.

Tu dobimo še eno pomembno prednost – redundanco. Ko en primerek odpove (morda preobremenjen ali se je zrušil), nam ostanejo drugi, ki se še naprej odzivajo na dohodne zahteve. Če bi deloval samo en primerek, bi se v primeru okvare celoten sistem zrušil.

Izravnalnik obremenitve omogoča tudi samodejno skaliranje. Lahko ga konfiguriramo tako, da poveča število primerkov pred največjo obremenitvijo in ga zmanjša, ko vsi uporabniki spijo.

Z izravnalnikom obremenitve je mogoče nivo API-ja spreminjati skoraj neomejeno, preprosto z dodajanjem novih primerkov, ko se število zahtev poveča.

Opomba. Trenutno je naš sistem zelo podoben tistemu, ki ga ponujajo podjetja PaaS, kot sta Heroku ali Elastic Beanstalk na AWS (zato so tako priljubljena). Heroku postavi bazo podatkov na ločenega gostitelja, upravlja izravnalnik obremenitve s samodejnim skaliranjem in vam omogoča gostovanje spletnega odjemalca ločeno od API-ja. To je odličen razlog za uporabo Herokuja za projekte v zgodnji fazi ali zagonska podjetja - vse osnovne storitve dobite takoj.

10 uporabnikov: CDN

Morda bi morali to storiti že na samem začetku. Obdelava zahtev in sprejemanje novih fotografij začenjata preveč obremenjevati naše strežnike.

Na tej stopnji morate uporabiti storitev v oblaku za shranjevanje statične vsebine – slik, video posnetkov in še veliko več (AWS S3 ali Digital Ocean Spaces). Na splošno se mora naš API izogibati obravnavanju stvari, kot je streženje slik in nalaganje slik na strežnik.

Druga prednost gostovanja v oblaku je CDN (AWS ta dodatek imenuje Cloudfront, vendar ga številni ponudniki shranjevanja v oblaku ponujajo takoj). CDN samodejno shranjuje naše slike v različnih podatkovnih centrih po vsem svetu.

Čeprav je naš glavni podatkovni center morda v Ohiu, bo ponudnik oblaka, če bo zahteval sliko iz Japonske, naredil kopijo in jo shranil v svoj japonski podatkovni center. Naslednja oseba, ki bo zahtevala to sliko na Japonskem, jo ​​bo prejela veliko hitreje. To je pomembno, ko delamo z velikimi datotekami, kot so fotografije ali videoposnetki, katerih prenos in prenos po celem planetu traja dolgo časa.

100 uporabnikov: prilagajanje podatkovne plasti

CDN je veliko pomagal: promet raste s polno hitrostjo. Slavni video bloger Mavid Mobrick se je pravkar registriral pri nas in objavil svojo »zgodbo«, kot pravijo. Zahvaljujoč izravnalniku obremenitve sta poraba procesorja in pomnilnika na strežnikih API nizka (deset primerkov API-ja se izvaja), vendar začenjamo dobivati ​​veliko časovnih omejitev pri zahtevah ... od kod prihajajo te zamude?

Če se malo poglobimo v metrike, vidimo, da je CPU na strežniku baze podatkov obremenjen 80-90%. Smo na meji.

Skaliranje podatkovne plasti je verjetno najtežji del enačbe. Strežniki API služijo zahtevam brez stanja, zato preprosto dodamo več primerkov API. Nos večina baze podatkov tega ne zmorejo. Govorili bomo o priljubljenih sistemih za upravljanje relacijskih baz podatkov (PostgreSQL, MySQL itd.).

Predpomnjenje

Eden najpreprostejših načinov za povečanje zmogljivosti naše podatkovne baze je uvedba nove komponente: plasti predpomnilnika. Najpogostejša metoda predpomnjenja je shramba zapisov ključ-vrednost v pomnilniku, kot sta Redis ali Memcached. Večina oblakov ima upravljano različico teh storitev: Elasticache na AWS in Memorystore na Google Cloud.

Predpomnilnik je uporaben, ko storitev velikokrat kliče bazo podatkov, da pridobi iste informacije. V bistvu dostopamo do baze podatkov le enkrat, podatke shranimo v predpomnilnik in se jih ne dotaknemo več.

Na primer, v naši storitvi Graminsta vsakič, ko nekdo obišče stran s profilom zvezdnika Mobrika, strežnik API poizveduje v bazi podatkov za informacije iz njegovega profila. To se dogaja znova in znova. Ker se podatki o Mobrikovem profilu ne spreminjajo ob vsaki zahtevi, je odličen za predpomnjenje.

Rezultate iz baze podatkov bomo shranili v Redis po ključu user:id z veljavnostjo 30 sekund. Zdaj, ko gre nekdo na Mobrikov profil, najprej preverimo Redis, in če so podatki tam, jih preprosto prenesemo direktno iz Redisa. Zdaj zahteve za najbolj priljubljen profil na spletnem mestu praktično ne naložijo naše baze podatkov.

Druga prednost večine storitev predpomnjenja je, da jih je lažje prilagoditi velikosti kot strežnike baz podatkov. Redis ima vgrajen način Redis Cluster. Podobno kot izravnalnik obremenitve1, vam omogoča, da predpomnilnik Redis razdelite na več računalnikov (po potrebi na tisoče strežnikov).

Skoraj vse velike aplikacije uporabljajo predpomnjenje; je absolutno sestavni del hitrega API-ja. Hitrejša obdelava poizvedb in bolj produktivna koda sta pomembni, vendar je brez predpomnilnika skoraj nemogoče razširiti storitev na milijone uporabnikov.

Preberi replike

Ko se število poizvedb v bazi podatkov zelo poveča, lahko naredimo še eno stvar, da dodamo branje replik v sistemu za upravljanje baze podatkov. Z zgoraj opisanimi upravljanimi storitvami je to mogoče storiti z enim klikom. Prebrana replika bo ostala aktualna v glavni bazi podatkov in je na voljo za stavke SELECT.

Tukaj je zdaj naš sistem:

Naslednji koraki

Ker se aplikacija še naprej povečuje, bomo še naprej ločevali storitve, da jih bomo neodvisno prilagajali. Na primer, če začnemo uporabljati Websockets, je smiselno kodo za obdelavo Websockets potegniti v ločeno storitev. Lahko ga postavimo na nove instance za lastnim izravnalnikom obremenitve, ki se lahko poveča in zmanjša glede na odprte povezave Websockets in ne glede na število zahtev HTTP.

Prav tako se bomo še naprej borili proti omejitvam na ravni baze podatkov. Na tej stopnji je čas za preučevanje particioniranja in razčlenjevanja baze podatkov. Oba pristopa zahtevata dodatne stroške, vendar omogočata skoraj neomejeno spreminjanje podatkovne baze.

Prav tako želimo namestiti storitev spremljanja in analitike, kot sta New Relic ali Datadog. To vam bo pomagalo prepoznati počasne poizvedbe in razumeti, kje so potrebne izboljšave. Ko se širimo, se želimo osredotočiti na iskanje ozkih grl in njihovo odpravo – pogosto z uporabo nekaterih idej iz prejšnjih razdelkov.

viri

Ta objava je nastala po navdihu enega od moje najljubše objave o visoki razširljivosti. Želel sem narediti članek nekoliko bolj specifičen za začetne faze projektov in ga odvezati od enega prodajalca. Vsekakor preberite, če vas ta tema zanima.

Opombe

1. Čeprav je podobna v smislu porazdelitve obremenitve med več primerki, se osnovna izvedba gruče Redis zelo razlikuje od izravnalnika obremenitve. [vrnitev]

Vir: www.habr.com