Lecciones aprendidas: Ejecutar Presto a escala de Meta

Presto es un motor de consultas SQL de código abierto gratuito. Llevamos diez años utilizándolo en Meta y hemos aprendido mucho en el proceso. Ejecutar a gran escala, ya sean herramientas, procesos o servicios, conlleva tener que resolver problemas para superar retos inesperados. A continuación, se incluyen cuatro cosas que hemos aprendido al ampliar Presto a escala de Meta, así como algunos consejos por si te interesa ejecutar tus propias consultas a escala.

¿A qué retos nos enfrentamos al escalar Presto rápidamente para satisfacer las demandas crecientes?

Implementación de nuevos lanzamientos de Presto

Figura 1: Flujo de trabajo del proceso de envío de nuevas versiones de Presto (diagrama de Philip S. Bell)

Meta ejecuta un gran número de clústeres de Presto repartidos por centros de datos en todo el mundo. Se crea una nueva versión de Presto y se prepara para su implementación aproximadamente al menos una vez al mes; a veces, dos. Uno de los primeros retos a los que nos enfrentamos a medida que la huella de Presto en Meta crecía rápidamente fue implementar el motor de consultas para un gran volumen de clústeres y, a la vez, garantizar que la disponibilidad y la fiabilidad fueran constantes. Esto sigue siendo especialmente cierto para los casos de uso interactivo de Presto; es decir, cuando un usuario inicia una consulta y espera activamente el resultado. Los errores en las consultas suponen una preocupación menor para los casos de uso “por lotes” automatizados en los que los reintentos automáticos aseguran que las consultas se acaben ejecutando correctamente.

La solución para este problema fue sencilla. Todos los clústeres de Presto se encuentran detrás de un equilibrador de carga llamado Gateway que se encarga (junto con otros sistemas de Meta) de dirigir las consultas de Presto al clúster adecuado. Cuando es necesario actualizar un clúster de Presto, primero se marca como vaciado de Gateway; es decir, que Gateway deja de dirigirle nuevas consultas. Luego, la automatización espera un periodo de tiempo predeterminado hasta que finalicen las consultas que se están ejecutando en ese momento en el clúster. Entonces, el clúster se actualiza y, una vez que está online, se hace visible para Gateway, que puede volver a dirigirle consultas.

El otro factor a tener en cuenta a la hora de implementar nuevos lanzamientos de Presto es la disponibilidad. Debemos asegurarnos de que los usuarios puedan seguir usando Presto mientras los clústeres se actualizan. De nuevo, la automatización garantiza que los centros de datos en todas las regiones físicas siempre dispongan del número necesario de clústeres de Presto. Por supuesto, se debe lograr el equilibrio entre desactivar demasiados clústeres al mismo tiempo (problema de disponibilidad) y desactivar un número de clústeres insuficiente (la implementación tarda demasiado).

Automatización de la creación y la eliminación de clústeres de Presto

Figura 2: Flujo de trabajo automatizado para añadir hardware a los clústeres (diagrama de Philip S. Bell)

La distribución del almacén de datos de Meta en diferentes regiones está en constante evolución. Esto quiere decir que deben crearse clústeres de Presto nuevos a la vez que los existentes se eliminan con frecuencia. Anteriormente, cuando solo había un pequeño número de clústeres de Presto, este proceso se realizaba de forma manual. Cuando Meta empezó a ampliarse, hacer un seguimiento manual de todos los cambios pronto se convirtió en un reto. A fin de solucionar este problema, implementamos automatizaciones para gestionar la creación y la eliminación de clústeres.

En primer lugar, tuvimos que estandarizar nuestras configuraciones de clústeres; es decir, tuvimos que crear configuraciones base para los distintos casos de uso de Presto en Meta. Luego, cada clúster contaba con un número mínimo de especificaciones adicionales o invalidadas sobre la configuración base. Una vez que dicho proceso se completaba, cualquier clúster nuevo se podía ampliar mediante la generación automática de configuraciones desde la plantilla base. Para ampliar los clústeres, también era necesaria la integración con las conexiones de automatización a fin de poder integrarse con los distintos servicios de infraestructura de toda la empresa como Tupperware y servicios específicos del almacén de datos. Una vez que un clúster está online, se le envían algunas consultas de prueba y la automatización verifica que el clúster las ejecuta correctamente. Entonces, el clúster se registra con Gateway y empieza a atender consultas.

