Resumen del Kafka Summit London 2022
El pasado 25 y 26 de abril se celebraba el Kafka Summit London 2022, un encuentro de partners y fabricantes de productos alrededor del ecosistema Kafka. Es interesante ver cómo se han construido soluciones de monitoreo, workflow, seguridad, etc. alrededor de Kafka, el producto estrella en la conferencia. En el showroom estuvieron los proveedores cloud más utilizados, además de fabricantes conocidos en el software middleware como Azul, MongoDB, Hazelcast.
En este artículo comparto con vosotros un resumen de la conferencia.
KeyNote
La KeyNote fue bastante interesante y se describieron los factores importantes al cambiar hacia el paradigma orientado a eventos en una organizacion cuando se usa Kafka como un sistema nervioso central de intercambio de datos.
Batch -> Streaming: Sorprende como aun salen nuevas versiones al mercado de productos que aun usan el paradigma batch, cuando la tendencia del mercado y de las integraciones actuales es usar el dato/mensaje en tiempo real, cuando este se necesita, para poder reaccionar antes y responder a más necesidades de negocio.
Centralizado -> decentralizado En el mundo típico de warehouses teníamos un repositorio centralizado donde enviamos los datos vía procesos de carga ETL. Esto ya no es necesario. Con el streaming podemos extraer la data y escribirla en múltiples formatos no normalizados para su fácil consumo, además de crear métricas cuando se está produciendo el evento vía Kafka Streams.
El real time streaming es paralelismo, donde se puede diseñar un "modern data flow", resiliente y sin únicos puntos de fallo, fácil de escalar. En cambio, las integraciones de tipo worfklow centralizadas basadas en batch son muy propensas a quedar congeladas si alguno de sus pasos secuenciales se detiene. Además, son difíciles de escalar.
Orientado a infraestructura -> declarativo Las soluciones antiguas están basadas en una infraestructura fija. Una vez cargados los datos a un repositorio batch centralizado son difíciles de modificar. En cambio con KSQL tenemos una forma expresiva, flexible y accesible de obtener los datos del streaming y distintos formatos de agregación adaptados a los diferentes consumidores.
Orientado a herramientas con GUI -> orientado a desarrolladores "El código es el rey". Salgamos con una versión inicial del producto, acortemos time-to-market y empecemos a iterar mejorando el código fuente que ya tenemos, aprovechando toda la cadena que ya tenemos montada alrededor de este: versionamiento, revisión de código, monitoreo, despliegues. Todo esto con nuestras herramientas favoritas. Las herramientas antiguas de integración cuentan con un GUI propietaria poco flexible y difícil de integrar.
No gobernado y poco visible -> gobernado y observable En la organización hay conflictos usuales. Por un lado, se quiere que los datos estén disponibles para todos, y, por otro lado, se requiere que cumpla condiciones de regulaciones de seguridad, de conformidad, etc. Esto hay que tenerlo en cuenta cuando se requiere una herramienta de gobierno que responda a necesidades: dónde obtener el stream de datos (catálogo), cómo son los datos (esquema) y, finalmente, cómo los datos están conectados (pipelines de flujos de datos) desde los productores a los consumidores. Aquí destacamos Confluent Stream Lineage, que es un producto que nos da visibilidad sobre estos puntos.
Sesiones
De entre todas las sesiones ofrecidas, quería destacar aquí las que más me gustaron:
Evergreen: Building Airbnb’s Merge Queue With Kafka Streams
El problema de los posibles conflictos en un repositorio de código con múltiples merges concurrentes es solucionado con un sistema que exige que cualquier commit en master pase todas las comprobaciones automáticas, como la compilación, el análisis estático o las pruebas, como si se fusionaran secuencialmente sin superponerse en el tiempo.
A Hitchhiker's Guide to Apache Kafka Geo-Replication
Entendimos la evolucion de los "Observers", este tipo de partición que, a diferencia de un follower, siempre es asíncrono y no se cuenta en la lista ISR por defecto, a menos que exista un evento de indisponibilidad de las réplicas ISR, actuando como miembro "backup". De esta forma el tópico no llega a perder disponibilidad.
Los "Observers" son útiles para los casos de uso de replicación global, donde tenemos en una zona diferente réplicas de un "stretched cluster". Debido a las condiciones de bajo ancho de banda y latencia es útil usar una replicación de particiones asíncrona y solo pasar a síncrona temporalmente en el caso en que se necesite. Es el caso de los "Observers".
Keep Your Cache Always Fresh with Debezium
Vimos una solución CDC (Change Data Capture), implementada con PostgreSQL, Infinispan, y Debezium. Usando el patrón CQRS (Command Query Response Seggregation), donde las lecturas están cacheadas en una cache Ifinispan de topologia distribuida con data denormalizada desde tablas PostgreSQL, donde hay un conector (Kafka Connect) Debezium que envía los cambios desde la base de datos hacia Kafka. Y desde ahí un microservicio los consume para invalidar y recrear la cache.
CI/CD with an Idempotent Kafka Producer & Consumer
LakeFs es un producto que nos permite escribir y leer en múltiples repositorios de objetos como AWS S3, Azure Blob Storage y Google Cloud Storage con las facilidades de un repsositorio de versiones Git, tales como hacer commits, reverts, crear ramas, etc. Una de sus fuentes de datos es Kafka Connect, donde se aprovecha la funcionalidad de producir sin mensajes duplicados "exactly once".
Improving fault tolerance Kafka Streams
Se explicaron las novedades en las mejoras de Kafka Streams, entre ellas:
- KIP 441: Dirigido a mejorar la disponibilidad de Kafka Streams cuando una tarea tiene que migrar a otra instancia por un rebalanceo. Con esta mejora se puede tener más de una instancia réplica para actuar en caso de caída del líder.
- KIP 429: Este cambio se hizo para mejorar el "stop the world" que ocasionan los eventos de rebalanceo, donde todas las instancias tienen que parar de consumir y esperar a que el algoritmo determine la nueva asignación de particiones para luego actualizar su estado (KsqlDB) y poder seguir ejecutando la tarea. Con este nuevo protocolo el rebalanceo es incremental no se hace un solo rebalanceo sino algunos consecutivos, cada uno dirigido a un grupo de consumidores, de tal forma que no se desconectan todos a la vez.
- KIP 535: Con esta mejora los querys interactivos pueden ser servidos desde una instancia standby que no esté "up-to-date" o si lo está, el usuario tiene las opciones sobre cuánto "consumer lag" tolerar para los resultados de su consulta. Antes, si el query fallaba no se podía ejecutar la consulta.
Debido a la complejidad de tener una plataforma de prueba de Kafka en nuestros tests de código fuente, muchas veces estos son muy simples o se usan estrategias de mocks. TestContainers viene a solucionar este requerimiento. Ahora con pocas líneas de código podemos tener una distribución específica de Kafka y versión para poder lanzar nuestros tests. Por detrás se usa una máquina docker que, si no existe, se descarga y la librería TestContainers hace todo este trabajo por detrás.
Mi conclusión final
Fueron dos días llenos de novedades y casos de uso reales que nos servirán para proponer soluciones. Recomiendo ver las sesiones. Seguramente hay alguna o varias que aplican a tu caso de uso: https://www.confluent.io/events/kafka-summit-london-2022/