En las dos lecciones anteriores hemos visto qué es un sistema distribuido y qué modelos nos permiten describirlo. Ahora toca responder a la pregunta que cualquier arquitecto de Kilómetro Cero se haría tras la caída de la Semana de la Vendimia: ¿merece la pena distribuir? La respuesta honesta es "depende", y esta lección da las herramientas para que ese "depende" sea un cálculo y no una corazonada.

Vamos a cuantificar las ventajas (cuánta capacidad ganamos al añadir máquinas, cuántos minutos de caída al año supone cada "nueve" de disponibilidad, cuánto acelera realmente el paralelismo) y a poner nombre a los desafíos (complejidad, heterogeneidad, consistencia, fallos parciales, latencia, seguridad, observabilidad y coste). Terminaremos con una tabla de situaciones en las que no conviene distribuir, porque saber cuándo no hacerlo es tan importante como saber cómo hacerlo.

1. Ventajas de distribuir
2. Escalabilidad: vertical frente a horizontal
3. Tolerancia a fallos y disponibilidad: los "nueves"
4. Flexibilidad, localidad y compartición de recursos
5. La ley de Amdahl: el límite del escalado
6. Desafíos de distribuir
7. Cuándo NO distribuir
8. Ejemplo de código: disponibilidad combinada en Kilómetro Cero
9. Errores comunes y consejos
10. Ejercicios
11. Conclusión

Las ventajas de un sistema distribuido son la otra cara de los motivos por los que existen (lección 01-01). Las agrupamos en cinco, y las tres primeras las cuantificaremos:

Escalar es aumentar la capacidad de un sistema para atender más carga. Hay dos caminos:

• Escalado vertical (scale up): sustituir la máquina por una más potente (más CPU, más memoria, discos más rápidos).
• Escalado horizontal (scale out): añadir más máquinas y repartir la carga entre ellas.

Recordemos los datos del incidente (lección 01-01): el servidor único empezó a degradarse a unos 380 peticiones/s y cayó por encima de 700 peticiones/s. Marketing prevé que la próxima campaña, la "Semana del Queso Artesano", con Quesería Montblanc como protagonista, alcance un pico de 1.200 peticiones/s.

Hagamos las cuentas para las dos opciones:

Opción vertical. Necesitamos una máquina que aguante 1.200 pet/s con un margen de seguridad del 30 %: 1.560 pet/s, es decir, unas 4 veces la capacidad actual (380 pet/s "cómodas"). Un servidor cuatro veces más potente que el actual (32 vCPU, 128 GB) no cuesta 4 veces más, sino típicamente 5-6 veces más, y seguirá siendo un único punto de fallo. Además, no está claro que la aplicación aproveche linealmente los núcleos adicionales (apartado 5).

Opción horizontal. Medimos que una instancia de la aplicación Python, en una máquina modesta (4 vCPU, 16 GB), atiende cómodamente 200 pet/s. Entonces:

Nueve máquinas pequeñas durante la semana de campaña y, el resto del año, dos o tres. Esta elasticidad es imposible con el escalado vertical.

Pero atención: el cálculo asume que la capa de aplicación es el cuello de botella. En el incidente real, PostgreSQL agotó sus conexiones a 610 pet/s. Si ponemos 9 instancias de aplicación delante de la misma base de datos, simplemente la ahogaremos antes. El escalado horizontal de la aplicación obliga a escalar también los datos (caché, réplicas de lectura, particionado), que es materia del Módulo 4. La lección: el escalado horizontal no es una propiedad de "el sistema", sino de cada componente, y el sistema escala tanto como su componente menos escalable.

La disponibilidad de un sistema es la fracción del tiempo en que funciona correctamente. Se expresa como porcentaje y, coloquialmente, por su número de nueves. Es fundamental traducir cada nivel a tiempo de caída para entender qué significa realmente:

