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.
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).
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.
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:
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:
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.
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:
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.
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.
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:
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.