Mnogi startupi su prošli kroz ovo: gomile novih korisnika se registruju svakog dana, a razvojni tim se bori da održi servis.

Lijep je problem imati, ali na webu je malo jasnih informacija o tome kako pažljivo skalirati web aplikaciju od ničega do stotina hiljada korisnika. Obično postoje ili rješenja za požar ili rješenja za usko grlo (a često i jedno i drugo). Stoga ljudi koriste prilično klišeirane tehnike kako bi svoj amaterski projekat pretvorili u nešto zaista ozbiljno.

Pokušajmo filtrirati informacije i zapisati osnovnu formulu. Mi ćemo proširiti našu novu stranicu za dijeljenje fotografija Graminsta korak po korak od 1 do 100 korisnika.

Hajde da zapišemo koje konkretne radnje treba preduzeti kada se publika poveća na 10, 100, 1000, 10 i 000 ljudi.

1 korisnik: 1 mašina

Gotovo svaka aplikacija, bilo da je web stranica ili mobilna aplikacija, ima tri ključne komponente:

• API
• baza podataka
• klijent (sama mobilna aplikacija ili web stranica)

Baza podataka pohranjuje trajne podatke. API služi zahtjeve za i oko ovih podataka. Klijent prenosi podatke korisniku.

Došao sam do zaključka da je mnogo lakše govoriti o skaliranju aplikacije ako su, sa arhitektonske tačke gledišta, klijent i API entiteti potpuno odvojeni.

Kada prvi put počnemo da gradimo aplikaciju, sve tri komponente se mogu pokrenuti na istom serveru. Na neki način, ovo je slično našem razvojnom okruženju: jedan inženjer pokreće bazu podataka, API i klijenta na istoj mašini.

U teoriji, mogli bismo ga implementirati u oblaku na jednoj DigitalOcean Droplet ili AWS EC2 instanci, kao što je prikazano u nastavku:

S obzirom na to, ako će na web lokaciji biti više korisnika, gotovo uvijek ima smisla posvetiti sloj baze podataka.

10 korisnika: premještanje baze podataka na poseban nivo

Podjela baze podataka na upravljane usluge kao što su Amazon RDS ili Digital Ocean Managed Database će nam dugo služiti. To je malo skuplje od samostalnog hostinga na jednoj mašini ili EC2 instanci, ali uz ove usluge dobijate puno korisnih ekstenzija iz kutije koje će vam dobro doći u budućnosti: sigurnosna kopija u više regija, replike čitanja, automatska sigurnosne kopije i još mnogo toga.

Ovako sistem sada izgleda:

100 korisnika: premještanje klijenta na poseban nivo

Srećom, našim prvim korisnicima se naša aplikacija jako svidjela. Saobraćaj postaje sve stabilniji, pa je vrijeme da se klijent prebaci na poseban nivo. Treba napomenuti da razdvajanje entiteti je ključni aspekt izgradnje skalabilne aplikacije. Kako jedan dio sistema prima više prometa, možemo ga particionirati kako bismo kontrolirali kako se usluga skalira na osnovu specifičnih obrazaca prometa.

Zbog toga volim da mislim o klijentu odvojenom od API-ja. Ovo olakšava razmišljanje o razvoju za više platformi: web, mobilni web, iOS, Android, desktop aplikacije, usluge trećih strana, itd. Svi su oni samo klijenti koji koriste isti API.

Na primjer, sada naši korisnici najčešće traže izdavanje mobilne aplikacije. Ako odvojite klijenta i API entitete, ovo postaje lakše.

Ovako izgleda takav sistem:

1000 korisnika: dodajte balansator opterećenja

Stvari idu gore. Korisnici Graminsta postavljaju sve više fotografija. Raste i broj registracija. Naš usamljeni API server ima problema sa svim prometom. Treba mi još gvožđa!