El cálculo es directo: un año tiene 365 × 24 × 60 = 525.600 minutos; el 0,1 % de esa cifra son 525,6 minutos (8 h 46 min); el 0,01 %, 52,56 minutos.

Dos observaciones importantes:

1. Cada nueve adicional multiplica el coste. Pasar de 99,9 % a 99,99 % no es "un poco mejor": significa que en todo el año solo puedes permitirte 52 minutos de caída, incluyendo despliegues, actualizaciones del sistema operativo, fallos de hardware y errores humanos. Exige redundancia en todos los niveles, despliegues sin parada y guardias 24×7.
2. La disponibilidad se combina. Si una petición de Ana para comprar un queso atraviesa cuatro componentes en serie (web, pedidos, inventario, pagos), y cada uno tiene un 99,9 %, la disponibilidad de la compra no es 99,9 %, sino aproximadamente 99,6 %: las indisponibilidades se suman. Por el contrario, si un componente tiene dos réplicas independientes al 99,9 % y basta con que una funcione, la disponibilidad combinada sube al 99,9999 %. El ejemplo de código del apartado 8 hace estos cálculos.

Con el monolito, Kilómetro Cero tenía una disponibilidad real del 99,3 % el último año (unas 61 horas de caída, entre la Semana de la Vendimia, actualizaciones y un fallo de disco). El objetivo tras la reestructuración es alcanzar el 99,9 % en la compra y el 99,95 % en la consulta del catálogo.

Cuando cada servicio es una unidad de despliegue independiente, los equipos pueden trabajar sin pisarse. En Kilómetro Cero, el equipo de reparto necesita desplegar varias veces al día para ajustar el algoritmo de rutas, mientras que el de pagos, sujeto a auditorías, prefiere despliegues quincenales muy controlados. En el monolito, ambos ritmos son incompatibles: cada despliegue es de todo. Distribuir permite que cada servicio tenga su ritmo, su tecnología (Python para casi todo, quizá otro lenguaje para el procesamiento de posiciones en tiempo real) y su equipo responsable.

La velocidad de la luz en fibra óptica es de unos 200.000 km/s. Un viaje de ida y vuelta entre Barcelona y un centro de datos en Fráncfort (unos 1.100 km) tarda, como mínimo, 11 ms; con los saltos de enrutamiento reales, 25-35 ms. Entre Barcelona y Virginia (EE. UU.), unos 90-110 ms. Si cargar una página del catálogo requiere 10 peticiones secuenciales, la diferencia entre servir desde cerca y desde lejos es de más de un segundo. Por eso los sistemas grandes replican datos y servicios en varias regiones, y usan CDN para el contenido estático (las fotos de los productos, en el caso de Kilómetro Cero). Servir a cada ciudad desde un nodo cercano es una ventaja que un sistema centralizado no puede ofrecer.

Un sistema distribuido permite que muchos usuarios y servicios compartan recursos costosos: una base de datos, un clúster de procesamiento analítico, un almacén de fotos. El servicio analitica de Kilómetro Cero necesitará, unas horas al día, una capacidad de cálculo enorme para procesar las ventas; el resto del día, esa capacidad puede dedicarse a otras cosas. Compartir es más eficiente que dedicar.

Es tentador pensar que con el doble de máquinas se obtiene el doble de rendimiento. Casi nunca es así, y la razón la formuló Gene Amdahl en 1967: toda tarea tiene una parte que no se puede paralelizar, y esa parte limita la aceleración máxima.

Si una fracción p del trabajo es paralelizable (y por tanto 1 − p es secuencial), la aceleración S al usar n máquinas es:

Y cuando n tiende a infinito:

Apliquémoslo a Kilómetro Cero. Supongamos que, al procesar un pedido, el 90 % del trabajo (validar, calcular precios, generar la confirmación, renderizar) es paralelizable entre instancias, pero el 10 % (la escritura en la única base de datos PostgreSQL, que serializa las transacciones sobre el stock) es inherentemente secuencial. Entonces:

