Monet startup-yritykset ovat käyneet tämän läpi: joukoittain uusia käyttäjiä rekisteröityy joka päivä, ja kehitystiimi kamppailee pitääkseen palvelun käynnissä.

Se on mukava ongelma, mutta verkossa ei ole juurikaan selkeää tietoa siitä, kuinka verkkosovellus skaalata huolellisesti tyhjästä satoihin tuhansiin käyttäjiin. Tyypillisesti on olemassa joko paloratkaisuja tai pullonkaularatkaisuja (ja usein molempia). Siksi ihmiset käyttävät melko kliseisiä tekniikoita skaalatakseen amatööriprojektinsa todella vakavaksi.

Yritetään suodattaa tiedot ja kirjoittaa peruskaava muistiin. Aiomme skaalata uuden valokuvanjakosivustomme Graminsta askel askeleelta yhdestä 1 100 käyttäjään.

Kirjataan ylös, mitä konkreettisia toimia pitää tehdä, kun yleisö kasvaa 10, 100, 1000, 10 000 ja 100 000 ihmiseen.

1 käyttäjä: 1 kone

Lähes jokaisessa sovelluksessa, olipa kyseessä verkkosivusto tai mobiilisovellus, on kolme avainosaa:

• API
• tietokanta
• asiakas (itse mobiilisovellus tai verkkosivusto)

Tietokanta tallentaa pysyviä tietoja. API palvelee pyyntöjä näihin tietoihin ja niiden ympärille. Asiakas lähettää tiedot käyttäjälle.

Tulin siihen tulokseen, että on paljon helpompaa puhua sovelluksen skaalauksesta, jos arkkitehtonisesti asiakas- ja API-oliot ovat täysin erillään.

Kun aloitamme sovelluksen rakentamisen, kaikki kolme komponenttia voidaan ajaa samalla palvelimella. Jollain tapaa tämä muistuttaa kehitysympäristöämme: yksi insinööri käyttää tietokantaa, API:ta ja asiakasta samalla koneella.

Teoriassa voisimme ottaa sen käyttöön pilvessä yhdessä DigitalOcean Droplet- tai AWS EC2 -esiintymässä alla olevan kuvan mukaisesti:

Tästä huolimatta, jos sivustolla on useampi kuin yksi käyttäjä, on lähes aina järkevää omistaa tietokantakerros.

10 käyttäjää: tietokannan siirtäminen eri tasolle

Tietokannan jakaminen hallinnoituihin palveluihin, kuten Amazon RDS tai Digital Ocean Managed Database, palvelee meitä hyvin pitkään. Se on hieman kalliimpaa kuin itseisännöinti yhdellä koneella tai EC2-esiintymillä, mutta näiden palvelujen avulla saat käyttöösi paljon hyödyllisiä laajennuksia, joista on hyötyä tulevaisuudessa: usean alueen varmuuskopiointi, replikoiden lukeminen, automaattinen varmuuskopiot ja paljon muuta.

Tältä järjestelmä näyttää nyt:

100 käyttäjää: asiakkaan siirtäminen eri tasolle

Onneksi ensimmäiset käyttäjämme pitivät todella sovelluksestamme. Liikenne on tasaantumassa, joten on aika siirtää asiakas erilliselle tasolle. On huomattava, että erottaminen entiteetit on keskeinen osa skaalautuvan sovelluksen rakentamista. Kun yksi järjestelmän osa vastaanottaa enemmän liikennettä, voimme osioida sen hallitaksemme, kuinka palvelu skaalautuu tiettyjen liikennemallien perusteella.

Tästä syystä haluan ajatella, että asiakas on erillinen API:sta. Tämän ansiosta on erittäin helppo harkita kehittämistä useille alustoille: web, mobiiliverkko, iOS, Android, työpöytäsovellukset, kolmannen osapuolen palvelut jne. Ne ovat kaikki vain asiakkaita, jotka käyttävät samaa APIa.

Esimerkiksi nyt käyttäjämme useimmiten pyytävät vapauttamaan mobiilisovelluksen. Jos erotat asiakas- ja API-entiteetit, tämä helpottuu.

Tältä tällainen järjestelmä näyttää:

1000 käyttäjää: lisää kuormituksen tasapainotin

Asiat ovat parantuneet. Graminstan käyttäjät lataavat yhä enemmän kuvia. Myös ilmoittautumisten määrä on kasvussa. Yksinäisellä API-palvelimellamme on vaikeuksia pysyä mukana kaikessa liikenteessä. Tarvitaan lisää rautaa!

