Moitas startups pasaron por isto: multitude de novos usuarios rexístrase todos os días e o equipo de desenvolvemento loita por manter o servizo funcionando.
É un bo problema, pero hai pouca información clara na web sobre como escalar coidadosamente unha aplicación web de nada a centos de miles de usuarios. Normalmente hai solucións contra incendios ou solucións de pescozo de botella (e moitas veces ambas). Polo tanto, a xente usa técnicas bastante clichés para escalar o seu proxecto afeccionado a algo realmente serio.
Intentemos filtrar a información e anotar a fórmula básica. Imos escalar o noso novo sitio para compartir fotos Graminsta paso a paso de 1 a 100 usuarios.
Anotemos que accións concretas hai que levar a cabo cando a audiencia aumente a 10, 100, 1000, 10 e 000 persoas.
1 usuario: 1 máquina
Case todas as aplicacións, xa sexa un sitio web ou unha aplicación móbil, teñen tres compoñentes fundamentais:
- API
- base de datos
- cliente (aplicación móbil ou sitio web)
A base de datos almacena datos persistentes. A API atende solicitudes a estes datos e ao seu redor. O cliente transmite datos ao usuario.
Cheguei á conclusión de que é moito máis doado falar de escalar unha aplicación se, dende o punto de vista arquitectónico, as entidades cliente e API están completamente separadas.
Cando comezamos a construír unha aplicación, os tres compoñentes pódense executar no mesmo servidor. Nalgúns aspectos, isto é semellante ao noso entorno de desenvolvemento: un enxeñeiro executa a base de datos, a API e o cliente na mesma máquina.
En teoría, poderiamos implantalo na nube nunha única instancia de DigitalOcean Droplet ou AWS EC2, como se mostra a continuación:
Dito isto, se haberá máis dun usuario nun sitio, case sempre ten sentido dedicar unha capa de base de datos.
10 usuarios: movendo a base de datos a un nivel separado
Dividir a base de datos en servizos xestionados como Amazon RDS ou Digital Ocean Managed Database serviranos durante moito tempo. É un pouco máis caro que o autoaloxamento nunha única máquina ou unha instancia EC2, pero con estes servizos obtén moitas extensións útiles que serán útiles no futuro: copia de seguranza de varias rexións, lectura de réplicas, automática. copias de seguridade e moito máis.
Este é o aspecto do sistema agora:
100 usuarios: movendo o cliente a un nivel separado
Afortunadamente, aos nosos primeiros usuarios gustoulles moito a nosa aplicación. O tráfico é cada vez máis estable, polo que é hora de mover o cliente a un nivel separado. Cómpre sinalar que separación entidades é un aspecto clave para construír unha aplicación escalable. Como unha parte do sistema recibe máis tráfico, podemos particionalo para controlar como se escala o servizo en función de patróns de tráfico específicos.
É por iso que me gusta pensar no cliente como separado da API. Isto fai que sexa moi doado pensar en desenvolver para múltiples plataformas: web, web móbil, iOS, Android, aplicacións de escritorio, servizos de terceiros, etc. Todos son só clientes que usan a mesma API.
Por exemplo, agora os nosos usuarios solicitan a maioría das veces lanzar unha aplicación móbil. Se separas as entidades cliente e API, isto faise máis fácil.
Este é o aspecto deste sistema:
1000 usuarios: engade equilibrador de carga
As cousas están mirando cara arriba. Os usuarios de Graminsta cargan cada vez máis fotos. Tamén medra o número de inscricións. O noso servidor API único está a ter dificultades para manterse ao día con todo o tráfico. Necesita máis ferro!
O equilibrador de carga é un concepto moi poderoso. A idea clave é que poñamos un equilibrador de carga diante da API e que distribúa o tráfico a instancias individuais do servizo. Así é como escalamos horizontalmente, é dicir, engadimos máis servidores co mesmo código, aumentando o número de solicitudes que podemos procesar.
Imos colocar equilibradores de carga separados diante do cliente web e diante da API. Isto significa que pode executar varias instancias executando código API e código de cliente web. O equilibrador de carga dirixirá as solicitudes ao servidor que estea menos cargado.
Aquí temos outra vantaxe importante: a redundancia. Cando falla unha instancia (quizais sobrecargada ou falla), quedamos con outras que seguen respondendo ás solicitudes entrantes. Se só funcionase unha instancia, en caso de falla, todo o sistema fallaría.
O equilibrador de carga tamén proporciona escalado automático. Podemos configuralo para aumentar o número de instancias antes do pico de carga e reducilo cando todos os usuarios están durmindo.
Cun equilibrador de carga, o nivel da API pódese escalar case indefinidamente, simplemente engadindo novas instancias a medida que aumenta o número de solicitudes.
Nota. Agora mesmo, o noso sistema é moi similar ao que ofrecen empresas de PaaS como Heroku ou Elastic Beanstalk en AWS (por iso son tan populares). Heroku coloca a base de datos nun host separado, xestiona un equilibrador de carga de escala automática e permíteche aloxar o cliente web por separado da API. Este é un gran motivo para usar Heroku para proxectos iniciais ou startups: obtén todos os servizos básicos da caixa.
10 usuarios: CDN
Quizais deberíamos ter feito isto dende o principio. O procesamento de solicitudes e a aceptación de novas fotos está empezando a esforzar demasiado os nosos servidores.
Nesta fase, cómpre utilizar un servizo na nube para almacenar contido estático: imaxes, vídeos e moito máis (AWS S3 ou Digital Ocean Spaces). En xeral, a nosa API debería evitar manexar cousas como servir imaxes e cargar imaxes ao servidor.
Outra vantaxe do hospedaxe na nube é o CDN (AWS chama a este complemento Cloudfront, pero moitos provedores de almacenamento na nube ofréceno listo para usar). O CDN almacena automaticamente en caché as nosas imaxes en varios centros de datos de todo o mundo.
Aínda que o noso centro de datos principal pode estar situado en Ohio, se alguén solicita unha imaxe de Xapón, o provedor da nube fará unha copia e almacenará no seu centro de datos xaponés. A seguinte persoa que solicite esta imaxe en Xapón recibiraa moito máis rápido. Isto é importante cando traballamos con ficheiros grandes, como fotos ou vídeos, que tardan moito tempo en descargarse e transmitirse por todo o planeta.
100 usuarios: escalando a capa de datos
A CDN axudou moito: o tráfico crece a toda velocidade. A famosa videoblogger Mavid Mobrick acaba de rexistrarse connosco e publicar a súa "historia", como din. Grazas ao equilibrador de carga, o uso da CPU e da memoria nos servidores de API mantense baixo (dez instancias de API en execución), pero estamos comezando a ter moitos tempos de espera nas solicitudes... de onde veñen estes atrasos?
Afondando un pouco nas métricas, vemos que a CPU do servidor de base de datos está cargada nun 80-90%. Estamos no límite.
A escala da capa de datos é probablemente a parte máis difícil da ecuación. Os servidores de API atenden solicitudes sen estado, polo que simplemente engadimos máis instancias de API. Nariz a maioría as bases de datos non poden facelo. Falaremos dos populares sistemas de xestión de bases de datos relacionais (PostgreSQL, MySQL, etc.).
caché
Unha das formas máis sinxelas de aumentar o rendemento da nosa base de datos é introducir un novo compoñente: a capa de caché. O método de almacenamento en caché máis común é un almacén de rexistros de valores clave na memoria, como Redis ou Memcached. A maioría das nubes teñen unha versión xestionada destes servizos: Elasticache en AWS e Memorystore en Google Cloud.
Unha caché é útil cando un servizo fai moitas chamadas repetidas á base de datos para recuperar a mesma información. Esencialmente, accedemos á base de datos só unha vez, almacenamos a información na caché e non a tocamos de novo.
Por exemplo, no noso servizo Graminsta, cada vez que alguén vai á páxina de perfil da estrela Mobrik, o servidor da API consulta a base de datos para obter información do seu perfil. Isto ocorre unha e outra vez. Dado que a información do perfil de Mobrik non cambia con cada solicitude, é excelente para almacenar na caché.
Cachearemos os resultados da base de datos en Redis por clave user:id cun período de validez de 30 segundos. Agora, cando alguén vai ao perfil de Mobrik, primeiro comprobamos Redis e, se os datos están alí, simplemente transferímolos directamente desde Redis. Agora as solicitudes ao perfil máis popular do sitio practicamente non cargan a nosa base de datos.
Outra vantaxe da maioría dos servizos de caché é que son máis fáciles de escalar que os servidores de bases de datos. Redis ten un modo Redis Cluster incorporado. Similar a un equilibrador de carga, permítelle distribuír a súa caché Redis en varias máquinas (en miles de servidores se é necesario).
Case todas as aplicacións a gran escala usan caché; é unha parte absolutamente integral dunha API rápida. Son importantes un procesamento de consultas máis rápido e un código máis produtivo, pero sen caché é case imposible escalar un servizo a millóns de usuarios.
Ler réplicas
Cando o número de consultas á base de datos aumentou moito, unha cousa máis que podemos facer é engadir réplicas de lectura no sistema de xestión de bases de datos. Cos servizos xestionados descritos anteriormente, isto pódese facer cun só clic. A réplica de lectura permanecerá actual na base de datos principal e estará dispoñible para as instrucións SELECT.
Aquí está o noso sistema agora:
Pasos seguintes
A medida que a aplicación siga escalando, seguiremos separando os servizos para escalalos de forma independente. Por exemplo, se comezamos a usar Websockets, ten sentido incorporar o código de procesamento de Websockets a un servizo separado. Podemos colocalo en novas instancias detrás do noso propio equilibrador de carga, que pode escalar cara arriba e abaixo en función das conexións abertas de Websockets e independentemente do número de solicitudes HTTP.
Tamén seguiremos loitando contra as restricións a nivel de base de datos. É nesta fase cando é hora de estudar a partición e a fragmentación de bases de datos. Ambos enfoques requiren sobrecarga adicional, pero permítenche escalar a base de datos case indefinidamente.
Tamén queremos instalar un servizo de monitorización e análise como New Relic ou Datadog. Isto axudarache a identificar consultas lentas e comprender onde é necesario mellorar. A medida que escalamos, queremos centrarnos en atopar pescozos de botella e eliminalos, a miúdo utilizando algunhas das ideas das seccións anteriores.
Fontes
Esta publicación está inspirada nun de . Quería facer o artigo un pouco máis específico para as fases iniciais dos proxectos e desatalo dun provedor. Non deixes de ler se estás interesado neste tema.
Notas ao pé de páxina
- Aínda que é similar en termos de distribución de carga en varias instancias, a implementación subxacente dun clúster de Redis é moi diferente dun equilibrador de carga.
Fonte: www.habr.com