Con 8 máquinas conseguimos menos de 5 veces la capacidad, y nunca superaremos 10 veces por muchas máquinas que añadamos, mientras ese 10 % siga siendo secuencial. Esto conecta con el apartado 2: las 9 instancias de aplicación no darán 9 × 200 = 1.800 pet/s si la base de datos es el componente secuencial. La única forma de romper el techo es reducir la fracción secuencial: cachear las lecturas del catálogo (04-05), particionar los datos (04-01), o convertir en asíncronas las operaciones que no necesitan ser inmediatas (02-04). Buena parte de la arquitectura distribuida consiste, en el fondo, en atacar el (1 − p) de Amdahl.

Cada ventaja tiene su factura. Estos son los ocho desafíos que aparecerán, uno por uno, en el resto del curso:

Merece la pena detenerse en el de consistencia, porque es el más contraintuitivo. En el monolito, la transacción de PostgreSQL garantiza que si Ana compra la última unidad, Marc verá stock cero. Con pedidos e inventario separados, y quizá con inventario replicado en varias ciudades, esa garantía desaparece por defecto y hay que reconstruirla con técnicas específicas (consenso, transacciones distribuidas, sagas) que tienen su coste en latencia y complejidad. El Módulo 3 se dedica por entero a este problema; aquí basta con saber que existe y que no tiene solución gratuita.

Un buen arquitecto sabe decir "no". Estas son situaciones en las que distribuir es, casi con seguridad, un error:

Kilómetro Cero, tras la Semana de la Vendimia, cumple los criterios para distribuir: la carga ya no cabe en una máquina, hay varios equipos, los dominios (catálogo, pedidos, reparto...) tienen límites naturales y la disponibilidad del 99,3 % es inaceptable para el negocio. Pero conviene observar que no todos los componentes tienen que distribuirse de la misma forma ni al mismo tiempo: la lección 01-06 propone un camino gradual.

Vamos a escribir un pequeño simulador que calcula la disponibilidad de un flujo de negocio a partir de la disponibilidad de los componentes que atraviesa. Las dos reglas son:

• Componentes en serie (la operación necesita que todos funcionen): la disponibilidad combinada es el producto de las disponibilidades. Si A tiene 0,999 y B tiene 0,999, A y B juntos tienen 0,999 × 0,999 = 0,998.
• Componentes en paralelo (basta con que uno funcione, por ejemplo, réplicas): la indisponibilidad combinada es el producto de las indisponibilidades. Si A y A' tienen 0,999 cada uno, la probabilidad de que fallen los dos a la vez es 0,001 × 0,001 = 0,000001, así que la disponibilidad es 1 − 0,000001 = 0,999999.

La segunda regla asume que los fallos son independientes, cosa que en la realidad no siempre es cierta (si las dos réplicas comparten alimentación o red, fallan a la vez). Lo comentaremos tras el código.

La salida es la siguiente:

Analicemos el programa y sus resultados:

1. Componente guarda un nombre y una disponibilidad entre 0 y 1; caida_anual_min la traduce a minutos de caída al año, que es la magnitud que entiende el negocio.
2. en_serie multiplica disponibilidades. Observa el escenario 1: ningún componente individual baja del 99,5 %, pero la compra completa queda en el 99,2 %, casi 70 horas al año. Cuantos más componentes atraviese una operación, peor. Este es el coste oculto de "descomponer en servicios": cada frontera de red que se añade a un flujo síncrono resta disponibilidad.
3. en_paralelo y replicar aplican la regla de la redundancia. El escenario 2 muestra el efecto: replicar los cuatro servicios lleva la compra del 99,2 % al 99,95 %, y ahora el componente que domina es el que no se ha replicado, PostgreSQL (4 h 23 min de las 4 h 37 min totales).
4. El escenario 3 replica también la base de datos y alcanza el 99,997 %. Pero cuidado: replicar una base de datos no es tan simple como replicar un servicio sin estado. Hay que mantener las copias coherentes, y eso es todo el Módulo 3. El número es una cota superior optimista.
5. El último bloque responde a una pregunta muy práctica: pagos, que depende de una pasarela externa con solo el 99,5 %, pasa al 99,9975 % con dos réplicas. Eso, sin embargo, solo es cierto si las dos réplicas fallan de forma independiente. Si ambas dependen de la misma pasarela externa y es esta la que cae, las dos caen a la vez y la réplica no sirve de nada. El modelo de este script no captura fallos correlacionados; en la realidad, siempre hay que preguntarse qué comparten las réplicas (red, alimentación, proveedor, versión de software con el mismo error).

