Siete medidas, una noche real de examen y un error de scale-in: cómo las pruebas de carga, un modelo de capacidad y un plan de soak honesto formaron la arquitectura final de NovaCommerce, su costo, y la lista de verificación de un Solutions Architect. La Parte 5 cierra la serie.
Author
Anichur Rahaman
Part 5 of 5
De Un Servidor a Listo para el Día de ExamenLa tarde del 7 de octubre, 661 estudiantes comenzaron un examen en NovaCommerce, con un pico de 86 inicios por minuto, y 439 más tomaron un segundo examen después. El backend alcanzó pico de aproximadamente 69 solicitudes por segundo y alcanzó 47% de CPU en un promedio de dos minutos. La base de datos usó menos de un cuarto de su CPU. Ningún trabajo de fondo falló.
Luego se bajó un mínimo de pool en el medio del examen. Un nodo sirviendo desapareció sin drenaje, y aproximadamente 360 solicitudes fallaron en dos minutos.
Ambas mitades de esa noche fueron resultados de prueba: la mitad tranquila vino de una corta serie de pruebas en los días anteriores, la mitad fea de algo que ninguna prueba había cubierto aún. Esta parte recorre el viaje en orden (línea base, prueba de carga, cuello de botella, optimización, reexamen, escalado, soak, resultado final), luego muestra la arquitectura final, su costo, y la lista de verificación que ahora uso en cada revisión.
Esta es la parte 5 del caso de estudio de cinco partes "From One Server to Exam-Day Ready". NovaCommerce es un nombre ficticio; la arquitectura, los números y los errores son reales.
Cada cambio en esta serie salió de un bucle: medir, encontrar el cuello de botella, entender la causa, cambiar el diseño, probar de nuevo, medir de nuevo. Un cambio hecho antes de que se entienda la causa es una suposición, y una suposición que resulta ser un servidor cuesta dinero cada mes. Piensa en una manguera de jardín con un nudo: si el agua es débil, un grifo más grande no hace nada, así que recorres la manguera hasta que encuentras el nudo. El nuestro se movió tres veces, y cada vez fue un tipo diferente de problema.
Lo primero que medimos en producción no fue CPU. El 25 de septiembre, los estudiantes recibían HTTP 429 (demasiadas solicitudes) durante los exámenes. El rate limiter de API global estaba codificado por dirección IP, porque el guard de autenticación por defecto estaba vacío para estudiantes basados en token. Una escuela u operador de telefonía móvil pone cientos de estudiantes detrás de una IP NAT, así que un edificio entero compartía un bucket. Un 429 es la aplicación diciendo no, no un servidor sin aliento, así que ningún nodo extra podría haber ayudado. Implementado: el limitador ahora codifica por cuenta de estudiante o instructor, y por IP solo para invitados.
A las 02:28 el 6 de octubre, una prueba de carga del backend devolvió 2.854 500s de aplicación, cada uno RedisException: Operation timed out mientras se conectaba (timeout de conexión de 5 segundos). La causa: Valkey (4 GB, primary y standby) no podía aceptar conexiones lo suficientemente rápido, y cada solicitud abría una conexión TLS fresca a él, aproximadamente 5.4 ms de CPU por solicitud contra aproximadamente 3.3 ms para MySQL. Más nodos web solo habrían abierto más conexiones al mismo Valkey.
Implementado: Valkey redimensionado in-place a 8 GB en dos nodos (primary y standby), datos preservados, host sin cambios. Cuesta más dinero, y eliminó una falla real.
Reexamen: una escalada gradual de 25 a 500 solicitudes por segundo, comenzando en dos nodos backend mientras el pool escalaba, dio 0 errores de aplicación y 0 5xx del backend. Había 143 errores en el load balancer, pero solo mientras los nodos estaban saturados de CPU. Esa es la señal esperada de "fuera de capacidad", no un bug, y nos mostró dónde cada nodo se queda sin capacidad.
Las pruebas del backend también nos dieron el número en el que cada decisión posterior se inclina. A CPU completa, un nodo backend de 4 vCPU / 8 GB sirvió aproximadamente 65 a 70 solicitudes por segundo de la mezcla API real, aproximadamente 59 ms de CPU por solicitud. Las cifras concuerdan: 4 vCPU es 4.000 ms de CPU por segundo, y 4.000 dividido por 59 es aproximadamente 68. Autoscale agregó el primer nodo extra aproximadamente 7 minutos después de que CPU alcanzó 99%.
Eso hace tres cuellos de botella en orden: una regla (el limitador), la capa de datos (conexiones Valkey), y solo luego CPU del backend simple. Cada necesitaba una corrección diferente, y solo la última se resuelve con más servidores.
Con el frontend reconstruido como un pool (nginx enfrente de dos contenedores Next.js idénticos por nodo), dos nodos sirvieron aproximadamente 356 solicitudes por segundo, p95 0.05 s, 0 errores, con CPU del 55 a 60%, y comparamos 12 páginas reales contra el servidor antiguo. El espacio libre se pagó: el pool se movió de droplets de CPU dedicada a droplets de AMD compartido de 2 vCPU / 4 GB. Implementado.
El 5 de octubre, de 21:17 a 21:33, k6 reprodujo la mezcla real de solicitudes de pico de examen (solo GET, nada escrito): 300 a 450 solicitudes por segundo, luego aproximadamente 750 durante seis minutos.
La lección estaba en la sincronización. La métrica de CPU de DigitalOcean se retrasa 5 a 8 minutos de la carga real, así que el escalado comienza tarde y luego se pasa: el backend brevemente escaló a 4 después de que la carga había parado. El primer nodo backend extra llegó doce minutos después de que la prueba comenzara, y un examen no espera doce minutos. Así que para exámenes programados pre-escalamos, elevando el mínimo del pool aproximadamente 45 minutos antes de uno grande, y mantenemos el autoscaling reactivo como la red de seguridad. La versión genérica de este argumento está en Autoscaling for Traffic Spikes.
Probado, luego arreglado: nuestro primer rollout de plantilla de backend produjo un blip 503 corto, porque DigitalOcean eliminó los droplets antiguos mientras el load balancer aún estaba enrutando a ellos. El rollout guardado cambia solo la imagen, espera hasta que los nuevos nodos respondan /lb-health, espera aproximadamente 40 segundos para que el balancer los admita, y drena los nodos antiguos primero. El rollout completo de ambos pools el 7 de octubre se ejecutó bajo una sonda de uptime cada 2 segundos en páginas reales: 219 sondas, 0 errores.
Esta es la tabla que desearía haber visto antes de comenzar. Para cada problema que las pruebas o la producción expusieron, hace una pregunta: ¿más servidores lo habrían arreglado?
| Problema encontrado | ¿Más servidores? | Qué lo arregló | Estado |
|---|---|---|---|
| CPU del backend saturada a 65 a 70 solicitudes/s por nodo | Sí | Pool de autoscaling (2 a 10 nodos) más pre-scaling | Implementado |
| Escuelas enteras recibiendo 429 (25 de septiembre) | No | Limitador codificado por cuenta de estudiante, IP solo para invitados | Implementado |
| Throttles de ruta aún contando por IP: 74% de llamadas a un endpoint de dashboard devolvió 429 en un examen (7 de octubre) | No | Throttles contando por estudiante por ruta; 0 tales 429s después | Implementado |
| 2.854 timeouts de conexión Valkey (6 de octubre) | No | Valkey redimensionado in-place a 8 GB x 2 | Implementado |
| Tarjetas de mérito (un trabajo de 0.34 segundos) esperando 10 a 115 minutos detrás de trabajos de IA de aproximadamente 10 segundos cada uno (6 de octubre) | No | Carril de cola separado para trabajos de IA; tarjetas de mérito listas en aproximadamente 1 minuto | Implementado |
| Backend ve una IP de frontend para cada estudiante | No | Pasar la IP real del estudiante en un encabezado firmado | Planeado |
De seis problemas, uno fue un problema de capacidad. Los otros cinco fueron dos reglas, un límite de conexión, una disposición de cola y un encabezado faltante. El lado de capa de datos de este patrón se cubre en The Data Tier Under Load.
Una prueba de carga pregunta cuánto puede tomar un sistema. Una prueba de soak pregunta cuánto tiempo puede tomarlo: un motor a revoluciones máximas por un minuto prueba poco sobre tres horas, porque los problemas lentos muestran tarde (memoria que se repta, conexiones que pierden, discos que se llenan, colas que derivan). "Lo probamos con soak" es fácil de decir y difícil de defender, así que seré exacto: aún no hemos ejecutado una prueba de soak formal.
| Evidencia | Lo que cubre | Estado |
|---|---|---|
| Corridas sostenidas cortas: la escalada de 25 a 500 solicitudes/s, la prueba de autoscaling de 16 minutos hasta aproximadamente 750 solicitudes/s, una sonda de uptime de 2 segundos a través de un rollout | Minutos de carga sostenida: 0 errores de aplicación en la escalada, 0 errores de servidor en la prueba de autoscaling | Probado |
| La noche de examen del 7 de octubre: aproximadamente dos horas, dos exámenes uno detrás del otro | CPU estable, 0 trabajos fallidos, un error de scale-in | Observado en producción |
| Un soak de varias horas junto con la próxima prueba de carga grande, en una ventana de mantenimiento acordada | Crecimiento de memoria, pérdidas de conexión, deriva de colas | Planeado |
La noche de examen es lo más cercano a esto que tenemos, pero es una observación, no una prueba controlada. Un control relacionado se mantiene: los nodos backend escribieron 0 archivos al disco en 24 horas, así que los discos no son un riesgo de soak allá. Los nodos frontend aún mantienen aproximadamente 440 MB de logs nginx al día localmente, que es por qué Fluent Bit en el frontend está en la lista Planeado.
Nada reemplaza estudiantes reales. Dos exámenes se ejecutaron uno detrás del otro, y nuestro resumen una vez por minuto los observó: estudiantes iniciados y enviados, solicitudes y 5xx por nodo, pool CPU, carga de worker y trabajos fallidos.
| Medida | Resultado |
|---|---|
| Examen A (20 minutos) | 661 iniciados, 638 enviados (96.5%); inicios alcanzaron pico de 86 por minuto |
| Examen B (25 minutos) | 439 iniciados, 425 enviados (96.8%) |
| Frontend | Hasta 1.741 visitantes únicos en Examen A, pico de 403 en un minuto; aproximadamente 732.000 solicitudes de 6 a 8 pm; CPU hasta 24% |
| Backend | Pico aproximadamente 69 solicitudes/s (logs por minuto; 63 en el promedio de dos minutos del proveedor); CPU hasta 47% en promedio de dos minutos; un nodo a 86% durante un minuto |
| MySQL | CPU máx 24.5% (promedio 13.4%), como máximo 5 consultas en ejecución, 0 lock waits |
| Valkey | 12.5% memoria |
| Worker | CPU 46%, 0 trabajos fallidos |
Tres cosas destacan.
En el medio de un examen, alguien bajó el mínimo del pool backend. DigitalOcean removió un nodo sirviendo sin drenarlo, y aproximadamente 360 solicitudes fallaron en dos minutos. Las pruebas anteriores nos enseñaron que el scale-out es lento y tarde. El examen enseñó la otra mitad: el scale-in es rápido y no se despide. Implementado como una regla de runbook: elevar el mínimo antes de un examen, bajarlo solo después, y nunca confiar en que el autoscale scale-in drenará un nodo.
Después del examen convertí los datos reales en un pequeño modelo, así que el próximo examen puede ser planeado con aritmética en lugar de miedo. Tiene cuatro entradas medidas: aproximadamente 15 solicitudes por estudiante cuando abre un examen, luego aproximadamente 1.5 por minuto (0.025 por segundo); aproximadamente 30 solicitudes/s de tráfico de línea base; 50 solicitudes/s como la carga segura para un nodo backend (75% CPU); y un margen del 30% para división desigual.
En palabras simples: toma los nodos que tendrás, multiplica por 50, divide por 1.3 para el margen, y resta los 30 de tráfico de línea base. Lo que queda es lo que los estudiantes pueden usar en el momento que se une el último. Cada estudiante cuesta sus 15 solicitudes de apertura esparcidas sobre la ventana de unión, más 0.025 por estar presente.
Toma 4 nodos. 4 x 50 / 1.3 es aproximadamente 154, y menos 30 deja aproximadamente 124. Si los estudiantes se unen sobre 10 minutos, cada uno cuesta 15 / 600 + 0.025 = 0.05 solicitudes/s, así que 124 / 0.05 da aproximadamente 2.500 estudiantes; la tabla redondea hasta 2.400. Si todos se unen dentro de 2 minutos, cada uno cuesta 15 / 120 + 0.025 = 0.15, que da aproximadamente 800.
| Nodos backend | Uniéndose sobre ~10 minutos | Todos uniéndose dentro de ~2 minutos | Carga segura del backend (derivada) |
|---|---|---|---|
| 2 | aproximadamente 900 | aproximadamente 300 | aproximadamente 77 solicitudes/s |
| 4 | aproximadamente 2.400 | aproximadamente 800 | aproximadamente 154 solicitudes/s |
| 6 | aproximadamente 4.000 | aproximadamente 1.300 | aproximadamente 231 solicitudes/s |
| 8 a 10 | 5.500 o más | 1.800 a 2.300 | aproximadamente 308 a 385 solicitudes/s |
La noche real encaja en la primera fila: un pico de 86 inicios por minuto contra aproximadamente 90 por minuto que esa fila permite. Dónde el modelo se detiene:
Los cuadros sólidos corren hoy; la tira discontinua es planeada.
sticky = true); Valkey 8 GB en dos nodos; PostgreSQL con pgvector (2 vCPU / 4 GB) mantenido aparte, así que las consultas de vectores nunca compiten con escrituras de examen.| Área | Antes (hasta 5 de octubre) | Ahora |
|---|---|---|
| Frontend | Un droplet de 8 vCPU / 16 GB, un contenedor Next.js, sin load balancer | Pool balanceado por carga de 2 a 10 nodos, dos contenedores por nodo |
| Backend | Dos droplets fijos, apuntados por ID, así que nuevos servidores nunca podrían unirse | El balancer apunta a una etiqueta; pool de 2 a 10 de una imagen, pre-escalado antes de exámenes |
| MySQL | Un nodo Advanced, 8 vCPU / 32 GB, sin standby | Standard 4 vCPU / 16 GB, primary y standby |
| Servidores "standby" | Dos droplets apagados, $112 al mes, minutos para encender | Removido; standby reales dentro de MySQL y Valkey (ahora 8 GB, de 4) |
| Elemento (mensual, precios de lista de DigitalOcean) | Costo |
|---|---|
| Antes: capa web completa (16 GB frontend, 2 backend, worker, 1 load balancer, 2 standby apagados) | aproximadamente $416 |
| Ahora, capa web: 2 backend ($56 cada uno), 2 frontend ($28 cada uno), worker, dos load balancers | $112 + $56 + $56 + $48 |
| Ahora, datos y logs: MySQL pair, Valkey 8 GB x 2, PostgreSQL, OpenSearch | aproximadamente $389 + $240 + $60 + $20 |
| Ahora: snapshots, Spaces | aproximadamente $5 + $5 y uso |
| Ahora: producción total, pool backend en 2 nodos | aproximadamente $990 |
Los totales no son lo mismo para lo mismo: $416 era solo la capa web, y $990 es la pila de producción completa. En los mismos precios de lista la capa web ahora es aproximadamente $272. Los otros $709 son MySQL gestionado, Valkey, PostgreSQL y OpenSearch, y eso es lo que el dinero extra compra: una base de datos que sobrevive a la falla de un nodo, un Valkey con espacio y un standby, búsqueda de vectores que se mantiene fuera del camino de escrituras de examen, y logs que sobreviven a un nodo eliminado. El pre-scaling es la parte barata: un nodo backend extra cuesta aproximadamente $0.08 por hora. Las decisiones detrás de los números están en la lista de verificación abajo.
Esta es la lista de verificación que ahora uso en revisiones de arquitectura. Cada elemento es algo que este proyecto hizo o pagó.
/lb-health) antes de ser removido.Cuando esta serie comenzó, la plataforma era un droplet frontend, dos droplets backend fijados por ID y un nodo de base de datos grande. La noche de examen del 7 de octubre corría en un sistema diferente, y ninguna de la diferencia vino de agregar servidores por su propio bien. Vino del mismo bucle, una y otra vez, incluyendo los tiempos que la medida nos dijo que estábamos equivocados.
Mide. Encuentra el cuello de botella. Entiéndelo. Cambia una cosa. Prueba. Mide de nuevo.
Ese bucle es la arquitectura; los pools, los standby y los diagramas son lo que deja atrás. Si guardas una cosa de estas cinco partes, guarda el bucle, y úsalo antes de tu próxima noche de examen, venta o lanzamiento.
Gracias por leer las cinco partes. Para volver, comienza con la parte 1, el punto de partida y alta disponibilidad, luego la parte 2, escalado de la capa de aplicación, la parte 3, la base de datos y la parte 4, Valkey, workers y logging. Esta fue la última parte de la serie.
About the Author
Anichur Rahaman
Continue Reading
