¿Qué tuvo que hacer para mejorar la escalabilidad de una aplicación web que realmente ayudó mucho?

Hay muchas formas de escalar una aplicación web, pero debe tenerse en cuenta que la escalabilidad no se trata solo de cómo lo hace, sino también de la razón por la que lo hace y la necesidad comercial. Porque la razón probablemente conducirá a cualquier cantidad de posibles soluciones.

Por lo tanto, he experimentado varias necesidades comerciales para hacer que un sitio web sea escalable, y generalmente se reducen a crear una experiencia de usuario elegante, independientemente de las demandas impuestas a la aplicación web y la infraestructura subyacente, bajo diferentes cargas y tipos de uso. Por lo tanto, el rendimiento no necesariamente equivale a escalabilidad.

Caracterizo la escalabilidad a lo largo de una de dos dimensiones, escalabilidad vertical u horizontal.

La escalabilidad vertical generalmente tiene que ver con la capacidad de su sitio web para responder a la carga cambiante, ya sea una explosión de usuarios, o un aumento gradual de los usuarios con el tiempo, o la carga debido al alto costo de transacción, cálculos complejos. Por lo general, se resuelve con más potencia computacional, servidores más grandes y más rápidos.

La escalabilidad horizontal es la capacidad de distribuir la carga con múltiples servidores que cooperan tomando una parte de las conexiones generales, o distribuyendo la carga de trabajo computacional, o segregando la aplicación en diferentes servidores, de modo que un servidor pueda manejar gráficos, los otros inicios de sesión, el otras transacciones de comercio electrónico, etc.

La escalabilidad horizontal es más compleja, porque tiene el problema de la afinidad de la sesión del usuario, lo que significa que la sesión de un usuario generalmente se establece con una sola entidad, y si divide las capacidades operativas de manejar la solicitud del usuario en múltiples sistemas, cada uno necesita saber algo sobre el estado del usuario, su sesión. Por lo tanto, distribuir esta sesión y realizar un seguimiento de la misma, especialmente si aumenta la carga total de usuarios, es algo complejo de administrar y requiere mucho cuidado, especialmente si las transacciones que está tratando de coordinar tienen un valor comercial innato (son de misión crítica).

Almacenamiento en caché! generalmente tenemos las siguientes capas de almacenamiento en caché:

1. Caché a nivel de aplicación
2. Almacenamiento en caché de archivos estáticos (funciona bien para tráfico anónimo)
3. Caché de la base de datos (ej: caché de consultas mysql)
4. Caché de memoria (Redis, Memcache): se puede utilizar para sesiones, consultas, almacenamiento en caché de página completa, etc.)
5. Almacenamiento en caché del servidor de aplicaciones: (por ejemplo, si usa PHP, APC y Eaccelerator)
6. Caché de nivel HTTP: (ej: barniz)
7. Caché de nivel de red: (ej .: CDN)

Algunos otros consejos:
Usar servidores basados ​​en eventos para servir datos estáticos como nginx, habilitar la compresión, etc.

Aquí hay un ejemplo, el crédito va para mi colega Nikolay, quien recientemente escribió un artículo sobre este tema.

Los drones se han hecho conocidos por sus capacidades de imágenes aéreas. Su fotografía ofrece información significativa basada en datos para industrias donde existe una demanda creciente de automatización y adopción de tecnología.

La agricultura está madura para beneficiarse de las imágenes de drones. Usando un dron UAV para volar sobre los campos, se pueden capturar fotografías detalladas de los cultivos y luego unirlas para formar una sola imagen de mapa muy similar a Google o Bing Maps.

Si bien son increíblemente útiles, las fotos, de muchos gigabytes de tamaño, pueden tardar entre 6 y 8 horas en renderizarse en una estación de trabajo moderna. Los proveedores que proporcionan estos servicios de procesamiento de imágenes necesitan un sistema capaz de manejar múltiples tareas de procesamiento a la vez.

En los casos en que los usuarios cargan imágenes para generar un mapa aéreo e informes, una sola tarea de procesamiento puede monopolizar todos los recursos en el servidor. La cola de mensajes de Azure puede ayudar a descargar el servidor de aplicaciones principal al enviar el procesamiento a servidores dedicados.

El uso de máquinas virtuales de Azure y colas de mensajes de Azure para descargar tareas de procesamiento intensivo de sus servidores de aplicaciones principales a servidores de procesamiento dedicados puede ayudar a las empresas a escalar horizontal y verticalmente al ahorrar tiempo que de lo contrario se gastaría en descargar imágenes a los nodos.

