Cómo el comercio electrónico sobrevive a las promociones a gran escala. Preparándose para las cargas máximas en la web [Parte 1]

Hola a todos, estoy en contacto con Alexey Pristavko, director del proyecto web DataLine.
Black Friday, el evento de comercio electrónico más grande del mundo, tiene lugar anualmente en los últimos días de noviembre. Este es el momento de descuentos récord, las tiendas abren casi a la medianoche y los sitios que participan en la acción caen, a pesar del fuerte aumento en el flujo de tráfico.

Por lo tanto, utilizando su ejemplo, analizaremos cómo prepararse para un aumento serio de la carga en un sitio web o aplicación web.
Debajo del gato, hablaremos en detalle sobre cómo los gerentes de TI, desarrolladores y administradores de tiendas en línea pueden sobrevivir a eventos a gran escala.

Lo que amenaza el viernes negro

Como escribí anteriormente, el Black Friday es un día que causa muchos problemas a todos los involucrados en el mantenimiento de sitios de comercio electrónico.

Para sentirlo, considere la tabla a continuación. Refleja el aumento en el número de solicitudes en el sitio durante el Black Friday.



En comparación con los picos diarios normales, cuando no se mantienen acciones, en Black Friday el tráfico crece en un 100-200%, y este no es el límite.

Si un sitio grande ya tiene mucho tráfico propio, entonces una tienda en línea modesta durante el período de la campaña recibirá fácilmente la mayor cantidad de visitantes y estrangulamiento. Para parafrasear un poco la vieja broma: "el negocio hizo que todas las tiendas fueran diferentes, y el Black Friday en línea igualó a todos".

Obtenido el Black Friday "alimenta" al vendedor todo el próximo año. El negocio está extremadamente interesado en atraer el número máximo de nuevos clientes que regresarán al sitio para comprar una y otra vez. Pero para esto, su primera experiencia con el sitio debe ser fluida y garantizar que esta sea la tarea de los especialistas de TI.

Mientras más clientes estén simultáneamente en el sitio, mayores serán los requisitos para su estabilidad y velocidad de respuesta. Seguramente notó que el sitio web de la tienda, al que cambió desde la página de inicio de blackfridaysales, funcionó extremadamente lento o no funcionó en absoluto. Dudo que te hayan dejado esperando la descarga, pero no te fuiste después de unos segundos.

Hablaremos sobre cómo proteger a los clientes de experiencias negativas y el sitio de fallas debido a sobrecargas, a continuación. Sin embargo, otros consejos son válidos para cualquier carga máxima esperada.

En general, hay dos etapas de preparación de un sitio para aumentar el tráfico: técnico y organizativo. En este artículo discutiremos la etapa técnica, y describiré los detalles de la organización en detalle en la segunda parte, que se lanzará en una semana.

Preparación técnica del sitio.

Un pequeño descargo de responsabilidad: no espere encontrar aquí instrucciones detalladas sobre qué, dónde y cómo apretarlo para que "la felicidad para todos sea en vano y nadie se sienta ofendido". En primer lugar, los sitios y proyectos son diferentes para todos. En segundo lugar, el asesoramiento técnico específico sobre un software en particular es más que suficiente. Incluido en Habré. En primer lugar, quiero transmitir a los lectores los principios fundamentales de trabajar con proyectos web y mostrar los puntos de partida, introducir técnicas básicas y matices independientes de la plataforma.

Comencemos con el axioma: al usuario no le gusta esperar, por lo que es extremadamente importante trabajar con tiempos y velocidad de respuesta. En el Black Friday, habrá muchas más solicitudes al sitio de lo habitual, y puede encontrar no solo una caída en las conversiones debido a una carga larga, sino también un exceso de tiempos de espera HTTP (el sitio no responde).

Muy a menudo, los sitios caen bajo carga no debido a fallas físicas, sino porque el tiempo de respuesta comenzó a exceder los tiempos de espera debido a la sobrecarga en algún nodo. Esto es similar a un atasco de tráfico, y por un tiempo tendrá que tomar el control en sus propias manos: expandir (escalar) el equipo, ajustar, cortar y configurar (tiempos de espera), optimizar la carga en los vehículos (paquetes y solicitudes) y trabajar con excepciones.

Dado que en el contexto del rendimiento del sitio tiene dos aspectos: la velocidad de respuesta y el número de solicitudes procesadas simultáneamente, mejoraremos estos parámetros.

Muy a menudo, una empresa representa la velocidad de respuesta como la velocidad del sitio según Google Analytics, y la cantidad de solicitudes simultáneas como la cantidad de usuarios simultáneos en el sitio.

En el trabajo técnico, no es muy conveniente operar con estos parámetros.
A continuación, propondré una métrica más adecuada para los cálculos.

