Mnogi startupi su prošli kroz ovo: mnoštvo novih korisnika registrira se svaki dan, a razvojni tim se bori da nastavi rad usluge.
Lijepo je imati problem, ali na webu postoji malo jasnih informacija o tome kako pažljivo skalirati web aplikaciju od ničega do stotina tisuća korisnika. Obično postoje ili rješenja za požar ili rješenja za uska grla (a često oboje). Stoga ljudi koriste prilično klišeizirane tehnike kako bi svoj amaterski projekt prerasli u nešto stvarno ozbiljno.
Pokušajmo filtrirati informacije i zapisati osnovnu formulu. Proširit ćemo našu novu stranicu za dijeljenje fotografija Graminsta korak po korak od 1 do 100 korisnika.
Zapišimo koje konkretne radnje treba poduzeti kada se publika poveća na 10, 100, 1000, 10 000 i 100 000 ljudi.
1 korisnik: 1 stroj
Gotovo svaka aplikacija, bilo 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 puno lakše govoriti o skaliranju aplikacije ako su, s arhitektonskog gledišta, klijent i API entiteti potpuno odvojeni.
Kada prvi put počnemo graditi aplikaciju, sve tri komponente mogu se izvoditi na istom poslužitelju. Na neki način, ovo je slično našem razvojnom okruženju: jedan inženjer pokreće bazu podataka, API i klijenta na istom računalu.
U teoriji, mogli bismo ga implementirati u oblaku na jednoj instanci DigitalOcean Droplet ili AWS EC2, kao što je prikazano u nastavku:
Uz navedeno, ako će biti više od jednog korisnika na stranici, gotovo uvijek ima smisla posvetiti sloj baze podataka.
10 korisnika: premještanje baze podataka na zasebnu razinu
Dijeljenje baze podataka u upravljane usluge kao što su Amazon RDS ili Digital Ocean Managed Database dobro će nam služiti dugo vremena. To je malo skuplje od samostalnog hostinga na jednom stroju ili EC2 instanci, ali s ovim uslugama dobivate mnogo korisnih proširenja odmah iz kutije koja će vam dobro doći u budućnosti: sigurnosno kopiranje za više regija, čitanje replika, automatsko sigurnosne kopije i više.
Ovako sustav sada izgleda:
100 korisnika: premještanje klijenta na zasebnu razinu
Srećom, našim prvim korisnicima se jako svidjela naša aplikacija. Promet postaje stabilniji, pa je vrijeme da klijenta premjestimo na zasebnu razinu. Treba napomenuti da razdvajanje entiteta ključni je aspekt izgradnje skalabilne aplikacije. Kako jedan dio sustava prima više prometa, možemo ga podijeliti da kontroliramo kako se usluga skalira na temelju specifičnih obrazaca prometa.
Zbog toga volim razmišljati o klijentu odvojenom od API-ja. Zbog toga je vrlo lako razmišljati o razvoju za više platformi: web, mobilni web, iOS, Android, aplikacije za stolna računala, 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 puštanje mobilne aplikacije. Ako odvojite klijent i API entitete, ovo postaje lakše.
Ovako izgleda takav sustav:
1000 korisnika: dodajte balanser opterećenja
Stvari se popravljaju. Korisnici Graminsta postavljaju sve više fotografija. Raste i broj prijava. Naš jedini API poslužitelj teško može pratiti sav promet. Treba više željeza!
Balansiranje opterećenja vrlo je moćan koncept. Ključna ideja je da stavimo balanser opterećenja ispred API-ja i on distribuira promet pojedinačnim instancama usluge. Ovo je način na koji skaliramo vodoravno, što znači da dodajemo više poslužitelja s istim kodom, povećavajući broj zahtjeva koje možemo obraditi.
Postavit ćemo odvojene balansere opterećenja ispred web klijenta i ispred API-ja. To znači da možete pokrenuti više instanci s API kodom i kodom web klijenta. Uravnoteživač opterećenja usmjerit će zahtjeve na poslužitelj koji je manje opterećen.
Ovdje dobivamo još jednu važnu prednost – redundanciju. Kada jedna instanca zakaže (možda je preopterećena ili se srušila), ostaju nam druge koje nastavljaju odgovarati na dolazne zahtjeve. Kad bi radila samo jedna instanca, u slučaju kvara cijeli bi se sustav srušio.
Balancer opterećenja također omogućuje automatsko skaliranje. Možemo ga konfigurirati da poveća broj instanci prije najvećeg opterećenja i smanji ga kada svi korisnici spavaju.
S balanserom opterećenja, razina API-ja može se skalirati gotovo neograničeno, jednostavnim dodavanjem novih instanci kako se broj zahtjeva povećava.
Bilješka. Trenutačno je naš sustav vrlo sličan onome što PaaS tvrtke poput Herokua ili Elastic Beanstalk na AWS-u nude odmah (zbog čega su toliko popularni). Heroku stavlja bazu podataka na zasebno računalo, upravlja balanserom opterećenja s automatskim skaliranjem i omogućuje vam da hostirate web klijenta odvojeno od API-ja. Ovo je izvrstan razlog za korištenje Herokua za projekte u ranoj fazi ili startupe - dobivate sve osnovne usluge odmah.
10 000 korisnika: CDN
Možda smo to trebali učiniti od samog početka. Obrada zahtjeva i prihvaćanje novih fotografija počinje previše opterećivati naše poslužitelje.
U ovoj fazi potrebno je koristiti uslugu u oblaku za pohranjivanje statičnog sadržaja – slika, videa i još mnogo toga (AWS S3 ili Digital Ocean Spaces). Općenito, naš bi API trebao izbjegavati rukovanje stvarima poput posluživanja slika i učitavanja slika na poslužitelj.
Još jedna prednost hostinga u oblaku je CDN (AWS ovaj dodatak naziva Cloudfront, ali ga mnogi pružatelji usluga pohrane u oblaku nude odmah). CDN automatski sprema naše slike u različite podatkovne centre diljem svijeta.
Iako se naš glavni podatkovni centar može nalaziti u Ohiju, ako netko zatraži sliku iz Japana, pružatelj usluge oblaka napravit će kopiju i pohraniti je u svoj japanski podatkovni centar. Sljedeća osoba koja zatraži ovu sliku u Japanu dobit će je mnogo brže. Ovo je važno kada radimo s velikim datotekama, poput fotografija ili videozapisa, za čije preuzimanje i prijenos diljem planeta treba puno vremena.
100 000 korisnika: skaliranje podatkovnog sloja
CDN je puno pomogao: promet raste punom brzinom. Poznati video bloger Mavid Mobrick upravo se registrirao kod nas i objavio svoju “priču”, kako kažu. Zahvaljujući balanseru opterećenja, upotreba CPU-a i memorije na API poslužiteljima je niska (deset instanci API-ja je pokrenuto), ali počinjemo dobivati puno vremenskih ograničenja na zahtjeve... odakle dolaze ta kašnjenja?
Kopajući malo po metrici, vidimo da je CPU na poslužitelju baze podataka opterećen 80-90%. Na granici smo.
Skaliranje podatkovnog sloja vjerojatno je najteži dio jednadžbe. API poslužitelji poslužuju zahtjeve bez statusa, tako da jednostavno dodajemo više API instanci. Nos većina baze podataka to ne mogu učiniti. Govorit ćemo o popularnim sustavima za upravljanje relacijskim bazama podataka (PostgreSQL, MySQL itd.).
predmemoriranje
Jedan od najlakših načina za povećanje performansi naše baze podataka je uvođenje nove komponente: sloj predmemorije. Najčešća metoda predmemoriranja je pohrana zapisa ključa i vrijednosti u memoriji, kao što su Redis ili Memcached. Većina oblaka ima upravljanu verziju ovih usluga: Elasticache na AWS-u i Memorystore na Google Cloudu.
Predmemorija je korisna kada usluga mnogo puta poziva bazu podataka kako bi dohvatila iste informacije. U biti, bazi podataka pristupamo samo jednom, podatke spremamo u predmemoriju i više ih ne diramo.
Na primjer, u našoj usluzi Graminsta, svaki put kada netko ode na profilnu stranicu zvijezde Mobrik, API poslužitelj traži podatke iz njegovog profila u bazi podataka. Ovo se događa uvijek iznova. Budući da se podaci o Mobrikovom profilu ne mijenjaju sa svakim zahtjevom, odličan je za predmemoriju.
Predmemorirati ćemo rezultate iz baze podataka u Redisu po ključu user:id s rokom valjanosti od 30 sekundi. Sada kada netko ode na Mobrikov profil, prvo provjerimo Redis, pa ako su podaci tamo, jednostavno ih prenesemo direktno iz Redisa. Sada zahtjevi za najpopularniji profil na web mjestu praktički ne učitavaju našu bazu podataka.
Još jedna prednost većine usluga predmemoriranja je da ih je lakše skalirati od poslužitelja baze podataka. Redis ima ugrađen Redis Cluster mod. Slično balanseru opterećenja, omogućuje vam distribuciju vaše Redis predmemorije na više strojeva (po potrebi na tisuće poslužitelja).
Gotovo sve velike aplikacije koriste predmemoriju; to je apsolutno sastavni dio brzog API-ja. Brža obrada upita i produktivniji kod su važni, ali bez predmemorije gotovo je nemoguće proširiti uslugu na milijune korisnika.
Čitajte replike
Kada se broj upita prema bazi podataka jako poveća, još jedna stvar koju možemo učiniti je dodati čitanje replika u sustav za upravljanje bazom podataka. Uz gore opisane upravljane usluge, to se može učiniti jednim klikom. Replika za čitanje ostat će aktualna u glavnoj bazi podataka i dostupna je za naredbe SELECT.
Ovo je sada naš sustav:
Sljedeći koraci
Kako se aplikacija nastavlja skalirati, nastavit ćemo razdvajati usluge kako bismo ih neovisno skalirali. Na primjer, ako počnemo koristiti Websockets, tada ima smisla povući Websockets kôd za obradu u zasebnu uslugu. Možemo ga postaviti na nove instance iza vlastitog balansera opterećenja, koji se može povećavati i smanjivati na temelju otvorenih Websockets veza i bez obzira na broj HTTP zahtjeva.
Također ćemo se nastaviti boriti protiv ograničenja na razini baze podataka. Upravo je u ovoj fazi vrijeme za proučavanje particioniranja i dijeljenja baze podataka. Oba pristupa zahtijevaju dodatnu potrošnju, ali vam omogućuju gotovo beskonačno skaliranje baze podataka.
Također želimo instalirati uslugu praćenja i analitike poput New Relic ili Datadog. To će vam pomoći da prepoznate spore upite i shvatite gdje je potrebno poboljšanje. Kako se širimo, želimo se usredotočiti na pronalaženje uskih grla i njihovo uklanjanje—često koristeći neke od ideja iz prethodnih odjeljaka.
izvori
Ovaj post inspiriran je jednim od . Želio sam članak učiniti malo specifičnijim za početne faze projekata i odvojiti ga od jednog dobavljača. Svakako pročitajte ako vas zanima ova tema.
Fusnote
- Iako je slična u smislu raspodjele opterećenja na više instanci, temeljna implementacija Redis klastera uvelike se razlikuje od balansera opterećenja.
Izvor: www.habr.com