Balansator opterećenja je veoma moćan koncept. Ključna ideja je da stavimo balanser opterećenja ispred API-ja i on distribuira promet na pojedinačne instance usluge. Ovako skaliramo horizontalno, što znači da dodajemo više servera sa istim kodom, povećavajući broj zahtjeva koje možemo obraditi.

Postavićemo odvojene balansere opterećenja ispred web klijenta i ispred API-ja. To znači da možete pokrenuti više instanci sa API kodom i kodom web klijenta. Balansator opterećenja će usmjeriti zahtjeve na server koji je manje opterećen.

Ovdje dobijamo još jednu važnu prednost - redundantnost. Kada jedna instanca ne uspije (možda je preopterećena ili se srušila), ostaju nam druge koje nastavljaju da odgovaraju na dolazne zahtjeve. Ako bi radila samo jedna instanca, onda bi se u slučaju kvara cijeli sistem srušio.

Balansator opterećenja takođe omogućava automatsko skaliranje. Možemo ga konfigurirati da poveća broj instanci prije vršnog opterećenja i smanji ga kada svi korisnici spavaju.

Sa balansatorom opterećenja, nivo API-ja se može skalirati gotovo neograničeno, jednostavnim dodavanjem novih instanci kako se broj zahtjeva povećava.

Bilješka. Trenutno je naš sistem vrlo sličan onome što PaaS kompanije kao što su Heroku ili Elastic Beanstalk na AWS nude iz kutije (zbog čega su tako popularne). Heroku stavlja bazu podataka na poseban host, upravlja balansom opterećenja sa automatskim skaliranjem i omogućava vam da hostujete web klijent odvojeno od API-ja. Ovo je sjajan razlog da koristite Heroku za projekte u ranoj fazi ili startupe - dobijate sve osnovne usluge iz kutije.

10 korisnika: CDN

Možda smo to trebali učiniti od samog početka. Obrada zahtjeva i prihvatanje novih fotografija počinje previše opterećivati ​​naše servere.

U ovoj fazi trebate koristiti uslugu u oblaku za pohranjivanje statičnog sadržaja – slika, video zapisa i još mnogo toga (AWS S3 ili Digital Ocean Spaces). Općenito, naš API bi trebao izbjegavati rukovanje stvarima poput posluživanja slika i učitavanja slika na server.

Još jedna prednost cloud hostinga je CDN (AWS ovaj dodatak naziva Cloudfront, ali mnogi provajderi za pohranu u oblaku ga nude odmah). CDN automatski kešira naše slike u različitim centrima podataka širom svijeta.

Iako se naš glavni data centar može nalaziti u Ohiju, ako neko zatraži sliku iz Japana, provajder u oblaku će napraviti kopiju i pohraniti je u svoj japanski data centar. Sljedeća osoba koja zatraži ovu sliku u Japanu će je dobiti mnogo brže. Ovo je važno kada radimo sa velikim datotekama, kao što su fotografije ili video zapisi, za koje je potrebno mnogo vremena za preuzimanje i prenos širom planete.

100 korisnika: skaliranje sloja podataka

CDN je puno pomogao: promet raste punom brzinom. Čuveni video bloger Mavid Mobrick upravo se registrovao kod nas i objavio svoju "priču", kako kažu. Zahvaljujući balanseru opterećenja, upotreba CPU-a i memorije na API serverima je niska (pokrenuto je deset API instanci), ali počinjemo da dobijamo mnogo vremena čekanja na zahtjeve... odakle ta kašnjenja dolaze?

Kopajući malo u metriku, vidimo da je CPU na serveru baze podataka opterećen 80-90%. Na granici smo.

Skaliranje sloja podataka je vjerovatno najteži dio jednačine. API serveri služe zahtjevima bez stanja, tako da jednostavno dodajemo više API instanci. Nos većina baze podataka to ne mogu učiniti. Govorićemo o popularnim sistemima za upravljanje relacionim bazama podataka (PostgreSQL, MySQL, itd.).

keširanje

