Fundamentos de Kafka — Resúmen: Orígen
El Problema de LinkedIn
LinkedIn tenía un sistema para recopilar métricas de aplicaciones y sistemas que utilizaban recopiladores personalizados y herramientas de código abierto para almacenar y presentar datos internamente. Además de las métricas tradicionales, como el uso de la CPU y el rendimiento de la aplicación, existía una característica sofisticada de seguimiento de solicitudes que utilizaba el sistema de monitoreo y podía proporcionar una introspección sobre cómo se propagaba una solicitud de un solo usuario a través de aplicaciones internas. Sin embargo, el sistema de monitoreo tenía muchas fallas. Esto incluyó la recopilación de métricas basada en sondeos, grandes intervalos entre métricas y la falta de capacidad para que los propietarios de aplicaciones administren sus propias métricas. El sistema era de alto contacto, requería la intervención humana para la mayoría de las tareas simples y era inconsistente, con diferentes nombres de métricas para la misma medición en diferentes sistemas.
Al mismo tiempo, se creó un sistema para rastrear la información de la actividad del usuario. Este era un servicio HTTP al que los servidores frontend se conectaban periódicamente y publicaban un lote de mensajes (en formato XML) en el servicio HTTP. Luego, estos lotes se movieron a plataformas de procesamiento fuera de línea, que es donde se analizaron y clasificaron los archivos. Este sistema tenía muchas fallas. El formato XML era incoherente y su análisis resultaba computacionalmente costoso. Cambiar el tipo de actividad del usuario que se rastreó requirió una cantidad significativa de trabajo coordinado entre las interfaces y el procesamiento fuera de línea. Incluso entonces, el sistema se rompería constantemente debido a los esquemas cambiantes. El seguimiento se creó en lotes por hora, por lo que no se pudo utilizar en tiempo real.
El Monitoreo y Seguimiento de la actividad del usuario no podían utilizar el mismo servicio de backend. El servicio de Monitoreo era demasiado torpe, el formato de datos no estaba orientado al seguimiento de la actividad y el modelo de sondeo para el seguimiento no era compatible con el modelo push para el seguimiento. Al mismo tiempo, el servicio de Monitoreo era demasiado frágil para usarlo en métricas y el procesamiento orientado por lotes no era el modelo adecuado para el monitoreo y las alertas en tiempo real. Sin embargo, los datos de monitoreo y seguimiento compartían muchas características, y la correlación de la información (por ejemplo, cómo los tipos específicos de actividad del usuario afectaban el rendimiento de la aplicación) era muy deseable. Una caída en los tipos específicos de actividad del usuario podría indicar problemas con la aplicación que le dio servicio, pero horas de retraso en el procesamiento de los lotes de actividad significaron una respuesta lenta a este tipo de problemas.
Al principio, se investigaron a fondo las soluciones de código abierto listas para usar para encontrar un nuevo sistema que proporcionara acceso en tiempo real a los datos y escale horizontalmente para manejar la cantidad de tráfico de mensajes necesario. Los sistemas prototipo se configuraron utilizando ActiveMQ, pero en ese momento no podía manejar la báscula. También fue una solución frágil para la forma en que LinkedIn necesitaba usarlo, descubriendo muchas fallas en ActiveMQ que harían que los corredores hicieran una pausa. Estas pausas respaldarían las conexiones con los clientes e interferirían con la capacidad de las aplicaciones para atender solicitudes a los usuarios. Se tomó la decisión de seguir adelante con una infraestructura personalizada para la canalización de datos.
El nacimiento de Kafka
El equipo de desarrollo de LinkedIn estaba dirigido por Jay Kreps, un ingeniero de software principal que anteriormente era responsable del desarrollo y lanzamiento de código abierto de Voldemort, un sistema de almacenamiento distribuido de valor clave. El equipo inicial también incluía a Neha Narkhede y, más tarde, a Jun Rao. Juntos, se propusieron crear un sistema de mensajería que pudiera satisfacer las necesidades de los sistemas de seguimiento y seguimiento, y escalar para el futuro. Los objetivos principales fueron:
- Desacoplar a productores y consumidores mediante el uso de un modelo push-pull
- Proporcionar persistencia para los datos de los mensajes dentro del sistema de mensajería para permitir que varios consumidores
- Optimizar para un alto rendimiento de mensajes
- Permitir que la escalabilidad horizontal del sistema crezca a medida que crecen los flujos de datos
El resultado fue un sistema de mensajería de publicación / suscripción que tenía una interfaz típica de los sistemas de mensajería, pero una capa de almacenamiento más parecida a un sistema de agregación de registros. Combinado con la adopción de Apache Avro para la serialización de mensajes, Kafka fue eficaz para manejar tanto las métricas como el seguimiento de la actividad del usuario a una escala de miles de millones de mensajes por día. La escalabilidad de Kafka ha ayudado a que el uso de LinkedIn crezca en más de siete billones de mensajes producidos (a febrero de 2020) y más de cinco petabytes de datos consumidos diariamente.
Código abierto
Kafka fue lanzado como un proyecto de código abierto en GitHub a finales de 2010. Cuando comenzó a ganar atención en la comunidad de código abierto, se propuso y aceptó como un proyecto de incubadora de Apache Software Foundation en julio de 2011. Apache Kafka se graduó de la incubadora en Octubre de 2012. Desde entonces, se ha trabajado continuamente y ha encontrado una sólida comunidad de colaboradores y comprometidos fuera de LinkedIn. Kafka ahora se utiliza en algunas de las canalizaciones de datos más grandes del mundo, incluidas las de Netflix, Uber y muchas otras empresas.
La adopción generalizada de Kafka también ha creado un ecosistema saludable en torno al proyecto principal. Hay grupos de reuniones activos en docenas de países de todo el mundo, que brindan discusión local y soporte para el procesamiento de transmisiones. También hay numerosos proyectos de código abierto relacionados con Apache Kafka. LinkedIn sigue manteniendo varios, incluidos Cruise Control, Kafka Monitor y Burrow. Además de sus ofertas comerciales, Confluent ha lanzado proyectos que incluyen ksqlDB, un registro de esquema y un proxy REST bajo una licencia comunitaria (que no es estrictamente de código abierto, ya que incluye restricciones de uso).
Compromiso comercial
En el otoño de 2014, Jay Kreps, Neha Narkhede y Jun Rao dejaron LinkedIn para fundar Confluent, una empresa centrada en brindar desarrollo, soporte empresarial y capacitación para Apache Kafka. También se unieron a otras empresas (como Heroku) para proporcionar servicios en la nube para Kafka. Confluent, a través de una asociación con Google, proporciona clústeres Kafka administrados en Google Cloud Platform, así como servicios similares en Amazon Web Services y Azure. Una de las otras iniciativas importantes de Confluent es organizar la serie de conferencias Kafka Summit. Iniciado en 2016, con conferencias celebradas anualmente en los Estados Unidos y Londres, Kafka Summit ofrece un lugar para que la comunidad se reúna a escala global y comparta conocimientos sobre Apache Kafka y proyectos relacionados.
El nombre
La gente a menudo pregunta cómo Kafka obtuvo su nombre y si significa algo específico sobre la aplicación en sí. Jay Kreps ofreció la siguiente información:
Pensé que dado que Kafka era un sistema optimizado para la escritura, usar el nombre de un escritor tendría sentido. Había tomado muchas clases de literatura en la universidad y me gustaba Franz Kafka. Además, el nombre sonaba genial para un proyecto de código abierto.
Entonces, básicamente, no hay mucha relación.
Creadores, es la primera parte de varios encuentros con Kafka. ¡Sigan atentos!