Optimizamos la velocidad de respuesta

Al optimizar la velocidad de respuesta, nos interesan dos indicadores: la velocidad de respuesta del servidor y el tiempo de carga de la página.

El tiempo de carga de la página consta de los siguientes enlaces:

• Tiempo de generación de la página del servidor;
• Tiempo de transferencia de página del servidor al cliente;
• El tiempo de procesamiento de la página en el navegador del cliente.

Cuando todo funciona como de costumbre, el factor decisivo para el Tiempo de carga de la página no es el momento en que el servidor generó la página y el momento en que la página se entregó a través de la red, sino la calidad del front-end y la velocidad del sitio en el navegador. Dado que este último está completamente del lado del usuario, no puede temerle a los frenos el Black Friday. Sin embargo, pueden surgir problemas debido a sobrecargas en su canal de Internet o en la entrega de un componente externo (contadores de afiliados, chats en línea, complementos de CRM, etc.).
¿Cómo lidiar con eso? Aquí hay algunos consejos de trabajo:

1. Verifique la carga del canal de Internet. Cuente el crecimiento estimado. En caso de duda, expanda el canal. Algunos proveedores, además de las extensiones costosas de forma continua, pueden ofrecerle una extensión temporal para el período pico (mucho más barato) o incluso permitirle exceder brevemente la velocidad máxima.
2. ¿Usando un CDN? Póngase en contacto con el soporte técnico y advierta sobre el crecimiento planificado del tráfico. También se están preparando para el pico general, y su pronóstico será útil. Si el CDN promete que todo estará bien, pero, a pesar de todo, se "acostará", la presencia de correspondencia ayudará a presentar reclamos de indemnización.
3. De antemano, elabore un script para deshabilitar temporalmente los componentes externos en caso de problemas. Alinear el escenario con el negocio. No será superfluo comunicarse con el soporte técnico de los servicios utilizados, de todos modos, por lo general, es imposible influenciarlos de alguna manera.
4. En muchos sitios, la estática se representa con el servidor de aplicaciones. Bajo alta carga, el número de solicitudes de estadísticas aumenta muchas veces, y comienzan a competir por los recursos con la aplicación misma. Asegúrese de configurar el retorno estático directamente desde Nginx. En primer lugar, será mucho mejor para esto y, en segundo lugar, habrá un trabajo mucho más útil para sus hilos Apache, Tomcat o Jetty.

Mejorando la velocidad de respuesta

La optimización de la velocidad de respuesta per se se refiere a la mejora general en el rendimiento del sitio. Teóricamente, ayuda a reducir la cantidad de trabajo realizado por la aplicación, y debido a esto mejora la escala, porque si cada solicitud se vuelve "más barata", puede procesar más solicitudes con los mismos recursos.

Pero en la práctica, la optimización de la velocidad de respuesta requiere una gran cantidad de trabajo independiente. Es imposible optimizar todo de una vez, pero romper algo en el proceso es fácil.

Consejo: piense sistemáticamente. Digamos que el rendimiento del código ha aumentado y la aplicación ha comenzado a realizar más consultas simultáneas en la base de datos. Pero aquí está el problema: el rendimiento de la base de datos no permite procesar tantas solicitudes, y el sitio en su conjunto solo empeoró, y se dedicó un tiempo valioso antes del inicio de la acción.

Por lo tanto, es mejor centrarse en la escalabilidad y la escalabilidad, y realizar una optimización general por separado de la preparación para el Black Friday, para no equivocarse debido a plazos estrictos. Recuerde, ahora nuestra tarea es asegurar que en el pico de cargas el sitio no funcione peor que afuera.

La velocidad de generación de páginas será de interés para nosotros solo junto con otro indicador: la cantidad de carga entrante.

Tenga en cuenta: para el sitio, solo importa el número de solicitudes simultáneas creadas por los usuarios, y no el número de usuarios en línea en el sitio. Y calcular con precisión aceptable el número de solicitudes por segundo por el número de visitantes es bastante difícil (escribí sobre esto anteriormente). Es mejor pedirle a la empresa otras métricas: páginas vistas por hora y hora del servidor.

Como resultado, obtenemos un objetivo comprensible: garantizar la generación de páginas en el tiempo X con el número de solicitudes por segundo Y. Teniendo métricas numéricas específicas en la mano, es mucho más fácil evaluar el nivel de preparación y el resultado actual.

Aquí hay un plan general de capacitación técnica:

1. Averigüe los indicadores actuales (realice pruebas de carga de la versión actual del sitio);
2. Para entender qué es exactamente lo que falta y cuántos recursos se requieren para ordenar;
3. Agregar recursos;
4. Repita las pruebas de estrés y vea si eso ayuda.

