Dimensionar MySQL y Frontales

Hola a tod@s:

Estoy buscando ayuda para solucionar unos "pequeños cálculos" que no encuentro cómo realizar. A ver si hay algún experto que me pueda dar sus estimaciones o alguien me puede decir dónde o cómo aprender a hacerlos.

Os pongo en antecedentes rápidamente. Estoy montando una aplicación web que va a funcionar, o eso espero, tirando de Lighttpd y MySQL Cluster (NDB, sí). Ya está, éste es el problema: no sé cómo dimensionar ambos, es decir, tanto los frontales como el cluster, máquina a máquina, para soportar según qué tráficos y peticiones. Obviamente, empezaremos como todo el mundo con cero usuarios, pero no quiero que nos pillemos los dedos y he hecho cálculos para todo. Ya sé que muchos os fijaréis en los números gordos y me diréis que estoy soñando. Pero eso no es relevante, lo relevante es cómo calcular la relación entre tráfico y máquinas. Si llegamos, no llegamos o nos estrellamos ya será otro asunto


1.000 usuarios => 5,25 tx/s => 1,25 KB/s
10.000 usuarios => 52,5 tx/s => 12,5 KB/s
100.000 usuarios => 1.000 tx/s => 240 KB/s
1.000.000 usuarios => 10.500 tx/s => 2.45 MB/s
10.000.000 usuarios => 105.000 tx/s => 24.5 MB/s
100.000.000 usuarios => 1.050.000 tx/s => 245 MB/s

Son estimaciones de cuántas transacciones (tx) por segundo tendría en la base de datos y el total de tráfico por segundo que moverían esas transacciones. Como toda estimación fallará pero la cuestión, como os digo, es: ¿Cuántos frontales necesitaría en cada caso y cuál sería su configuración (RAM, procesadores, balanceo de carga en caso de ser necesario...)? Y ¿cuántos nodos debería tener el Cluster MySQL de cada tipo (API, datos, gestión) y cuál sería su configuración (RAM, procesadores, conexión de Mbit o Gbit...)?

Lo que realmente me gustaría es encontrar la forma de calcular o estimar esto, aunque fuera vagamente, más que alguien me dijera "necesitas esto", porque quiero saber el por qué de las cosas, pero no encuentro información. ¿Alguien me puede decir algo? Aunque no sea la forma de calcularlo, aunque sea sólo su experiencia...

Por cierto, también tengo los tamaños de la base de datos:

1.000 usuarios => Unos 10 MB
10.000 usuarios => Unos 50 MB
100.000 usuarios => Entre 200 y 500 MB
1.000.000 usuarios => Entre 1,5 GB y 2,3 GB
10.000.000 usuarios => Entre 9 y 20 GB
100.000.000 usuarios => Entre 110 y 300 GB

Conforme más se descontrola el número de usuarios, más horquilla veo que me dan los cálculos, pero bueno, es una pista al menos...

Gracias de antemano!!

 

La pregunta que haces, es imposible de contestar sin hacer un análisis de carga de la aplicación en funcionamiento.

Dependiendo del uso de la DDBB puedes necesitar 1, para 100,000 usuarios, si cada usuario hace una sola consulta simple en cada acceso, a un cluster gigante si todos actualizan la DDBB después de hacer un select con joins con los índices mal diseñados.

Las necesidades de plataforma las da el diseño de la aplicación, sin eso no se puede hacer nada.

Un ejemplo, tenemos un cliente con unos 6 millones de vistas mensuales, que está funcionando en un cluster simple, con una instancia para web + otra para DDBB, en cambio otro, con la quinta parte de visitas, necesita una estructura de 6 instancias, 1 de control, 1 para DDBB, 2 para web, 1 para imágenes, 1 para procesos.

A esto le añades, que una aplicación que funciona perfectamente con 1000 o 2000 usuarios, no sirve para 3,000, porque por su diseño tiene techo.

El diseño de plataformas de alto tránsito es un producto, en el que un especialista con experiencia puede analizar tu aplicación y sobre eso, hacer un diseño de la plataforma que necesitas, preparada para crecer en función de tus proyecciones, eso si, tienes que estar dispuesto a pagar lo que vale y te aseguro que los precios son bien altos.

 

Hola ideasmultiples,

Gracias por responder y hacerlo tan rápido. Seguramente estoy hablando desde mi ignorancia del tema y por eso posiblemente no te estoy entendiendo bien o estoy pasando algo por alto, pero cuando dices que no es posible estimar eso sin un análisis de la carga de la aplicación, estoy de acuerdo, y por eso he dado esas cifras.

