Planificación de capacidad para bases de datos

Nota: Esta publicación está inspirada en la publicación reciente de Julia Evans sobre la planificación de la capacidad.

RDBMS

Primero, establezcamos algunas reglas básicas. Sí... esta publicación está dirigida a aquellos de nosotros que usamos MySQL con un solo escritor a la vez y 2 o más réplicas de lectura. Mucho de lo que hablaré aquí se aplica de manera diferente, o no se aplica en absoluto, a los almacenes de datos en clúster de múltiples escritores, aunque estos también vienen con su propio conjunto de compromisos y advertencias. Entonces... su millaje definitivamente variará.

Sin embargo, esta publicación de blog SE APLICARÁ independientemente de si utiliza hosts físicos autohospedados o está en AWS, donde puede usar instancias reservadas mágicas y un aprovisionamiento casi instantáneo. Estar en “la nube” no le impide conocer las capacidades y límites de su infraestructura y no le absuelve de esa responsabilidad hacia su equipo y clientes.

fragmentación

Ya he cubierto grandes trazos de esto en una de mis publicaciones anteriores, me enfoqué principalmente allí en los beneficios de la fragmentación funcional u horizontal. Sí, ese es un requisito previo absoluto, ya que lo que use para acceder a la capa de la base de datos DECIDIRÁ cuánta flexibilidad tiene para escalar.

Si es una empresa nueva, es posible que no necesite la fragmentación funcional el día 1, pero si espera (y sospecho que lo hace) crecer, no se encierre en un ORM de código abierto que no le permitirá dividir sus datos sobre una base funcional en el futuro. Puntos de bonificación si tampoco inicia su empresa con todos sus datos relacionales en un solo esquema.

Capacidad para dividir lecturas y escrituras

Esto es algo que deberá poder hacer, pero no necesariamente imponerlo como una regla escrita en piedra. Habrá casos de uso en los que se deba leer una escritura muy poco tiempo después y en los que la tolerancia a cosas como el retraso o la consistencia eventual sea baja. Está bien tenerlos, pero en las mismas aplicaciones, también tendrá escenarios para lecturas que pueden tolerar un período de tiempo más largo de consistencia eventual. Cuando tales lecturas están en gran volumen, ¿realmente desea que ese volumen vaya a su único escritor si realmente no es necesario? Hágase un favor y asegúrese de que pronto en sus días de crecimiento pueda controlar el uso de una IP de lectura o escritura en su código.

Ahora, en el proceso de pensamiento de la planificación de la capacidad real... Un clúster de base de datos no se mantiene al día, ¿qué debo hacer?

Determinar el cuello de botella del sistema.

• ¿Tiene cuellos de botella en escrituras o lecturas?
• ¿El problema se muestra como CPU alta?
• ¿Está exhibiendo como capacidad IO?
• ¿Está aumentando el retraso en las réplicas sin un culpable de consulta de lectura clara?
• ¿Son cerraduras?
• ¿Cómo puedo saber cuál es?

Cada uno de estos puede ser una publicación por sí mismo. El punto que estoy tratando de hacer es que debe estar familiarizado con su sistema y las métricas específicas de la base de datos para poder descubrir qué pieza es el cuello de botella.

Necesitas una línea de base

Siempre asegúrese de tener métricas básicas del sistema disponibles para visualizar durante al menos unas semanas atrás. Muchas herramientas proporcionan esto (Cacti, Munin, Graphite…etc). Una vez que sepa a qué métrica del sistema está vinculado principalmente, debe establecer valores de referencia y máximos. De lo contrario, determinar si su problema actual es un nuevo error originado en la aplicación frente a un crecimiento real será mucho más propenso a errores de lo que le gustaría.

Sin embargo, las métricas básicas del servidor solo pueden llegar hasta cierto punto: en algún momento encontrará que también necesita métricas basadas en el contexto. El rendimiento de las consultas y el rendimiento percibido del lado de la aplicación le dirán lo que la aplicación ve como tiempo de respuesta a las consultas. Hay muchas herramientas para hacer este seguimiento intensivo del contexto. Algunos son de código abierto como Anemometer y herramientas comerciales como Vivid Cortex (los usamos en SendGrid. Véanos hablar sobre esto aquí). Incluso el simple seguimiento de estas métricas desde la perspectiva de la aplicación y lanzarlas como métricas statsd será un buen primer paso. Pero, desde el principio, debe acostumbrarse al hecho de que lo que percibe su aplicación es lo que perciben sus clientes. Y primero debes encontrar una manera de saberlo.

Conozca los patrones de tráfico de su negocio

¿Es su empresa susceptible a picos extremos en días específicos de la semana (por ejemplo, marketing)? ¿Tiene lanzamientos regulares que triplican o cuadruplican su tráfico como los juegos? Este tipo de preguntas determinará la cantidad de espacio libre reservado que debe mantener o si necesita invertir en un crecimiento elástico.

Determinar la proporción de números de tráfico sin procesar en relación con la capacidad en uso

Esta es simplemente la respuesta a "Si no hicimos optimizaciones de código, ¿cuántos correos electrónicos/ventas/usuarios en línea/lo que sea" podemos servir con las instancias de base de datos que tenemos ahora?

Idealmente, este es un valor específico que hace que las matemáticas para planificar el crecimiento de un año sean una ecuación matemática simple. Pero la vida nunca es ideal y este valor variará según la temporada o factores felices completamente externos, como la inscripción de un nuevo cliente importante. En las primeras empresas, este número es un objetivo de movimiento más rápido, pero debería estabilizarse a medida que la empresa pasa de los primeros días a un negocio más establecido con patrones de crecimiento empresarial más predecibles.

¿Realmente necesito comprar más máquinas?

Debe encontrar una manera de determinar si esto es realmente capacidad: necesito dividir las escrituras para admitir una carga de escritura más simultánea o agregar más réplicas de lectura vs. cuello de botella de rendimiento basado en código (esta nueva consulta de una implementación reciente realmente puede tener sus resultados almacenados en caché en algo más barato y no superar tanto a la base de datos).

¿Cómo haces eso? Necesita familiarizarse con sus consultas. El pequeño paso para eso es una combinación de innotop, registro lento y pt-query-digest de Percona Toolkit. Puede automatizar esto enviando los registros de la base de datos a una ubicación central y automatizando la parte del resumen.

Pero esa tampoco es la imagen completa, los registros lentos requieren un rendimiento intensivo si reduce demasiado su umbral. Si puede vivir con un muestreo menos selectivo, deberá detectar todas las conversaciones entre la aplicación y el almacén de datos. En la tierra de código abierto, puede ir tan básico como tcpdump o puede usar productos alojados como Datadog, New Relic o VividCortex.

Haz una llamada

La planificación de la capacidad puede ser un 90 % ciencia y un 10 % arte, pero ese 10 % no debería significar que no debamos esforzarnos por obtener la mayor cantidad posible de la imagen. Como ingenieros, a veces podemos obsesionarnos con el 10 % que falta y no darnos cuenta de que, si hicimos el trabajo, ese 90 % puede darnos una mejor idea de la salud de nuestra pila, un uso más eficiente de nuestro tiempo, optimizar el rendimiento y planificar la capacidad. aumenta cuidadosamente, lo que eventualmente resulta en un mejor retorno de la inversión para nuestros productos.