El costo de no administrar adecuadamente su base de datos MySQL

Todos los días, se desperdician cientos de millones de dólares, lo que permite que los sistemas mal configurados o mal configurados, la infraestructura mal entendida y las operaciones de TI ineficientes vivan y prosperen en los centros de datos de todo el mundo. Hay costos directos e indirectos asociados con permitir que estos sistemas insalubres continúen existiendo. Vamos a ver.

Instalación:

Comencemos con un pequeño ejemplo. Comenzaremos observando una pequeña configuración de base de datos. Esta configuración tendrá un solo maestro-esclavo, con un tamaño de base de datos de 500 GB. El tráfico es estable y decimos que esto se traduce en 500 IOPS en el maestro. Ha elegido alojar esto en AWS de Amazon. Una forma habitual de garantizar las copias de seguridad en AWS es instalar instantáneas esclavas de ebs. En cuanto al uso, suponga que su CPU se utiliza en un 50 % y tiene unos 20 GB de datos activos que deberían estar en la memoria de la base de datos.

Si observa lo que EC2 necesita admitir, está viendo esto:

  • 2 servidores c3.4xlarge (16 vcpu, 30 GB de memoria)
  • Conjunto maestro-esclavo
  • con 1 TB de SSD IOPS provisionadas, más de 2 volúmenes
  • con 500 IOPS en el maestro, 125 IOPS en el esclavo
  • 7 TB estimados de almacenamiento para instantáneas

Esta calculadora nos da un costo estimado de $3,144.28 por mes, o alrededor de $38,000 por año en cuota de hospedaje. Tenga en cuenta que puede elegir otros niveles de servicio, o servidores reservados o lugares para obtener diferentes precios.

Crecimiento regular y constante:

Ahora suponga que su base de datos crece con su tráfico en aproximadamente un 5% por mes (estos son números grandes, lo sé). Después de un año, su servidor de base de datos estaría fuera de servicio utilizando un 86 % de la CPU, 34 GB de datos activos (así que confíe más en el espacio en disco) y consuma solo alrededor de 850 GB de espacio de almacenamiento. Pasando al siguiente nivel de servidores y con iops adicionales, verá que sus gastos mensuales aumentan a aproximadamente $ 4,771.32 por mes ($ 57,000 por año).

Al ajustar y auditar un entorno como el anterior, podríamos ofrecer a algunos clientes hasta un 50 % o más de mejora en el rendimiento y, a menudo, ver una reducción del 20-25 % en el espacio. Somos conservadores y decimos que podemos obtener un aumento del 25 % en su rendimiento, reducir su crecimiento mensual del 5 % al 4 % y reducir su base de datos en un 10 %. En base a esto, puede omitir la actualización de sus servidores durante 9 meses adicionales, ahorrando casi $ 15,000 solo en ese primer año. Durante 4 años, este cliente termina ahorrando aproximadamente $75 000 en gastos totales en costos de AWS basados ​​únicamente en datos más pequeños y mejoras de rendimiento.

En este caso, las mejoras de rendimiento no son el único lugar para ahorrar costos. Al pasar de las instantáneas de EBS a las copias de seguridad regulares de MySQL usando Percona XtraBackup, manteniendo una copia en el disco y enviando esas copias de seguridad a s3, el costo del entorno se reduce a $ 2043,87 por mes (desde $ 3144,28). Esto quiere decir que un simple cambio en tu metodología de ahorro puede ahorrarte unos $1.100 al mes o $13.200 al año de tu factura de hosting.

imagen 02

Estos números se basan en solo dos servidores, el ahorro de decenas o incluso cientos de servidores puede ser enorme. Eche un vistazo a este entorno de 10 servidores:
imagen 04

A menudo, no solo estamos reduciendo los recursos necesarios, sino que también podemos reducir la cantidad de servidores necesarios para ejecutar su aplicación mediante la optimización. Tuvimos un cliente reciente que pudo ver una reducción del 90 % en su gran carga de trabajo de lectura y, de hecho, deshabilitar los servidores que usaban para atender su aplicación. Estos son sus ahorros durante los próximos dos años:

Ahorro de costos de base de datos - 90% de descuento

Aquí ayudamos a reducir los costos directos de los clientes en dos tercios.

Tratamiento pico:

Lo único a tener en cuenta es que esto supone un crecimiento lineal en cuanto a la aplicación y uso de la base de datos. Esto significa que puede predecir cuándo necesitará hardware. Si su base de usuarios está creciendo y la adición de funciones está controlada, es posible, pero en la mayoría de los entornos no verá ese crecimiento lineal. Probablemente veas algo como esto:

Carga de trabajo de base de datos - Ahorro de costos

Comprenda este patrón y los picos son vitales para mantener sus costos. ¿Ves ese pico gigante hasta 2500? La primera reacción para muchos es actualizar su hardware y luego sintonizar. Inevitablemente, los beneficios de ajuste se ven contrarrestados por el bajo costo de las actualizaciones de hardware que no necesita después del ajuste. Adelantarse a ese pico y prevenirlo podría haber ahorrado decenas o incluso cientos de miles de dólares.

Los picos matan el rendimiento y cuestan dinero real. Esas piezas pueden no ser fáciles de encontrar. Hace unos años estaba trabajando con un cliente de Fortune 500 que tenía uno de estos picos. Habían funcionado perfectamente bien con un crecimiento constante pero controlable durante 7 u 8 meses, después del noveno mes las cosas se pusieron muy mal muy rápidamente.

Un componente crítico de su empresa era certificar profesionales a través de una aplicación de prueba. Durante su temporada alta, estas certificaciones cesaron por completo, lo que retrasó las certificaciones de miles de empleados y clientes durante 2 semanas. Me sacaron para ayudar a controlar el sangrado y, con suerte, resolver el problema.

