Apache Kafka es una popular plataforma de streaming distribuido para crear aplicaciones de streaming y pipelines de datos en tiempo real. Es conocido por su alto rendimiento, escalabilidad y tolerancia a los fallos. A menudo se utiliza para tareas clave como el seguimiento de la actividad de un sitio web, el procesamiento de pedidos y el análisis de transacciones financieras. Kafka está alcanzando un notable dominio en todos los sectores, con operaciones de minoristas hasta hospitales que aprovechan las impresionantes capacidades de la plataforma. Puedes convertirlo en la columna vertebral de tu plataforma de datos, conectarlo a la perfección con una multitud de otros servicios y tecnologías, y ajustarlo para que admita diferentes garantías de entrega, como la semántica «at-least-once» (al menos una vez) o «exactly-once» (exactamente una vez). Puedes alojar la plataforma de manera local o en la nube utilizando distribuciones autogestionadas o totalmente gestionadas. De hecho, se podría llegar a decir que las posibilidades son infinitas.
A medida que crece la adopción de Kafka, se aplica a casos de uso cada vez más diversos, lo que exige una evolución continua de la plataforma. Un área de desarrollo continuo es la escalabilidad, que es crucial para gestionar los enormes volúmenes de datos que se ven en las aplicaciones modernas como IoT. Aquí expondré cómo los nuevos desarrollos de la plataforma están abordando estos retos cambiantes.
Un Repaso Rápido a las Particiones
Aunque Apache Kafka es increíblemente flexible y ampliamente utilizado, tiene ciertas opiniones y formas predeterminadas de hacer las cosas utilizando sus propias APIs y protocolos. Un área en la que la personalización ha sido limitada es en el escalado de los consumidores de Kafka. Sin embargo, es importante señalar que las capacidades de escalado por defecto de Kafka son suficientes para la gran mayoría de los casos de uso (alrededor del 95%). Para entenderlo mejor, recapitulemos cómo escala Kafka en el lado del consumidor sin profundizar demasiado en su arquitectura. El concepto central de la escalabilidad de Kafka es la partición. Cada topic se divide en una o varias particiones. Cada mensaje de un topic se asigna a una partición concreta, determinada normalmente por la clave del mensaje. Esta partición actúa como unidad de escalabilidad en Kafka. Sin embargo, este diseño crea un límite superior en la escalabilidad del procesamiento. Además, vincula estrechamente la estructura de partición del topic con la redundancia y el rendimiento del consumo de mensajes.
En términos más sencillos, el número de unidades de procesamiento de un grupo de consumidores está restringido por el número total de particiones dentro de los topics consumidos. Por tanto, el consumo de un topic con diez particiones puede escalarse a un máximo de diez instancias en un grupo de consumidores.
Figura 1: La escalabilidad de Kafka con un Grupo de Consumidores estándar. Los productores generan mensajes para la partición representativa del topic de Kafka. Basándose en un particionador, generalmente un particionador por clave, los mensajes se distribuyen entre las particiones disponibles. Las instancias de consumidores dentro del Grupo de Consumidores se asignan a estas particiones. Los mensajes de una única partición son consumidos, como máximo, por una instancia consumidora.
Además de ser una unidad de escalabilidad, las particiones son los únicos contenedores lógicos que admiten garantías de ordenación de mensajes. Esta arquitectura interna de Kafka, basada en particiones, asignadores y grupos de consumidores, es lo suficientemente flexible como para soportar la mayoría de las distribuciones de carga. Sin embargo, como puedes ver, este estrecho acoplamiento del almacenamiento de mensajes, el orden de los mensajes y el escalado del procesamiento puede ser limitante para algunos casos de uso específicos.
La incorporación de los Consumidores Paralelos de Confluent
Precisamente esta preocupación llevó a la creación de la biblioteca del Consumidor Paralelo de Confluent.
El Consumidor Paralelo de Confluent introduce una capa de abstracción adicional que envuelve la API estándar del Consumidor Kafka. A continuación, permite escalar aún más las instancias del Grupo de Consumidores aprovechando Vert.x, el llamado modelo de arquitectura paralela no bloqueante.
Figura 2 Escalabilidad del Consumidor Kafka con el Consumidor Paralelo de Confluent. Cada instancia del Grupo de Consumidores, de las que sólo puede haber una, se escala aún más en unidades de procesamiento (componentes verdes), que consumen mensajes en paralelo.
El consumidor paralelo de Confluent rompe el límite de escalabilidad estándar de Kafka. Sin embargo, no manipula el protocolo ni la API de Kafka. Todo lo que necesitas para aprovechar este Consumidor es empaquetar la API estándar del Consumidor Kafka con la biblioteca de Confluent, ajustarla con la ayuda de múltiples propiedades, y convertir el Consumidor incluso en una solución de procesamiento paralelo masivo. Los detalles de la implementación quedan fuera del alcance de este artículo. Aun así, merece la pena conocer esta inteligente pieza de ingeniería y la forma en que proporciona un equilibrio entre las garantías de ordenación de los mensajes, la escalabilidad del consumo y la semántica de la garantía de entrega.
Novedades en el Horizonte de Apache Kafka
En la versión 4.0 de Apache Kafka, que se publicará próximamente, llegará otra forma de escalar tus consumidores. En el KIP-932 obtenemos lo que se llama una «partición compartida duradera» en el Área de Procesamiento del Flujo. Esta nueva herramienta supone un cambio de paradigma que abre nuevas y apasionantes posibilidades. De hecho, es un disruptor, pero no uno al que debamos enfrentarnos con temor.
En términos sencillos, esta nueva funcionalidad podría verse como «Colas para Kafka». Esta nueva funcionalidad podría parecer sugerir la adición de nuevas entidades junto a los topics tradicionales de Kafka, pero no es así. Los brokers de Kafka siguen siendo estructuralmente los mismos, pero la complejidad añadida se traslada a los clientes. El KIP-932 amplía la funcionalidad de agrupación de consumidores, introduciendo los Grupos Compartidos de Consumidores junto a la función existente de Grupos de Consumidores.
Como en el caso del consumidor paralelo de Confluent, la ingeniería que hay detrás de la actualización es ciertamente avanzada. En este caso, sin embargo, fue necesario realizar cambios en el protocolo y la API de Kafka. Aunque por ahora, solo hay topics en los brokers, esta funcionalidad requiere una actualización tanto en el lado central (brokers) como en el lado cliente.
Figura 3 Con el nuevo protocolo de Grupo Compartido de Consumidores, el número de instancias del grupo consumidor está completamente desvinculado del número de particiones de un topic. Todas las instancias de consumidores procesan en paralelo un flujo común de mensajes como si fuera de una única partición.
Ampliación de los conceptos básicos para mejorar la escalabilidad
A pesar de ser opinable, Kafka es notablemente extensible, incluso con conceptos arquitectónicos básicos como la escalabilidad. Aunque su enfoque original del escalado podría haber sido limitante en determinadas situaciones, como las plataformas de procesamiento IoT, soluciones como el consumidor paralelo de Confluent ya han proporcionado formas de superar estas limitaciones. Además, la próxima versión Apache Kafka 4.0.0 introduce un nuevo enfoque para abordar estos casos de uso. En definitiva, Kafka sigue mejorando. Su evolución es una clara demostración del compromiso de Kafka para responder a las necesidades cambiantes de las aplicaciones modernas de flujo de datos. Al perfeccionar continuamente sus mecanismos de escalabilidad, la plataforma garantiza su capacidad para gestionar el creciente volumen y velocidad de los datos en el mundo actual, impulsado por los datos. Con los próximos avances de Apache Kafka 4.0.0, la plataforma estará bien equipada para afrontar futuros retos de escalabilidad y mantener su posición como opción líder para soluciones de flujo de datos en tiempo real.
Pawel Wasowicz
Pawel es Lead Data Engineering en Mimacom en Berna, Suiza, y ayuda a nuestros clientes a sacar el máximo partido de sus datos aprovechando las nuevas tendencias, tecnologías ya probadas y los muchos años de experiencia en este campo.