Estimador de capacidad

¿Cuántos servidores necesitas realmente? Respóndelo con aritmética en lugar de sensaciones: dale al estimador tu tasa de solicitudes, el tiempo de CPU que quema cada solicitud y el tiempo de respuesta que ven los usuarios, y te devolverá los núcleos que el tráfico mantiene ocupados, los servidores completos que aprovisionar —con tu política de redundancia aplicada—, la concurrencia que tus grupos de conexiones deben sobrevivir y qué aspecto tiene el mismo servicio con dos, cinco y diez veces el tráfico.

Las fórmulas, en lenguaje sencillo

Núcleos. Multiplica la tasa de solicitudes por los segundos de CPU que consume cada solicitud: eso es cuántos núcleos mantiene ocupados el tráfico al 100 %. Luego divide entre tu utilización objetivo: al 70 %, cada núcleo que aprovisionas solo cuenta como 0,7 núcleos de plan, y el otro 0,3 es el margen que mantiene las colas cortas cuando el tráfico oscila. Núcleos necesarios = solicitudes/s × segundos de CPU por solicitud ÷ utilización objetivo.

Servidores. Divide los núcleos entre los núcleos por servidor y redondea hacia arriba: no existe tal cosa como 0,4 de servidor, y redondear hacia abajo es como un plan que funciona en promedio fracasa en el pico. La redundancia se aplica después: N+1 añade un servidor de repuesto a la cifra redondeada; 2N duplica toda la flota. La concurrencia es un número distinto, procedente de Little's law: solicitudes en curso = solicitudes/s × tiempo de respuesta en segundos. Dimensiona los grupos de hilos, las conexiones a la base de datos y los descriptores de archivo: los límites que los servicios realmente alcanzan mientras sus CPU aún están ociosas. La salida, cuando das un tamaño de respuesta, es solicitudes/s × tamaño × 8, los bits de los que está hecha tu factura de red. El artículo complementario, cuántos servidores necesitas realmente, explica de dónde sale cada entrada y por qué los benchmarks de los proveedores no coinciden con nada de esto.

Compañeros de planificación: la calculadora de presupuesto de error de SLA convierte en minutos el objetivo de disponibilidad que esta capacidad defiende, y la calculadora de retención de copias dimensiona el lado del almacenamiento del mismo sistema.

Preguntas frecuentes

¿Por qué planificar para una utilización del 70 % en lugar del 100 %?

Porque las colas explotan antes de la saturación, no en ella. Una CPU ocupada al 95 % en promedio es una CPU cuya cola crece sin límite cada vez que el tráfico oscila, y el tráfico siempre oscila. El objetivo de utilización es el margen que absorbe los picos, los despliegues, los reintentos y una dependencia lenta. El 70 % es el valor por defecto del sector para servicios sensibles a la latencia; los trabajadores por lotes que toleran retrasos pueden ir más calientes, y todo lo orientado al usuario y con picos debería ir más frío.

¿Cuál es la diferencia entre núcleos y solicitudes en curso?

Responden a preguntas distintas. Los núcleos salen del tiempo de servicio de CPU: cuánto procesador consume cada solicitud. Las solicitudes en curso salen de Little's law: la tasa multiplicada por el tiempo de respuesta, y miden la concurrencia —conexiones, hilos, memoria mantenida abierta—, no la carga del procesador. Un servicio con llamadas lentas a sistemas posteriores puede mantener 500 solicitudes en curso usando dos núcleos, y agotará el grupo de conexiones mucho antes de agotar la CPU. Dimensiona ambos, o el que ignoraste se convertirá en la caída.

Mi prueba de carga dice que un servidor maneja 2.000 solicitudes por segundo. ¿Por qué este estimador no está de acuerdo?

Las pruebas de carga suelen medir un servicio caliente, estable y con la caché al rojo vivo respondiendo a una única forma de solicitud desde un cliente generoso. Producción añade arranques en frío, apretones de manos TLS, reintentos, una larga cola de solicitudes lentas, vecinos ruidosos y el despliegue que reduce la capacidad a la mitad durante diez minutos. El estimador es deliberadamente conservador: tiempo medio de CPU, un techo de utilización, servidores completos, redundancia añadida. Trata la prueba de carga como el techo de lo posible y esta cifra como el suelo de lo que hay que aprovisionar; la verdad para planificar es el suelo.

¿Contra qué protege realmente N+1?

Contra un fallo: un host muerto, un mal despliegue retirado de la rotación, un evento de zona de disponibilidad que se lleva una única instancia. Con N+1, los N servidores restantes siguen cumpliendo el objetivo: ese es el sentido de dimensionar primero N desde el tráfico y añadir el repuesto después. 2N es una promesa distinta: dos copias completas, normalmente entre regiones, para los servicios que deben sobrevivir a perder una copia entera. Duplica la factura, así que se compra para los servicios cuya ausencia se mide en titulares.

¿Cómo obtengo mi tiempo de servicio de CPU por solicitud?

Mídelo, no lo adivines. En un servicio en funcionamiento: los segundos totales de CPU consumidos en una ventana, divididos entre las solicitudes servidas en la misma ventana. Las herramientas de monitorización del rendimiento de aplicaciones lo informan directamente como CPU por solicitud; en Linux puedes derivarlo del tiempo de CPU del proceso en /proc o de las métricas de tus contenedores. Usa la cifra de tu hora realista más ocupada, no la media de todo el día: la capacidad planificada desde promedios fracasa precisamente en el pico para el que se compró.