¿Intentando escalar Apache Kafka? Considere usar Apache Pulsar

Hoy en día, incluso las aplicaciones web y móviles más básicas consumen una gran cantidad de datos. La clave para intercambiar y actuar sobre estos datos es un sistema de mensajería respaldado por una arquitectura basada en eventos.

Un sistema basado en eventos permite que las soluciones de mensajería y el procesamiento sean escalables y asincrónicos. Los sistemas asincrónicos pueden manejar más solicitudes, ya que cada solicitud se maneja en segundo plano.

Cuando se realiza una solicitud al servidor, se agrega a una cola, donde un procesador la leerá. Esto permite a las organizaciones crear sistemas que aceptan cientos de miles, o incluso millones, de solicitudes por segundo a escala al procesar las solicitudes en un clúster separado.

La industria ha producido varios sistemas de intermediación de mensajes y plataformas de publicación-suscripción (pub-sub) basadas en temas que siguen este formato basado en eventos y mensajes. Apache Kafka y Apache Pulsar son dos ejemplos ampliamente utilizados de sistemas distribuidos de entrega y transmisión de mensajes.

Kafka y Pulsar se basan en un patrón pub-sub que puede usar para escalar la entrega de mensajes a miles de clientes conectados. Ambos ofrecen un modelo de almacenamiento persistente para garantizar que los mensajes no se pierdan y ambos usan particiones para almacenar y procesar los mensajes.

Si bien Kafka y Pulsar son similares en muchos aspectos, tienen algunas diferencias notables en cuanto a capacidades, especialmente cuando se administran grandes cantidades de datos, se crean aplicaciones en tiempo real y se desarrollan a escala.

Kafka brinda muchos beneficios, pero el soporte de Pulsar para la escalabilidad y el crecimiento es inigualable. Y en un cierto punto de crecimiento, la opción óptima es no intentar optimizar Kafka, sino separarse de él. Aquí, compararemos las diferencias entre Kafka y Pulsar, demostrando cómo el siguiente paso lógico para la escalabilidad cuando se usa Kafka es cambiar a Pulsar.

Desafíos con las aplicaciones de Apache Kafka

Kafka es el de facto para los patrones pub-sub distribuidos en la arquitectura de software. Una organización que usa Kafka es capaz de manejar miles de mensajes y transmitirlos a varios consumidores al mismo tiempo.

Kafka tiene varios beneficios , pero también tiene ciertas limitaciones al intentar escalar. Exploremos algunos desafíos que enfrentará al intentar escalar aplicaciones creadas con Apache Kafka.

Limitaciones de almacenamiento

La arquitectura de Kafka crea el primer desafío al que se enfrentará al escalar sus aplicaciones en Kafka: el almacenamiento.

Los agentes con estado son la primera razón por la que a una organización le resulta difícil escalar. Los datos en Kafka se almacenan en el nodo líder , mientras que las particiones de datos se almacenan en el disco local. Los datos están vinculados a los nodos y los intermediarios en Kafka tienen estado. Esto significa que una vez que el nodo líder alcanza la capacidad máxima de almacenamiento, el clúster no puede aceptar más mensajes a menos que se aumente el almacenamiento de la infraestructura. Esto es un desafío porque, en un entorno en constante crecimiento, un clúster requerirá múltiples actualizaciones.

Una forma de superar este desafío es comprar un gran clúster de almacenamiento, que es muy costoso.

Además, según esta arquitectura, una vez que la plataforma alcanza el límite máximo de almacenamiento o memoria, no puede aceptar nuevos mensajes entrantes. Esto puede conducir a una gran pérdida para las aplicaciones críticas para el negocio. La arquitectura de Kafka está diseñada para aceptar y transmitir muchos mensajes. El almacenamiento de datos a largo plazo no es una prioridad. Como resultado, escalar una aplicación Kafka es muy desafiante porque no puede proporcionar el almacenamiento que necesita, al menos no sin una etiqueta de precio considerable.

Problemas con el procesamiento de mensajes

Administrar Kafka es un desafío porque no incluye las funciones necesarias para el monitoreo de actividades, el procesamiento de mensajes y la persistencia de datos.

Kafka se destaca por los sistemas de transmisión de mensajes sin encabezado, donde no es necesario mutar un mensaje antes de la entrega. Sin embargo, suponga que necesita procesar un mensaje antes de reenviarlo a los consumidores; esto requiere depender de plataformas adicionales, lo que hace que sea más desafiante y complejo procesar mensajes con Kafka.

Además, la participación de otras plataformas como las enumeradas anteriormente aumenta significativamente la complejidad de su sistema de entrega de datos, ya que cada componente de la plataforma de transmisión requiere mantenimiento y tiene limitaciones que se aplican a todo el clúster. Además, los clústeres de Kafka tienen datos limitados y persistencia de mensajes a medida que aumentan los requisitos de datos con el tiempo.

Bibliotecas de clientes complicadas

Las empresas utilizan principalmente Kafka para los servicios de transmisión proporcionados. La API de transmisión está escrita sobre la entrega de mensajes pub-sub para admitir un caso comercial único . La API de Kafka Streams es un producto independiente que ofrece funciones avanzadas dirigidas a clientes empresariales. La función más destacada de Kafka Streams, las transacciones , ayuda a las empresas a garantizar la coherencia de los resultados generados por el flujo de mensajes. Por este motivo, Kafka tiene dos API independientes para cada caso de uso.

Por ejemplo, la biblioteca Kafka Streaming permite a las empresas ofrecer una entrega de mensajes "exactamente una vez". Las garantías de entrega que ofrecen tanto Kafka como Pulsar son:

• Al menos una vez
• Como máximo una vez
• Exactamente una vez

