Streaming que cambia el juego: Apache Pulsar presenta el escalado automático

Apache Pulsar siempre se ha visto a sí mismo como nativo de la nube. Está justo ahí en la página de inicio:

“Apache® Pulsar™ es una plataforma de transmisión y mensajería distribuida de código abierto creada para la nube”

Pulsar ciertamente incorpora muchos principios nativos de la nube, incluida la separación de la computación del almacenamiento donde el corredor Pulsar maneja el servicio de mensajes y Apache BookKeeper maneja el almacenamiento de los mismos, y la idea de componentes sin estado que se pueden escalar hacia arriba y hacia abajo a voluntad como el corredor Pulsar.

Sin embargo, en realidad nunca ha cumplido la máxima promesa de la nube: el escalado automático. Al menos, no hasta hoy.

Estoy emocionado de presentar Kubernetes Autoscaling para Apache Pulsar, o KAAP. KAAP es un operador de Kubernetes que está disponible en OperatorHub. Incluye todas las sutilezas que esperaría de un operador de Kubernetes. Una vez que haya instalado el operador en su clúster de Kubernetes, puede obtener un clúster Pulsar completamente funcional aplicando una única definición de recurso personalizada (CRD) como esta:

 apiVersion: kaap.oss.datastax.com/v1alpha1 kind: PulsarCluster metadata: name: pulsar spec: global: name: pulsar image: 'apachepulsar/pulsar:3.0.0'

Pulsar tiene múltiples componentes: ZooKeeper, BookKeeper, corredores y proxies. El operador se encarga de configurarlos todos con el PulsarCluster CRD. Debido a que el operador trabaja a nivel de clúster, no tiene que preocuparse por cómo funcionan juntos los componentes. El operador se encarga de eso por ti.

Actualizaciones por etapas automáticas

Habiendo operado un servicio de producción en la nube para Pulsar más tiempo que nadie que yo conozca (primero en Kesque y ahora con DataStax Astra Streaming), sé de primera mano cuánto se tarda en realizar una actualización adecuada de un clúster Pulsar. Si bien podría simplemente actualizar YOLO todos los componentes a la vez, el método recomendado y más seguro es actualizar cada componente de uno en uno, asegurándose de que cada componente se haya actualizado correctamente antes de pasar al siguiente.

Este es el proceso que seguimos cuando actualizamos los clústeres Pulsar en nuestro servicio Astra Streaming porque la disponibilidad de nuestro servicio al cliente es primordial, pero requiere mucho tiempo para nuestro equipo de ingeniería de producción. De hecho, esta es la solicitud número uno que tienen: ¿pueden hacer que las actualizaciones sean más inteligentes y automáticas? Bueno, con KAAP, hemos hecho precisamente eso.

Con un solo cambio de línea en PulsarCluster CRD, puede activar una actualización por etapas de su clúster Pulsar. El operador de KAAP orquestará una actualización cuidadosa y por etapas de su clúster. Por supuesto, debe monitorear las métricas durante la actualización, pero puede dejar que el operador KAAP conduzca (sin dormir al volante).

Escalado automático de código abierto

Las actualizaciones por etapas automáticas son agradables, pero eso no es lo que más me emociona con KAAP. El concepto de recursos elásticos es una promesa clave de la nube. Es por eso que muchos de los servicios de AWS tienen "elástico" en su nombre. Yo (en realidad ChatGPT ) hice una búsqueda rápida y hay al menos 10 de ellos.

La nube le permite adquirir y liberar recursos a pedido, por lo que puede usar técnicas de escalado automático para hacer coincidir la cantidad de recursos que usa su aplicación con la carga en ella. A medida que aumenta la carga, puede agregar automáticamente más recursos. A medida que la carga disminuye, puede liberar recursos. Dado que los proveedores de la nube cobran por el uso de los recursos, el escalado automático puede ayudarlo a hacer el uso más eficiente de su inversión en la nube.

Estoy seguro de que todos podemos pensar en ejemplos de servicios en la nube que cuentan con escalado automático detrás de escena. La mayoría de esos servicios de AWS "elásticos" funcionan así. Sin embargo, la implementación del ajuste de escala automático es patentada y está bloqueada en el repositorio privado de un proveedor. A veces hablarán sobre cómo han implementado el escalado automático, como en este papel sobre AWS DynamoDB, o esto entrada en el blog sobre cómo Confluent Cloud hace que Kafka sea elástico. Pero nadie, que yo sepa, ha hecho que su implementación de escalado automático sea de código abierto, disponible gratuitamente para todos los usuarios bajo una licencia de código verdaderamente abierto. Eso es exactamente lo que estamos haciendo con KAAP.

KAAP agrega sofisticadas capacidades de escalado automático a su Pulsar (o Luna Streaming , nuestra distribución Pulsar) bajo una licencia Apache 2.0. Puedes consultarlo en nuestro repositorio GitHub . Si te gusta, recuerda darle una estrella.

Pulsar + escalado automático: una combinación perfecta

