Open guilleiguaran opened 5 years ago
Algunas ideas relacionadas con el primer cap de las que queria hacer anotación:
Un error muy comun que cometemos frecuentemente es hacer performance tests para ver cuanta carga puede "manejar" nuestro sistema sin definir antes que es "manejar". Al hacer performance tests es muy importante definir previamente SLI/SLA que se enfoquen principalmente en las latencias (ej. p50, p75, p95, p99) y en las tasas de error, y luego medir exhautivamente el sistema. Mas sobre esto en [1][2][3]
Algo en lo que hace enfasis el autor y otros [4][5] es que los promedios muchas veces suelen ser engañosos y los percentiles nos dan un mejor overview sobre como los usuarios perciben el sistema en un momento dado, pero es importante tener en cuenta tambien que los percentiles NO pueden ser promediados [6][7], asi que no podemos por ejemplo calcular algo como el p99 a lo largo de un mes sumando los p99 de cada dia. Almacenar absolutamente todos los puntos de las metricas durante un largo periodo de tiempo para calcular los porcentiles es impractico por lo que muchas veces es recomendable calcular percentiles aproximados usando histogramas [8][9]
[1] https://www.oreilly.com/library/view/site-reliability-engineering/9781491929117/ch04.html [2] https://content.pivotal.io/blog/slis-and-error-budgets-what-these-terms-mean-and-how-they-apply-to-your-platform-monitoring-strategy [3] https://www.datadoghq.com/blog/set-and-monitor-slas/ [4] https://signalvnoise.com/posts/1836-the-problem-with-averages [5] https://blog.optimizely.com/2013/12/11/why-cdn-balancing/ [6] https://twitter.com/heinrichhartman/status/748355170040352768 [7] https://www.circonus.com/2015/02/problem-math/ [8] https://www.circonus.com/2018/11/the-problem-with-percentiles-aggregation-brings-aggravation/ [9] https://www.vividcortex.com/blog/why-percentiles-dont-work-the-way-you-think
My raw notes:
3 principles: reliability, scalability and maintainability
Standard building blocks:
Reliability
Scalability
Metrics and percentiles
Regarding the aggregation of percentile measurements, I asked in an observability chat and someone told me:
regarding whether its a good approximation, thats kind of the crux of the problem, there's no error bounds for the approximation, so in many cases, yes it probably is, but there may be pathological cases (especially where the number of samples in each windows varies wildly) where it may not be a good approximation
Disculpen por el resumen tardío, estas fueron mis anotaciones con respecto al primer capítulo del libro:
El primer capítulo se enfoca en 3 principios:
Como introducción se mencionan los sistemas de antes que solían ser computer-intensive versus los de ahora que son data-i, al enfocarse más en la intensidad y cantidad de los datos, llegan nuevos problemas para estos sistemas:
Un sistema data-intesive podría tener las siguientes partes en común, pero se necesitaría saber que combinación de herramientas + enfoque va mejor con cada solución de software:
¿Por qué poner colas y bases de datos bajo el mismo término "Data Systems"?, si tienen sus similitudes pero diferentes patrones de acceso, implementación y rendimiento. Entonces estas herramientas de almacenamiento de datos están diseñadas para diferentes soluciones y además se puede decir que no encajan bajo un modelo en específico. Con esto dicho, y viendo el ejemplo de la página 5, se pueden combinar varios de estos componentes para crear un Data i que nos puede garantizar:
A partir de esto surgen las siguientes preguntas cuando el sistema, aunque completo, todavía es propenso a fallas y errores:
Aquí entran los 3 principios en los que se enfoca este capítulo.
Para resumir, confiabilidad significa que el sistema debe seguir funcionando correctamente cuando las cosas se ponen difíciles en términos de fallas y errores. Resiliencia.
El sistema debería:
El autor hace una diferenciación importante, menciona que "fault" no es lo mismo que "failure":
"Es imposible reducir la probabilidad de una falla a 0, así que es mejor diseñar mecanismos tolerantes a estas que previenen que estas fallas (faults) causen fracasos (failures)"[cita] Así que de cierta manera es preferible que deliberadamente se induzcan estas fallas (como parar procesos) y construir el sistema para que sea tolerante a ellas.
El cuarto de servidores podría sufrir un apagón o un rack podría ser desconectado, para evitar tener un major outage a causa de esto, una de las prevenciones mencionadas es usar Redundancia/RAID configuration como un enfoque para prevenir problemas de hardware. Esto además tendría que ser combinado con técnicas de tolerancia a fallas del lado el software.
Una falla sistemática en un componente puede causar que otras partes del sistema fallen, esto puede ser debido a dependencias internas entre los componentes. En los ejemplos que se muestran en las páginas 8 y 9 podemos concluir que no hay manera para prevenir al 100% las fallas de software pero se podrían prevenir usando ciertas técnicas:
Los errores de configuración son la causa No. 1 de las fallas en los sistemas cuando se mide las fallas que son únicamente operacionales. Para evitar tener estos errores hay que pensar en:
El incremento en la carga de datos puede perjudicar el rendimiento del sistema. La habilidad de de atender el incremental número de usuarios concurrentes o la carga de datos en un sistema, la llamamos escalabilidad.
Según el autor, lo más importante para poder trabajar sobre la escalabilidad de un sistema, es saber describir los puntos sobre los cuales es medido el rendimiento de este. En el texto se mencionan como "load parameters" (parámetros de carga), los cuales dependen de la arquitectura del sistema y podrían ser:
Después de describir la carga y los puntos para medir el rendimiento del sistema, se puede determinar cómo manejar el rendimiento. Para esto se deben responder los siguientes interrogantes:
Los valores que hayan escogido para medir el rendimiento del sistema pueden variar rápidamente, por eso usar la media/promedio no dice en concreto cuantos usuarios están percibiendo los tiempos de respuesta reflejados. A partir de esto el autor recomienda usar percentiles para las medidas de rendimiento. Entre más alto sea el percentil sobre el que se está evaluando, mejor información se va a obtener; aunque calcular sobre los percentiles más altos es más costoso.
¿Cómo mantener un buen rendimiento cuando nuestros parámetros de carga de datos se incrementan?
Algunos sistemas son elásticos, significa que pueden automáticamente añadir recursos computacionales cuando detectan que la carga de datos se incrementa, otros sistemas escalan manualmente. Es importante tener en cuenta que los sistemas sin estados internos pueden escalar de manera distribuida fácilmente entre varias máquinas, pero los sistemas que usan estados internos y que quieren escalar de un nodo a múltiples es más complejo.
"Cuesta más mantener un software que construirlo" Debemos tener en cuenta al construir sistemas que debemos minimizar el dolor que puede causar la mantención de este, pero como no hay una solución fácil para alcanzar esta meta, intentemos pensar en los siguientes principios:
Un buen equipo de operaciones puede buscar soluciones alternativas con respecto a las limitaciones de un software incompleto, pero un buen software usualmente no puede correr confiando en un mal equipo de operaciones. Los equipos de operaciones son vitales para mantener el software, un buen equipo de operaciones es responsable de:
Y los sistemas pueden hacerle la vida fácil al equipo de operaciones de la siguiente manera:
Sistemas grandes se vuelven mas dificiles de entender, pueden tener mucho legacy code y se hace mas dificil para personas nuevas hacer cambios. Los sistemas que se hacen más dificiles de entender es usualmente por dependencia entre modules, acoplamiento, hacks al resolver problemas (o como decimos en la costa: "EMPANADAS") e inconsistencias en terminología. Estos problemas de complejidad pueden llevar a gastar mucho dinero en mantención. Por estas y otras razones, reducir la complejidad del sistema, mantenerlo simple, hace más fácil mantenerlo.
Una buena herramienta para eliminar complejidad es la abstracción que puede esconder implementación bajo una simple fachada y además hace mas simple usar ciertos módulos en diferentes partes del sistema. El autor menciona que a lo largo del libro explicará buenas prácticas de abstracción para mejorar la mantenabilidad del sistema.
Todos estamos conscientes que es muy probable que un sistema deba sufrir cambios, ya sea por cambios en el negocio o añadiduras necesarias para mejorarlo. Usar procedimientos ágiles o técnicas como TDD pueden ayudar a hacer mas faciles la implementación de cambios.
El termino Percentil puede ser un poco desconocido para los que no sabemos mucho de estadistica. Aquí dejo un articulo es español que explica y muestra ejemplos generales: https://www.matematicas10.net/2017/02/ejemplos-de-percentiles.html
1. Reliable, Scalable, and Maintainable Applications
Esta semana a cargo: @elba Siguiente semana: @sescobb27
EDIT:
El overview de @elba: https://github.com/colombia-dev/bookclub/issues/2#issuecomment-484332907