Eliminar un clúster sigue prácticamente el proceso a la inversa. El clúster se retira del registro de Gateway y se espera a que finalicen las consultas en ejecución. Los procesos de Presto se desactivan y las configuraciones del clúster se eliminan.

Esta automatización está integrada en el flujo de trabajo de creación y eliminación del hardware del almacén de datos. El resultado final es que el proceso completo —desde que llega nuevo hardware a un centro de datos hasta que los clústeres se ponen a disposición online y atienden consultas, y, luego, se desactivan cuando el hardware se elimina— es totalmente automático. Implementar este proceso ha ahorrado horas de trabajo manual valiosas, ha reducido el tiempo de inactividad del hardware y ha minimizado los errores humanos.

Depuración y correcciones automáticas

Figura 3: Detección de hosts defectuosos (diagrama de Philip S. Bell)

Debido a la gran implementación de Presto en Meta, es fundamental contar con herramientas y automatizaciones que faciliten el trabajo de la persona de guardia (el punto de contacto de Presto).

A lo largo de los años, hemos creado varios “analizadores” que ayudan a la persona de guardia a depurar y analizar la causa principal de los problemas que van surgiendo de manera eficiente. Los sistemas de supervisión emiten alertas cuando se producen vulneraciones de los SLA de cara al cliente. Entonces, se activan los analizadores, que obtienen información de un amplio conjunto de sistemas de supervisión (almacén de datos operativos u ODS), eventos publicados en Scuba e, incluso, registros en el nivel del servidor. La lógica personalizada del analizador une toda esta información para deducir la causa probable del problema. Esto resulta extremadamente útil para la persona de guardia, ya que le ofrece un análisis de la causa principal y le permitirle centrarse directamente en las opciones de mitigación posibles. En algunos casos, hemos automatizado completamente tanto las tareas de depuración como las de corrección, de modo que la persona de guardia ni siquiera tiene que involucrarse. A continuación, se describen un par de ejemplos:

Detección de hosts defectuosos

Nos hemos dado cuenta de que, cuando Presto se ejecuta a escala en un gran número de máquinas, determinados hosts “defectuosos” pueden demasiados errores de consulta. Gracias a nuestras investigaciones, hemos identificado una serie de causas principales que resultaron en que los hosts se volvieran “defectuosos”, como, por ejemplo:

• Problemas en el nivel del hardware que los sistemas de supervisión de toda la flota aún no habían detectado debido a la falta de cobertura.
• Errores desconocidos en la JVM que a veces provocaban un goteo constante de errores en las consultas.

Para hacer frente a este problema, ahora supervisamos los errores de consulta en los clústeres de Presto. En concreto, cuando es posible, atribuimos cada error de consulta al host que lo causó. También configuramos alertas que se emiten cuando se atribuye un número excepcionalmente elevado de errores de consulta a hosts específicos. Entonces, la automatización se activa para vaciar el host de la flota de Presto y, así, detener los errores.

Depuración de problemas en cola

Los clústeres de Presto admiten consultas en cola una vez que se alcanza el número máximo de consultas en ejecución simultánea, en función del caso de uso, la configuración del hardware y el tamaño de la consulta. Meta dispone de un mecanismo de enrutamiento sofisticado para que la consulta de Presto se dirija al clúster “correcto” que pueda ejecutar la consulta usando los recursos de la mejor forma posible. Hay varios sistemas además de Presto que participan en la toma de decisiones sobre el enrutamiento basándose en múltiples factores, como los siguientes:

• El estado actual de la cola en los clústeres de Presto.
• La distribución del hardware en los distintos centros de datos.
• La localidad de los datos de las tablas que utiliza la consulta.

A causa de esta complejidad, a la persona de guardia le puede resultar muy difícil descubrir la causa principal de los problemas en cola que se encuentren durante producción. Esta es otra instancia en la que los analizadores toman protagonismo al obtener información de múltiples orígenes y presentar conclusiones.

Robustez del equilibrador de carga

Figura 4: Robustez del equilibrador de carga (diagrama de Philip S. Bell)

