Estrategias de escalado: vertical, horizontal y el cubo de escalado

Qué significa escalar en la práctica

La Sección 2.4 definió la escalabilidad como la capacidad de gestionar más carga añadiendo recursos, y mostró con la ley de Amdahl y la ley de escalabilidad universal por qué añadir recursos no siempre añade capacidad. Esta sección trata de las decisiones prácticas: qué recursos añadir, dónde, cuándo y con cuánta automatización. El punto de partida es siempre la misma pregunta: ¿cuál es el parámetro de carga y qué recurso se agota primero? La API de pedidos de una plataforma de reparto de comida a la hora del almuerzo está limitada por las solicitudes por segundo; su servicio de despacho, por el número de repartidores activos cuyas posiciones hay que emparejar cada pocos segundos; su base de datos, por las transacciones de escritura por segundo y por las conexiones. Cada uno necesita una respuesta distinta.

Escalar un sistema significa en realidad escalar su cuello de botella actual y después encontrar el siguiente. Duplicar la capa web de un sistema cuya base de datos está ocupada al 95% no aporta nada salvo una factura mayor y una base de datos a la que ahora se presiona más. Por eso toda decisión de escalado empieza por la medición: la utilización y la saturación de cada recurso (el método USE de Brendan Gregg, que se trata en Observabilidad) y una prueba de carga que encuentre dónde empieza a subir la latencia (Planificación de capacidad y pruebas de rendimiento).

Escalado vertical: una máquina más grande

El escalado vertical (scaling up) consiste en dar a la máquina existente más núcleos de CPU, más memoria, discos más rápidos o una red más rápida. Su gran virtud es que no cambia nada en el software. Una única base de datos relacional en un servidor más grande conserva sus transacciones, sus joins y su consistencia sencilla; una aplicación conserva sus cachés en memoria y sus archivos locales. En la nube, redimensionar es una llamada a una API seguida de un reinicio. Las mayores máquinas virtuales en la nube ofrecen hoy cientos de CPU virtuales y terabytes de memoria, mucho más de lo que la mayoría de los sistemas de negocio necesitarán jamás, y algunos sitios web con muchísimo tráfico han explicado públicamente que atienden un tráfico enorme con un pequeño número de potentes servidores de bases de datos.

Los límites, sin embargo, son reales. Existe una máquina más grande que todas, y el precio por unidad de capacidad sube de forma pronunciada cerca de lo más alto de la gama. Una máquina es un dominio de fallo: cuando falla, o se reinicia para redimensionarla o aplicarle parches, todo lo que hay en ella se detiene, así que escalar verticalmente por sí solo no hace nada por la disponibilidad. A menudo el software no puede aprovechar del todo una máquina más grande: un proceso de un solo hilo, un bloqueo global o una fila caliente de la base de datos limitan la aceleración exactamente como predice la ley de Amdahl. Y la capacidad llega en escalones grandes y lentos, así que pagas el pico a todas horas. Aun así, el escalado vertical es el primer paso correcto con mucha más frecuencia de lo que sugiere la moda, sobre todo en las bases de datos, donde escalar horizontalmente es caro en esfuerzo de diseño.

Escalado horizontal: más máquinas

El escalado horizontal (scaling out) consiste en ejecutar más instancias y repartir el trabajo entre ellas, normalmente con un balanceador de carga delante. Escala mucho más lejos, en escalones pequeños y baratos, y la misma redundancia que añade capacidad también tolera los fallos: con ocho instancias, perder una cuesta un octavo de la capacidad y no toda. Las plataformas en la nube convierten añadir una instancia en cuestión de segundos o minutos, y esa es la base del autoescalado.