Kuormantasauslaite on erittäin tehokas konsepti. Keskeinen ajatus on, että asetamme API:n eteen kuormituksen tasapainottimen, joka jakaa liikenteen yksittäisiin palveluinstanssiin. Näin skaalaamme vaakasuunnassa, mikä tarkoittaa, että lisäämme palvelimia samalla koodilla, mikä lisää käsittelemiemme pyyntöjen määrää.

Aiomme sijoittaa erilliset kuormituksen tasaajat verkkoasiakkaan ja API:n eteen. Tämä tarkoittaa, että voit ajaa useita esiintymiä, joissa käytetään API-koodia ja verkkoasiakaskoodia. Kuormituksen tasapainotin ohjaa pyynnöt vähemmän kuormitettuun palvelimeen.

Täällä saamme toisen tärkeän edun - redundanssin. Kun yksi ilmentymä epäonnistuu (ehkä ylikuormitettu tai kaatuu), jäämme muihin, jotka jatkavat vastaamista saapuviin pyyntöihin. Jos toiminnassa olisi vain yksi ilmentymä, koko järjestelmä kaatuu vian sattuessa.

Kuormantasauslaite tarjoaa myös automaattisen skaalauksen. Voimme määrittää sen lisäämään esiintymien määrää ennen huippukuormitusta ja vähentämään sitä, kun kaikki käyttäjät nukkuvat.

Kuormantasaajan avulla API-tasoa voidaan skaalata lähes loputtomiin lisäämällä uusia esiintymiä pyyntöjen määrän kasvaessa.

Huomautus. Tällä hetkellä järjestelmämme on hyvin samankaltainen kuin PaaS-yritykset, kuten Heroku tai Elastic Beanstalk AWS:ssä, tarjoavat heti valmiina (siksi ne ovat niin suosittuja). Heroku asettaa tietokannan erilliselle isännälle, hallitsee automaattisesti skaalautuvaa kuormitustasainta ja antaa sinun isännöidä verkkoasiakasta erillään API:sta. Tämä on hyvä syy käyttää Herokua alkuvaiheen projekteihin tai startup-yrityksiin – saat kaikki peruspalvelut valmiiksi.

10 000 käyttäjää: CDN

Ehkä meidän olisi pitänyt tehdä tämä alusta alkaen. Pyyntöjen käsittely ja uusien kuvien hyväksyminen alkaa kuormittaa palvelimiamme liikaa.

Tässä vaiheessa sinun on käytettävä pilvipalvelua staattisen sisällön - kuvien, videoiden ja paljon muuta - tallentamiseen (AWS S3 tai Digital Ocean Spaces). Yleisesti ottaen API:mme tulisi välttää sellaisten asioiden käsittelyä, kuten kuvien näyttäminen ja kuvien lataaminen palvelimelle.

Toinen pilvipalvelun etu on CDN (AWS kutsuu tätä lisäosaa Cloudfrontiksi, mutta monet pilvitallennuspalveluntarjoajat tarjoavat sen heti valmiina). CDN tallentaa kuvamme automaattisesti välimuistiin useissa datakeskuksissa ympäri maailmaa.

Vaikka pääpalvelinkeskuksemme saattaa sijaita Ohiossa, jos joku pyytää kuvaa Japanista, pilvipalveluntarjoaja tekee siitä kopion ja tallentaa sen japanilaiseen palvelinkeskukseensa. Seuraava henkilö, joka pyytää tätä kuvaa Japanissa, saa sen paljon nopeammin. Tämä on tärkeää, kun käsittelemme suuria tiedostoja, kuten valokuvia tai videoita, joiden lataaminen ja lähettäminen ympäri planeettaa kestää kauan.

100 000 käyttäjää: tietokerroksen skaalaus

CDN on auttanut paljon: liikenne kasvaa täydellä nopeudella. Kuuluisa videobloggaaja Mavid Mobrick rekisteröityi juuri meille ja julkaisi "tarinansa", kuten he sanovat. Kuormituksen tasapainottajan ansiosta API-palvelimien prosessorin ja muistin käyttö pysyy alhaisena (kymmenen API-instanssia käynnissä), mutta pyyntöihin alkaa tulla paljon aikakatkaisuja... mistä nämä viiveet tulevat?

Kun kaivellaan hieman mittareihin, huomaamme, että tietokantapalvelimen CPU on 80-90% ladattu. Olemme rajalla.

Tietokerroksen skaalaus on luultavasti vaikein osa yhtälöä. API-palvelimet palvelevat tilattomia pyyntöjä, joten lisäämme vain lisää API-esiintymiä. Nenä valtaosa tietokannat eivät voi tehdä tätä. Puhumme suosituista relaatiotietokannan hallintajärjestelmistä (PostgreSQL, MySQL jne.).

