¿Qué es Redpanda?

Redpanda es un reemplazo directo de Kafka como broker de eventos, para el uso de clientes Kafka (consumidores/productores)

Está desarrollado en C++, afirmando que de esta manera es más eficiente que Kafka (implementado en Java) y por tanto no usa una JVM, permitiendo mejor gestión del uso de memoria.

También eliminan la necesidad de Zookeeper / KRaft, ya que basan Redpanda en un único binario con todas las funcionalidades requeridas. De esta manera, Redpanda implementa el protocolo de consenso Raft.

Open

Arquitectura de cluster Kafka vs Redpanda (fuente: redpanda.com)

Redpanda VS Kafka

Ya hemos podido ver las mayores diferencias entre Kafka y Redpanda, al menos a nivel de implementación y/o arquitectura:

El principal atractivo de Redpanda es la simplicidad de configuración y velocidad (baja latencia), así como el mejor uso de los recursos para el cluster de brokers desplegados.

Así lo afirma Redpanda con el siguiente Benckmark en el que se afirma una reducción en coste de 6x y un aumento de velocidad 10x.

Como contrapunto, tenemos el siguiente Benckmark, creado a partir del anterior, por un empleado de Confluent, donde comenta algunos puntos interesantes sobre la configuración de Kafka y los resultados de los mismos. Este análisis es bastante más detallado, teniendo en cada uno de los puntos que veremos a continuación, una subsección explicando el resultado obtenido y cómo lanzar dicho benchmark.

Los resultados más significativos son:

1. La latencia aumenta en Redpanda a medida que aumentan los productores. Según los datos, cuando subimos de 4 (benckmark de Redpanda) a 50 (benchmark de Kafka) productores, el tiempo de latencia se dispara en Redpanda.

2. Deterioro del rendimiento en ejecuciones continuadas en el tiempo. Tras 12 horas de ejecución Redpanda muestra un aumento en la latencia que viene de los discos NVMe. En concreto se achaca a cómo Redpanda acaba distribuyendo los datos de las particiones, siguiendo un patrón más similar a acceso aleatorio, lo cual lleva a un mayor IO de disco. En Kafka no sucede por la naturaleza más secuencial de organizar los datos.

3. Deterioro de la latencia en Redpanda cuando se alcanza el punto de retención de datos. Esto es muy importante, ya que en un entorno de producción lo habitual es estar siempre en este punto, en el que los tópicos se vayan “purgando” según las políticas de retención definidas.

4. El impacto de escribir mensajes/eventos con clave. Si bien es cierto que para la mayor parte de nuestros casos de uso no hacemos uso de esta funcionalidad (que ayuda a repartir los mensajes entre particiones de manera única y garantizar el orden), en los casos en los que es necesario, se detecta una reducción significativa del throughput para Redpanda cuando también se aumentan los productores.

5. Redpanda no llega al límite de transferencia de los discos NVMe con acks=1. Esta configuración nos acepta la escritura del dato siempre que haya sido persistido en el lider, no esperando a la replicación completa. En estos casos se observa que Redpanda no alcanza el throughput límite de los discos NVMe mientras que Kafka sí.

6. Problemas con Redpanda a la hora de agotar el backlog. Supongamos que en un escenario dado, mantemos los clusters de Kafka/Redpanda corriendo, así como los productores de datos, pero paramos los consumidores. Al volver a conectar dichos consumidores se detecta que Redpanda tiene problemas para ir bajando el “lag” en el consumo de datos.

Integración en OnesaitPlatform

Además de la comparativa de rendimiento, latencias y throughput, si analizamos Redpanda como reemplazo directo de Kafka vemos que permite autenticación y autorización.

Como parte de la integración de Kafka dentro de la OnesaitPlatform, hacemos uso de nuestro propio plugin de autenticación y por debajo usamos la Admin API de Kafka para generar las ACLs de esos usuarios/ digital clients creados.

Desde Redpanda en su documentación vemos que soporta los siguiente métodos de autenticación:

Esto nos deja fuera la posibilidad de usar nuestro plugin de seguridad tanto para la API de Kafka como para la de Admin.

Conclusiones

Tras ver todo esto, no creemos que Redpanda pueda ser un reemplazo directo del uso de Kafka para nuestros casos de uso habituales, a menos a día de hoy.

En la mayoría de proyectos que usan Kafka con OnesaitPlatform, estamos en posiciones donde entran en juego algunos de los puntos mencionados anteriormente, principalmente los puntos 2, 3 y 6 de la comparativa de bechmarks:

• Ejecuciones continuadas en el tiempo: Para la mayoría de nuestros casos de uso, Kafka es un bus de entrada de datos/ comunicación de procesos, que permanece en continua conexión.

• Retención de datos: Dado que son procesos continuados en el tiempo, lo habitual es que siempre entre en juego la retención de datos (defecto a 7 días, pero configurable).

• Agotar el backlog: Hay casos de uso en los que el backlog aumenta (productores que envían de manera irregular,paradas de mantenimiento,…) y tenemos que garantizar que acaba bajando a 0 lo más rápidamente posible.