Jedan od najlakših načina za povećanje performansi naše baze podataka je uvođenje nove komponente: sloj keša. Najčešći metod keširanja je skladište zapisa ključ/vrijednost u memoriji, kao što su Redis ili Memcached. Većina oblaka ima upravljanu verziju ovih usluga: Elasticache na AWS-u i Memorystore na Google Cloud-u.

Keš memorija je korisna kada usluga obavlja mnogo ponovljenih poziva bazi podataka kako bi dohvatila iste informacije. U suštini, bazi podataka pristupamo samo jednom, pohranjujemo informacije u keš memoriju i više je ne dodirujemo.

Na primjer, u našem Graminsta servisu, svaki put kada neko ode na stranicu profila zvijezde Mobrik, API server pita bazu podataka za informacije sa njegovog profila. Ovo se dešava iznova i iznova. Budući da se podaci o Mobrikovom profilu ne mijenjaju sa svakim zahtjevom, odličan je za keširanje.

Rezultate iz baze podataka u Redisu ćemo keširati po ključu user:id sa rokom važenja od 30 sekundi. Sada, kada neko ode na Mobrikov profil, prvo provjeravamo Redis, a ako su podaci tamo, jednostavno ih prenosimo direktno iz Redisa. Sada zahtjevi za najpopularniji profil na stranici praktički ne učitavaju našu bazu podataka.

Još jedna prednost većine usluga keširanja je da ih je lakše skalirati od poslužitelja baze podataka. Redis ima ugrađen Redis Cluster mod. Slično balanseru opterećenja1, omogućava vam da distribuirate Redis keš na više mašina (na hiljade servera ako je potrebno).

Gotovo sve aplikacije velikih razmjera koriste keširanje; ono je apsolutno sastavni dio brzog API-ja. Brža obrada upita i produktivniji kod su važni, ali bez keš memorije gotovo je nemoguće proširiti uslugu na milione korisnika.

Pročitajte replike

Kada se broj upita bazi podataka znatno poveća, još jedna stvar koju možemo učiniti je da dodamo replike čitanja u sistem upravljanja bazom podataka. Uz gore opisane upravljane usluge, to se može učiniti jednim klikom. Replika za čitanje će ostati aktuelna u glavnoj bazi podataka i dostupna je za SELECT izraze.

Evo našeg sistema sada:

Sledeći koraci

Kako se aplikacija nastavlja skalirati, nastavit ćemo odvajati usluge kako bismo ih skalirali nezavisno. Na primjer, ako počnemo koristiti Websockets, onda ima smisla povući kod za obradu Websockets-a u zasebnu uslugu. Možemo ga postaviti na nove instance iza našeg vlastitog balansera opterećenja, koji se može povećavati i smanjivati ​​na osnovu otvorenih Websockets veza i bez obzira na broj HTTP zahtjeva.

Također ćemo nastaviti da se borimo protiv ograničenja na nivou baze podataka. U ovoj fazi je vrijeme za proučavanje particioniranja i dijeljenja baze podataka. Oba pristupa zahtijevaju dodatne troškove, ali vam omogućavaju skaliranje baze podataka gotovo neograničeno.

Takođe želimo da instaliramo servis za praćenje i analizu poput New Relic ili Datadog. Ovo će vam pomoći da prepoznate spore upite i shvatite gdje je potrebno poboljšanje. Kako skaliramo, želimo se fokusirati na pronalaženje uskih grla i njihovo eliminisanje – često koristeći neke od ideja iz prethodnih odjeljaka.

Izvori

Ovaj post je inspirisan jednim od moji omiljeni postovi o visokoj skalabilnosti. Želio sam da članak učinim malo konkretnijim za početne faze projekata i odvojim ga od jednog dobavljača. Svakako pročitajte ako vas zanima ova tema.

Fusnote

1. Iako slična u smislu distribucije opterećenja na više instanci, osnovna implementacija Redis klastera se veoma razlikuje od balansera opterećenja. [povratak]

izvor: www.habr.com