¿Parece demasiado fácil? Tienes razón, cada punto está lleno de muchas sorpresas.

Muy a menudo, agregar recursos mejora parcialmente la situación, pero no salva todo. O en un entorno de prueba, el sitio funciona como un reloj, y en el producto, nuevamente los frenos.

A continuación, le mostraré cómo identificar posibles problemas y corregir las debilidades. Comencemos con cómo realizar pruebas de estrés y obtener un resultado realista.

Realizamos pruebas de carga correctamente

¿Dónde hacer la prueba?

A menudo, las pruebas de estrés se realizan en un sistema productivo. Esto puede ser bueno para controlar la situación como un todo, pero no para resolver iterativamente problemas específicos. Recuerde, generalmente después de los problemas recientemente descubiertos después de la eliminación, pueden aparecer otros nuevos. Las balas de plata rara vez golpean el objetivo.

Una prueba de carga fallida puede causar inconvenientes para los usuarios del sitio o incluso "interrumpirla" por un tiempo. Es mejor usar un área dedicada como conejo experimental.

Debe cumplir los siguientes requisitos:

• El área dedicada debe ser completamente independiente y aislada de la productiva;
  
• Idealmente, un área dedicada debe ser consistente con el tamaño del producto. Un modelo a gran escala también es adecuado, pero reducirá la calidad y la importancia de las pruebas. Si la carga en un recurso crece de manera no lineal (como suele suceder), su modelo no mostrará que bajo carga completa el recurso se agota antes de tiempo;
  
• Es mejor usar exactamente el mismo equipo (¡pero no el mismo!) Para pruebas que en productos. De lo contrario, incluso si se observan los valores cuantitativos de los recursos, no será posible proporcionar calidad. Puede jugar una broma cruel en el momento crucial. Si esto no es posible, pruebe el rendimiento del equipo bajo su carga y determine el coeficiente de ajuste.
  

Ahora hablemos sobre formas de generar una carga de prueba. Daré algunas técnicas básicas, cada una de las cuales tiene sus ventajas y desventajas.

¿Cómo generar una carga?

1. Prueba de solicitudes de los registros

Es posible emular el flujo de tráfico a través de los registros del servidor de batalla. Una ventaja obvia de este enfoque es que no tiene que molestarse con análisis, modelos estadísticos y un perfil de tráfico sintético.

Pero aún tiene que limpiar los registros de las solicitudes que no se pueden hacer o no son necesarias.
Por ejemplo, no necesita "comprar" productos de manera productiva, esto causará problemas con el contenido del producto de la base de datos.

Será difícil reproducir retrasos realistas entre las solicitudes.
Emular sesiones de usuario también es extremadamente difícil, este método está muy cerca de las pruebas basadas en resultados.

2. Usando Yandex.Tank y Phantom

El tanque junto con Phantom es una herramienta muy conveniente y popular para pruebas basadas en golpes. Tiene una interfaz bien pensada y le permite administrar la carga. Para comenzar a bombardear un tanque, debe preparar "cartuchos": archivos especiales que contienen solicitudes de un generador.

Pero, a pesar de todas las ventajas, el Tank tiene un gran inconveniente: no sabe cómo usar las sesiones de usuario.

Puede olvidarse de la autorización, del trabajo completo con cookies y de los retrasos variables. Un tanque solo puede "picotear" solicitudes de una sola dirección.

Te conviene si:

• No hay diferencia en el tiempo de respuesta del servidor para usuarios autorizados y no autorizados, o es insignificante;
• Prueba de API sin sesiones HTTP explícitamente;
• Este enfoque generalmente es coherente con la lógica de su sitio (generalmente no es adecuado para tiendas en línea).

3. Usando Apache JMeter

Esta es la herramienta más flexible que le permite emular sesiones de usuario en detalle. Entonces, con su ayuda, aún puede responder la pregunta de la empresa "¿cuántos usuarios soporta el sitio?" Además, JMeter puede trabajar en conjunto con Yandex.Tank.
Su clave menos es el consumo de recursos y la complejidad de la preparación de pruebas.

El consejo principal directamente sobre JMeter: trate de evitar analizar los cuerpos de las páginas con sus fuerzas, es mejor usar conjuntos de datos preparados previamente para reproducir la lógica de la sesión. En principio, es mejor minimizar el trabajo realizado por JMeter en general. Al igual que Tank, es posible adjuntarle "cartuchos" pregenerados. Aquí es donde deben tener en cuenta la distribución de páginas específicas dentro de un tipo, la variabilidad de las solicitudes, etc.

En JMeter, los modelos de comportamiento del usuario deben programarse. Si la tarea es probar no solo la parte del servidor, sino también el retorno del contenido estático, ejecute esta prueba por separado usando Phantom, si es necesario simultáneamente con la prueba JMeter. Esto ayudará a reducir significativamente el consumo de recursos del generador de carga y aumentará la reproducibilidad de la prueba.

