Sitios web
Escalado y auto-escalado de una aplicación Node.js
Auto-scaling grows and shrinks the number of instances running your Node.js app as CPU load changes, so busy periods get more capacity and quiet periods cost less. This guide covers the KPanel tab…
Escalado y Auto-escalado de una Aplicación Node.js
El auto-escalado aumenta y reduce el número de instancias que ejecutan tu aplicación Node.js conforme cambia la carga de CPU, de modo que los períodos ocupados obtienen más capacidad y los períodos tranquilos cuestan menos. Esta guía cubre la pestaña de KPanel, cada configuración, qué se factura y cómo hacer que una aplicación sea segura para escalar.
Dónde vive el escalado en KPanel
- Inicia sesión en KPanel.
- Haz clic en Websites en la barra lateral izquierda y luego haz clic en el sitio.
- En la barra de pestañas del sitio, abre Advanced y luego Scaling.
La dirección directa es /websites/<site-id>/autoscale. La dirección más antigua /websites/<site-id>/scaling sigue funcionando y te envía al mismo lugar.
La pestaña solo aparece en sitios Node.js. No estará en el menú para un sitio WordPress, WooCommerce, estático, PHP, Python o Ruby, porque el mecanismo escala un clúster de procesos Node.js.
Una pestaña, una configuración
KPanel solía llevar dos pestañas aquí, Scaling y Autoscale, sobre un conjunto de configuraciones. Eran dos vistas de la misma configuración, que solo era una forma de perderse, así que ahora son una única pestaña Scaling: estado en vivo, la configuración, eventos de escalado recientes y el panel de uso y costo del período de facturación actual, todo en un lugar.
Cómo funciona
Tu aplicación se ejecuta como un clúster de procesos. El auto-escalado supervisa el CPU promedio en las instancias en ejecución y añade o elimina instancias según los umbrales que estableces.
Se requiere modo de clúster. Si tu aplicación no se está ejecutando ya en modo de clúster, habilitar el auto-escalado la cambia automáticamente, lo que implica un breve reinicio. La página te dirá cuándo sucede esto.
Lectura del estado en vivo
La tarjeta de estado muestra tres cosas:
- Instances: cuántas se están ejecutando en este momento.
- Avg CPU: el CPU promedio en esas instancias.
- Cluster: si la aplicación está en modo de clúster. Si dice no, habilitar el auto-escalado la cambiará.
Si la aplicación no se está ejecutando en absoluto, la tarjeta lo indica en lugar de mostrar ceros.
La pestaña también muestra Last scale, la hora del evento de escalado más reciente, o never.
La configuración
| Configuración | Rango | Qué hace |
|---|---|---|
| Min instances | 1 a 16 | El piso. Nunca escala por debajo de esto |
| Max instances | 1 a 16 | El techo. Nunca escala por encima de esto |
| Scale up at CPU % | 5 a 99 | CPU promedio por encima de esto añade una instancia |
| Scale down at CPU % | 1 a 95 | CPU promedio por debajo de esto elimina una |
| Cooldown (sec) | 30 a 3600 | Espera mínima entre acciones de escalado |
El interruptor maestro es el botón en el encabezado de la tarjeta de configuración. Cuando el auto-escalado está desactivado, la configuración se atenúa y tu aplicación permanece en su recuento de instancias actual.
Valores de inicio sensatos:
- Min instances 1 o 2. Dos si no puedes tolerar que el reinicio de una única instancia desconecte la aplicación.
- Max instances en lo que estés dispuesto a pagar en el pico, no en el techo.
- Scale up alrededor del 70 por ciento. Lo suficientemente alto para que no estés pagando por margen de maniobra que nunca usas, lo suficientemente bajo para que haya tiempo de añadir capacidad antes de que las solicitudes comiencen a encolar.
- Scale down alrededor del 30 por ciento. Deja un espacio amplio entre los dos umbrales.
- Cooldown de algunos minutos. Esta es la configuración más subestimada.
Establecer los dos umbrales de CPU muy cercanos causa flapping: el clúster escala hacia arriba, cae inmediatamente por debajo del umbral de escalado hacia abajo porque la carga ahora se distribuye más ampliamente, escala hacia abajo, se dispara de nuevo y se repite. Mantén un espacio amplio y usa un cooldown generoso. El flapping cuesta dinero y desestabiliza la aplicación.
Eventos de escalado
La pestaña lista eventos de escalado recientes, los más nuevos primero, cada uno mostrando la dirección, el recuento de instancias antes y después, la lectura de CPU que lo activó y la hora.
Este es el registro a consultar cuando la aplicación se comportó mal. Una ráfaga de eventos hacia arriba y hacia abajo en algunos minutos significa que tus umbrales están demasiado cerca o tu cooldown demasiado corto. Un único escalado hacia arriba que nunca bajó significa que la carga se mantuvo alta, que es una cuestión de capacidad más que de configuración. Sin eventos en absoluto cuando esperabas algunos significa que el CPU nunca cruzó un umbral o el auto-escalado está desactivado.
Qué cuesta el auto-escalado
Las instancias por encima de la asignación base de tu plan se miden y se facturan por segundo. La pestaña muestra, para el período actual:
- Instance-time used, en horas y minutos, con los segundos de instancia sin procesar debajo.
- Spent so far en este período.
- Projected month-end, extrapolado del uso hasta ahora.
- Tracking, cuántas ventanas de uso se han facturado de las totales registradas.
- Period progress, días transcurridos de los días del mes.
La tasa por segundo se muestra en la parte superior del mismo panel, de modo que la cifra por la que se te factura siempre es visible junto al uso al que se aplica.
La proyección es el número a vigilar. Se extrapola de lo que has usado hasta ahora, así que una semana inusualmente ocupada al principio del mes la sobrestimará. Compruébala algunos días después y nuevamente a mitad de mes antes de sacar conclusiones. Si es más alta de lo que quieres, baja el recuento máximo de instancias en lugar de elevar el umbral de escalado hacia arriba: el techo es un límite duro, un umbral es solo una sugerencia.
Escalar hacia abajo al mínimo detiene la medición. Si desactivas el auto-escalado por completo, la aplicación permanece en el recuento de instancias que tenga actualmente, así que bájalo primero al mínimo si el costo es la razón por la que estás desactivando.
Hacer que una aplicación sea segura para escalar
La página lleva una advertencia, y es lo más importante en ella: tu aplicación Node.js debe ser segura para clúster para escalar limpiamente entre instancias.
En la práctica, eso significa:
Sin estado de sesión en memoria. Si la sesión de un usuario autenticado vive en la memoria de una instancia, está cerrada cada vez que una solicitud llega a una instancia diferente. Mueve las sesiones a un almacén compartido.
Sin caché en memoria en el que confíes para la corrección. Cada instancia tiene la suya. Un caché que debe ser consistente tiene que ser compartido.
Sin escrituras en el sistema de archivos local que esperes leer de nuevo. Las cargas escritas en disco local por una instancia son invisibles para las otras. Escribe en almacenamiento compartido.
Sin trabajo programado sin protección. Si un temporizador se ejecuta dentro de la aplicación, cada instancia lo ejecuta, de modo que un trabajo nocturno en cuatro instancias se ejecuta cuatro veces. Mueve el trabajo programado a un cron job o protégelo con un bloqueo. Consulta Cron Jobs.
Sin asumir que el recuento de instancias es estable. Cualquier cosa que divida el trabajo por índice de instancia se rompe en el momento en que el recuento cambia.
Si alguno de estos se aplica a tu aplicación, corrígelos antes de habilitar el auto-escalado. Una aplicación que no es segura para clúster falla de formas intermitentes y difíciles de reproducir, porque dependen de qué instancia sirvió qué solicitud.
Solución de problemas
El botón no se habilita. Habilitar necesita permiso de escritura del sitio. Con un rol de solo lectura los controles están deshabilitados.
La aplicación se reinició cuando habilité el auto-escalado. Esperado. Cambiar a modo de clúster requiere un reinicio y ocurre una sola vez.
Los usuarios están siendo cerrados de sesión al azar. Síntoma clásico de no ser seguro para clúster. Las sesiones están en memoria y las solicitudes llegan a instancias diferentes.
Las instancias escalaron hacia arriba y nunca bajaron. Bien la carga se mantuvo por encima del umbral de escalado hacia abajo, o algo mantiene el CPU alto independientemente del tráfico. Consulta la lista de eventos y mira qué está haciendo realmente la aplicación.
Un trabajo programado se ejecutó varias veces. Cada instancia lo ejecutó. Muévelo a un cron job o añade un bloqueo.
Nada escala. Confirma que el botón está activado, la aplicación se está ejecutando y el modo de clúster está habilitado. Luego comprueba si el CPU realmente cruzó tu umbral de escalado hacia arriba en la lista de eventos.
El costo es más alto de lo esperado. Busca flapping en la lista de eventos y luego baja tu recuento máximo de instancias.
Páginas relacionadas
- Site Performance and APM para ver si el CPU es genuinamente el cuello de botella.
- Site Uptime Monitoring para confirmar que el escalado está mejorando realmente la disponibilidad.
- Cron Jobs para trabajo programado que debe ejecutarse exactamente una vez.
- Resizing a Cloud Server si necesitas una máquina más grande en lugar de más instancias.