El precio es que el software debe estar diseñado para ello. Cualquier instancia debe poder gestionar cualquier solicitud, lo que significa que las instancias no deben guardar nada de lo que dependa una solicitud posterior (la siguiente sección). El trabajo debe ser divisible: una tarea que necesita un bloqueo global no se ejecuta más deprisa en diez máquinas. Los datos deben ser accesibles desde todas las instancias, lo que traslada la presión a la capa de datos compartida. Y el sistema pasa a ser distribuido, con los fallos parciales, los timeouts y los reintentos que describe la Sección 6.1. La mayoría de los sistemas reales combinan ambos: las capas de aplicación sin estado escalan horizontalmente, mientras que las bases de datos escalan verticalmente mientras pueden hacerlo de forma razonable y después escalan horizontalmente con réplicas y particiones.

El cubo de escalado: tres formas distintas de escalar horizontalmente

Martin Abbott y Michael Fisher, que dirigieron la tecnología en eBay y PayPal, describen el escalado horizontal con el cubo de escalado en The Art of Scalability (primera edición de 2009, segunda edición de 2015). Separa tres formas independientes de dividir un sistema, cada una dibujada como un eje de un cubo cuyo origen es una única instancia que lo hace todo.

El eje X es la duplicación horizontal, o clonación: ejecutar N copias idénticas de toda la aplicación o servicio y repartir las solicitudes entre ellas. Es el eje más sencillo y barato, y funciona bien para la gestión de solicitudes sin estado y para el tráfico de lectura. No hace nada por el tamaño de los datos ni por el volumen de escritura, porque todos los clones siguen hablando con los mismos datos, y tampoco hace nada por el tamaño del código base ni por el número de equipos que trabajan en él.

El eje Y divide el sistema por función: servicios distintos para las cartas, los pedidos, el despacho y los pagos, cada uno de los cuales ejecuta solo el código y los datos de su capacidad. Así, cada servicio puede escalar, fallar y desplegarse por separado, y cada uno es más pequeño y más fácil de entender. Este es el eje que hay detrás de los microservicios (Sección 6.3), con todos sus costos. El eje Z divide por datos: todas las copias ejecutan el mismo código, pero cada una es responsable solo de una parte de los clientes, inquilinos (tenants), regiones o registros, elegida mediante una clave como la ciudad o el identificador del cliente. El sharding de bases de datos es el eje Z aplicado al almacenamiento (Sección 7.4); una arquitectura basada en células lo aplica a pilas completas, de modo que un defecto o un despliegue erróneo en una célula afecta solo a los clientes de esa célula.

Los ejes se combinan. El servicio de pedidos de la plataforma (una división en el eje Y) se ejecuta como muchos clones (X) en cada célula regional (Z). El consejo práctico de Abbott y Fisher es usar el eje más barato que resuelva el problema real: X para el volumen de solicitudes, Y cuando partes del sistema tienen necesidades de escalado, de fallo o de equipo realmente distintas, y Z cuando un conjunto de datos o un radio de impacto se ha vuelto demasiado grande. Elegir Z porque suena impresionante trae el enrutamiento, el reequilibrado y las consultas entre particiones mucho antes de que hagan falta.

La ausencia de estado: la condición previa para clonar

El escalado en el eje X solo funciona si cualquier clon puede atender cualquier solicitud. Un servicio sin estado no guarda nada entre solicitudes en su propia memoria ni en su propio disco; todo lo que necesita una solicitud posterior vive en un almacén compartido o viaja con la solicitud. El estado que suele esconderse en una instancia es fácil de enumerar en cuanto lo buscas: sesiones de usuario guardadas en memoria, archivos subidos escritos en el disco local, cachés en memoria que se tratan como fuente de verdad, tareas programadas que deben ejecutarse exactamente en una máquina, bloqueos dentro del proceso que protegen un recurso compartido y contadores para los límites de tasa.

