Planificación de capacidad y pruebas de rendimiento

La capacidad es un plan, no una esperanza

La planificación de capacidad responde de antemano a una pregunta: ¿tendremos suficiente de todo cuando la demanda alcance su pico? Todo abarca más que los servidores. Incluye las conexiones a la base de datos y el rendimiento de escritura, la memoria de la caché, las particiones del intermediario de mensajes, las cuotas de la cuenta en la nube, los límites de tasa de terceros, las licencias y las personas de guardia. La elasticidad de la nube permite añadir rápidamente parte de la capacidad, pero no toda: el nodo primario de una base de datos no se puede duplicar en segundos, un proveedor de pagos puede necesitar semanas de aviso para elevar un límite, y el autoescalado (tratado en la Sección 9.1) reacciona en minutos a un salto brusco que llega en segundos.

El método tiene cuatro pasos, que se repiten en un ciclo regular (trimestral para un crecimiento constante, por evento para los lanzamientos y las salidas a la venta):

Los cálculos de dimensionamiento con la ley de Little se trabajaron en la Sección 9.1; esta sección se centra en cómo obtener cifras fiables para introducir en ellos. El error más común en la planificación de capacidad no es una mala aritmética, sino una capacidad por instancia medida en condiciones poco realistas, y el segundo es olvidar una restricción compartida, como un límite de un tercero, que ningún margen de capacidad (headroom) en tus propios servidores puede resolver.

Tipos de prueba de rendimiento

Las pruebas de rendimiento son la única forma de medir la capacidad, encontrar los cuellos de botella antes que los clientes y verificar que un lanzamiento no ha empeorado las cosas. Las pruebas se diferencian en la forma de la carga que aplican y en la pregunta que responden. Una prueba de carga comprueba el pico esperado; una prueba de estrés va más allá para ver cómo falla el sistema; una prueba de resistencia (soak test) se ejecuta durante horas para sacar a la luz fugas lentas; una prueba de picos (spike test) comprueba la reacción ante saltos repentinos; una prueba de punto de ruptura aumenta la carga hasta que algo se rompe, para encontrar el límite real.

Modelos de carga abiertos y cerrados

Los generadores de carga simulan a los usuarios de una de dos formas, y elegir la equivocada produce resultados que no solo son inexactos, sino peligrosamente optimistas. En un modelo de carga cerrado, la herramienta ejecuta un número fijo de usuarios virtuales; cada uno envía una solicitud, espera la respuesta, hace una pausa durante un tiempo de reflexión y repite. Si el sistema se ralentiza, cada usuario virtual envía menos solicitudes, así que la carga baja por sí sola. En un modelo de carga abierto, las solicitudes llegan a un ritmo fijo, con independencia de lo rápido que se respondan las anteriores, como hacen los visitantes reales de un sitio web público: miles de fans que pulsan Comprar a las 10:00 no se esperan unos a otros.

Bianca Schroeder, Adam Wierman y Mor Harchol-Balter demostraron (Open Versus Closed: A Cautionary Tale, NSDI 2006) que los dos modelos pueden dar tiempos de respuesta muy distintos para el mismo sistema y la misma carga media, y que las decisiones de planificación o de capacidad ajustadas con uno pueden ser erróneas con el otro. Los sistemas internos con una población fija de clientes, como una aplicación de centro de llamadas con 300 agentes, son razonablemente cerrados. El tráfico público de internet, los consumidores dirigidos por eventos que se alimentan de una cola y las salidas a la venta son abiertos, o casi. Para esos sistemas, la prueba realista es la de modelo abierto; los ejecutores (executors) constant-arrival-rate y ramping-arrival-rate de k6, por ejemplo, lo implementan, mientras que su ejecutor constant-vus es cerrado.

Omisión coordinada (coordinated omission)

