Cómo construimos de cero el sistema de evaluación de capacidad de bases de datos de Meituan

1. Contexto del proyecto

La base de datos es el pilar central de cualquier sistema de negocio; su importancia no necesita explicación. A medida que la escala del negocio y la influencia social de la empresa siguen creciendo, las exigencias sobre la estabilidad de la base de datos también alcanzan niveles sin precedentes. En el trabajo diario de garantizar esa estabilidad, el equipo de bases de datos de Meituan enfrenta varios problemas recurrentes:

Problema 1: durante los períodos de actividad intensa es difícil estimar con precisión el límite superior de capacidad de lectura/escritura de un clúster, lo que puede derivar en incidentes de producción por falta de capacidad.

Los métodos habituales de evaluación de capacidad son el cálculo de métricas y las pruebas de carga de extremo a extremo:

• Cálculo de métricas: compara indicadores de carga contra umbrales para determinar si un nodo está saludable, pero el tráfico y las métricas relacionadas no tienen una relación estrictamente lineal, por lo que predecir el límite de capacidad a partir de métricas no es muy preciso.
• Pruebas de carga de extremo a extremo: graban el tráfico de negocio de capas superiores y lo reproducen, lo que permite detectar cuellos de botella en toda la cadena de servicio. Pero el tráfico de base de datos se ve afectado por la complejidad del escenario de prueba y la riqueza de las muestras, entre otros factores, por lo que es difícil lograr una simulación completamente fiel, y conectar los servicios de negocio a las pruebas de carga tiene un costo de adaptación no menor.

Problema 2: los cambios en la base de datos son una de las principales causas de incidentes en producción, y los cambios de riesgo son difíciles de identificar.

Las soluciones habituales son la interceptación por reglas fijas y las pruebas fuera de línea:

• Interceptación por reglas fijas: integra reglas de interceptación en la plataforma de cambios para juzgar el riesgo según reglas predefinidas. Pero cambios habituales como agregar un índice o modificar el tipo de un campo normalmente no se interceptan, y ese tipo de cambios puede degradar la eficiencia de ejecución de SQL, provocando caída de rendimiento o incluso caída del sistema.
• Pruebas fuera de línea: identifican riesgos probando en un entorno separado, pero pueden diferir de los datos reales de producción y no ser lo bastante exhaustivas como para detectar todos los riesgos potenciales.

2. Objetivo del proyecto

Construir un sistema de evaluación de capacidad de bases de datos que, usando reproducción de tráfico real de producción, arme un sistema completo de evaluación de capacidad y ofrezca soporte de datos científico y base de decisión para la planificación de capacidad. Al construir el sistema se plantearon estos requisitos básicos:

• Seguridad en la operación de datos: como la base de datos es un componente central del negocio, el proceso de reproducción y evaluación no puede afectar la operación normal del clúster en producción.
• Resultados de evaluación fieles: hace falta usar tráfico y entornos completamente fieles a la realidad para evaluar la capacidad de lectura/escritura del clúster, con un mecanismo confiable que garantice la validez y precisión de los resultados.
• Sistema flexible y eficiente: se necesita capacidad de automatización eficiente, junto con alta flexibilidad, de modo que las capacidades base puedan integrarse rápidamente en distintos sistemas de forma modular (plug-in) para habilitar la funcionalidad de reproducción y validación.

3. Panorama de capacidades

• Plataforma de pruebas de carga: el portal de interacción del usuario con el sistema, con páginas para reproducción de tráfico, sondeo de capacidad, operación de capacidad y calibración de presupuesto.
• Habilitación externa: los servicios externos pueden aplicar la capacidad de reproducción a través de la interfaz estandarizada (OpenAPI) que ofrece el sistema de programación, habilitando la reproducción de tráfico de base de datos para otros equipos.
• Funciones núcleo: el sistema cubre tres escenarios clave —reproducción de tráfico, sondeo de capacidad y operación de capacidad— que en conjunto forman una capacidad de gestión de capacidad de extremo a extremo, desde la prueba hasta la operación.
• Capacidades base: la capacidad base de reproducción de tráfico usa una arquitectura modular, con una división clara de responsabilidades que mejora considerablemente la operabilidad de la reproducción.
• Tipo de pruebas de carga: la capacidad de reproducción de tráfico de base de datos no tuvo límites desde el diseño inicial; cualquier base de datos de prueba o componente periférico que soporte el protocolo SQL puede adaptarse para ser compatible.

A continuación, combinando escenarios reales de aplicación de bases de datos en producción, se explican en detalle las tres funciones núcleo del sistema —reproducción de tráfico, sondeo de capacidad y operación de capacidad— y sus respectivas implementaciones.

4. Reproducción de tráfico

La precisión de la evaluación es uno de los indicadores más importantes del proyecto. Grabamos el tráfico en línea, construimos un entorno sandbox y ejecutamos la reproducción de tráfico para evaluar el rendimiento del clúster de base de datos. En el mundo de las operaciones de base de datos, los cambios son operaciones frecuentes y de alto riesgo —ajuste de parámetros, optimización de consultas lentas, actualizaciones de versión—, así que ¿cómo evaluar el efecto y la estabilidad después de un cambio? A continuación lo mostramos con un caso real: la reproducción de tráfico.

Diseño de arquitectura

Grabamos el tráfico de base de datos en producción y lo reproducimos de forma fiel en un clúster sandbox aislado, construyendo así una capacidad completa de reproducción y análisis de tráfico. Este enfoque ofrece un entorno de prueba sandbox seguro y confiable para los cambios operativos, permitiendo validar el plan de cambio bajo condiciones que simulan el tráfico real, reduciendo de forma efectiva el riesgo en el entorno de producción.

Completar una prueba de reproducción de tráfico completa requiere cuatro procesos núcleo:

Recolección de tráfico (Traffic Collect)

Este proceso graba el tráfico en línea y provee el SQL original para la reproducción posterior, con tres módulos importantes:

• Recolección de datos: el kernel MTSQL, desarrollado internamente, recolecta el texto completo de cada SQL, el ID de transacción y el tiempo de ejecución, entre otros datos, y el recolector (rds-agent) los envía al Kafka del backend.
• Limpieza de datos: con Flink se construye una cadena de limpieza sobre el flujo completo de SQL, consumiendo la cola Kafka de SQL completo y filtrando la información SQL de los clústeres registrados para reproducción.
• Almacenamiento de datos: la información SQL original se estructura y se escribe en ClickHouse, lo que permite procesar eficientemente grandes volúmenes de datos SQL y da capacidad de extensión para organizar de forma flexible los archivos de tráfico.

Procesamiento de tráfico (Traffic Process)

Este proceso agrega, procesa y consolida el tráfico SQL recolectado.

• Agregación de datos: el procesador de archivos de tráfico (sql-log agent) escanea, por rol maestro/réplica, todo el SQL de cada clúster registrado desde ClickHouse.
• Procesamiento de datos: el procesador de archivos de tráfico organiza el SQL de reproducción según el rol maestro/réplica. En el maestro se agrupa por dimensión de transacción, integrando en una sola unidad de ejecución las múltiples operaciones SQL de una misma transacción, para garantizar consistencia y eficiencia; en la réplica se procesa cada SQL de forma independiente, para simular mejor un escenario de lectura de alta concurrencia.
• Consolidación de datos: los datos estructurados procesados se persisten como archivos de tráfico y se suben a S3 para que la reproducción los consuma.

Reproducción de tráfico (Traffic Replay)

Este proceso consume los archivos de tráfico y ejecuta la reproducción en el entorno sandbox:

• replay-agent: es el ejecutor principal de la reproducción, consume en modo streaming los archivos de tráfico almacenados en S3 y, mediante comunicación de datos y algoritmos de control, regula el ritmo de reproducción del SQL, reproduciendo el tráfico de forma fiel en el clúster sandbox aislado.
• Despliegue de carga: el replay-agent se empaqueta y despliega en un clúster de Kubernetes; cada tarea de reproducción crea dinámicamente un recurso Job independiente, con las tres ventajas de aislamiento de recursos, despliegue liviano y programación elástica, capaz de soportar pruebas de carga a gran escala.
• Entorno sandbox: mediante un backup de datos se construye una instantánea completa del momento en que empezó la grabación del tráfico, garantizando que los datos incrementales coincidan durante la reproducción. Antes de reproducir se ofrece una “ventana de cambio operativo” durante la cual el usuario puede completar la simulación del cambio que necesite, como actualizar la versión de MySQL, modificar parámetros o cambiar la estructura de una tabla.

Análisis de datos e informes (Data Analyze & Report)

Este proceso integra la recolección y el análisis de datos, dando soporte de observabilidad multidimensional tanto en producción como en el entorno sandbox:

• Métricas de carga de ejecución: CPU busy, carga del sistema (Load Average), consultas lentas, retraso maestro-réplica, entre otras.
• Información de ejecución SQL: tiempo de ejecución de cada plantilla de SQL.
• Parámetros de entorno: configuración de parámetros núcleo de MySQL, información del tipo de instancia.

Resultados

El informe de análisis de reproducción de tráfico muestra el top 3 de SQL que empeoraron, el top 3 que mejoraron, y una comparación detallada del rendimiento SQL. En un caso real, al activar la compresión de tablas, el tiempo de ejecución del SQL más frecuente pasó de 0,90ms a 0,97ms —sin caída notable— mientras el espacio de almacenamiento usado bajó al 40% del original. Con base en esa conclusión de la prueba de reproducción, el clúster en cuestión activó la compresión de tablas; tras el cambio, el sistema funcionó de forma estable y se alivió el problema de falta de espacio en disco.

En Meituan, la reproducción de tráfico también se usa ampliamente en la validación de rendimiento de cambios de índice y en pruebas de compatibilidad al actualizar la versión de la base de datos.

5. Sondeo de capacidad

El tráfico de los escenarios de cambio descriptos arriba se reproduce a la velocidad real (1x), pero en necesidades de negocio reales los usuarios quieren saber cuál es el QPS máximo que puede soportar un clúster, y cuántas veces el tráfico actual puede soportar como máximo. A continuación lo mostramos con un caso real: el sondeo de capacidad.

Implementación del proceso

El sondeo de capacidad toma muestras de tráfico real recolectadas durante los picos de negocio y ejecuta automáticamente, en el entorno sandbox de prueba, múltiples rondas de reproducción acelerada. Mediante un ajuste progresivo de presión, se acerca gradualmente al límite de rendimiento de la base de datos hasta detectar el QPS máximo de lectura/escritura que puede soportar el clúster.

Criterio de sobrecarga

La capacidad del clúster está estrechamente ligada a las alarmas: el usuario define la política de alarmas correspondiente para su clúster RDS según el escenario de negocio, y que el clúster dispare una alarma indica sobrecarga.

Entorno sandbox

El usuario puede ajustar libremente la configuración del entorno sandbox de prueba según sus necesidades reales —tipo de máquina, versión de MySQL, parámetros núcleo, etc. En el escenario de evaluar el límite superior de capacidad de un clúster en producción, para garantizar que el resultado del sondeo sea más fiel y preciso, se exige que la configuración del clúster sandbox coincida con la del clúster en producción.

Proceso de sondeo

El sondeo de capacidad usa un método de evaluación iterativo: después de cada ronda de reproducción de tráfico, el entorno sandbox revierte automáticamente los datos, el analizador revisa las alarmas de esa ronda y marca si se alcanzó el límite, calculando además la velocidad de reproducción de la siguiente ronda. El proceso de evaluación tiene dos etapas clave:

• Sondeo rápido: el sistema aumenta continuamente la velocidad de reproducción del tráfico, sondeando rápidamente el límite que dispara la alarma mediante presión exponencial, para determinar de forma preliminar el rango del límite de capacidad.
• Calibración precisa: a partir de la velocidad mínima que disparó alarma y la velocidad máxima que no la disparó —los dos valores límite—, el analizador hace un cálculo de bisección para determinar la velocidad de la siguiente reproducción. Cuando se alcanza la precisión predefinida, el ciclo de evaluación termina automáticamente y entrega el resultado final del sondeo de capacidad.

Reproducción a velocidad variable

El sondeo de capacidad ajusta la velocidad de reproducción para simular el crecimiento del tráfico. La reproducción a velocidad variable comprime el intervalo de ejecución de los SQL, aumentando la densidad de solicitudes por unidad de tiempo y, con eso, la presión de carga sobre la base de datos.

Dentro del agente de reproducción, el flujo de procesamiento y reproducción de SQL funciona así: el proceso de reproducción asigna a cada SQL pendiente en el archivo de tráfico una corrutina de ejecución, y dentro de la corrutina la función CalcSendTime controla con precisión la temporización de la reproducción del SQL, mediante este mecanismo:

1. El eje temporal del tráfico original toma como punto de referencia sqlBaseTime. Calculando la diferencia entre el tiempo real de ejecución en producción (sqlinfo.BeginAt) y sqlBaseTime, se obtiene el desfase temporal original de ejecución del SQL, originalDelta.
2. Para lograr la reproducción a velocidad variable, el sistema escala originalDelta según la velocidad de reproducción, obteniendo el desfase temporal planificado ajustado, planDelta (fórmula: planDelta = originalDelta / velocidad de reproducción).
3. Para evitar la distorsión de tráfico que generaría que las corrutinas obtengan y ejecuten el SQL de forma sincronizada exactamente en el instante planDelta, se usa una lógica de pre-obtención asíncrona de SQL: la corrutina asigna de antemano el SQL a ejecutar, registra la hora actual del sistema (time.now) y calcula el desfase real transcurrido desde el inicio de la reproducción, realPassDelta.
4. El sistema compara planDelta con realPassDelta para decidir el momento de ejecución del SQL:
   • Cuando planDelta >= realPassDelta, la corrutina espera el tiempo waitTime de diferencia antes de ejecutar el SQL; idealmente, todos los SQL entran en esta rama de espera.
   • Cuando planDelta < realPassDelta, el SQL se ejecuta de inmediato; si esto ocurre con frecuencia, indica que la concurrencia de procesamiento de la corrutina actual es insuficiente y puede provocar distorsión en la reproducción.

Este mecanismo de control de temporización asegura que el proceso de reproducción de SQL coincida con precisión con la velocidad de reproducción predefinida, logrando así una capacidad confiable de ajuste de velocidad.

Resultados

El informe de sondeo de capacidad muestra el resultado del sondeo y los resultados de las pruebas a distintos múltiplos de velocidad. En un caso real, al reducir la configuración de máquina de un clúster de negocio, la alarma del clúster recién se disparó al superar las 6 veces el tráfico, cumpliendo sobradamente con la necesidad de negocio de soportar 2 veces el tráfico normal; en base a eso se decidió reducir la configuración de ese clúster, y tras el downgrade el servicio funcionó de forma estable.

En Meituan, el sondeo de capacidad también se usa ampliamente en pruebas comparativas de rendimiento de servidores y en la validación del ajuste de parámetros de bases de datos.

6. Operación de capacidad

Ante un evento de negocio, el área de negocio quiere que el DBA le dé una evaluación del estado de capacidad de todos sus clústeres: ¿en qué nivel de agua está el clúster a su cargo? ¿está cerca del cuello de botella o tiene mucho margen? Para esto construimos el servicio de operación de capacidad, que permite monitorear en tiempo real el estado de capacidad de los clústeres.

Diseño de la operación

La operación de capacidad integra tres módulos funcionales núcleo —gestión de evaluación, cálculo de capacidad y operación automatizada—, ofreciendo un punto de entrada cómodo para la observación de capacidad de clústeres a gran escala, y logrando, mediante gestión operativa integral, un ciclo cerrado de operación y gobernanza que mejora notablemente la eficiencia operativa.