Como se ha mencionado anteriormente, nuestros clústeres de Presto se encuentran detrás de equilibradores de carga que dirigen las consultas de Presto en Meta. Al principio, cuando Presto aún no se había ampliado al nivel de uso interno que tiene hoy en día, Gateway era muy sencillo. Sin embargo, a medida que incrementaba el uso de Presto en Meta, nos encontramos con problemas de escalabilidad en un par de ocasiones. Uno de ellos era que Gateway se bloqueaba con grandes cargas, lo que podía causar que Presto no estuviese disponible para todos los usuarios. La causa principal de algunos problemas de estabilidad era que un servicio bombardeaba accidentalmente Gateway con millones de consultas en un corto periodo de tiempo, lo que resultaba en que los procesos de Gateway fallasen y no pudiesen dirigir ninguna consulta.

Para evitar esta situación, nos propusimos hacer Gateway más robusto y tolerante con este tipo de tráfico DDoS accidental. Implementamos una función de restricción que rechaza consultas cuando la carga ya es grande. Esta restricción se puede activar en función del recuento de consultas por segundo en diferentes dimensiones como, por ejemplo, por usuario, por origen, por IP y también a nivel global para todas las consultas. Otra mejora que implementamos fue el escalado automático. Apoyándose en un servicio en el nivel de Meta que admite la ampliación y reducción de tareas, el número de instancias de Gateway ahora es dinámico. Esto quiere decir que ahora, cuando Gateway soporta grandes cargas, se puede ampliar para gestionar el tráfico adicional y no alcanzar el límite de la CPU/memoria. De esta forma, se evita la situación de bloqueo que hemos descrito antes. Esto, junto con la función de restricción, garantiza que Gateway sea robusto y pueda soportar patrones imprevistos de tráfico desfavorables.

¿Qué consejo daríamos a un equipo que está ampliando su propio data lakehouse mediante Presto?

Figura 5: Escalado de la arquitectura de Presto (diagrama de Philip S. Bell)

Estos son algunos aspectos importantes a tener en cuenta al ampliar Presto:

1. Establecimiento de SLA de cara al cliente bien definidos y fáciles de entender. A medida que Presto se amplía, resulta esencial definir los SLA en base a métricas importantes como el tiempo en cola y la frecuencia de errores en las consultas de una forma que permita hacer un seguimiento de los puntos críticos para los clientes. Cuando existe un número de usuarios grande, la falta de SLA apropiados puede actuar en detrimento de los esfuerzos por mitigar los problemas de producción a causa de confusiones al determinar el impacto de un incidente.
2. Supervisión y depuración automática. A medida que Presto se amplía y el número de clústeres aumenta, la supervisión y la depuración automática son críticas.
   • Disponer de procesos de supervisión exhaustivos puede ayudar a identificar problemas de producción antes de que tengan un impacto demasiado grande. La identificación temprana de dichos problemas garantizará que se minimiza el impacto en el usuario siempre que sea posible.
   • La investigación manual de los problemas que afectan a los clientes no es escalable. Es fundamental disponer de un proceso de depuración automatizada para poder determinar rápidamente la causa principal del problema.
3. Buen equilibrio de la carga. A medida que la flota de Presto crece, es importante tener una buena solución para equilibrar la carga al frente de los clústeres de Presto. Cuando se opera a gran escala, las pequeñas ineficiencias en el equilibrio de la carga pueden tener un impacto negativo desmesurado a causa del enorme volumen de la carga de trabajo.
4. Administración de la configuración. La administración de la configuración de una flota grande de clústeres de Presto puede ser un problema si no se planea correctamente. Siempre que sea posible, las configuraciones deberían poder recargarse activamente para que las instancias de Presto no tengan que reiniciarse ni actualizarse de forma disruptiva, lo que causaría errores en las consultas y descontento en los clientes.

Este artículo se ha escrito en colaboración con Neerad Somanchi, ingeniero de producción en Meta, y Philip Bell, colaborador de desarrollo de Meta.

Para obtener más información sobre Presto, consulta prestodb.io, ve la explicación rápida sobre Presto de Philip Bell en YouTube o sigue a Presto en Twitter, Facebook y LinkedIn.

Para obtener más información sobre Meta Open Source, visita nuestro sitio de código abierto, suscríbete a nuestro canal de YouTube o síguenos en Twitter, Facebook y LinkedIn.