Sabiendo lo que hace nuestra aplicación y el comportamiento y cosas que puede hacer un usuario hemos sacado unas estimaciones (es decir, hemos hecho cierto análisis de la aplicación y la carga o esa es nuestra impresión) y ciframos la carga en KB o MB por segundo y número de transacciones por segundo. Es verdad que es una media, pero la mayoría de las operaciones serán sólo consultas y creemos que están bastante optimizadas. No obstante también hemos considerado otras operaciones que pueden hacer, las hemos ponderado y hemos tenido en cuenta cuánto movimiento de datos generan, en bytes. Y con todo eso, sacamos esas medias: nº total de transacciones por segundo y carga o peso total medio de por segundo, es decir, cantidad de datos que se mueven con todas esas transacciones.

En definitiva, pensaba que lo que exponía aquí era el resultado de ese análisis que comentas. Por lo que dices entonces, ¿me equivoco y no es esto lo que hace falta para poder estimar qué necesidades hw hemos de satisfacer para dar soporte a una demanda que genere ese tráfico?

Gracias de nuevo!

 

Completamente de acuerdo con ideasmultiples ... es imposible poder hacer estimaciones del rendimiento de un sistema complejo en un cluster con MySQL y las cargas son completamente diferentes para los nodos web que para los nodos MySQL.

Hace poco me tocó implementar un proyecto bastante interesante y que funcionó PERFECTO ... información bastante detallada la puedes encontrar en :

http://www.comunidadhosting.com/102663-post9.html

Pero tal como comento en ese post, era imposible poder garantizar que el sistema soportara la carga de usuarios simultáneos sobre todo cuando el peak iba a llegar en muy pocos minutos ... lo único que podía hacer era ir monitoreando online las cargas e ir obteniendo información estadística que hoy "vale oro" ... pero te aseguro que en la medida que aumentaban los usuarios y la carga subía y subía la tensión era bastante alta, solo cuando se alcanzó el peak y las cargas comenzaron a bajar vino el relajo y las felicitaciones

Por si acaso tenía preparados un par de VM's adicionales para "meterlos" al cluster en unos minutos y también tenía la posibilidad de "meterle" mas cores y/o memoria a cada VM en minutos.

Tampoco he usado MySQL Cluster NDB hasta el minuto y creo que cada vez hay menos posibilidades de que lo vaya a usar alguna vez ... en la medida que estoy usando SAN's duales con discos SAS que integran cache con SSD la confiabilidad, redundancia y rendimiento del sistema es bastante alta

 

Tendrías dos opciones, si dispones de dinero hacer con máquinas físicas, seguro con una máquina de gama media/alta, como front y otra para bd inicialmente, o si andas más escaso buscarte un proveedor que te ofrezca un sistema flexible de crecimiento sobre vps/cloud. saludos.

 

Es mucho mas flexible trabajar sobre instancias que sobre servidores físicos, las instancias te permiten crecer/decrecer o añadir nuevas online de forma instantánea.

Y por cierto, el trabajar con instancias (hablamos de profesionales, no de 4 duros) no es más barato que usar servidores físicos.

 

Mientras más aumenta la cantidad de usuarios simultáneos, más crítico es tener la carga distribuída y balanceada en varios servidores y un cluster de varias máquinas virtuales de menor potencia normalmente va a tener un mejor rendimiento que tener solo un dedicado de mayor potencia y considerando los costos la alternativa puede ser incluso de menor costo.

Mientras mas uso hay de BD, más crítico es el rendimiento y la confiabilidad del sistema de discos y es mucho más probable que un nodo de hardware usado en una máquina virtual cuente con discos SAS, sistemas RAID, controladoras con cache, aceleradores con SSD, etc.

El cluster que describí anteriormente en el link llegó a tener 38 cores y 38 Gb en total y el costo de todo el proyecto fué varias veces inferior a que si se hubiera usado servidores dedicados ... por costo, rendimiento, confiabilidad y flexibilidad la mejor alternativa es lejos un cluster de máquinas virtuales ( no cualquiera obviamente, sino algo parecido a lo que yo usé y que está bastante detallado en el link anterior )

 

Perdonad por no haber dado señales de vida antes. Me ha sido imposible. Esto de lanzar un nuevo negocio consume mucho tiempo y energías.

Muchísimas gracias a todos por vuestras indicaciones y experiencias. Me han sido bastante útiles. Finalmente creo que nos vamos a decantar por usar Amazon. La posibilidad de autoescalado y de montar clusters con máquinas conectadas a 10Gb/s me parece que son adecuadas para empezar con un sistema pequeño, acorde a nuestro tamaño inicial, e ir creciendo conforme vayan surgiendo necesidades, si surgen.

¿Qué os parece? ¿Habéis trabajado con ese sistema o conocéis a alguien que tenga una experiencia en ese sentido? He visto que, por ejemplo, Menéame usa esa opción. Ahora nos faltaría un buen administrador de sistemas que se encargue de todas estas cosas!

 

Amazon para bases de datos de alto rendimiento es muy problemática y muy cara, no te lo aconsejo.

 

Incluso usando HPC (aws.amazon.com/hpc-applications/) habría problemas de rendimiento? Otra cosa es el precio, pero me imagino que cualquier opción para bases de datos de alto rendimiento no será barata , no?

 

Amazon se cae más de lo que parece, y cuando se cae no puedes hacer absolutamente nada, además el rendimiento de las DDBB baja hasta límites inaceptables cuando tienes "vecinos" de alto consumo en tu nodo.

La nube pública no es para DDBB.

 

De nada sirve tener enlaces a 10 Gb/s si el rendimiento de IO es muy bajo, he visto varias pruebas de rendimiento en IOPS de múltiples sistemas cloud y normalmente Amazon es uno de los más bajos, lamentablemente no tengo esa información disponible en este minuto pero la voy a buscar para publicarla "a la brevedad".

Respecto a los HPC de Amazon están orientados a otro tipo de aplicaciones, básicamente cuando se requiere un alto volúmen de cálculo numérico con muchos Teraflops, pero para poder aprovechar al máximo las GPU de NVidia es necesario utilizar software especializado que soporte la programación CUDA, sino no se gana mucho ... todo eso sin contar que el HPC más básico de Amazon "no debe ser muy barato"

Y cuando tengas algún problema por una caída de Amazon solo te sirve rezar ya que normalmente sistemas tan complejos son muy difíciles de recuperar y no creo que el soporte sea tan eficiente como otras alternativas ... creo que aún estoy esperando por un ticket de una consulta técnica hecha hace como 2 meses ... y para el soporte Basic de AWS el tiempo de respuesta es "desconocido"
http://aws.amazon.com/es/premiumsupport/

Aunque obviamente y sobre todo al comienzo lo más probable es que Amazon es una buena alternativa ... por rendimiento, costo, soporte, confiabilidad y sobre todo "portabilidad" no creo que sea la mejor opción.

Te comento mi experiencia respecto a la portabilidad, hace mucho tiempo y después de analizarlo muy detalladamente opté por utilizar exclusivamente CentOS + cPanel lo que me da la gran ventaja de poder montar y/o migrar el mismo dominio y en pocos minutos sobre innumerables plataformas ... algunas de las que he probado en todos estos años : containers Virtuozzo, Xen, Citrix XenServer, KVM, 3Tera Applogic, OpenVZ, etc ... y sobre innumerables plataformas de hardware hasta "monstruitos" con 64 cores Xeon o clusters de hasta 8 VM's con más de 48 cores Xeon ... o sistemas de discos con RAID-10, RAID-50, RAID-6, SAN, SAN duales active/active, etc. ... reitero que es migrando "el mismo dominio" sin hacer absolutamente ninguna modificación ... y si un cliente necesita alto rendimiento de IO para MySQL tomo el dominio y en unos minutos lo subo a un VM con tarjetas Fusion-io que me entregan hasta 10.000 IOPS ... eso es unas 100 veces lo que podría entregar Amazon o un cloud tradicional

No me quiero ni imaginar lo que habría que hacer para migrar un sistema "básico" montado sobre Amazon usando EC2 + EBS + RDS + S3 ... en general las plataformas propietarias limitan muchísimo la portabilidad y al menos a mi eso no me gusta ... pero sobre gustos ya todos sabemos que no hay nada escrito

 

Encontré el link con estadísticas de IOPS de los principales sistemas cloud, aunque es del 2010 creo que muchas cosas no han cambiado tanto y es plenamente válida la comparación :

http://blog.cloudharmony.com/2010/06/disk-io-benchmarking-in-cloud.html

La mayoría tiene IOPS en el rango de 30 a 100 y calculo que en promedio deben estar alrededor de 50 IOPS ... algo que para un sistema de BD de alto tráfico obviamente no es muy recomendable

Si alguien encuentra otra tabla de benchmarks mas actualizada podria agregarla a continuación, creo que con los nuevos sistemas que incluyen aceleradores SSD debería mejorar el rendimiento.