Gestión de evaluación

• Admisión de clústeres gestionados: se registran para gestión los clústeres núcleo con un modelo de tráfico estable, y la lista de gestionados se ajusta periódicamente según reglas de admisión.
• Ejecución automática de gestión: todos los clústeres registrados entran automáticamente en la cola de evaluación; el sistema programa y ejecuta de forma unificada las tareas de sondeo de capacidad, y cada clúster termina con un informe de sondeo de capacidad y una evaluación del límite de QPS de lectura/escritura, con fecha de vencimiento; al vencer, se reevalúa automáticamente.
• Actualización de resultados: el sistema revisa periódicamente las diferencias entre la instantánea de configuración usada en la evaluación y la configuración actual del clúster en producción. Si cambia el modelo de tráfico de negocio, la configuración de hardware, la versión, los parámetros o el umbral de alarma, el sistema marca como inválidos los resultados relacionados y vuelve a lanzar la evaluación.

Cálculo de capacidad

• Cálculo del estado de capacidad: nivel de uso de capacidad = QPS del clúster en producción / límite de QPS de lectura-escritura del sondeo. El rango de nivel saludable por defecto es [30%, 50%]; por debajo del límite inferior indica capacidad sobrante, por encima del límite superior indica capacidad insuficiente (no puede soportar el requisito habitual de 2x tráfico del negocio); el nivel de agua se puede ajustar por clúster.
• Cálculo de recomendaciones de capacidad: genera un plan de optimización operativa. Cuando se detectan recursos sobrantes, el sistema calcula qué nodos específicos se pueden reducir manteniendo los requisitos de recuperación ante desastres; cuando detecta recursos insuficientes, calcula automáticamente cuántos nodos hacen falta agregar y sugiere la distribución óptima entre data centers.

Operación automatizada

• Adopción de la recomendación: lógica de interacción de un clic que dispara el flujo de trabajo operativo del backend y ejecuta automáticamente la acción operativa según la recomendación de capacidad.
• Control de riesgo: la cadena de operación automatizada es rastreable, observable y reversible, garantizando estabilidad en los cambios.

Resultados

El informe de operación de capacidad muestra el nivel de uso de capacidad de lectura/escritura del maestro y las réplicas del clúster, junto con recomendaciones de capacidad. Un área de negocio pudo ver de forma directa, desde la página de operación, el estado de capacidad de los clústeres a su cargo y, para los que tenían riesgo de capacidad, completó la expansión y partición de la base de datos siguiendo la recomendación del sistema — una serie de acciones que simplificaron el proceso de evaluación, antes complejo, y mejoraron notablemente la eficiencia de trabajo.

7. Planes futuros

• Soportar más tipos de base de datos: hoy soporta MySQL maestro-réplica; en el futuro soportará MGR, Proxy y Blade, la base de datos distribuida desarrollada internamente por Meituan, además de Elasticsearch, entre otros.
• Apoyo a la planificación de presupuesto: los usuarios arman su presupuesto según el uso actual de recursos y el crecimiento del negocio, pero suelen pasar por alto los recursos sobrantes. Vamos a integrar esto con el sistema de presupuesto para que los usuarios vean claramente el margen actual y reduzcan el trabajo de completar el presupuesto.
• Ajuste inteligente de capacidad: completar de forma automática el análisis de cuellos de botella de capacidad de un clúster y la elaboración del plan de optimización, lanzando automáticamente una nueva prueba para validar el efecto, mejorando aún más la eficiencia del sistema.
• Construcción de una biblioteca de casos: para escenarios típicos como grandes promociones o incidentes, conservar de forma permanente una imagen de esos casos —instantáneas de datos, tráfico SQL y configuración del clúster— que sirva como tráfico real en línea para la ingeniería del caos y para el sistema de estabilidad a largo plazo de MySQL.

Adaptación del artículo original del equipo de Plataforma de Investigación y Desarrollo Base de Meituan (基础研发平台), “从0到1建设美团数据库容量评估系统”, publicado en el blog técnico de Meituan.