La cantidad de usuarios que usaban la aplicación era la misma, la cantidad de páginas vistas en la web se mantenía estable, pero la cantidad de consultas a la base de datos estaba descubierta. Ninguna de las preguntas había alcanzado su umbral de 1 segundo para ser marcada como pregunta problema. Resultó ser una solicitud que tardó 250 ms en ejecutarse lo que provocó el arresto de esta empresa. Esta solicitud se ejecutó 25 000 veces por página cuando se cumplieron ciertas condiciones, y estas condiciones no se cumplieron hasta el noveno mes después de que se lanzó esta solicitud.

Esta demanda era como un caballo de Troya que esperaba destruir la capacidad de esta empresa para cumplir con sus clientes.

De esto se pueden aprender dos lecciones. El primero es también un sistema aparentemente bien afinado que puede no serlo. En segundo lugar, las cosas pequeñas importan. En este caso, la corrección del código es la solución correcta, sin embargo, la indexación adecuada de las tablas redujo el tiempo de solicitud de 250 ms a 50 ms. Esto fue un alivio suficiente para permitir que se reanudara el proceso de certificación hasta que se pudiera reparar el código. Una demanda aparentemente de bajo impacto siempre debe optimizarse.

Otra fuente de estos picos de rendimiento es el ciclo de lanzamiento de aplicaciones de la empresa. Las aplicaciones son en gran medida una entidad viva en el mundo de hoy. Crecen, se expanden y cambian de forma regular. Para anticiparse a cualquier problema, debe contar con un proceso y recursos que pueda monitorear y sintonizar de manera proactiva. Cada lanzamiento del nuevo código debe pasar por una revisión de rendimiento rigurosa para evitar problemas de troyanos que pueden causar problemas y costos adicionales en el futuro.

Los costos indirectos son difíciles de calcular:

Toda esta discusión hasta ahora se ha centrado en los costos directos de hospedaje. También hay un costo para su reputación y su capacidad para brindar servicios que satisfagan las expectativas del cliente. Los clientes que visitan su sitio o usan su aplicación pueden irse en masa debido al bajo rendimiento. Hemos visto muchos clientes que han perdido el 50 % o más de su base de usuarios debido a problemas de rendimiento con la aplicación.

La pérdida de ingresos y ganancias suele ser mucho más difícil de cuantificar y varía mucho de una empresa a otra. Este costo, sin embargo, es muy real. Silicon Valley está atascado con los restos de empresas que no pensaron en abordar la escala o simplemente carecían de problemas importantes en su infraestructura de TI. Desafortunadamente, he trabajado directamente con numerosas empresas que han aprendido esta lección con dificultad. Estos costos ocultos pueden matar a un cliente más rápido que cualquier competidor o cambiar en el mercado.

Uno de los mayores costos ocultos que las empresas pagan innecesariamente es el costo del tiempo de inactividad.

Costo del tiempo de inactividad:

Estuve leyendo un estudio de Gartner donde estimaron que el costo por minuto de inactividad era de $5,600; otros estudios, como esta, han fijado el costo por minuto de tiempo de inactividad en $ 7,900.

Sin embargo, reducirlo aunque sea por un minuto le costará dinero. Si somos conservadores en nuestras estimaciones, el costo de una hora de tiempo de inactividad puede superar fácilmente los $ 100,000. Es sorprendente la cantidad de empresas bien establecidas que no tienen un plan sólido para lidiar con el tiempo de inactividad.

Estas son algunas políticas comunes de recuperación ante desastres:

Reinstalar desde el respaldo:

¿Con qué rapidez se puede notificar a sus DBA sobre una interrupción, luego aceptar observar la interrupción y finalmente hacer una llamada para restaurar o no? Supuse que la mayoría de la gente tardaría unos minutos en recibir una alerta (digamos 2). Luego pueden tomar unos minutos para llegar a la computadora y al sistema (digamos 5 minutos). Luego tomará al menos 10 minutos tratar de entender lo que está sucediendo. Avance rápido 17 minutos después… Se pasa el mínimo sin nada que mostrar.

La restauración de la copia de seguridad en sí puede tardar unos minutos o varias horas. Dijimos solo 40 minutos en total. Si usamos ese número de $ 7,900, es posible que haya perdido $ 316,000. Es una cantidad enorme que podría evitarse fácilmente. Tal vez sepa que no está perdiendo $ 7,900 por minuto, tal vez solo sean $ 1,000. ¡Sigue siendo $ 40,000!

Fallo manual de un esclavo:

El tiempo para obtener, reaccionar y actuar no cambia en esta ecuación. El tiempo original de 17 minutos (mínimo) para reaccionar y comenzar a resolver solo le costará potencialmente $ 134,300.

Conmutación por error automatizada:

No todas las conmutaciones por error automatizadas son iguales. Algunas soluciones pueden tardar de varios minutos a incluso horas en restaurar el servicio adecuado (tiempo de calentamiento esclavo frío pasivo). El hecho de que creas que estás a salvo no significa que estés a salvo. Tener la solución automatizada correcta puede significar minimizar sus riesgos de tiempo de inactividad a $ 10K o menos, tener la incorrecta puede ser peor que no tener ninguna.

Es importante comprender el costo del tiempo de inactividad y elegir la solución adecuada para mitigarlo.

El costo de equivocarse es alto:

Estos son solo algunos de los costos en los que las empresas pueden incurrir al obtener la base de datos y la configuración de infraestructura incorrectas. Mitigar estos costos requiere un proceso sólido, un alto nivel de experiencia y los recursos adecuados en el lugar.

¿Listo para leer más? Consulte nuestra publicación El impacto del tiempo de inactividad en su negocio

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario