Rendimiento, escalabilidad, resiliencia y operabilidad

Te damos la bienvenida al Capítulo 9: Rendimiento, escalabilidad, resiliencia y operabilidad. Un diseño que cumple sus objetivos en un diagrama puede venirse abajo a las doce y media de un viernes, cuando todas las oficinas de la ciudad piden el almuerzo. La diferencia rara vez es un código ingenioso. Es un conjunto de decisiones arquitectónicas sobre cómo se añade capacidad, cómo se reparte la carga, cómo espera el trabajo, cómo se contienen los fallos y cómo saben las personas que operan el sistema qué está haciendo.

Este capítulo está pensado para desarrolladores y arquitectos que conocen los estilos distribuidos del Capítulo 6 y que deben mantener un sistema rápido y en funcionamiento bajo carga real. Se basa en el Capítulo 2, que hizo precisos el rendimiento y la disponibilidad como escenarios de atributos de calidad que se pueden probar. Aquí aprendes a lograr esos escenarios en un sistema en ejecución y a mantenerlos ciertos el día de más actividad del año. Remite al Capítulo 7 para la replicación, el particionamiento y la caché, en lugar de repetirlos. Y lleva al Capítulo 10, sobre las plataformas en la nube, las funcionalidades de Kubernetes y los diseños multirregión sobre los que suelen ejecutarse estos sistemas.

Dos ejemplos recurrentes recorren el capítulo. Una plataforma de reparto de comida, con picos muy marcados a la hora del almuerzo y por la noche. Y una puesta a la venta de entradas, en la que la demanda pasa de casi nada a muchas veces la capacidad del sistema en cuestión de segundos. La sección nueve punto uno compara el escalado vertical con el horizontal, usa el cubo de escalado para separar la clonación, la división por función y la división por datos, y explica por qué el autoescalado basado en la CPU suele ser la elección equivocada. La sección nueve punto dos trata de lo que se sitúa delante de las instancias: los balanceadores de carga, los algoritmos que usan, las comprobaciones de estado, el drenaje de conexiones y por qué las sesiones persistentes deben dar paso a un estado de sesión guardado fuera de la instancia. La sección nueve punto tres trata de lo que ocurre cuando el trabajo llega más deprisa de lo que se puede hacer: colas acotadas, back pressure, descarte de carga y limitación de tasa, que deciden qué se acepta, qué espera y qué se rechaza educadamente. La sección nueve punto cuatro se ocupa del fallo entre servicios: timeouts y plazos, reintentos con backoff y jitter, circuit breakers, bulkheads y alternativas.

El ejemplo práctico de la sección nueve punto cuatro muestra cómo la falta de un solo timeout permite que una única dependencia lenta tumbe todo lo que la llama. El proveedor de pagos responde normalmente en cero punto tres segundos. Hoy ha dejado de responder. El servicio de pedidos lo llama sin timeout, así que, uno a uno, sus doscientos hilos acaban esperando llamadas de pago. Ahora falla el proceso de pago. Pero también fallan el historial de pedidos y el seguimiento, que nunca tocan los pagos, porque no quedan hilos libres para atenderlos. La base de datos está perfectamente sana, pero no hay ningún hilo libre para llamarla. Los timeouts, los circuit breakers y los bulkheads son los patrones que detienen este tipo de cascada.

La segunda mitad pasa de los mecanismos a la operación. La sección nueve punto cinco muestra cómo expresar la fiabilidad desde el punto de vista del usuario y cómo un presupuesto de errores convierte un objetivo de disponibilidad en una cantidad de fallo permitido que los equipos pueden gastar en cambios. La sección nueve punto seis trata de los logs, las métricas y las trazas que permiten a los ingenieros hacer preguntas nuevas a un sistema en producción, y del trazado distribuido con OpenTelemetry. La sección nueve punto siete cierra el círculo entre las previsiones y la evidencia, con pruebas de carga, de estrés, de resistencia, de picos y de punto de ruptura, y un plan de capacidad para una puesta a la venta de entradas. Y la sección nueve punto ocho se ocupa de los fallos que ocurren de todos modos: experimentos deliberados para encontrar las debilidades antes que los clientes, roles claros durante los incidentes y revisiones sin culpas que cambian el sistema y no a las personas.

Este diagrama de la sección nueve punto cinco sitúa tres términos en una misma escala, usando la disponibilidad del proceso de pago durante veintiocho días móviles. El objetivo de nivel de servicio, o SLO, es la meta interna: aquí, el noventa y nueve punto nueve por ciento. El acuerdo de nivel de servicio, o SLA, es un contrato con los socios, fijado de forma menos exigente, en el noventa y nueve punto cinco por ciento. El indicador de nivel de servicio, o SLI, es la medición. Este mes es del noventa y nueve punto nueve cuatro por ciento, dentro de la zona en la que el servicio está dentro de su presupuesto. Por debajo del SLO, el objetivo no se cumple, y una política escrita de presupuesto de errores dice qué ocurre a continuación. Solo por debajo del SLA se deben créditos de servicio. El hueco entre el SLO y el SLA es la zona de aviso. El presupuesto de errores es simplemente uno menos el SLO. En treinta días, un objetivo del noventa y nueve punto nueve por ciento permite cuarenta y tres punto dos minutos de caída total, o que falle una solicitud de cada mil.

Las secciones forman una cadena y llevan a una sola idea. Todo recurso es finito, así que todo sistema tiene un punto de ruptura. El trabajo del arquitecto es decidir de antemano qué ocurre cuando se alcanza. Un sistema bien diseñado sometido a una carga excesiva se ralentiza de forma elegante y descarta primero el trabajo menos importante. Rechaza con claridad, en lugar de agotar el tiempo en silencio. Aísla la parte que falla. Y se recupera por sí solo cuando pasa la presión. Uno mal diseñado encola sin límite, reintenta hasta derrumbarse y arrastra consigo a sus vecinos. Estos mecanismos son baratos de añadir en la fase de diseño y caros de incorporar después. Si un servicio es sin estado, si una cola está acotada y si una solicitud lleva un plazo se decide mucho antes del primer incidente.

Al final del capítulo, sabrás elegir cómo escalar y dimensionar una flota para un pico conocido con la ley de Little y un margen de capacidad. Sabrás combinar timeouts, plazos, reintentos con backoff y jitter, circuit breakers, bulkheads y alternativas para contener los fallos. Sabrás definir indicadores y objetivos de nivel de servicio desde el punto de vista del usuario, calcular presupuestos de errores y diseñar alertas según la rapidez con que se gastan. Y sabrás planificar pruebas de capacidad y de rendimiento, ejecutar experimentos de caos de forma segura y dirigir revisiones posteriores a incidentes sin culpas.

Como las secciones forman una cadena, lo mejor es leerlas en orden. Pero cada una se sostiene también por sí sola, así que puedes ir directamente a la sección que necesites. Calcula unas tres horas y media para leer todo el capítulo. Al final de cada sección hay preguntas de autoevaluación. Respóndelas mentalmente antes de mirar las respuestas. Cuando estés listo, hay una prueba opcional del capítulo, que lleva unos cuarenta y cinco minutos. Tiene veinte preguntas de opción múltiple y dos respuestas escritas. La nota de aprobado es el ochenta por ciento.

Esa es la estructura del capítulo. Empieza por la sección nueve punto uno, sobre el escalado vertical, el escalado horizontal y el cubo de escalado. Nos vemos allí.