La solución propuesta, creada utilizando los servicios de Azure, utilizará la cola de mensajes de Azure para programar tareas pendientes junto con el almacenamiento de tablas para el registro centralizado y las máquinas virtuales para completar el procesamiento.

Las imágenes de los usuarios se cargarán en un Almacenamiento de archivos de Azure y se montarán en Máquinas virtuales de Azure para su procesamiento. Esto ahorra tiempo de descarga al proporcionar al servidor de procesamiento acceso a todos los archivos del usuario en el sistema sin tener que descargar muchos gigabytes.

¿Cómo afecta esta implementación automatizada a la escalabilidad vertical?

En esta implementación, la máquina virtual que completa el procesamiento está alojada en Azure, lo que significa que podemos aumentar fácilmente su potencia en cuestión de segundos reduciendo el tiempo para una tarea de procesamiento. En el caso de las imágenes de drones, aumentar la RAM y la CPU puede reducir el tiempo de 6 horas a 4 horas. Agregar GPU puede reducir el tiempo a 2 horas.

¿Qué pasa con la escalabilidad horizontal?

Los servidores de procesamiento múltiple toman tareas de procesamiento de las colas. Comience con un servidor y agregue servidores adicionales si es necesario. El diseño del sistema permite agregar y eliminar nodos de procesamiento sin tiempo de inactividad ni tener que reconfigurar otras partes del sistema. Los desarrolladores simplemente deben apuntar el nuevo nodo a las colas de mensajes.

Si está interesado en aprovechar Azure de manera similar en sus propios proyectos, aquí hay un buen tutorial. ¡Espero que ayude!

Una vez tuve la tarea de construir un sitio web multimedia para ESPN. Se esperaba que este sitio tuviera grandes picos en el tráfico, especialmente después de los comerciales de televisión. El sitio requería un back-end para la gestión de contenido y se actualizaría periódicamente. Decidí alojar el sistema en un servidor privado, luego empujar estáticamente todo el sitio a su CDN con solo un botón “Publicar” en el backend administrativo. Entonces, el público solo llegó a la CDN. He escrito más detalles en DocForge: Estudio de caso / sitio web de alto tráfico multimedia.

También utilizo varias técnicas de almacenamiento en caché en cada sitio, p. Ej.

• Encabezados HTTP
• Servidores proxy de almacenamiento en caché
• Páginas completas o parciales en disco dentro de aplicaciones web
• Memoria compartida entre instancias de aplicaciones y servidores
• Caché de consultas de bases de datos

Más en la aplicación web / almacenamiento en caché.

Vigila de cerca todo lo que pasa por la red.

• Prefiere una conexión de socket de dominio en lugar de tcp o http siempre que sea posible
• Mantenga grupos de conexiones para sus bases de datos, soluciones de almacenamiento en caché, etc.
• Utilice protocolos de peso ligero si está transfiriendo datos dentro de la aplicación web (ejemplo Protobuf)
• Los servidores web controlados por eventos (Ejemplo Nginx, nodejs) están superando a los servidores web basados ​​en hilos (Apache) tanto en términos de rendimiento como de latencia

Para la escalabilidad horizontal como Piyush Goel mencionó sus servidores de aplicaciones sin estado.
Y, por supuesto, inserte sus servidores de aplicaciones en el equilibrador de carga.

Aquí hay algunas cosas que hicimos

• Contenido estático descargado que sirve a un CDN. Deje que las CDN hagan lo que mejor saben hacer.
• Las llamadas desde el navegador del usuario se devolvieron de inmediato, lo que significa que todo el procesamiento de backend significativo fue asíncrono. Escala en múltiples niveles: experiencia más rápida para el usuario final, mejor escala para el servidor web (más subprocesos de trabajo gratuitos), procesamiento asíncrono a conveniencia del back-end.
• Automatice de manera sensata y exhaustiva, de modo que en tiempos de crisis no tengamos que pensarlo dos veces.

• Las llamadas a la base de datos son caras. Intenta leerlos en / de memoria tanto como sea posible. Sin embargo, tenga cuidado en un entorno agrupado.
• Almacenamiento en caché distribuido

• Almacene valores como información de referencia en lugar de buscarlos cada vez desde un lugar costoso como db, archivo, etc.
• Esto podría ser costoso si pocos escenarios

Además de las cosas de almacenamiento en caché mencionadas por Nidhal, asegúrese de que los servidores de su aplicación no tengan estado para que pueda escalar horizontalmente cuando sea necesario.

Utilice NoSQL y el modelo de coherencia eventual para lograr la escalabilidad horizontal de las bases de datos.