Cada uno tiene un remedio estándar: las sesiones pasan a un almacén compartido o a un token firmado (Sección 9.2); los archivos pasan al almacenamiento de objetos; las cachés se convierten en una optimización de rendimiento que puede perderse en cualquier momento, o pasan a una caché compartida (Sección 7.6); las tareas programadas usan un planificador con elección de líder o una cola; los bloqueos pasan a la base de datos o a un servicio de coordinación; los contadores de límite de tasa pasan a un almacén compartido. La regla de la aplicación de doce factores según la cual los procesos son sin estado y no comparten nada (Sección 10.3) es esta misma idea. La ausencia de estado es barata de incorporar en el diseño y cara de añadir después, porque el estado se filtra en el código en muchos sitios pequeños.

Autoescalado: reactivo, programado y predictivo

El autoescalado cierra un bucle de retroalimentación: mide la carga, la compara con un objetivo y cambia el número de instancias. El autoescalado reactivo lo hace de forma continua a partir de una métrica. El seguimiento de objetivo (target tracking) es la forma habitual: mantener la CPU media al 60%, o las solicitudes en curso por instancia en 30. El Horizontal Pod Autoscaler de Kubernetes calcula desired = ceil(current replicas × current metric ÷ target): seis pods con una media de 45 solicitudes en curso frente a un objetivo de 30 pasan a ser ceil(6 × 45 ÷ 30) = 9. De forma predeterminada, vuelve a evaluar cada 15 segundos e ignora las desviaciones de hasta el 10% respecto al objetivo.

El autoescalado programado cambia la capacidad en momentos conocidos: subir el mínimo a 18 instancias a las 11:15 todos los días laborables antes del pico del almuerzo y bajarlo a las 14:00. Es rudimentario y muy eficaz para patrones predecibles, y es la única manera de tener la capacidad lista antes de un cambio brusco, como una puesta a la venta de entradas a las 10:00 en punto. El autoescalado predictivo, que ofrecen los principales proveedores de nube, prevé la carga a partir del historial (ciclos diarios y semanales) y escala por delante de ella, con el escalado reactivo como red de seguridad para las sorpresas.

La propiedad crucial de cualquier esquema reactivo es el retraso. Las métricas se recogen y se promedian durante decenas de segundos; el autoescalador actúa en su siguiente evaluación; una máquina virtual nueva tarda un minuto o más en arrancar, hay que descargar una imagen de contenedor, y un servicio JVM o Python debe iniciarse, calentar sus cachés y sus pools de conexiones y superar su comprobación de preparación antes de que el balanceador de carga le envíe tráfico. En un clúster, puede que primero haya que añadir los propios nodos mediante un segundo autoescalador, más lento. Desde el momento en que sube la carga hasta que la nueva capacidad es útil suelen pasar de dos a diez minutos. Por tanto, el autoescalado reactivo gestiona los cambios graduales; los cambios repentinos deben absorberse con margen de capacidad (headroom), con colas (Sección 9.3) o con capacidad programada de antemano.

Qué métrica usar para escalar, y por qué la CPU suele ser un error

La utilización de la CPU es la señal predeterminada en la mayoría de las plataformas porque siempre está disponible. Solo es la señal correcta cuando el servicio está limitado por la CPU: redimensionado de imágenes, cifrado, serialización intensiva. La mayoría de los servicios de negocio no lo están. Una API de pedidos pasa la mayor parte de cada solicitud esperando a la base de datos, al proveedor de pagos y a otros servicios; su CPU puede estar al 25% mientras todos los hilos de trabajo están ocupados esperando y las solicitudes nuevas se encolan. Escalar según la CPU no hace entonces nada hasta que es demasiado tarde. También ocurre el fallo contrario: una tormenta de recolección de basura o el calentamiento del JIT elevan la CPU sin que aumente la carga, y el autoescalador añade instancias que no hacen falta.