välimuisti

Yksi helpoimmista tavoista parantaa tietokantamme suorituskykyä on ottaa käyttöön uusi komponentti: välimuistikerros. Yleisin välimuistimenetelmä on muistissa oleva avainarvotietuevarasto, kuten Redis tai Memcached. Useimmissa pilvissä on hallittu versio näistä palveluista: Elasticache AWS:ssä ja Memorystore Google Cloudissa.

Välimuisti on hyödyllinen, kun palvelu soittaa useita toistuvia puheluita tietokantaan hakeakseen samoja tietoja. Käytämme tietokantaa käytännössä vain kerran, tallennamme tiedot välimuistiin emmekä koske siihen uudelleen.

Esimerkiksi Graminsta-palvelussamme joka kerta kun joku menee tähti Mobrikin profiilisivulle, API-palvelin kyselee tietokannasta tietoja hänen profiilistaan. Tämä tapahtuu yhä uudelleen ja uudelleen. Koska Mobrikin profiilitiedot eivät muutu jokaisen pyynnön yhteydessä, se sopii erinomaisesti välimuistiin.

Tallennamme tulokset välimuistiin Redis-tietokannasta avaimella user:id joiden voimassaoloaika on 30 sekuntia. Nyt kun joku menee Mobrikin profiiliin, tarkistamme ensin Rediksen, ja jos tiedot ovat siellä, siirrämme ne suoraan Rediksestä. Nyt sivuston suosituimman profiilin pyynnöt eivät käytännössä lataa tietokantaamme.

Toinen useimpien välimuistipalveluiden etu on, että niitä on helpompi skaalata kuin tietokantapalvelimia. Redisissä on sisäänrakennettu Redis Cluster -tila. Samanlainen kuin kuorman tasauslaite1, sen avulla voit jakaa Redis-välimuistisi useille koneille (tarvittaessa tuhansien palvelimien kesken).

Lähes kaikki suuret sovellukset käyttävät välimuistia; se on ehdottoman olennainen osa nopeaa APIa. Nopeampi kyselynkäsittely ja tuottavampi koodi ovat kaikki tärkeitä, mutta ilman välimuistia palvelua on lähes mahdotonta skaalata miljoonille käyttäjille.

Lue kopioita

Kun tietokantaan kohdistuvien kyselyiden määrä on lisääntynyt huomattavasti, voimme vielä tehdä lukukopioita tietokannan hallintajärjestelmään. Yllä kuvatuilla hallinnoiduilla palveluilla tämä voidaan tehdä yhdellä napsautuksella. Luettu replika pysyy ajan tasalla päätietokannassa ja on käytettävissä SELECT-käskyjä varten.

Tässä on nyt järjestelmämme:

Seuraavat vaiheet

Sovelluksen skaalaamisen jatkuessa jatkamme palveluiden erottamista skaalataksemme ne itsenäisesti. Jos esimerkiksi aloitamme Websocketsin käytön, on järkevää vetää Websocketsin käsittelykoodi erilliseen palveluun. Voimme sijoittaa sen uusiin instansseihin oman kuormituksen tasapainottimemme taakse, joka voi skaalata ylös ja alas avoimien Websockets-yhteyksien perusteella ja HTTP-pyyntöjen määrästä riippumatta.

Jatkamme myös tietokantatason rajoitusten torjuntaa. Tässä vaiheessa on aika tutkia tietokannan osiointia ja jakamista. Molemmat lähestymistavat vaativat lisäkustannuksia, mutta niiden avulla voit skaalata tietokantaa lähes loputtomiin.

Haluamme myös asentaa seuranta- ja analytiikkapalvelun, kuten New Relicin tai Datadogin. Tämä auttaa sinua tunnistamaan hitaat kyselyt ja ymmärtämään, missä tarvitaan parannuksia. Skaalautuessamme haluamme keskittyä pullonkaulojen löytämiseen ja niiden poistamiseen – usein hyödyntäen joitain aiempien osioiden ideoita.

lähteet

Tämä postaus on saanut inspiraationsa yhdestä suosikkiviestini korkeasta skaalautumisesta. Halusin tehdä artikkelista hieman tarkemman projektin alkuvaiheessa ja irrottaa sen yhdeltä toimittajalta. Muista lukea, jos olet kiinnostunut tästä aiheesta.

Alaviitteet

1. Vaikka Redis-klusterin taustalla oleva toteutus eroaa hyvin kuormituksen jakautumisesta useiden esiintymien kesken, se on hyvin erilainen kuin kuormituksen tasapainottaja. [palata]

Lähde: will.com