KAAP le brinda una forma de agregar escalado automático a Pulsar cuando se ejecuta en Kubernetes. No se trata de un escalador automático de pod horizontal simple (HPA) agregado a una implementación de intermediario de Pulsar, sino de un escalador automático sofisticado que funciona con los componentes nativos de la nube existentes de Pulsar para proporcionar un sistema de transmisión y mensajería verdaderamente elástico. En mi opinión, esta es una combinación que no se puede superar.

Escalado de intermediarios sin estado

Echemos un vistazo a las dos dimensiones principales de escalado automático de KAAP. Primero, veremos a los corredores de Pulsar. Como sabrá, los corredores de Pulsar no tienen estado, lo que significa que puede escalarlos hacia arriba y hacia abajo fácilmente, según sea necesario. Pero lo que quizás no sepa es que Pulsar tiene un mecanismo integrado de balanceo de carga de intermediarios que monitorea continuamente la CPU, la memoria y el ancho de banda de la red en cada intermediario. Utilizando esa información y uno de los algoritmos de equilibrio de carga configurables, Pulsar moverá los temas de un intermediario a otro para evitar que un intermediario se sobrecargue.

Una solución ingenua de escalado automático sería configurar un escalador automático de pod horizontal (HPA) de Kubernetes en los intermediarios y, cuando alguna métrica, como la CPU, aumente, escalar otro pod de intermediario. Pero esto podría no ser realmente necesario porque el balanceador de carga del corredor Pulsar podría decidir cambiar los temas para nivelar la carga al mismo tiempo. Ahora ha ampliado un pod de intermediario que no es necesario porque el balanceador de carga Pulsar ha equilibrado las cosas. Así que ahora la HPA decide reducir el nuevo grupo de intermediarios, lo que hace que todos los temas nuevos que se hayan creado en él se trasladen a un intermediario existente. Como puede imaginar, el balanceador de carga Pulsar y un HPA pueden crear un lío de corredores que suben y bajan y los temas se cambian de un corredor a otro.

KAAP evita este problema al integrarse directamente con el balanceador de carga Pulsar. KAAP aumenta la escala de los intermediarios cuando las métricas de todo el clúster del balanceador de carga Pulsar sugieren que el clúster se está acercando a su capacidad máxima, no cuando un único módulo de intermediario está ocupado. Y solo reduce la escala de un intermediario si el uso de todo el clúster cae por debajo de un umbral configurado. El operador KAAP trabaja con el balanceador de carga del intermediario Pulsar, no contra él.

Escalar el almacenamiento hacia arriba y hacia abajo: ¡Notable!

Escalar la capa de cómputo (o servicio) de Pulsar es excelente, pero no es suficiente para una verdadera implementación de escalado automático. Claro, la cantidad de mensajes (o eventos) que deben procesarse puede variar con el tiempo, pero ¿qué pasa con la cantidad de mensajes que deben almacenarse? Probablemente todos hemos tenido que lidiar con una acumulación de mensajes atrasados debido a una falla en un sistema descendente. A medida que se prolonga la interrupción, el almacenamiento disponible en el sistema de transmisión comienza a agotarse.

Este es un escenario donde brilla Pulsar y su confianza en BookKeeper. Para agregar capacidad de almacenamiento a un clúster Pulsar, solo necesita agregar un nuevo nodo BookKeeper, cariñosamente llamado "bookie". Debido a que el almacenamiento de BookKeeper se basa en segmentos de temas y no en temas completos, el nuevo corredor de apuestas está disponible de inmediato para aliviar la presión sobre el almacenamiento, con cualquier reequilibrio doloroso de temas o cualquier otra intervención operativa.

KAAP puede, por supuesto, manejar este caso por usted. Supervisa constantemente el uso del disco de los nodos de apuestas y, si el almacenamiento disponible se está agotando, escalará un nuevo nodo de apuestas. Esto no es tan notable (al menos para Pulsar). Es bastante sencillo agregar una nueva réplica en Kubernetes, incluso si tiene estado y está respaldada por volúmenes persistentes. Pero, ¿qué pasa cuando termina la interrupción y se elimina la acumulación? ¿Estás atrapado ahora con un nodo de apuestas extra que consume recursos que ya no son realmente necesarios?

No con KAAP, no lo eres. Una vez que el almacenamiento de BookKeeper cae por debajo de un umbral configurado, el operador de KAAP orquestará cuidadosamente la eliminación del nodo de corredor de apuestas innecesario. Lo hace de una forma muy segura, asegurando que no se pierdan mensajes y que se mantenga en todo momento el factor de replicación requerido. Por ejemplo, si configuró Pulsar para mantener tres copias de cada mensaje (el quórum de escritura y reconocimiento es igual a tres), KAAP interactúa con BookKeeper para copiar mensajes del corredor de apuestas que se está reduciendo a otros corredores de apuestas para garantizar que haya al menos tres copias del mensaje disponibles. Una vez que se haya completado con éxito, se procederá a eliminar el corredor de apuestas innecesario.

