Mad scalability (perfomance debugging)
- 1. Mis primeros pasos usando las escaleras Alejandro BM -@ae_bm Mad Scalability 2018/4/4
- 2. Trigger Warning ● Puedo herir sensibilidades. Se recomienda discreción ● No hablare de nada esotérico o exótico – No cloud – No scheduler de containers – No SDNs – Etc ● Si esto parece relleno ^_^ don’t blame me ● Esta presentación no ha sido revisada por Relaciones Públicas ● La siguiente es una historia inspirada en hechos reales
- 3. En un comienzo ● En un hardware que tiene varios sistemas ejecutándose (Gente a la que le gusta ahorrar) ● Hay quejas sobre la lentitud del sistema ● Los recursos están saturados ● El contenedor con el proceso web está a tope de CPU ● Se cambia la máquina por una más potente ● Aún con más recursos el sistema funciona de pena ¯_(ツ)_/¯
- 4. En un comienzo Diagrama del Sistema Inicial
- 5. En un comienzo ● Comenté que un sólo contenedor con un proceso python no iba a utilizar más cores por arte de magia ● Se decide poner otro contenedor con un proceso python para aprovechar mejor los recursos de la máquina. Ahora NGINX además de proxy funciona como load balancer ● El sistema se pensó para no usar cookies o un almacén externo de sesiones, lo cual maravilla a los usuarios cuando peticiones relacionadas son procesadas por backends distintos
- 7. En un comienzo ● Mientras tanto yo analizaba logs ● Vi que la mayoría de las peticiones venían de la propia máquina originadas por un sistema interno ● Así que configuré a NGINX para que las peticiones del sistema interno usaran un contenedor y el resto el otro contenedor ● Mi idea era que los usuarios externos no fueran penalizados por el sistema interno
- 8. En un comienzo Diagrama del Sistema
- 9. Unas semanas después ● Quejas porque el sistema está lento ● El backend para peticiones internas está casi ocioso mientras su clon está comiéndose casi toda la carga ● Esta vez pude revisar de nuevo los logs sin que se tomaran decisiones apresuradas ● Omití todo el trafico originado desde localhost
- 10. Unas semanas después ● Existían 2 tipos de peticiones desde clientes externos – URLs con /html/ – URLs sin /html/ ● Después de una comunicación OPS DEV – Si la URL tiene /html/ se han hecho con un navegador web – Posible humano – Si no tienen /html/ son consultas al API – Posible no humano
- 11. Unas semanas después ● Manteniendo la doctrina de no penalizar humanos*, se configura el sistema para usar otro backend más – 1 backend para peticiones desde localhost (siguen siendo un montón) – 1 backend para peticiones sin /html/ (peticiones al API) – 1 backend para peticiones con /html/ (peticiones de humanos) ● Cambio el formato de logs en NGINX para tener más datos – Saber que backend procesó la petición $proxy_host – Saber el tiempo que tardo la petición $request_time * still a misanthrope ^_^
- 12. Unas semanas después Diagrama del Sistema
- 13. Hace unas pocas semanas ● El cliente comenta que el sistema esta lento ● La página web funciona con las latencias esperadas ● El cliente especifica que el problema es con el API – Ahora son específicos ● La ventaja es que ahora hay datos y no sólo sensaciones
- 15. Hace unas pocas semanas ● Aplicando estadísticas a los logs de un mes y medio además de comparándolo con otro cliente grande
- 16. Hace unas pocas semanas ● Peticiones procesadas por cada backend ● Respuestas HTTP retornadas por NGINX local 0.98 html 0.01 api 0.0043 200 0.9989 404 0.0008
- 17. Hace unas pocas semanas Histograma de la duración de las peticiones
- 18. Hace unas pocas semanas Duración de las peticiones en base al tiempo
- 19. Hace unas pocas semanas Histograma de las duraciones menores a 1 seg
- 20. Hace unas pocas semanas ● Estadísticas ● Nada llamativo min 0.0 q1 0.003 max 63.287 q3 0.005 mean 0.04 IQR 0.002 median 0.004 p90 0.008 mad 0.07 p99 0.6 stdev 0.67
- 21. Hace unas pocas semanas ● Dos errores – Revisar casi 2 meses de logs – Revisar el agregado y no el API ● Viendo sólo los números parece que el sistema no va tan mal (considerando que nadie ha definido una latencia objetivo) ● El problema es la gran cantidad de peticiones que hace el sistema local. Por lo que el resto de peticiones son outliers
- 23. Hace unas pocas semanas API - Histograma de la duración de las peticiones
- 24. Hace unas pocas semanas API - Duración de las peticiones en base al tiempo
- 25. Hace unas pocas semanas ● Estadísticas - API ● FUUUUUUU….. min 0.0 q1 4.76975 max 36.394 q3 7.9235 mean 5.97 IQR 3.15375 median 5.212 p90 11.4481 mad 3.41 p99 25.12393 stdev 4.98
- 27. Hace unas pocas semanas ● El backend que atiende las peticiones del API sucks hard ● Me intrigaba que un proceso web usara constantemente 100% una CPU ● No es una aplicación que mina criptomonedas ● Confirmo que es una aplicación asíncrona
- 28. Hace unas pocas semanas ● Decido formular una hipótesis: – Estamos aceptando peticiones que no avanzan porque están esperando por otras partes del sistema. Es el proceso de aceptar peticiones de forma continua lo que hace que se use el CPU al 100% ● Toca ver si existen recursos críticos
- 29. Hace unas pocas semanas Buscando ideas
- 30. Hace unas pocas semanas ● Para validar la hipótesis decido usar sysdig para ver cuales son las llamadas al sistema que más tardan en responder ● Todo está lleno de epolls, así que descarto los epolls – normal en un sistema asíncrono ● Cuando ignoro los epolls: – La mayoría de las esperas son por MySQL (ToySQL) – Hay mucha comunicación de red con REDIS
- 31. Hace unas pocas semanas La parte del sistema que nos interesa ahora
- 32. Hace unas pocas semanas ● Con MySQL ocurrían dos problemas: – Una query que hacia un order by con limit en un campo que no tenia índice – facepalm – Una query de union que tenia índices pero el filtrado se hacia en el having por lo que no usaba índices – sin comentarios ● Soluciones: – Crear un índice para la primera consulta – Reescribir la query para que el filtrado se haga en los where y no esperar hasta el final (el having) – Ahora me llaman DBA por esto. FML
- 33. Hace unas pocas semanas ● Ahora las queries a la BD iban algo mejor - mucho ● Pero persistía el alto uso de CPU ● Con sysdig veo que peticiones del tipo /algo? user=id – Se conectan a REDIS y piden una colección de miles de elementos – Reviso el código fuente y el filtrado lo está haciendo python - LLORO
- 35. Hace unas pocas semanas ● Soluciones: – Usar otra BD – No hay tiempo – Se utiliza otra estructura en REDIS para soportar este tipo de consultas ● Se dejo unos días para ver si había mejora y ...
- 36. Hace unas pocas semanas API - Histograma de la duración de las peticiones
- 37. Hace unas pocas semanas API - Duración de las peticiones en base al tiempo
- 38. Hace unas pocas semanas ● Estadísticas – API ● Parece que hemos mejorado un poco el sistema min 0.002 q1 0.004 max 3.037 q3 0.006 mean 0.03 IQR 0.002 median 0.005 p90 0.01 mad 0.04 p99 0.70078 stdev 0.13
- 40. Como conclusión ● Definir la latencia aceptable ● Medir / instrumentar ● Entender lo que se esta midiendo ● Hacer experimentos ● Hacer pruebas de carga de verdad
- 41. Como conclusión ● Ir de forma iterativa corrigiendo los bottlenecks ● Vale la pena diferenciar los tipos de carga de trabajo ● Usar loadsheding, quotas o fallar es mejor a crear un fallo en cascada https://landing.google.com/sre/book/chapters/addressing-cascading-failures.html
- 42. Como conclusión ● Antes de escalar en máquinas o cambiar el HW entender lo que esta limitando la escalabilidad ● Revisar los queries con explain y usar el f*** index ● Si la BD te puede dar el trabajo ya hecho es mucho mejor hacerlo en la aplicación: – Menos tráfico de red – No malgastas CPU
- 43. ¿Preguntas? se supone que es una lighting talk Things That Are Not Questions (by @QuinnyPig) • Calling Bullshit • Telling a pointless story • A spoken word version of your resume