Recomendaciones de pruebas de estrés

Las buenas pruebas de carga se basan en un análisis de tráfico competente y una preparación de alta calidad de un modelo estadístico y perfiles para la emulación.

Resalte 5-7 tipos principales de páginas (no se olvide también de las páginas de destino para las existencias), calcule el porcentaje del tráfico total distribuido entre ellas. Tenga en cuenta que puede haber varias solicitudes de contenido dinámico por página. Para usted, la página es el grupo completo de tales solicitudes. Analice cuánto tiempo pasan los usuarios en cada tipo de página: promedio, promedio mínimo, promedio máximo.

Si la página se basa en varias solicitudes, considere la demora entre ellas. Vea cuántas páginas suele visitar un usuario por sesión, cuál es la distribución de este número. Resalte 5-10 de las rutas de usuario más comunes por tipo de página.

Utilizando los datos obtenidos, construya los escenarios de tal manera que reproduzca todos los parámetros estadísticos descritos con extrema precisión. No se olvide de la variabilidad de los escenarios, deben variar tanto en el número como en la composición de los clics.

Dentro de cada tipo de página, resalte las direcciones individuales. Cuanto más, mejor, pero un par de miles de las direcciones más populares ya estarán fuera de la vista. Puede preparar listas de consultas a partir de ellas agregando cada dirección a la lista tantas veces como sea necesario.

Si hay demasiadas páginas, divídalas en varios grupos según el porcentaje de tráfico.

Los perfiles juegan un papel solo para JMeter, pero al crear listas de consultas, puede equipar cartuchos "tanque".

Y de nuevo: cuando use JMeter en modo de emulación de usuario, no se olvide de los retrasos entre las solicitudes. ¡Si no los agrega, su carga generada será muchas veces mayor de lo planeado!

Después de una ejecución de prueba, asegúrese de verificar los registros del servidor web para ver si el tráfico emulado es productivo.

Aerobatics preparará los guiones por adelantado para llevar la base de datos del sitio al estado que necesita. Por lo general, los datos preparados de la manera descrita anteriormente solo funcionan con el estado de la base de datos para la que se recopiló información sobre los bienes. Puede ser prohibitivamente largo recargar el volcado de SQL cada vez. Además, es muy deseable aprender a administrar las existencias en ejecución utilizando scripts en el área de prueba. A menudo son importantes para el funcionamiento del sistema, y ​​debe comprender con qué conjunto y cómo se prueban exactamente las existencias de trabajo.

¿Está todo listo? Genial, adelante!

Usamos monitoreo en pruebas

Entonces, realizamos pruebas competentes y obtuvimos los resultados. Si todo está bien y su sitio está lidiando con una gran carga, entonces ningún Black Friday le da miedo. Pero este artículo estaría incompleto si no consideramos un triste escenario realista.

Imagine que un sitio puede soportar una velocidad aceptable ... bueno, incluso si solo una quinta parte de lo que la empresa quiere obtener. ¿Es realmente necesario llamar al hoster en pánico y pedir cinco veces más capacidad?

En principio, al anfitrión le gustará este enfoque. Incluso puede obtener el estado de un cliente de oro.

Pero antes de actuar precipitadamente, intentemos averiguar qué salió mal exactamente.

Su salvavidas en el mar de posibles causas es un sistema de monitoreo.



Por lo tanto, damos un paso atrás e instalamos tantas muestras como sea posible antes de realizar la prueba. Idealmente, todos los recursos agotables deben ser monitoreados.

A continuación hay una lista para ayudarlo a comenzar:

• Carga de CPU (uso de CPU, carga de CPU);
• Carga de RAM;
• Carga de disco (IOPS, Latencia);
• Número de conexiones de red (tiempo de espera, fin de espera, cierre de espera, establecido);
• El número de tomas abiertas;
• El número de procesos de usuario;
• El número de archivos abiertos;
• Tráfico de red (en megabits y en paquetes, más errores y caídas).

Y también:

• El número de consultas, respuestas y conexiones a la base de datos y otros componentes;
• Velocidad de respuesta de componentes (base de datos, servidor de búsqueda, cachés, etc.);
• Todos los registros disponibles para errores.

. , « ». , «» , .

, , .

- , : , HDD SSD. -, .

. .

: , , ? , , , 2- , - (, 0,5 ) 1,5 . - «, ».

1 , . , . , . , ( ) , .

, , , .

«» , . 2-3 , , .

, : . , . , , , , .

. . , SLA, , , , , «» .

. , . .

, , . , , .

, .
-, ( ), -, . .

, . - , .

, , , « e-commerce. », 16 . .