Qué métricas usar para escalar

Sino estas decidido si usar SQL o NoSQL, preguntate que operacion realizara mas tu app:

• Si sera mas de lectura deberias usar NoSQL, por ejemplo twitter donde hay millones de usuarios leyendo tweets que usuarios escribiondolos
• De lo contrario deberias usar SQL

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

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.

• Generalmente y de una manera manual, los desarrolladores pueden realizar las operaciones de lecturas a una réplica de lectura y las operaciones de escrituras a un servidor de escritura.
• De manera automática, se puede interponer un proxy que nos ayudará a distribuir las operaciones de lectura y escritura de una manera inteligente; sin embargo, es una buena práctica la implementación manual de esta estrategia.

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.

Qué métricas usar para escalar

• Existen dos tipos de bases de datos
  • SQL
    • Escalar este tipo de sistemas es muy dificil → normalmente lo hace el equipo de sysadmin o el equipo de SRE
    • Se puede usar el patrón master slave, pero implica la consistencia eventual, es decir, puede que exista inconsistencia en las slaves una vez se haya hecho una escritura en la master, puede pasar un tiempo hasta que esta inconsistencia desaparezca.
  • NoSQL
    • Para escalar, es común hacer sharding
      • Consiste en separar tu base de datos en distintos servidores o bases de datos. Por ejemplo, si dos tablas no tienen que ver la una con la otra, es decir, no tienen relaciones, pueden estar en dos bases de datos distintas. De esta manera el tráfico que tiene que ver con una tabla, no afecta al tráfico, totalmente independiente, de la otra tabla.
      • Permite escalar horizontalmente
  • Independiente del tipo de base de datos que se escoja, es super importante escoger bien los índices
  • Ambos tipos de bases de datos se pueden escalar usando réplicas de lecturas
    • Un servidor encargado para las escrituras y otro para las lecturas
    • Es común que las lecturas sean mucho más frecuentes que las escrituras
    • Se puede usar un proxy intermedio que ayude a identificar las peticiones de lectura y escritura, para que las redireccione al componente adecuado
• Escalar automáticamente → normalmente, de esto se encarga el orquestador
  • El orquestador se encarga de manejar los servidores que están corriendo en la aplicación
  • Estos servidores son normalmente contenedores
  • El orquestador decide cuándo se debe escalar vertical u horizontalmente
  • El desarrollador debe decirle al orquestador que necesita escalar
  • Métricas para escalar
    • El orquestador tiene un sistema de monitoreo integrado que le permite ver, por ejemplo, el uso de CPU o memoria utilizado por cada servidor y evaluar si necesita escalar, ya sea vertical y horizontalmente
    • Latencia
    • Capacidad
      • Número de peticiones que se pueden resolver en determinada cantidad de tiempo
    • Existen criterios de aceptación o atributos de calidad para cada una de estas méticas, si ya no se cumplen, entonces quizá sea momento de escalar
      • Por ejemplo, que con un número concurrente de cien mil usuarios haciendo peticiones al componente A, estos reciban su respuesta en menos de un segundo. Si esto ya no se cumple, quizá toca escalar el componente de A de alguna manera
    • También pueden ser métricas de aplicación
      • Cantidad de request que están llegando a nuestro servicio
      • Cantidad de datos que hay que procesar
• Colas de mensajes → normalmente se usa en arquitecturas orientadas a eventos y permite la comunicación asíncrona entre servicios
  • Un servicio o componente recibe una petición, y dicha petición requiere del servicio de otro componente, pero puede que este componente esté ocupado, por lo que se deja dicha petición en una cola de mensajes, entonces la petición espera en la cola hasta que el componente ocupado se desocupe y pueda sacarla de la cola.
  • Esto permite escalar el componente que está suscrito a la cola de manera horizontal y vertical.

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/

Les recomiendo ProxySQL

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

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

• Lo más común es escalar con un dato de uso de la máquina, si por ejemplo el servidor está usando mucha CPU o mucha Memoria el orquestador se entera de eso ya que tiene un servicio propio de monitoreo y lo que hace es crear nuevos servidores o los hace crecer.
• Otra forma de escalar es con la cantidad de request que está recibiendo mi aplicación
• Cola de mensajes para escalar independientemente cuando se crea debido a que el servidor no está disponible en ese momento

Gracias

Buenas recomendaciones, casi siempre es por capacidad de los recurso-.