Gil Tene, de Azul Systems y autor de la biblioteca HdrHistogram, puso nombre a un error de medición que afecta a muchas pruebas de latencia y herramientas de monitorización: la omisión coordinada (coordinated omission). Un generador de carga en bucle cerrado espera cada respuesta antes de enviar la siguiente solicitud. Cuando el sistema se detiene, el generador se detiene con él, así que las solicitudes que los usuarios reales habrían enviado durante la parada, y que habrían sido todas lentas, nunca se envían ni se miden. La herramienta de prueba se coordina con el sistema que está probando y omite exactamente las muestras malas.

Imagina una prueba que pretende enviar una solicitud cada 10 ms durante 100 segundos contra un servicio que normalmente responde en 1 ms. A los 50 segundos, el servicio se congela durante 10 segundos (por ejemplo, una larga pausa de recolección de basura). La herramienta de prueba en bucle cerrado registra unas 9000 muestras rápidas y una muestra de 10 segundos, así que informa de un p99 de 1 ms e incluso de un p99.9 de 1 ms. Sin embargo, según el calendario previsto, durante la congelación habrían llegado unas 1000 solicitudes, que habrían esperado entre 10 segundos y 10 ms, unos 5 segundos de media. El diez por ciento de todas las solicitudes sufrió un retraso grave: el p95 real es de unos 5 segundos y el p99 real, de unos 9 segundos.

Las soluciones son usar generadores de modelo abierto (de tasa de llegada) para los sistemas abiertos, medir la latencia desde el momento en que se pretendía enviar la solicitud y no desde cuándo se envió realmente, registrar histogramas completos en lugar de medias y desconfiar de cualquier informe de latencia cuyo máximo esté muy por encima de su p99.9 con pocas muestras entre ambos. Para esto existen precisamente wrk2, la herramienta modificada de Tene para pruebas de rendimiento HTTP, y las opciones de corrección de HdrHistogram. El mismo error aparece en la monitorización de producción cuando una biblioteca cliente mide solo las solicitudes que consiguió enviar.

Herramientas

Cuatro herramientas de código abierto cubren la mayoría de las necesidades. Apache JMeter es la veterana: basada en Java, con un editor gráfico de planes de prueba, muchos plug-ins de protocolos y grupos de hilos (thread groups) que son cerrados por defecto. Gatling escribe las pruebas como código (Scala, Java y Kotlin, y más recientemente JavaScript y TypeScript), es eficiente con cargas altas y tiene perfiles de inyección abiertos y cerrados. k6, mantenida por Grafana Labs, ejecuta scripts de prueba en JavaScript sobre un motor escrito en Go, tiene ejecutores explícitos de modelo abierto y cerrado, y umbrales de aprobado o fallo adecuados para la integración continua. Locust describe el comportamiento de los usuarios en Python y distribuye la carga entre procesos trabajadores; sus usuarios son de bucle cerrado. Los servicios comerciales y alojados en la nube añaden generación de carga distribuida a gran escala e informes.

La herramienta importa menos que el escenario. Un buen script reproduce la combinación real de recorridos (según la analítica de producción: quizá un 70% de navegación, un 20% de cambios en el carrito y un 10% de proceso de pago), tiempos de reflexión realistas, datos realistas (usuarios, restaurantes y asientos distintos, no el mismo 10 000 veces) y el modelo de carga correcto, y comprueba que las respuestas sean correctas, porque una página de error rápida no es una solicitud con éxito.

import http from 'k6/http';
import { check } from 'k6';

export const options = {
  scenarios: {
    onsale: {
      executor: 'ramping-arrival-rate',   // open model: arrivals per second
      startRate: 100, timeUnit: '1s',
      preAllocatedVUs: 2000, maxVUs: 20000,
      stages: [
        { target: 4900, duration: '2m' },  // ramp to 1.5x design load
        { target: 4900, duration: '20m' }, // hold
      ],
    },
  },
  thresholds: {                            // fail the run if missed
    http_req_failed: ['rate<0.005'],
    http_req_duration: ['p(99)<500'],
  },
};