La entrega "exactamente una vez" garantiza que para cada mensaje, habrá una salida asociada, lo que garantiza que el mensaje se procese en caso de que un consumidor falle. Sin embargo, esto es imposible con la API de consumidores , que permite que las aplicaciones lean flujos de datos de temas en el clúster de Kafka, lo que requiere que escriba la mayoría de las funciones en la plataforma. Esto dificulta el uso de una sola biblioteca de cliente para todas las funciones que necesita para su empresa, lo que no es sostenible cuando se trabaja a escala.

Entra Pulsar

Para cada limitación de Kafka destacada anteriormente, Pulsar tiene una solución. Las siguientes secciones describen algunos de los beneficios de Pulsar.

Almacenamiento de datos persistente

Pulsar proporciona las funciones de publicación y transmisión de mensajes que ofrece Kafka, pero agrega la capacidad de conservar los datos durante períodos más prolongados.

Pulsar ofrece persistencia de almacenamiento de datos utilizando Apache Bookkeeper. Bookkeeper mantiene los datos y ayuda a descargar la persistencia de datos fuera del clúster. Puede utilizar otros medios de almacenamiento de datos, como AWS S3, para almacenar datos y escalar más allá de los límites de un disco local, lo que significa que puede expandir fácilmente sus aplicaciones sin problemas de almacenamiento.

Además, Pulsar incluye una función de almacenamiento en niveles que ayuda a mover los datos entre las opciones de almacenamiento frío y caliente; los datos se pueden almacenar en almacenamiento en frío durante el tiempo que necesite el negocio. El clúster no requiere un cambio continuo en el tamaño de la infraestructura para las opciones de almacenamiento.

Pulsar también mueve automáticamente los mensajes más antiguos de Bookkeeper a una opción de almacenamiento en frío más económica al hacer que un segmento de los datos sea inmutable. El segmento inmutable se puede mover a un almacenamiento más económico, lo que permite que Pulsar acepte cantidades infinitas de datos.

Experiencia del desarrollador

Desde la perspectiva del desarrollador, Pulsar ofrece una biblioteca de cliente sencilla e integrada para todos los lenguajes principales (Java, Python, Go y C#). Las bibliotecas ayudan a los desarrolladores a comenzar rápidamente con la plataforma, lo cual es clave al desarrollar y lanzar aplicaciones a escala. El protocolo binario de Pulsar amplía las funciones de la biblioteca del cliente según sea necesario, lo que hace que la biblioteca sea adecuada para el crecimiento. (Aquí está la lista de bibliotecas cliente de Pulsar disponibles y admitidas oficialmente).

Funciones Pulsar

Pulsar Functions es una función lista para usar que permite a los desarrolladores escribir código personalizado que puede procesar mensajes en el flujo de mensajes sin necesidad de implementar un sistema como Apache Heron, Apache Flink o Apache Storm.

Las funciones Pulsar se utilizan en un marco de conector sin servidor Pulsar IO, lo que facilita el movimiento de datos desde y hacia Pulsar. Este sistema listo para usar permite que Pulsar se conecte a bases de datos SQL y NoSQL externas, como Apache Cassandra.

Además, este procesamiento de mensajes es nativo del flujo, lo que significa que los mensajes se procesan y transforman dentro del clúster antes de que se entreguen a los consumidores. Debido a que Pulsar Functions es la infraestructura informática del sistema de mensajería Pulsar, respaldan los objetivos de nivel comercial, incluida la productividad del desarrollador, la resolución sencilla de problemas y la simplicidad operativa, cualidades cruciales para el rendimiento de la aplicación y el equipo cuando se trabaja a escala.

Escalabilidad

Además de las características y servicios mencionados anteriormente y su influencia en la escalabilidad, Pulsar ofrece varias características que lo convierten en una opción escalable para las necesidades de transmisión y publicación de mensajes de su empresa.

La función de replicación geográfica de Pulsar permite que Pulsar sea altamente escalable. El clúster replica los datos en varias ubicaciones en todo el mundo para usarlos en caso de que un desastre deje de funcionar la aplicación. Se admite que la replicación sea síncrona y asíncrona. La replicación asíncrona es más rápida pero ofrece menos garantías de coherencia de datos que la replicación síncrona.

Pulsar utiliza un concepto de agente por tema, lo que garantiza que el mismo agente maneje todas las solicitudes de un tema. La arquitectura Pulsar demuestra cómo el enfoque basado en intermediarios mejora el rendimiento del sistema en comparación con un clúster de Kafka.

Terminando

Kafka y Pulsar tienen algunas similitudes, pero hay algunas diferencias fundamentales que vale la pena considerar al seleccionar qué plataforma usar, especialmente cuando necesita escalabilidad.

La arquitectura, las capacidades de almacenamiento y la facilidad de uso de Kafka presentan numerosos desafíos que pueden inhibir la capacidad de crecimiento de una organización. Intentar escalar sus clústeres de Kafka más allá de un punto se vuelve costoso y, a menudo, es más problemático de lo que vale. Desde la forma en que almacena datos hasta la forma en que admite la transformación de mensajes, Pulsar es el retador unificado de próxima generación para Kafka que está diseñado para la escalabilidad.

Conozca más sobre DataStax Astra Streaming , construido sobre Apache Pulsar y entregado como un servicio completamente administrado.

Por Mary Grygleski. Mary es defensora de los desarrolladores de streaming en DataStax. Se centra en el desarrollo de la promoción y divulgación de la comunidad para Java, el código abierto y la tecnología en la nube, incluidas las arquitecturas nativas en la nube, sin servidor, impulsadas por eventos, microservicios y reactivas.