Performance and Availability
Resumen
Esta guía de estudio independiente aborda rendimiento y disponibilidad en la nube para la certificación LFCA.
No está afiliada ni avalada por la Linux Foundation ni por ningún proveedor.
El enfoque es conceptual: qué significa que un servicio esté disponible, cómo se mide, qué patrones reducen el impacto de los fallos y cómo se equilibran rendimiento, coste y complejidad.
Un servicio disponible no es un servidor encendido: es un sistema que cumple un nivel de servicio acordado, con latencia y errores aceptables, incluso cuando falla un componente.
Objetivos de aprendizaje
- Distinguir disponibilidad, fiabilidad, resiliencia y recuperación ante desastres.
- Explicar escalado vertical y horizontal y cuándo aplicar cada uno.
- Interpretar SLI, SLO y SLA y relacionarlos con la experiencia del usuario.
- Identificar puntos únicos de fallo y proponer redundancia adecuada.
- Definir RTO y RPO y elegir una estrategia de continuidad coherente.
Prerrequisitos y conexiones
Requiere los conceptos de cloud-computing: modelos de servicio, responsabilidad compartida y elasticidad. Se relaciona con cloud-networking para balanceo y aislamiento, con budgeting porque la redundancia cuesta, y con cloud-best-practices, que sitúa estas decisiones en un marco de gobernanza.
Disponibilidad, fiabilidad y resiliencia
La disponibilidad es la proporción de tiempo en que el servicio es utilizable. La fiabilidad es la probabilidad de que funcione correctamente durante un periodo. La resiliencia es la capacidad de absorber fallos y recuperarse sin degradación grave. La recuperación ante desastres cubre eventos que superan la respuesta normal, como perder una región completa.
El diseño empieza por eliminar puntos únicos de fallo con redundancia. No toda redundancia protege igual: duplicar una instancia en el mismo host no ayuda ante un fallo del host; distribuirla entre zonas reduce el riesgo local. La clave es alinear el dominio de fallo con la redundancia. Si dos réplicas comparten energía, red o almacenamiento, no son independientes.
La redundancia introduce compromisos: duplicar cuesta y añade complejidad. La replicación síncrona da coherencia fuerte pero aumenta la latencia; la asíncrona mejora latencia y disponibilidad a costa de posibles pérdidas en el fallo.
Niveles de disponibilidad y nueves
Los niveles se expresan en porcentaje de tiempo en que el servicio responde y se traducen en horas o minutos de interrupción anual. Los cálculos siguientes son ilustrativos y suponen 8.760 horas al año:
| Nivel | Caída anual aproximada | Lectura operativa |
|---|---|---|
| 99 % | unos 3,65 días | Un solo mantenimiento mal gestionado lo supera |
| 99,9 % | unas 8,76 horas | Unos 43 minutos de margen al mes |
| 99,95 % | unas 4,38 horas | Objetivo habitual de sistemas internos críticos |
| 99,99 % | unos 52 minutos | Exige redundancia activa y fallo rápido |
| 99,999 % | unos 5 minutos | Reservado a pocos servicios y con coste elevado |
Añadir un nueve no es una mejora marginal: pasa de tolerar horas a tolerar minutos y obliga a retirar los puntos únicos de fallo que queden. Un servicio con un solo componente sin respaldo en alguna capa promedia lejos del nivel declarado, aunque el resto del diseño sea redundante.
El nivel publicado describe la infraestructura del proveedor, no la aplicación ni sus dependencias: una caída del cliente, de un servicio externo o del propio código se descuenta del tiempo total percibido, aunque aparezca fuera del cómputo contractual. Por eso conviene leer el SLA ajeno como un techo, no como la disponibilidad que el usuario experimenta.
Comparar dos niveles exige leer la definición y no solo el número: algunos contratos excluyen el mantenimiento programado, otros fijan un umbral mínimo de errores o un volumen de muestras antes de reconocer la incidencia. El mismo porcentaje con letra distinta no representa el mismo compromiso, y la comparación solo es válida cuando las exclusiones son iguales.
Patrones de alta disponibilidad
En activo-pasivo solo un nodo atiende tráfico y el resto espera; la interrupción depende de cuánto tarde la detección en promover la réplica. En activo-activo todos los nodos sirven a la vez tras el balanceador, lo que aprovecha mejor la capacidad y acorta la pausa, pero exige que la aplicación tolere réplicas concurrentes y que las escrituras se repartan o se serialicen.
La detección la resuelve un mecanismo de conmutación: comprobaciones de salud que retiran destinos enfermos o un monitor externo que actualiza el destino activo. Sin ese mecanismo, la réplica existe pero nadie la pone a trabajar cuando el nodo principal cae.
| Patrón | Interrupción esperada | Coste | Complejidad operativa |
|---|---|---|---|
| Restauración desde copia | Horas o días | Bajo | Baja |
| Réplica caliente en espera | Minutos a horas | Medio | Media |
| Activo-pasivo con conmutación automática | Segundos a minutos | Alto | Media-alta |
| Activo-activo entre zonas | Segundos cuando el fallo es parcial | Alto | Alta |
Los patrones se pueden combinar por componente: balanceo activo-activo para el cómputo y réplica caliente en espera para la base de datos, en lugar de aplicar una sola etiqueta a todo el sistema.
Escalabilidad y balanceo de carga
El escalado vertical aumenta recursos de una instancia, como CPU o memoria. Es simple, pero tiene límites físicos y suele requerir redimensionado o reinicio. El horizontal añade instancias y suele preferirse para aplicaciones sin estado, porque tolera mejor los fallos y crece por partes.
El escalado horizontal necesita un balanceador de carga que distribuya peticiones entre destinos sanos y deje de enviar tráfico a los que fallan. También puede terminar TLS o enrutar por ruta. La afinidad de sesión simplifica aplicaciones con estado local, pero reduce la distribución y complica la recuperación.
El autoescalado ajusta instancias según métricas como CPU, longitud de cola o peticiones por segundo. Bien configurado sigue la demanda; mal configurado oscila o reacciona tarde. Se usan umbrales con histéresis, periodos de estabilización y métricas que representen la carga real, no solo el consumo de un componente.
Añadir instancias no corrige una consulta ineficiente ni una base de datos saturada. Antes de escalar hay que medir el cuello de botella: CPU, memoria, disco, red o una dependencia aguas abajo.
Escalar el estado
El cómputo sin estado se reparte añadiendo nodos, pero el estado no. Las lecturas pueden distribuirse entre réplicas, mientras que las escrituras suelen concentrarse en un primario que se convierte en el límite del sistema. Repartir escrituras obliga a particionar datos o a aceptar compromisos de consistencia, y ambas decisiones llegan hasta el código de la aplicación.
Por eso muchas arquitecturas separan el crecimiento del cómputo, barato y rápido, del crecimiento del almacenamiento, más lento. Cuando una sola instancia de base de datos deja de dar abasto, las opciones ordenadas por impacto son redimensionar, añadir una réplica de lectura o partir el conjunto de datos.
Vertical frente a horizontal: cuándo aplicar cada uno
| Situación | Opción razonable | Qué decidir antes |
|---|---|---|
| Carga estable que no decae | Escalar vertical la instancia | Si el mayor tamaño todavía deja margen |
| Picos diarios previsibles | Horizontal con autoescalado | Qué métrica dispara y cuánto tarda en estar lista la nueva capacidad |
| Base de datos al límite | Redimensionar o réplica de lectura | Si el límite está en CPU, en memoria o en escrituras |
| Equipo pequeño sin capacidad para operar muchos nodos | Vertical con replicación mínima | Si compensa el riesgo de un sistema central frente a la complejidad de varios |
Dimensionamiento y margen de trabajo
El dimensionamiento traduce una previsión de carga en recursos contratados. Parte de medir el comportamiento real: cuántas peticiones sostiene una instancia, cómo se comporta en el percentil alto y a partir de qué punto empieza a degradarse. Sobre esa base se calcula la capacidad para el pico y el margen que deja el objetivo de utilización.
Ejemplo ilustrativo: una instancia sostiene 200 peticiones por segundo en pruebas y el equipo decide no superar el 60 % de uso, de modo que cada instancia aporta 120 peticiones por segundo útiles. Con un pico previsto de 480 hacen falta 4 instancias; si además debe conservarse el pico tras perder una, el grupo sube a 5. Un margen demasiado amplio paga capacidad ociosa y uno demasiado ajustado convierte cualquier pico en incidente, así que el valor se recalibra con datos de producción y con la criticidad del servicio.
El autoescalado también tiene latencia: desde que se decide añadir capacidad hasta que la instancia responde pasan minutos, de modo que una escala programada no cubre un pico de segundos; para eso sirven mantener capacidad previa o degradar con elegancia. Las pruebas de carga aproximan el comportamiento, pero no reproducen la distribución real de datos ni el estado de las dependencias, por lo que el margen se confirma con tráfico de producción y se revisa cuando cambia el esquema o el patrón de acceso.
SLI, SLO y SLA
Un SLI es una medida cuantitativa de la calidad percibida, por ejemplo la proporción de peticiones exitosas o la latencia en un percentil. Un SLO es la meta interna para ese indicador. Un SLA es un compromiso contractual con consecuencias, normalmente compensaciones, si no se cumple.
El SLA suele ser menos exigente que el SLO para dejar margen operativo: el equipo puede fijar un objetivo más estricto y alertar antes de incumplir el contrato. Medir con percentiles es preferible a usar promedios, que pueden ocultar a usuarios con latencias muy altas.
Un SLO útil es alcanzable, medible y relevante; fijarlo en el máximo no es realista. Conviene definir una ventana de medición, un umbral y un presupuesto de error que permita priorizar mejoras frente a nuevas funcionalidades.
El presupuesto convierte el objetivo en una regla de decisión: si en la primera semana se consume una parte desproporcionada del total mensual, conviene congelar los despliegues de riesgo y dedicar el ciclo a corregir la causa. Si en cambio el presupuesto avanza despacio, el equipo puede aceptar cambios arriesgados sin salirse del compromiso. Acordar esa regla antes de agotar el margen evita que la discusión se resuelva por urgencia.
Observabilidad y monitorización
La monitorización responde si el sistema funciona; la observabilidad permite entender por qué no. Se apoya en métricas, logs y trazas, además de checks de salud y alertas.
Una alerta debe estar ligada a un síntoma de usuario o a un SLO, no a cada fluctuación interna. El exceso de alertas provoca fatiga y hace que las importantes se ignoren. Conviene vigilar también indicadores adelantados, como saturación de colas o crecimiento de latencia, además de los errores visibles.
Los paneles deben mostrar el servicio desde la perspectiva del usuario: éxito, latencia, saturación y errores. Las métricas internas ayudan a diagnosticar, pero no sustituyen las señales de experiencia. Los servicios gestionados ofrecen métricas y logs integrados; el reto es correlacionarlos y retenerlos para investigar.
Las trazas enlazan una petición que atraviesa varios servicios mediante un identificador común, lo que reparte el tiempo total entre componentes y localiza el tramo lento. Muestrear el tráfico reduce volumen y coste, pero un muestreo que descarta las peticiones lentas o erróneas se queda sin la evidencia útil; conviene conservar siempre las excepciones y muestrear solo lo normal.
Dos marcos ayudan a elegir qué medir. Para recursos de infraestructura se observan utilización, saturación y errores: cuánto se usa, cuándo empieza a haber cola o espera y cuántas veces falla el componente. Para servicios de usuario se mira tasa, errores y duración: cuántas peticiones entran, cuántas fallan y cuánto tardan en completarse. Empezar por estos pares acorta la discusión sobre qué métricas van en el panel.
Continuidad: RTO y RPO
El RTO es el tiempo máximo aceptable para restaurar el servicio. El RPO es la cantidad máxima de datos que se puede perder, expresada en tiempo. Ambos se definen desde el negocio, no desde la infraestructura.
Con RTO y RPO se eligen estrategias: copias y restauración, replicación entre zonas o regiones, o activo-activo. Un RPO cercano a cero suele implicar replicación continua; un RTO muy bajo exige capacidad ya disponible.
Las copias deben probarse: una que nunca se ha restaurado es una hipótesis. También hay que protegerlas contra borrado accidental o ransomware, con aislamiento, versionado o inmutabilidad según el servicio.
El cálculo del RTO incluye detectar el fallo, decidir, restaurar y verificar, no solo el tiempo de la herramienta; contar únicamente la restauración infravalora el resultado. El RPO se mide respecto de lo que se pierde en el peor caso, no respecto del intervalo configurado: mientras la copia se genera, los últimos cambios siguen sin cubrirse, y si la tarea falla en silencio, la ventana real supera con creces la programada.
Ejemplos prácticos
API sin estado con más tráfico del previsto. Se despliega detrás de un balanceador, se añaden instancias en varias zonas y se configura autoescalado por peticiones por segundo.
Base de datos como único componente con estado. Se define un RPO de minutos y un RTO de una hora. La estrategia combina replicación entre zonas, copias verificables y un procedimiento de recuperación documentado.
Equipo con demasiadas alertas. Se eliminan las reglas que no se traducen en acción. Las críticas se vinculan al SLO y a la latencia del percentil que percibe el usuario.
Servicio con SLA cumplido y usuarios molestos. El proveedor sostiene su 99,9 % mientras la aplicación tarda segundos en responder. El contrato no cubre la lentitud percibida, así que el equipo define su propio SLO de latencia en percentil alto y trabaja contra ese objetivo.
Equipo que nunca probó la conmutación. En el simulacro, la réplica tarda el doble de lo estimado: la detección está en tres minutos y la verificación manual añade otros diez. Los números corregidos obligan a replantear el RTO o a invertir en detección automática.
Errores frecuentes
- Confundir alta disponibilidad con tolerancia a desastres. La primera absorbe fallos locales; la segunda cubre la pérdida de una región.
- Duplicar en el mismo dominio de fallo. Dos réplicas en el mismo host no eliminan el punto único.
- Fijar el SLO en el máximo. Un objetivo inalcanzable genera alertas constantes.
- Usar solo promedios de latencia. Los percentiles revelan a los usuarios afectados.
- Escalar sin medir el cuello de botella. Más instancias no arreglan una base de datos lenta.
- Confundir el SLA del proveedor con el propio. El nivel publicado cubre su infraestructura, no el diseño de la aplicación ni sus dependencias.
- Dimensionar con promedios de tráfico. El pico, no la media, decide cuánta capacidad hace falta cuando no hay autoescalado.
- Tratar una réplica como una copia. La réplica sigue los cambios, incluidos los erróneos; la copia permite volver a un punto anterior.
Puntos clave para el examen
- Disponibilidad, fiabilidad y resiliencia son conceptos distintos.
- Escalado horizontal y balanceo suelen ir juntos en aplicaciones sin estado.
- SLI mide, SLO fija la meta interna y SLA establece el compromiso contractual.
- RTO es tiempo de recuperación; RPO es pérdida máxima de datos.
- Cada nueve adicional de disponibilidad recorta el margen de interrupción de horas a minutos y exige más redundancia.
- El escalado horizontal reparte el cómputo, mientras que el estado sigue concentrado en sus componentes.
- El presupuesto de error convierte el SLO en una regla sobre cuándo desplegar y cuándo corregir.
- Un patrón de alta disponibilidad se valida con la conmutación ejecutada, no con el diagrama.
Recursos externos
- Google SRE, Service Level Objectives: https://sre.google/sre-book/service-level-objectives/
- AWS Well-Architected, The pillars of the framework: https://docs.aws.amazon.com/wellarchitected/latest/framework/the-pillars-of-the-framework.html
- Google Cloud Architecture Framework: https://cloud.google.com/architecture/framework
- Microsoft Azure Well-Architected Framework: https://learn.microsoft.com/en-us/azure/well-architected/
Autoevaluación
1. ¿Cuál es la diferencia entre SLO y SLA?
Respuesta: El SLO es un objetivo interno medible; el SLA es un compromiso contractual con consecuencias.
Justificación: El SLO guía la operación y suele ser más estricto; el SLA define lo prometido y las consecuencias.
2. Una aplicación sin estado debe crecer y tolerar la caída de una instancia. ¿Qué enfoque es adecuado?
Respuesta: Escalado horizontal con balanceo entre zonas.
Justificación: Varias instancias sin estado permiten distribuir tráfico y retirar las que fallan. El escalado vertical no aporta redundancia por sí solo.
3. ¿Qué mide el RPO?
Respuesta: La cantidad máxima de datos que se puede perder, expresada como intervalo de tiempo.
Justificación: Se fija desde el negocio y determina la frecuencia de replicación. El RTO mide el tiempo de restauración.
4. Dos réplicas están en el mismo host físico. ¿Eliminan el punto único de fallo?
Respuesta: No.
Justificación: Comparten el mismo dominio de fallo: si el host cae, ambas caen. La redundancia efectiva requiere dominios independientes.
5. ¿Por qué medir latencia con percentiles?
Respuesta: Porque el promedio puede ocultar una parte de usuarios con latencias muy altas.
Justificación: Los percentiles muestran la cola de la distribución y se acercan a la experiencia de los afectados. El promedio mezcla todas las observaciones.
6. Un servicio declara 99,9 % de disponibilidad mensual. ¿Cuánto tiempo de interrupción admite?
Respuesta: Unos 43 minutos en un mes de 30 días.
Justificación: El 0,1 % de treinta días equivale a 0,03 días, es decir, 43,2 minutos; ese es el margen total de la ventana, y las interrupciones se descuentan de ahí sin distinguir su origen.
7. En un diseño activo-pasivo, ¿qué determina la interrupción que nota el usuario?
Respuesta: El tiempo que tarda la detección del fallo y la promoción de la réplica.
Justificación: Mientras el mecanismo de conmutación decide, el nodo secundario sigue en espera; por eso el patrón se juzga por su detección, no por tener dos nodos instalados.
8. ¿Qué debe incluir el cálculo de un RTO?
Respuesta: Detección, decisión, restauración y verificación del servicio.
Justificación: Medir solo la herramienta de recuperación deja fuera los minutos que consume enterarse y validar; el usuario percibe la suma completa.
9. ¿Qué problema plantea muestrear únicamente el tráfico normal?
Respuesta: Que se descarten justo las peticiones lentas o erróneas, que son las útiles para diagnosticar.
Justificación: Un muestreo uniforme mantiene bajo el volumen guardado, pero si no se conservan las excepciones, el sistema almacena datos que no explican ningún incidente.
10. Un SLO anual del 99 % admite casi cuatro días seguidos de caída. ¿Cómo se evita?
Respuesta: Midiendo en ventanas cortas, por ejemplo de treinta días.
Justificación: La ventana mensual reparte el presupuesto de error y hace visible un fallo prolongado en el primer periodo, en lugar de diluirlo durante doce meses.