Mnoho startupov si tým prešlo: každý deň sa registrujú davy nových používateľov a vývojový tím sa snaží udržať službu v prevádzke.
Je to pekný problém, ale na webe je málo jasných informácií o tom, ako opatrne škálovať webovú aplikáciu od ničoho až po státisíce používateľov. Zvyčajne existujú buď požiarne riešenia alebo riešenia prekážok (a často oboje). Preto ľudia používajú skôr klišé techniky, aby zmenili svoj amatérsky projekt na niečo skutočne vážne.
Skúsme filtrovať informácie a zapíšme si základný vzorec. Našu novú stránku na zdieľanie fotografií Graminsta postupne zväčšíme z 1 na 100 000 používateľov.
Napíšme si, aké konkrétne akcie treba urobiť, keď sa sledovanosť zvýši na 10, 100, 1000, 10 000 a 100 000 ľudí.
1 používateľ: 1 stroj
Takmer každá aplikácia, či už je to webová stránka alebo mobilná aplikácia, má tri kľúčové komponenty:
- API
- databázy
- klient (samotná mobilná aplikácia alebo webová stránka)
Databáza uchováva trvalé údaje. Rozhranie API obsluhuje požiadavky na tieto údaje a okolo nich. Klient prenáša dáta užívateľovi.
Prišiel som na to, že je oveľa jednoduchšie hovoriť o škálovaní aplikácie, ak sú z architektonického hľadiska klient a API entity úplne oddelené.
Keď prvýkrát začneme zostavovať aplikáciu, všetky tri komponenty môžu byť spustené na rovnakom serveri. V niektorých ohľadoch je to podobné nášmu vývojovému prostrediu: jeden inžinier prevádzkuje databázu, API a klienta na rovnakom počítači.
Teoreticky by sme ho mohli nasadiť v cloude na jednej inštancii DigitalOcean Droplet alebo AWS EC2, ako je uvedené nižšie:
Vzhľadom na to, ak bude na stránke viac ako jeden používateľ, takmer vždy má zmysel venovať databázovú vrstvu.
10 používateľov: presun databázy na samostatnú úroveň
Rozdelenie databázy na spravované služby ako Amazon RDS alebo Digital Ocean Managed Database nám bude slúžiť dlho. Je to o niečo drahšie ako vlastné hosťovanie na jednom počítači alebo inštancii EC2, ale s týmito službami získate hneď po vybalení množstvo užitočných rozšírení, ktoré sa vám budú hodiť v budúcnosti: zálohovanie viacerých regiónov, čítanie replik, automatické zálohy a ďalšie.
Takto vyzerá systém teraz:
100 používateľov: presun klienta na samostatnú úroveň
Našťastie sa našim prvým používateľom naša aplikácia veľmi páčila. Prevádzka sa stáva stabilnejšou, a tak je čas posunúť klienta na samostatnú úroveň. Treba poznamenať, že oddelenie entity je kľúčovým aspektom budovania škálovateľnej aplikácie. Keď jedna časť systému prijíma viac návštevnosti, môžeme ju rozdeliť, aby sme riadili, ako sa služba škáluje na základe špecifických vzorcov návštevnosti.
To je dôvod, prečo si rád predstavujem klienta ako oddeleného od API. Vďaka tomu je veľmi jednoduché uvažovať o vývoji pre viacero platforiem: web, mobilný web, iOS, Android, desktopové aplikácie, služby tretích strán atď. Všetko sú to len klienti používajúci rovnaké API.
Napríklad teraz naši používatelia najčastejšie žiadajú o vydanie mobilnej aplikácie. Ak oddelíte entity klienta a API, bude to jednoduchšie.
Takto vyzerá takýto systém:
1000 používateľov: pridajte nástroj na vyrovnávanie zaťaženia
Veci sa pozerajú hore. Používatelia Graminsta nahrávajú čoraz viac fotografií. Rastie aj počet registrácií. Náš osamelý server API má problém držať krok so všetkou premávkou. Potrebujete viac železa!
Load balancer je veľmi výkonný koncept. Kľúčovou myšlienkou je, že pred API umiestnime nástroj na vyvažovanie zaťaženia, ktorý rozdeľuje návštevnosť do jednotlivých inštancií služieb. Takto škálujeme horizontálne, čo znamená, že pridávame viac serverov s rovnakým kódom, čím zvyšujeme počet žiadostí, ktoré môžeme spracovať.
Pred webového klienta a pred API umiestnime samostatné vyrovnávače zaťaženia. To znamená, že môžete spustiť viacero inštancií s kódom API a kódom webového klienta. Nástroj na vyrovnávanie zaťaženia bude smerovať požiadavky na server, ktorý je menej zaťažený.
Tu dostávame ďalšiu dôležitú výhodu – redundanciu. Keď jedna inštancia zlyhá (možno preťažená alebo havarovaná), zostávajú nám ďalšie, ktoré naďalej odpovedajú na prichádzajúce požiadavky. Ak by fungovala iba jedna inštancia, v prípade zlyhania by sa zrútil celý systém.
Load balancer poskytuje aj automatické škálovanie. Môžeme ho nakonfigurovať tak, aby zvýšil počet inštancií pred špičkovým zaťažením a znížil ho, keď všetci používatelia spia.
Pomocou nástroja na vyrovnávanie záťaže je možné úroveň rozhrania API škálovať takmer donekonečna jednoduchým pridávaním nových inštancií so zvyšujúcim sa počtom požiadaviek.
Poznámka. Práve teraz je náš systém veľmi podobný tomu, čo spoločnosti PaaS ako Heroku alebo Elastic Beanstalk na AWS ponúkajú hneď po vybalení (preto sú také populárne). Heroku umiestňuje databázu na samostatného hostiteľa, spravuje nástroj na automatické škálovanie záťaže a umožňuje hosťovať webového klienta oddelene od rozhrania API. To je skvelý dôvod, prečo používať Heroku pre počiatočné projekty alebo startupy – všetky základné služby získate hneď po vybalení.
10 000 používateľov: CDN
Možno sme to mali urobiť od samého začiatku. Spracovanie žiadostí a prijímanie nových fotografií začína príliš zaťažovať naše servery.
V tejto fáze je potrebné využiť cloudovú službu na ukladanie statického obsahu – obrázkov, videí a mnoho ďalšieho (AWS S3 alebo Digital Ocean Spaces). Vo všeobecnosti by sa naše rozhranie API nemalo zaoberať vecami, ako je poskytovanie obrázkov a nahrávanie obrázkov na server.
Ďalšou výhodou cloudového hostingu je CDN (AWS nazýva tento doplnok Cloudfront, ale mnohí poskytovatelia cloudových úložísk ho ponúkajú hneď po vybalení). CDN automaticky ukladá naše obrázky do vyrovnávacej pamäte v rôznych dátových centrách po celom svete.
Aj keď sa naše hlavné dátové centrum môže nachádzať v Ohiu, ak si niekto vyžiada obrázok z Japonska, poskytovateľ cloudu vytvorí kópiu a uloží ju do svojho japonského dátového centra. Ďalšia osoba, ktorá si tento obrázok vyžiada v Japonsku, ho dostane oveľa rýchlejšie. Je to dôležité, keď pracujeme s veľkými súbormi, ako sú fotografie alebo videá, ktorých sťahovanie a prenos po celej planéte trvá dlho.
100 000 používateľov: škálovanie dátovej vrstvy
CDN veľmi pomohla: návštevnosť rastie plnou rýchlosťou. Slávny video blogger Mavid Mobrick sa u nás práve zaregistroval a zverejnil svoj „príbeh“, ako sa hovorí. Vďaka nástroju na vyrovnávanie záťaže je využitie procesora a pamäte na serveroch API udržiavané na nízkej úrovni (XNUMX spustených inštancií API), ale pri požiadavkách sa nám začína veľa prekračovať časové limity... odkiaľ pochádzajú tieto oneskorenia?
Keď sa trochu pohrabeme v metrikách, vidíme, že CPU na databázovom serveri je zaťažený na 80-90%. Sme na hranici.
Škálovanie dátovej vrstvy je pravdepodobne najťažšia časť rovnice. Servery API obsluhujú bezstavové požiadavky, takže jednoducho pridávame ďalšie inštancie API. Nos väčšina databázy to nedokážu. Budeme hovoriť o populárnych systémoch správy relačných databáz (PostgreSQL, MySQL atď.).
ukladanie do vyrovnávacej pamäte
Jedným z najjednoduchších spôsobov, ako zvýšiť výkon našej databázy, je zavedenie nového komponentu: vyrovnávacej pamäte. Najbežnejšou metódou ukladania do vyrovnávacej pamäte je úložisko záznamov kľúč – hodnota v pamäti, ako napríklad Redis alebo Memcached. Väčšina cloudov má spravovanú verziu týchto služieb: Elasticache na AWS a Memorystore na Google Cloud.
Vyrovnávacia pamäť je užitočná, keď služba opakovane volá do databázy, aby získala rovnaké informácie. V podstate pristupujeme k databáze iba raz, ukladáme informácie do vyrovnávacej pamäte a už sa ich nedotýkame.
Napríklad v našej službe Graminsta vždy, keď niekto prejde na profilovú stránku hviezdy Mobrik, server API požiada databázu o informácie z jeho profilu. Toto sa opakuje znova a znova. Keďže informácie o profile Mobrika sa pri každej požiadavke nemenia, je vynikajúci na ukladanie do vyrovnávacej pamäte.
Výsledky z databázy v Redis uložíme podľa kľúča user:id s dobou platnosti 30 sekúnd. Teraz, keď niekto ide na profil Mobrika, najprv skontrolujeme Redis a ak tam údaje sú, jednoducho ich prenesieme priamo z Redisu. Teraz požiadavky na najobľúbenejší profil na stránke prakticky nenačítajú našu databázu.
Ďalšou výhodou väčšiny služieb ukladania do vyrovnávacej pamäte je, že sa dajú ľahšie škálovať ako databázové servery. Redis má vstavaný režim Redis Cluster. Podobne ako vyvažovač záťaže, umožňuje vám distribuovať vyrovnávaciu pamäť Redis na viacero počítačov (v prípade potreby na tisíce serverov).
Takmer všetky rozsiahle aplikácie využívajú vyrovnávaciu pamäť, ktorá je absolútne neoddeliteľnou súčasťou rýchleho API. Rýchlejšie spracovanie dotazov a produktívnejší kód sú dôležité, ale bez vyrovnávacej pamäte je takmer nemožné škálovať službu pre milióny používateľov.
Prečítajte si Repliky
Keď sa počet dotazov do databázy výrazne zvýšil, ešte jedna vec, ktorú môžeme urobiť, je pridať čítacie repliky do systému správy databázy. S vyššie popísanými riadenými službami to možno vykonať jedným kliknutím. Čítaná replika zostane aktuálna v hlavnej databáze a je dostupná pre príkazy SELECT.
Tu je náš systém teraz:
Ďalšie kroky
Keďže aplikácia pokračuje v škálovaní, budeme naďalej oddeľovať služby, aby sme ich škálovali nezávisle. Napríklad, ak začneme používať Websockets, potom má zmysel stiahnuť kód spracovania Websockets do samostatnej služby. Môžeme ho umiestniť na nové inštancie za náš vlastný load balancer, ktorý sa môže škálovať nahor a nadol na základe otvorených pripojení Websockets a bez ohľadu na počet HTTP požiadaviek.
Budeme tiež pokračovať v boji proti obmedzeniam na úrovni databázy. V tejto fáze je čas študovať rozdelenie a zdieľanie databáz. Oba prístupy si vyžadujú dodatočnú réžiu, ale umožňujú škálovať databázu takmer na neurčito.
Chceme tiež nainštalovať monitorovaciu a analytickú službu ako New Relic alebo Datadog. To vám pomôže identifikovať pomalé dotazy a pochopiť, kde je potrebné zlepšenie. Pri škálovaní sa chceme zamerať na nájdenie prekážok a ich odstránenie – často s využitím niektorých nápadov z predchádzajúcich častí.
zdroje
Tento príspevok je inšpirovaný jedným z . Chcel som článok trochu spresniť pre počiatočné fázy projektov a odviazať ho od jedného predajcu. Určite si prečítajte, ak vás táto téma zaujíma.
Poznámky pod čiarou
- Hoci je podobná z hľadiska distribúcie záťaže vo viacerých inštanciách, základná implementácia klastra Redis je veľmi odlišná od vyrovnávacej záťaže.
Zdroj: hab.com