Qué métricas usar para escalar
Audiocurso de Fundamentos de Arquitectura de Alta Concurrencia
Contenido del curso
Escalabilidad
Herramientas
Seguridad
Protocolos
Negocios y casos de uso
Conclusiones
Qué métricas usar para escalar
Qué métricas usar para escalar
Audiocurso de Fundamentos de Arquitectura de Alta Concurrencia
Contenido del curso
Gonzalo Amador Hernández
Eduard Arias
Gonzalo Amador Hernández
Juan David Cajamarca Acuña
Harold Adrian Bolanos Rodriguez
Nicolás Peralta Páez
Sebastián Ospino
Nicolas David Pastran Zamora
Juan Manuel Hincapié
Ricardo Tribaldos Hernández
Rodmy Suarez
Pablo Antipan Quiñenao
Luis Enrique Álvarez Hernández
Jefred Bedoya
Daniel Eduardo Rojas Pulido
MARIA TERESA PANIAGUA RIVERA
DAVID EDUARDO BAEZ SANCHEZ
Sino estas decidido si usar SQL o NoSQL, preguntate que operacion realizara mas tu app:
con base a mi experiencia SQL es mas facil de mantener y de verdad es rara la vez que necesitas NoSQL, son pocos las empresas con una demanda de lectura que lo requiera asi, quizas aplicaciones de IoT donde el tiempo de respuesta es importantge
Una señal muy importante para usar una BD NoSQL es si notas que estas haciendo desnormalización en tus esquemas relacionales para ganar velocidad (ya que evitaras usar Joins en tus queries, por ende seran mas veloces), entonces es probable que sea hora de usar NoSQL
Personalmente, pienso que los servicios NoSQL son mejores para el escalamiento horizontal o en sistemas distribuidos ya que no tienen un esquema fijo y puede adaptarse mientras el software crece.
cuando pablo habla acerca de los indices, que deben ser usados bien es porque con ellos ganamos rendimiento a la hora de lecctura en las tablas, pero el costo es que estas agregando complejidad a la hora de la escritura
ya que los indices literal son estructuras de datos que nos ayudan a la busqueda rapida, cuando esa estrucutura se tiene que atualizar (por cada registro agregado) entonces le costara mucho trabajo modificar dicha estructura.
Usa los indices sabiamente
Cuando estamos escalando una aplicación, también tenemos que escalar datos. ¿Qué tipo de escalado deberíamos hacer en el motor de bases de datos?
Escalar en bases de datos siempre ha sido un problema, no es algo fácil y no es un problema fácil de resolver; es un problema relacionado con el equipo de SRE y SysAdmins.
Algo que debemos tener muy presente, y por lo que se tiene que preocupar el equipo de desarrollo es por usar correctamente los índices.
Una buena opción para escalar sistemas de bases de datos es utilizar réplicas de lectura. Es básicamente la creación de distintos servidores en donde, algunos se encargan de lecturas y escrituras, y otros se encargan solamente de las lecturas. Esta es una buena implementación en la mayoría de los casos, puesto que por lo general las aplicaciones suelen realizar más lecturas que escrituras en los sistemas de bases de datos. Siendo así, al multiplicar los servidores, se distribuye mucho mejor la carga.
Con respecto a los sistemas de bases de datos NoSQL, lo más común es hacer sharding, que es básicamente separar varias partes de la bases de datos en varios servidores. De esta manera, podemos tener colecciones que no interactúan tanto con las otras separadas en distintos servidores. Así podríamos escalar horizontalmente nuestros servidores de bases de datos.
Escaladores automáticos
Esto generalmente está más relacionado con el orquestador. El orquestador es quien se encarga de manejar los servidores en donde está corriendo nuestra aplicación, y estos servidores comúnmente son contenedores que pueden estar corriendo en muchos servidores. Este orquestador se va a encargar de decidir cuándo nuestra aplicación tiene que escalar horizontal o verticalmente; pero somos nosotros quienes definimos cuándo se debe escalar.
Nuestra aplicación puede escalar de diferentes formas. Lo más común es escalar usando CPU o memoria como una métrica, y el orquestador conoce el comportamiento de estos recursos debido a que cuenta con un sistema integrado de monitoreo. Sin embargo, muchas veces desearemos escalar basándonos en otras métricas (pueden ser métricas de aplicación: cantidad de peticiones que llegan a nuestro servicio, cantidad de datos procesados, etc.). Otro ejemplo para esto puede ser una cola de mensajes; últimamente se maneja mucho la comunicación asíncrona entres servicios: un servicio recibe una petición, y en lugar de hacer otra petición a otro servicio que puede estar ocupado, la petición es almacenada en una cola de mensajes. De esta forma podemos escalar independientemente: puede que el servicio que recibe las peticiones no necesite tantos recursos, entonces podríamos utilizar la cola de mensajes para escalar el servicio que va a procesar estos mensajes.
Estos son varios ejemplos que podemos utilizar para escalar nuestra aplicación.
Super aporte, esta Genial
Muchas gracias Juan David Cajamarca Acuña
Uff, men, aportazo!
Qué métricas usar para escalar
En el curso de bases de datos de aws hablan sobre las estrategias para aumentar el performance, tal como dice Pablo el uso de replicas de lectura. Acá les dejo la clase https://platzi.com/clases/1426-db-aws/15232-estrategias-de-performance-en-rds/
Escalado en motor de bases de datos
SQL
Escalado complicado, replicas de lectura consiste en crear dos servidores uno con posibilidad de escritura y lectura y el otro sólo con posibilidad de lectura ya que es lo que generalmente más se usa para distribuir la carga, proxy para automatizar
No SQL
Lo más común es hacer una separación de la base de datos en diferentes servidores, es importante que los datos no se requieran entre si
Orquestador encargado de manejar los servidores que corren mi aplicación, estos servidores generalmente son contenedores
Métricas
Les recomiendo ProxySQL
Para los casos en los que se realiza el escalamiento de bases de datos SQL el uso de replicaciones pueden generar Consistencia Eventual, ¿como se vende a los ejecutivos este concepto? ya que para una persona del negocio el concepto puede ser preocupante.
Hola Rodmy! Asumiré que con "ejecutivos" te refieres a las personas encargadas de vender la idea? Si así fuese, me sentaría con ellos y les explicaría las implicancias del uso de replicaciones y que toca considerar un costo adicional para resolver los posibles issues. A mi entender, dado que ninguna tech es infalible, mas bien corresponde asistir a que se pueda tener la estructura de costos tan claro como sea posible!
Saludos!
Imagina una tienda online en Black Friday: el tráfico se dispara. No miras solo cuánta gente entra (Requests Per Second), sino cuánto tarda en cargar la página (latencia) y si los servidores empiezan a ahogarse (uso de CPU al 90% constante).
Esas tres métricas te dicen exactamente cuándo escalar antes de que el sistema colapse.
Para escalar, el foco no está en medir todo, sino en lo que delata el cuello de botella.
Métricas Críticas de Sistema
Indicadores de Saturación
Usar orquestadores como kubernetes para escalar automáticamente.
Gracias
Buenas recomendaciones, casi siempre es por capacidad de los recurso-.