export default function () {
  const res = http.get('https://perf.tickets.example/api/events/42/seats');
  check(res, { 'status is 200': (r) => r.status === 200 });
}

Entornos y datos realistas

Una prueba de rendimiento solo es tan fiable como su entorno. Una base de datos de prueba con 10 000 filas cuyos índices caben en memoria no dice nada sobre producción, con 200 millones de filas cuyos índices no caben. La lista de comprobación siguiente detecta las diferencias habituales.

Tamaño y forma de los datos: volúmenes a escala de producción y distribuciones realistas, incluidas las claves calientes (hot keys), como los restaurantes más populares o los mejores asientos, que crean una contención que una prueba uniforme nunca ve. Los mismos bloques de construcción: los mismos tipos de instancia, límites de contenedor, configuración de la base de datos, tamaños de los grupos de conexiones y topología de red (incluidos los saltos entre zonas). Estado de la caché: prueba tanto con la caché caliente como en frío, porque un despliegue o un failover la vacían (Sección 7.6). Dependencias: servicios de terceros sustituidos por stubs que reproduzcan su distribución real de latencia y sus límites de tasa, no respuestas instantáneas. Aislamiento: ninguna prueba de otro equipo compartiendo el entorno, o los resultados son ruido. El propio generador: capacidad suficiente de generación de carga en las ubicaciones adecuadas; un generador que funciona al 100% de CPU se mide a sí mismo.

Algunas organizaciones prueban en producción, con cuidado, porque ninguna copia es nunca del todo igual: usuarios sintéticos y eventos de prueba que se excluyen de los informes de negocio, tráfico sombra (copiar solicitudes reales a una nueva versión y descartar sus respuestas) y subidas graduales con condiciones de cancelación automáticas. Esto necesita las mismas salvaguardas que los experimentos de caos: un radio de impacto pequeño, un interruptor de emergencia y una vigilancia estrecha de los SLO.

Presupuestos de rendimiento

Un presupuesto de rendimiento es un límite que un cambio no puede superar, acordado de antemano y comprobado automáticamente, para que el rendimiento no se erosione a base de pequeñas regresiones. Para los frontends web, los presupuestos abarcan el peso de la página, el tamaño de los scripts y las Core Web Vitals, cuyos umbrales de Google para una buena experiencia, medidos en el percentil 75 de las cargas de página, son un Largest Contentful Paint de 2.5 segundos o menos, un Interaction to Next Paint de 200 ms o menos y un Cumulative Layout Shift de 0.1 o menos.

Para los backends, un presupuesto de latencia reparte un SLO de extremo a extremo entre los saltos de un recorrido. El proceso de pago de la plataforma de reparto de comida tiene un objetivo de p99 de 800 ms; el equipo asigna 20 ms al gateway, 60 ms al servicio de pedidos, 80 ms a precios, 450 ms al pago (la mayor parte, el proveedor externo de tarjetas), 40 ms a la base de datos, 100 ms a la red y la serialización, y deja 50 ms de reserva. Ahora cada equipo conoce su propio objetivo, y un cambio que lleve precios a 150 ms se ve como un incumplimiento del presupuesto antes de convertirse en un incumplimiento del SLO. En sentido estricto, los percentiles de las partes no suman el percentil del todo, así que trata el reparto como una asignación de ingeniería y verifica por separado la cifra de extremo a extremo.

Los presupuestos se hacen cumplir ejecutando una prueba de rendimiento corta y estable en el pipeline de entrega y haciendo fallar la compilación cuando se cruza un umbral, como hacen los umbrales de k6 anteriores. Esto es una función de aptitud para el rendimiento. Las pruebas del pipeline tienen que ser más repetibles que realistas: el mismo entorno, los mismos datos, la misma carga, para que un cambio del 10% signifique una regresión real y no ruido.