Uso de métricas
Curso de escalabilidad v3, día 3
Qué veremos hoy
Cuatro señales de oro
Optimización de rendimiento
¿Qué es una métrica?
Una magnitud + un sistema de medición
¿Qué es, y cómo se obtiene?
¿De dónde sale?
¿Qué significa?
Métricas internas y externas
Internas: se miden en la propia máquina
Afectan a la medida
Externas: se miden desde fuera
Pueden no ser tan precisas
Toda métrica externa tiene su réplica interna
El problema de la medida
La propia medición afecta al resultado
Ocurre a todos los niveles
Si la medición es externa, entonces puede no ser tan precisa
Algunos problemas se resuelven al observarlos 🤔
Cuatro señales de oro
Tráfico: peticiones por segundo
Errores: tasa de fallos en el sistema
Latencia: tiempo en responder
Saturación: si el sistema está cerca del límite
Fuente: SRE Book
Peticiones
Una petición es parte de un intercambio de información
Petición + respuesta
(request + response/reply)
Orientado a conexiones de red
Sockets
HTTP
APIs
Sería equivalente a una consulta (query) a base de datos
Petición + respuesta
Medición de tráfico
Las peticiones se cuentan externamente
También se puede contar internamente mediante eventos de log
Durante un intervalo de tiempo (típicamente segundo o día)
Se suele registrar el tipo de resultado
- Status HTTP
- Éxito o error
Ejercicio: ¿Cómo medir el tráfico?
Discute en grupo cómo medir el tráfico
¿Cómo lo has medido en el pasado?
¿Cómo se podría medir mejor?
⮯
¡Chachi piruli!
Tasa de error
En un sistema distribuido no siempre hay "arriba" y "abajo"
Los sistemas pueden fallar intermitentemente
La disponibilidad se calcula como:
La tasa de errores = 1 - disponibilidad
Complicado de comprobar como cliente 😅
Cuando no hay sistema arriba/abajo
Latencia
El tiempo de espera entre el inicio de una petición
y la recepción de la respuesta
Medido externamente en el cliente
normalmente en milisegundos
Incluye tiempos de red
Cuanto más cerca, más preciso
Medición de latencia
Normalmente basta con medir milisegundos
Ejercicio: Midiendo latencias
Lanza una petición contra nuestro adorado servicio
http://service.pinchito.es/a
Mide la latencia en ms
Latencia = tiempo(fin) - tiempo(inicio)
⮯
Ejercicio +
Código:
const request = require('basic-request')
measure().catch(console.error)
async function measure() {
const start = Date.now()
await request.get('http://service.pinchito.es:3000/a')
const elapsed = Date.now() - start
console.log(`Elapsed: ${elapsed} ms`)
}
Hacer npm install en el directorio latency
⮯
Ejercicio +
Ahora resolvemos un problema de rendimiento
(En la práctica pasamos a medir http://service.pinchito.es/d).
Vuelve a medir la latencia
¿Qué te sale ahora?
⮯
Awesome!
Evento
Mensaje enviado de forma asíncrona
Medido internamente en la máquina que procesa
Puede generar una acción o no
Indica procesamiento retardado
- Fire & forget
- Polling
Proceso de eventos
Saturación
Uso de recursos finitos: CPU, red...
En unidades absolutas o porcentaje
Medición de red: 16 Mbit/s
El porcentaje indica mejor la saturación
Medición de uso de procesador
Interna (por CPUs): top puede medir 400%
Externa (por máquina): EC2 nunca pasa del 100%
¿Por qué las 4 señales de oro?
Tráfico: importante para la estabilidad y el coste
Errores: crucial para el cliente
Latencia: crucial para el cliente
Saturación: importante para la estabilidad y el coste
La tiranía de las medias
Twitter is a daily reminder that 50 percent of the population are of below average intelligence.
La inteligencia no es lo mismo que el cociente intelectual
La métrica nunca reemplaza a la magnitud que se quiere medir
¡Falso!
O no necesariamente cierto
Optimización de rendimiento
¿Por qué no escala un sistema?
Cuellos de botella
Recursos que se agotan
Aprovechamiento de recursos
Bloqueos
Cuellos de botella
Un sistema no puede rendir más que el componente menos capaz
Corolario: un componente con demasiado exceso de capacidad
está sobredimensionado
¿Qué recursos se saturan?
Respuesta corta: todos
- Memoria *
- CPU
- Ancho de banda
- Descriptores de fichero
- Buffers de entrada/salida *
- ...
Saturación no catastrófica: el sistema se bloquea
*Saturación catastrófica: el sistema se rompe
¿Nos enteramos siquiera de que se satura un recurso?
Los clásicos: CPU
Independencia
No requiere bloqueos
Inmutabilidad
Programación funcional
Ejemplo: Erlang
Ejercicio: Programación funcional
Resuelve el siguiente challenge:
Write a function solve(limit, array) that will return the number of elements of the array that are larger than the limit.
Usa challengerco.de
O mide el resultado en local con un array de 10k elementos
Escribe una solución funcional pura
⮯
Ejercicio +
Ahora escribe una solución con forEach()
Y otra estructurada (for clásico)
¿Cuál va más rápido?
¿Puedes acelerarlas?
⮯
Ejercicio +
Código funcional:
function solve(limit, array) {
return array.filter(e => e > limit).length
}Código forEach():
let t = 0
array.forEach(element => {
if (element > limit) t++
})
return t
Código for():
let t = 0
for (let i = 0; i < array.length; i++) {
if (array[i] > limit) t++
}
return t
¡Tecleando!
Bloqueos
Protegen un recurso
Ejemplo: global kernel lock
Cuando no se pueden procesar peticiones, se acumulan
Buffers de entrada y salida
(que también se saturan)
¿Cuándo usar bloqueos?
Modelado de dependencias (e.g. juegos)
Programación mono-proceso (Node.js)
Operaciones atómicas
Separación de lectura / escritura
Eventos
Canales
...
Ejercicio: contador de visitas
Somos un servidor de vídeos en 2012
Queremos contar las visitas a cada vídeo
Teníamos un servidor monoproceso con Node.js
escribiendo a múltiples ficheros
Se nos ha quedado pequeño
¿Puedes identificar posibles cuellos de botella?
⮯
Ejercicio +
Diseña un contador de visitas que pueda escalar horizontalmente
¿Qué tipo de operaciones son necesarias?
¿Qué llamadas tendrías en la API?
¿Qué estrategia(s) de escalado horizontal usarías?
⮯
Ejercicio +
Es 2013, estamos en una loca expansión internacional
Tenemos visitas de todo el mundo
¿Cómo ampliar el contador?
¿Es posible tener un contador preciso y sincronizado?
¿Se te ocurren alternativas?
⮯
Ejercicio + (en común)
Diseña ahora un servidor que asigne identificadores únicos
UUIDs
Tenemos un servidor centralizado
Mantiene un contador único
El servidor se colapsa por tráfico
Además abrimos nuevas regiones
¿Se te ocurren otras opciones?
⮯
Beep beep
Métricas comerciales
Disponibilidad
El porcentaje de tiempo que está el sistema levantado
También conocido como: uptime, availability
Valores típicos:
- 99%: caído 14 minutos al día
- 99.9%: caído 10 minutos a la semana
- 99.999%: caído 24 segundos al mes
- 99.99999%: caído 3 segundos al año
- 99.9999999%: caído 3 segundos al siglo
Ejercicio: Caídas periódicas
Calcula la disponibilidad de estos sistemas:
Banco nacional: caído 1 hora al día
Subastas de marketing: caído 1 hora al mes
Compra online: caído 5 horas al año
⮯
Ejercicio +
Tenemos un compromiso de disponibilidad del 99.9%
Queremos establecer una ventana de mantenimiento mensual
¿De cuántos minutos disponemos?
Una intervención nos cuesta dos horas
Tenemos que hacer una intervención
¿Cómo podemos mantener el compromiso?
⮯
Ejercicio + (en común)
¡Extra, extra!
Un comercial ha vendido a un cliente un 99.99% de uptime 😱
Tenemos diez servidores que actualizar
Cada uno requiere 30 minutos de downtime
¿Cómo mantenemos el compromiso?
⮯
Not bad
SLA
SLI: Service Level Indicator
SLO: Service Level Objective
SLA: Service Level Agreement
Chris Jones et al, SRE book
SLI
An SLI is a service level indicator—a carefully defined quantitative measure of some aspect of the level of service that is provided.
Indicador de nivel de servicio
(Vamos, una métrica de toda la vida)
Ejemplos:
- Latencia
- Disponibilidad: 99.999%
- Tasa de errores
- Rendimiento (throughput, peticiones por segundo)
SLO
An SLO is a service level objective: a target value or range of values for a service level that is measured by an SLI.
Objetivo de nivel de servicio
Ejemplos:
- Latencia media en una búsqueda < 100 ms
- Tasa de errores < 0.01%
Los objetivos sirven para fijar expectativas
SLA, ahora sí
Finally, SLAs are service level agreements: an explicit or implicit contract with your users that includes consequences of meeting (or missing) the SLOs they contain.
Acuerdo de nivel de servicio
Una entidad de negocio
Suelen tener truco
Ejercicio: Amazon SLA
Gastamos €1000/mes en EC2
Hay un terremoto y la disponibilidad cae al 99.01%
¿Cuánta pasta nos soltará Amazon?
¿Cuánto tiempo tiene que estar caído EC2 en un mes para obtener:
- un 10% de la factura?
-
un 100% de la factura?
⮯
That was easy!
Degradación de servicio
Muchas veces el SLA sólo atiende a la disponibilidad
A veces el servicio responde pero se degrada
Latencia alta, errores esporádicos...
Un SLA puede diseñarse para combinar varios SLOs
- Tasa de error < 0.1%
- Latencia > 1000 ms ⇒ error
Objetivo de uptime
Presupuesto de incidencias
Introducido por Google: error budget
La mayoría de las incidencias son por cambios
~70%
¿Queremos cumplir el SLO? Limitamos los cambios
Demasiada disponibilidad: mal
¡Podíamos haber hecho más cambios!
Ejercicio: Completa el presupuesto
Nuestro objetivo de uptime es del 99.9%
Hemos calculado que el 66% del downtime es por despliegues
Llevamos en el año siete caídas de una hora aprox.
¿Cuándo podremos hacer un cambio?
⮯
Ejercicio + (en común)
Mirando en detalle las caídas de los últimos años:
- Percentil 50: 1 hora
- Percentil 90: 2 horas
¿Qué podemos hacer para empezar a trabajar antes?
⮯
Alley oop!
Incógnitas desconocidas
Cuadrante de Rumsfeld
¿Qué no sabemos?
Hay conocimientos conocidos:
Lo que sabemos que sabemos
Hay incógnitas conocidas:
Lo que sabemos que no sabemos
Hay conocimientos desconocidos:
Lo que no sabemos que sabemos
Hay incógnitas desconocidas:
Lo que no sabemos que no sabemos
Ejemplos de incógnitas desconocidas
Testing in Production
I really hate metrics.
Bibliografía
SRE Book: Service Level Objectives
SRE Book: Embracing Risk
pinchito.es: Continuous Deployment on the Cheap
Charity Majors: I test in prod
Charity Majors: Yes, I Test in Production (And So Do You)
CdEv3 3: Uso de métricas
By Alex Fernández
CdEv3 3: Uso de métricas
Curso de escalabilidad v3, día 3: uso de métricas.