Una señal mejor es la que está directamente ligada al recurso que se agota. En los servicios de solicitud-respuesta, suele ser la concurrencia: el número de solicitudes en curso por instancia, comparado con el número de hilos de trabajo o de conexiones de que dispone. La ley de Little hace exacta la relación (en curso = tasa de llegada × tiempo de respuesta), y reacciona tanto a más tráfico como a respuestas más lentas. En los trabajadores de colas, es el trabajo acumulado por trabajador o la antigüedad del mensaje más antiguo, que expresa cuánto tardará la cola en vaciarse. La latencia es tentadora, pero peligrosa como señal de escalado: sube por razones que más instancias no pueden arreglar, como una base de datos lenta, y escalar horizontalmente un servicio cuya dependencia está en apuros envía a esa dependencia todavía más carga. Usa la latencia para las alertas y escala según una medida del trabajo.

Cooldowns, estabilización y flapping

Un autoescalador que reacciona a cada vaivén oscila (flapping): añade instancias cuando llega una ráfaga, las quita un minuto después cuando la ráfaga pasa y luego las vuelve a añadir, pagando cada vez el costo de arranque y alterando las cachés y los pools de conexiones. También puede perseguir su propia cola: las instancias nuevas están frías y son lentas, así que la latencia o la CPU por solicitud suben brevemente después de escalar horizontalmente, lo que parece más carga.

Las defensas habituales son asimétricas. Escala hacia fuera deprisa, porque la falta de capacidad perjudica a los usuarios; escala hacia dentro despacio, porque el exceso de capacidad solo cuesta dinero. Un cooldown o ventana de estabilización hace que el autoescalador espere después de una acción, o que tome la recomendación más alta de una ventana reciente antes de reducir: el autoescalador de Kubernetes usa de forma predeterminada una ventana de cinco minutos (300 segundos) para reducir y ninguna para ampliar. Una banda de tolerancia ignora las desviaciones pequeñas. Los recuentos mínimo y máximo de instancias acotan el bucle: el mínimo mantiene capacidad suficiente para sobrevivir a la pérdida de una zona y a los primeros minutos de una avalancha, y el máximo protege la base de datos, los servicios aguas abajo y el presupuesto frente a un autoescalador que confunde un problema con carga. La reducción también debe ser elegante: una instancia elegida para retirarse debe dejar de recibir solicitudes nuevas y terminar las que tiene en curso (drenaje de conexiones, Sección 9.2).

Escalar la capa de datos

Las capas de aplicación sin estado son fáciles de escalar; para eso se hacen sin estado. La presión recae entonces sobre las bases de datos, las cachés y los intermediarios que comparten, y por eso la capa de datos suele ser el verdadero límite de un sistema. Las herramientas se trataron en el Capítulo 7 y aquí se resumen en el orden en que los profesionales suelen recurrir a ellas. Primero, reduce el trabajo: índices, mejores consultas, menos idas y vueltas por solicitud. Segundo, absorbe las lecturas con la caché (Sección 7.6) y las réplicas de lectura, aceptando el retardo de replicación cuando el caso de uso lo permita. Tercero, protege las conexiones: cada instancia de la aplicación tiene un pool, así que el total crece con la flota, y un pooler de conexiones como PgBouncer permite que miles de conexiones de clientes compartan unos pocos cientos de conexiones a la base de datos (el max_connections predeterminado de PostgreSQL es de solo 100). Cuarto, escala verticalmente la base de datos principal, lo que a menudo es más barato que cualquier rediseño. Solo entonces particiona las escrituras en el eje Z según una clave como la ciudad o el cliente (Sección 7.4), o pasa a una base de datos SQL distribuida.

Hay dos advertencias. Primera, autoescalar la capa de aplicación puede perjudicar a la capa de datos: cada instancia nueva abre conexiones y calienta su caché desde la base de datos, así que un gran escalado horizontal puede sobrecargar por sí mismo la base de datos. Segunda, algunos límites son lógicos, no físicos: una sola fila caliente (el recuento de existencias de las últimas 500 entradas de un concierto, o un número de secuencia global) serializa las escrituras por grande que sea el servidor. Esos límites se eliminan con el diseño, por ejemplo dividiendo las existencias en varios contadores o reservando asientos por lotes, no con hardware.