Una rápida introducción a la moderna plataforma de streaming de eventos y a los distintos componentes que conforman Apache Kafka.
La única línea de la documentación de Apache Kafka que explica lo que es Apache Kafka en pocas palabras.,
Apache Kafka® es una plataforma de streaming de eventos.
Hay dos partes en esta línea única. Un evento y la plataforma de transmisión del evento.
¿Qué es un evento?
Es simplemente un cambio en el estado de algo.
Considera que estás reservando comida por Internet.
Has confirmado tu pedido. Es un evento.
Ahora tu pago se ha realizado con éxito. Es un evento.
Si tu comida ha llegado a tu local, también es un evento.
En segundo lugar, la plataforma de streaming es la que toma el flujo continuo de eventos, los procesa y los interpreta, para proporcionar algún significado al consumidor final.
Tomemos la sencilla analogía de un periódico. El periódico es una colección de todos los eventos ocurridos en el mundo, recogidos por personas de diversos lugares, interpretados y procesados en un formato legible para el usuario. En cierto modo, es un antepasado indirecto de Apache Kafka.
Pero Apache Kafka no es sólo esto. Es mucho más que una colección de eventos y un procesamiento de eventos. Por eso es una de las plataformas de transmisión de eventos más populares, utilizada por varios gigantes de la industria, como NETFLIX, PayPal, Spotify, Twitter y Airbnb.
Ventajas de utilizar sistemas de mensajería y streaming basados en Apache Kafka
En un sistema de mensajería tradicional, siempre es responsabilidad del productor de mensajes asegurarse de que el mensaje llegue al consumidor final. Pero éste no es el caso en Apache Kafka. Los productores y consumidores del mensaje son anónimos entre sí. Y ésta es la gran ventaja de Apache Kafka.
Kafka tiene temas, a los que los productores empujarán los eventos y los consumidores finales seguirán sondeando los nuevos mensajes sobre ese tema.
Para conseguirlo, Apache Kafka introduce la asincronía en el panorama. De este modo, nuestro hilo de aplicación también se convierte en no bloqueante, lo que hace que el escalado de productores, consumidores y la gestión de recursos sea mucho más simple y fácil.
También conseguimos una gran flexibilidad y fiabilidad gracias a las políticas de retención y las opciones de replicación que ofrece Apache Kafka.
Vamos a profundizar en las distintas partes que componen lo que es Kafka.
Registros
Son los datos de eventos que entran y salen del servidor Kafka. Siguiendo con la analogía del periódico, son la información real que lees y para la que tienes un título, un cuerpo y otros datos relacionados. Del mismo modo, los registros enviados al servidor Apache Kafka tienen una clave, un valor y otros metadatos que hay que interpretar y procesar.
Productores
Son los clientes del servidor Apache Kafka. Producen los eventos y los introducen en Kafka. Los productores son como las distintas fuentes que proporcionan la información a un periódico org. Estas fuentes proporcionan información para esa sección concreta en cuestión. Y del mismo modo, los productores producen eventos siempre para el mismo tema. Pero, ¿qué es un tema?
Topics
Los temas son los componentes fundamentales del flujo de trabajo de Kafka. Considéralos como las diferentes secciones de un periódico. La información relacionada con una sección se recopila conjuntamente y se presenta bajo esa sección. Y del mismo modo, todos los eventos emitidos por el productor tienen un tema que se mantendrá unido bajo ese nombre de tema. Entonces, ¿quién va a utilizar esa información?
Consumers
Los consumidores son el otro conjunto de clientes del servidor Apache Kafka. Los consumidores son similares a los lectores de un periódico. Los lectores de un periódico o una revista están suscritos a ese tema/sección y consumen toda la información que está disponible como parte de él. Y del mismo modo, los consumidores siguen sondeando los nuevos eventos del tema que les interesa. Para un gran conjunto de consumidores, ¿cómo podemos garantizar que los datos se proporcionen sin ningún fallo o pérdida?
Brokers
Los brokers son el corazón de la arquitectura de Apache Kafka. A cada corredor se le asigna un tema y almacenan todos los eventos que se publican en ese tema. Para garantizar que no haya pérdida de datos y evitar un único punto de fallo, replicamos los datos utilizando el factor de replicación al configurar el broker. Y en la mayoría de los casos, siempre hay un cluster que mantiene múltiples brokers escuchando los temas para este fin. Estos brokers no son más que el propio periódico org que recoge la información de los productores y la publica a los consumidores.
Factor de replicación
El factor de replicación se utiliza para denotar el número de réplicas de una pieza de información que se almacenará en el sistema de archivos del broker. En caso de que un corredor concreto falle o se caiga, el otro corredor de ese clúster que tenga los datos replicados se adelantará y dará el trozo de datos de eventos requerido al consumidor. Esto es como una función de copia de seguridad. Pero, ¿almacenamos estos datos para siempre?
Política de retención
No almacenamos los datos de los eventos para siempre y no tiene sentido hacerlo para el servidor Apache Kafka si esos datos ya han sido consumidos y procesados por el cliente. Esta política de retención determina el tiempo que se almacenan estos datos en el sistema de archivos del broker Kafka. Por defecto, es de 7 días.
Particiones y Offsets
Cuando un consumidor se cae durante un tiempo y vuelve, ¿cómo sabe dónde empezar a leer los datos? Los offsets se utilizan para asegurar el ordenamiento cuando los clientes leen los datos de los eventos de los brokers. Y las particiones se utilizan para dividir el almacenamiento de datos de eventos del tema en diferentes cubos entre los corredores para garantizar la escalabilidad y la fiabilidad. Los offsets son los índices representados como 0,1,2, etc en el diagrama anterior.
Zookeeper
Además de todo esto, el único líder principal de todo es el Zookeeper. Porque es bastante difícil garantizar que todas estas unidades de la arquitectura Apache Kafka funcionen bien juntas en la orquestación. Y Zookeeper se asegura de que todo en la configuración de Kafka esté bien. Recibe los latidos del corazón de los brokers durante intervalos específicos para asegurarse de que todo va bien y sin problemas.
Contras de Apache Kafka
Sin embargo, no todo es arco iris y sol. También hay algunos inconvenientes en el uso de Kafka. Es posible que te sientas abrumado al conocer tantos componentes desde el principio. Y también para un principiante esto es demasiado complejo para un sistema de mensajería.
Además, al revisar los distintos componentes, te habrás encontrado con un montón de configuraciones que pueden modificar el flujo de eventos, como el número de corredores, el factor de replicación, la política de retención, etc. Y definitivamente son muchos mandos que hay que girar para conseguir el funcionamiento óptimo de tu sistema.
También al trabajar con Apache Kafka, podemos confirmar un alto rendimiento gracias a la naturaleza asíncrona introducida en el entorno. Pero debido a esto, existe una alta latencia. Por lo tanto, existe un equilibrio entre el rendimiento y la latencia.
Conclusión
Apache Kafka es un framework muy popular utilizado por múltiples gigantes de la industria. Hay muchas razones para utilizar Kafka en tu proyecto, y la más importante de todas ellas es que Kafka es un modelo asíncrono Pub-Sub basado en eventos. Y, un aviso antes de incluir Kafka en tu proyecto: Apache Kafka es muy eficaz cuando hay muchos eventos fluyendo por el sistema. Para proyectos relativamente pequeños, Kafka es excesivo.
Espero que este artículo os haya dado una mejor comprensión de Apache Kafka y de su arquitectura y de las diferentes partes que lo componen. Espero que hayas encontrado valor al leerlo.
Por favor, comparte tus comentarios sobre este artículo. ¡Gracias por leerlo!
Deja una respuesta