• Sumar disponibilidades en lugar de multiplicarlas. "Cada servicio tiene 99,9 %, así que el sistema tiene 99,9 %" es falso. Con cinco componentes en serie al 99,9 %, el sistema tiene 99,5 %. Cada salto de red en un flujo síncrono es un factor multiplicador menor que uno.
• Creer que las réplicas fallan de forma independiente. Dos réplicas en el mismo rack, con la misma versión de software y la misma dependencia externa, tienen fallos muy correlacionados. La redundancia real exige diversidad (zonas distintas, despliegues escalonados).
• Escalar el componente equivocado. Añadir instancias de aplicación cuando el cuello de botella es la base de datos no sirve de nada (Amdahl). Hay que medir antes de escalar.
• Confundir "más rápido" con "más escalable". Un sistema distribuido suele ser más lento para una única petición (latencia de red) y más capaz para muchas peticiones (rendimiento total). Si lo que importa es la latencia de una operación aislada, la distribución puede empeorarla.
• Perseguir nueves sin que el negocio los necesite. Cada nueve cuesta aproximadamente un orden de magnitud más. Pregunta siempre cuánto cuesta cada hora de caída para el negocio y compara con lo que cuesta evitarla.
• Consejo: documenta la disponibilidad objetivo de cada operación de negocio (no de cada servicio) y calcula, con la regla de la serie, qué disponibilidad exige eso a cada componente. Así se descubren rápidamente los componentes que necesitan redundancia.

El equipo de Kilómetro Cero mide que una instancia del servicio catalogo atiende 350 consultas/s con un 60 % de CPU, y que a partir del 80 % de CPU la latencia se dispara. Para la Semana del Queso Artesano se prevén 2.100 consultas/s al catálogo.

1. ¿Cuántas consultas/s puede atender una instancia sin superar el 80 % de CPU (suponiendo relación lineal entre consultas y CPU)?
2. ¿Cuántas instancias hacen falta para el pico, con redundancia N+1?
3. Si la mitad de las consultas pudieran resolverse desde una caché en memoria sin llegar al servicio, ¿cuántas instancias harían falta?

El negocio decide que la operación "consultar el estado de mi pedido" debe tener un 99,95 % de disponibilidad. La operación atraviesa, en serie: la puerta de enlace (99,99 %), el servicio pedidos (X) y su base de datos (99,98 %).

1. ¿Cuántos minutos de caída al año permite el objetivo del 99,95 %?
2. ¿Qué disponibilidad mínima X necesita pedidos para que la operación cumpla el objetivo?
3. Si una instancia de pedidos solo consigue el 99,9 %, ¿bastan dos réplicas independientes?

El servicio analitica procesa las ventas del día en un trabajo que tarda 60 minutos en una máquina. Un análisis muestra que 6 minutos corresponden a leer y consolidar el resultado final en un único fichero (secuencial) y los 54 restantes a cálculos por ciudad (paralelizables).

1. Calcula la aceleración con 6 máquinas y con 18 máquinas.
2. ¿Cuál es el tiempo mínimo posible por muchas máquinas que se añadan?
3. Modifica el script del apartado 8 (o escribe uno nuevo) con una función amdahl(p, n) y úsala para imprimir una tabla de aceleraciones para n = 1, 2, 4, 8, 16, 32.