Con KAAP, obtiene un escalado automático del almacenamiento en su clúster Pulsar tanto hacia arriba como hacia abajo para que pueda optimizar el uso del almacenamiento en su clúster y no quedarse atascado con capacidad inactiva después de un desafortunado incidente de producción. No sé ustedes, pero creo que eso es bastante notable.

Herramientas de migración y reconocimiento de zonas

KAAP puede realizar actualizaciones por etapas y una escala inteligente de su clúster Pulsar. Pero hay más Para operar un clúster de alta disponibilidad en un proveedor de nube, es importante tener en cuenta las zonas de disponibilidad (AZ). Si no distribuye sus componentes, especialmente BookKeeper, entre las zonas de disponibilidad, no podrá sobrevivir a una falla de AZ y proporcionar múltiples nueves de disponibilidad.

Afortunadamente, Pulsar tiene excelentes capacidades integradas, como la conciencia de rack para admitir implementaciones de alta disponibilidad. La parte complicada es que para configurarlo correctamente, debe configurar Kubernetes correctamente con reconocimiento de zona y también configurar Pulsar. El operador de KAAP lo tiene cubierto al presentar el concepto de conjuntos de recursos, que le permiten agrupar componentes y darles reconocimiento de rack. El operador KAAP aplicará automáticamente las configuraciones de Kubernetes y Pulsar en función de su configuración declarativa de conjuntos de recursos. Los conjuntos de recursos son flexibles, lo que le permite admitir una variedad de opciones de implementación de Pulsar.

¿Y si ya está ejecutando su Pulsar usando un gráfico de Helm o tal vez solo un poco de magia de manifiesto de Kubernetes? KAAP tiene una herramienta de migración para ayudarte. Puede apuntar la herramienta de migración a su implementación de Kubernetes Pulsar existente y generará automáticamente una configuración de CRD coincidente que puede usar para que el operador KAAP se haga cargo de la operación de su clúster por usted.

La pila KAAP

El operador KAAP tiene muchas características excelentes, turboalimentando su clúster Pulsar normal en una máquina de escalado automático bien engrasada y de alta disponibilidad. Pero como alguien que ha operado clústeres Pulsar de producción durante mucho tiempo, sé que hay muchas otras consideraciones para crear un clúster Pulsar de producción, como la administración, autenticación y monitoreo de certificados TLS.

Es por eso que hemos incluido lo que llamamos la pila KAAP con el operador. Es un diagrama general de Helm que instala el operador KAAP junto con herramientas de producción críticas, que incluyen:

• Administrador de certificados
• Capa de llaves
• Pila de Prometeo (Grafana)
• Tableros Pulsar Grafana

Estas son herramientas imprescindibles cuando se ejecutan nuestros clústeres Pulsar de producción y no queríamos dejarlo en la estacada, por lo que las juntamos todas y las integramos en un paquete conveniente.

¿Por qué usar KAAP?

Entonces, ha oído hablar de todas las excelentes funciones de Kubernetes Autoscaling para Apache Pulsar. Puede crear un clúster Pulsar completo con un solo CRD. Puede poner sus actualizaciones en piloto automático y dejar que el operador KAAP realice actualizaciones seguras y por etapas. Puede escalar automáticamente los brókeres de Pulsar hacia arriba y hacia abajo según el balanceador de carga del bróker de Pulsar que indica que los brókeres se están sobrecargando, y puede escalar hacia arriba y hacia abajo los nodos de BookKeeper (!) de manera segura según los requisitos de almacenamiento de sus clústeres. Puede configurar fácilmente su clúster para el conocimiento de la zona de disponibilidad para una alta disponibilidad. E incluso incluye una herramienta de migración para que pueda pasar fácilmente de su antigua implementación basada en Helm a una basada en un operador KAAP turboalimentado.

Entonces, muchas características excelentes, pero ¿cuáles son los beneficios de KAAP? Se me ocurren varios:

• Configure y opere fácilmente clústeres Pulsar de alta disponibilidad que se ejecutan en Kubernetes, lo que reduce el esfuerzo para usted y sus equipos de producción.
• Simplifique drásticamente el escalado de Pulsar para adaptarse a las demandas cambiantes mediante el escalado automático de los recursos del clúster para que coincida con la demanda.
• Reduzca el costo total de propiedad de un clúster Pulsar eliminando el aprovisionamiento para picos de carga o sobreaprovisionamiento como resultado de incidentes de producción
• Evite el bloqueo de proveedores mediante el uso de todas las tecnologías de código abierto

En mi opinión, lanzar KAAP es un momento verdaderamente innovador en el espacio de transmisión y mensajería. Ningún otro proyecto de código abierto combina el poder de transmisión y mensajería de Apache Pulsar con la última promesa de la computación en la nube: escalabilidad automática totalmente elástica. Estoy deseando que lo pruebes. Ingrese a las discusiones de GitHub en nuestro repositorio y háganos saber lo que piensa.

Saber más

Si desea profundizar técnicamente en KAAP, eche un vistazo a esta publicación de blog . Puede encontrar la documentación completa para KAAP aquí . Y aquí es el repositorio de GitHub.

Por Chris Bartholomew, DataStax