Moltes startups han passat per això: cada dia es registren multituds d'usuaris nous i l'equip de desenvolupament lluita per mantenir el servei en funcionament.
És un bon problema tenir, però hi ha poca informació clara al web sobre com escalar acuradament una aplicació web del no res a centenars de milers d'usuaris. Normalment hi ha solucions contra incendis o solucions de coll d'ampolla (i sovint ambdues). Per tant, la gent utilitza tècniques més aviat clixades per transformar el seu projecte amateur en alguna cosa realment seriós.
Intentem filtrar la informació i anotar la fórmula bàsica. Anem a escalar el nostre nou lloc per compartir fotos Graminsta pas a pas d'1 a 100 usuaris.
Anotem quines accions concretes s'han de fer quan l'audiència augmenta a 10, 100, 1000, 10 i 000 persones.
1 usuari: 1 màquina
Gairebé totes les aplicacions, ja sigui un lloc web o una aplicació mòbil, tenen tres components clau:
- API
- base de dades
- client (aplicació mòbil o lloc web)
La base de dades emmagatzema dades persistents. L'API serveix sol·licituds a aquestes dades i al seu voltant. El client transmet dades a l'usuari.
Vaig arribar a la conclusió que és molt més fàcil parlar d'escalar una aplicació si, des del punt de vista arquitectònic, les entitats client i API estan completament separades.
Quan comencem a crear una aplicació, els tres components es poden executar al mateix servidor. D'alguna manera, això és similar al nostre entorn de desenvolupament: un enginyer executa la base de dades, l'API i el client a la mateixa màquina.
En teoria, podríem desplegar-lo al núvol en una única instància DigitalOcean Droplet o AWS EC2, tal com es mostra a continuació:
Dit això, si hi haurà més d'un usuari en un lloc, gairebé sempre té sentit dedicar una capa de base de dades.
10 usuaris: movent la base de dades a un nivell separat
Dividir la base de dades en serveis gestionats com Amazon RDS o Digital Ocean Managed Database ens servirà molt durant molt de temps. És una mica més car que l'allotjament automàtic en una única màquina o instància EC2, però amb aquests serveis obtindreu moltes extensions útils de la caixa que us seran útils en el futur: còpia de seguretat multiregional, lectura de rèpliques, automàtica. còpies de seguretat i molt més.
Aquest és el que sembla ara el sistema:
100 usuaris: movent el client a un nivell separat
Afortunadament, als nostres primers usuaris els va agradar molt la nostra aplicació. El trànsit és cada cop més estable, així que és hora de traslladar el client a un nivell separat. Cal tenir en compte que separació entitats és un aspecte clau per construir una aplicació escalable. A mesura que una part del sistema rep més trànsit, podem particionar-lo per controlar com s'escala el servei en funció de patrons de trànsit específics.
És per això que m'agrada pensar en el client com a separat de l'API. Això fa que sigui molt fàcil pensar en desenvolupar per a múltiples plataformes: web, web mòbil, iOS, Android, aplicacions d'escriptori, serveis de tercers, etc. Tots són només clients que utilitzen la mateixa API.
Per exemple, ara els nostres usuaris solen sol·licitar llançar una aplicació mòbil. Si separeu les entitats client i API, això es farà més fàcil.
Aquest és el que sembla aquest sistema:
1000 usuaris: afegiu un equilibrador de càrrega
Les coses van millor. Els usuaris de Graminsta estan pujant cada cop més fotos. També creix el nombre d'inscripcions. El nostre servidor d'API solitari està tenint dificultats per mantenir-se al dia amb tot el trànsit. Necessites més ferro!
L'equilibri de càrrega és un concepte molt potent. La idea clau és que posem un equilibrador de càrrega davant de l'API i distribueix el trànsit a instàncies de servei individuals. Així és com escalem horitzontalment, és a dir, afegim més servidors amb el mateix codi, augmentant el nombre de peticions que podem processar.
Col·locarem equilibradors de càrrega separats davant del client web i davant de l'API. Això vol dir que podeu executar diverses instàncies amb codi API i codi de client web. L'equilibrador de càrrega dirigirà les sol·licituds al servidor que estigui menys carregat.
Aquí obtenim un altre avantatge important: la redundància. Quan una instància falla (potser sobrecarregada o fallada), ens quedem amb altres que continuen responent a les sol·licituds entrants. Si només hi hagués una instància funcionant, en cas de fallada, tot el sistema es bloquejaria.
L'equilibrador de càrrega també proporciona un escalat automàtic. El podem configurar per augmentar el nombre d'instàncies abans de la càrrega màxima i reduir-lo quan tots els usuaris estan dormint.
Amb un equilibrador de càrrega, el nivell d'API es pot escalar gairebé indefinidament, simplement afegint noves instàncies a mesura que augmenta el nombre de sol·licituds.
Nota. Ara mateix, el nostre sistema és molt semblant al que ofereixen empreses de PaaS com Heroku o Elastic Beanstalk a AWS (per això són tan populars). Heroku posa la base de dades en un amfitrió independent, gestiona un equilibrador de càrrega d'escala automàtica i us permet allotjar el client web per separat de l'API. Aquesta és una gran raó per utilitzar Heroku per a projectes en fase inicial o startups: obteniu tots els serveis bàsics de la caixa.
10 usuaris: CDN
Potser ho hauríem d'haver fet des del principi. El processament de sol·licituds i l'acceptació de fotos noves està començant a posar massa pressió als nostres servidors.
En aquesta etapa, heu d'utilitzar un servei al núvol per emmagatzemar contingut estàtic: imatges, vídeos i molt més (AWS S3 o Digital Ocean Spaces). En general, la nostra API hauria d'evitar gestionar coses com ara publicar imatges i penjar imatges al servidor.
Un altre avantatge de l'allotjament en núvol és el CDN (AWS anomena aquest complement Cloudfront, però molts proveïdors d'emmagatzematge en núvol l'ofereixen de manera immediata). El CDN guarda automàticament les nostres imatges a la memòria cau en diversos centres de dades d'arreu del món.
Tot i que el nostre centre de dades principal es troba a Ohio, si algú sol·licita una imatge del Japó, el proveïdor de núvol en farà una còpia i l'emmagatzemarà al seu centre de dades japonès. La propera persona que sol·liciti aquesta imatge al Japó la rebrà molt més ràpid. Això és important quan treballem amb fitxers grans, com ara fotos o vídeos, que triguen molt de temps a descarregar-se i transmetre'ls a tot el planeta.
100 usuaris: escalar la capa de dades
CDN ha ajudat molt: el trànsit creix a tota velocitat. El famós videobloguer Mavid Mobrick s'acaba de registrar amb nosaltres i va publicar la seva "història", com diuen. Gràcies a l'equilibrador de càrrega, l'ús de la CPU i la memòria als servidors d'API es manté baix (deu instàncies d'API en funcionament), però estem començant a tenir molts temps d'espera a les sol·licituds... d'on provenen aquests retards?
Aprofundint una mica en les mètriques, veiem que la CPU del servidor de bases de dades està carregada entre un 80 i un 90%. Estem al límit.
Escalar la capa de dades és probablement la part més difícil de l'equació. Els servidors d'API serveixen sol·licituds sense estat, de manera que simplement afegim més instàncies d'API. Nas per la majoria les bases de dades no poden fer-ho. Parlarem dels sistemes de gestió de bases de dades relacionals populars (PostgreSQL, MySQL, etc.).
memòria cau
Una de les maneres més senzilles d'augmentar el rendiment de la nostra base de dades és introduir un nou component: la capa de memòria cau. El mètode d'emmagatzematge a la memòria cau més comú és un magatzem de registres de valor-clau a la memòria, com ara Redis o Memcached. La majoria dels núvols tenen una versió gestionada d'aquests serveis: Elasticache a AWS i Memorystore a Google Cloud.
Una memòria cau és útil quan un servei fa moltes trucades repetides a la base de dades per recuperar la mateixa informació. Bàsicament, accedim a la base de dades només una vegada, emmagatzemem la informació a la memòria cau i no la tornem a tocar.
Per exemple, al nostre servei Graminsta, cada vegada que algú va a la pàgina de perfil de l'estrella Mobrik, el servidor de l'API consulta la base de dades per obtenir informació del seu perfil. Això passa una i altra vegada. Com que la informació del perfil de Mobrik no canvia amb cada sol·licitud, és excel·lent per a la memòria cau.
Emmagatzemarem a la memòria cau els resultats de la base de dades a Redis per clau user:id amb un període de validesa de 30 segons. Ara, quan algú va al perfil de Mobrik, primer comprovem Redis, i si les dades hi són, simplement les transferim directament des de Redis. Ara les sol·licituds al perfil més popular del lloc pràcticament no carreguen la nostra base de dades.
Un altre avantatge de la majoria dels serveis de memòria cau és que són més fàcils d'escalar que els servidors de bases de dades. Redis té un mode de clúster de Redis integrat. Similar a un equilibrador de càrrega, us permet distribuir la vostra memòria cau de Redis entre diverses màquines (a través de milers de servidors si cal).
Gairebé totes les aplicacions a gran escala utilitzen la memòria cau; és una part absolutament integral d'una API ràpida. Un processament de consultes més ràpid i un codi més productiu són importants, però sense una memòria cau és gairebé impossible escalar un servei a milions d'usuaris.
Llegeix les rèpliques
Quan el nombre de consultes a la base de dades ha augmentat molt, una cosa més que podem fer és afegir rèpliques de lectura al sistema de gestió de bases de dades. Amb els serveis gestionats descrits anteriorment, això es pot fer amb un sol clic. La rèplica de lectura es mantindrà actual a la base de dades principal i està disponible per a sentències SELECT.
Aquest és el nostre sistema ara:
Passos següents
A mesura que l'aplicació segueixi escalant, continuarem separant els serveis per escalar-los de manera independent. Per exemple, si comencem a utilitzar Websockets, llavors té sentit treure el codi de processament de Websockets en un servei independent. Podem col·locar-lo en instàncies noves darrere del nostre propi equilibrador de càrrega, que pot augmentar i baixar en funció de les connexions obertes de Websockets i independentment del nombre de sol·licituds HTTP.
També continuarem lluitant contra les restriccions a nivell de base de dades. És en aquesta etapa que és el moment d'estudiar la partició i la fragmentació de bases de dades. Tots dos enfocaments requereixen una sobrecàrrega addicional, però us permeten escalar la base de dades gairebé indefinidament.
També volem instal·lar un servei de monitorització i anàlisi com New Relic o Datadog. Això us ajudarà a identificar les consultes lentes i a entendre on cal millorar. A mesura que anem escalant, volem centrar-nos a trobar colls d'ampolla i eliminar-los, sovint utilitzant algunes de les idees de les seccions anteriors.
Fonts
Aquesta publicació està inspirada en un dels . Volia fer l'article una mica més específic per a les etapes inicials dels projectes i deslligar-lo d'un proveïdor. Assegureu-vos de llegir si esteu interessats en aquest tema.
Notes a peu de pàgina
- Tot i que és similar pel que fa a la distribució de càrrega en múltiples instàncies, la implementació subjacent d'un clúster Redis és molt diferent d'un equilibrador de càrrega.
Font: www.habr.com