Solución 1:

1. Si 350 consultas/s consumen el 60 % de CPU, el 80 % corresponde a 350 × (80 / 60) ≈ 467 consultas/s por instancia.
2. 2.100 / 467 = 4,5 → se necesitan 5 instancias para el pico, 6 con redundancia N+1.
3. Si la caché absorbe la mitad, llegan 1.050 consultas/s al servicio: 1.050 / 467 = 2,25 → 3 instancias (4 con N+1). Fíjate en que una caché (lección 04-05) reduce las máquinas a la mitad: reducir el trabajo suele ser más rentable que añadir máquinas.

Solución 2:

1. 0,05 % de 525.600 minutos = 262,8 minutos (unas 4 h 23 min) al año.
2. La disponibilidad en serie es 0,9999 × X × 0,9998 ≥ 0,9995. Despejando: X ≥ 0,9995 / (0,9999 × 0,9998) = 0,9995 / 0,99970002 ≈ 0,99980 (99,98 %). Es decir, pedidos necesita casi la misma disponibilidad que el objetivo global, porque los otros dos componentes ya "gastan" parte del presupuesto.
3. Dos réplicas independientes al 99,9 %: 1 − (0,001)² = 0,999999 (99,9999 %), muy por encima del 99,98 % necesario. Sí bastan, siempre que el fallo de una no arrastre a la otra y que el balanceador que las reparte no se convierta en el nuevo punto único de fallo (habría que incluirlo en la cadena en serie).

Solución 3:

1. La fracción paralelizable es p = 54 / 60 = 0,9. Con n = 6: S = 1 / (0,1 + 0,9 / 6) = 1 / 0,25 = 4,0 (el trabajo tarda 15 minutos). Con n = 18: S = 1 / (0,1 + 0,9 / 18) = 1 / 0,15 = 6,67 (9 minutos). Triplicar las máquinas solo mejora el tiempo de 15 a 9 minutos.
2. El tiempo mínimo es la parte secuencial: 6 minutos (aceleración máxima 1 / 0,1 = 10). Para bajar de ahí hay que atacar la consolidación final, por ejemplo, escribiendo resultados parciales por ciudad en paralelo (el patrón que hace MapReduce, lección 05-02).

Salida:

La columna de eficiencia (qué fracción de cada máquina se aprovecha) es la que debería mirar quien paga la factura: con 32 máquinas se está aprovechando menos de la cuarta parte de cada una.

Distribuir un sistema aporta ventajas reales y medibles: escalabilidad horizontal (con un cálculo de capacidad que, en el caso de la Semana del Queso Artesano, sustituye una máquina enorme por nueve modestas y elásticas), disponibilidad (donde hemos aprendido a traducir los "nueves" a minutos de caída y a combinar componentes en serie y en paralelo), localidad (servir a cada ciudad desde cerca), flexibilidad (cada equipo con su ritmo) y compartición de recursos. Pero también hemos visto que el escalado tiene un techo, la ley de Amdahl, marcado por la fracción secuencial del trabajo —normalmente, el acceso a los datos—, y que cada frontera de red que añadimos a un flujo síncrono multiplica la disponibilidad por un factor menor que uno.

Los desafíos —complejidad, heterogeneidad, consistencia, fallos parciales, latencia, seguridad, observabilidad y coste operativo— son el índice del resto del curso. Y la tabla de "cuándo no distribuir" recuerda que la respuesta correcta a muchos problemas sigue siendo un monolito bien hecho.

Muchos de estos desafíos nacen de suposiciones falsas que los programadores hacemos sin darnos cuenta sobre la red. La siguiente lección, Las Falacias de la Computación Distribuida, las pone nombre una a una y muestra, con código, qué pasa cuando las creemos ciertas.