Dominar la implementación y replicación de múltiples clústeres con Kafka

Breve descripción general de Apache Kafka y casos de uso comunes, herramientas actuales para escalar implementaciones de múltiples clústeres y soluciones de conectividad para simplificar las implementaciones de múltiples clústeres.

Tabla de contenido

• ¿Qué es Kafka?

• Kafka y Kubernetes

• El caso de Kafka en múltiples grupos

• Kafka de múltiples grupos

  • Clústeres estirados: replicación sincrónica
  • Clústeres conectados: replicación asincrónica

• Conclusión

  
  

¿Qué es Kafka?

Comúnmente conocido simplemente como Kafka , Apache Kafka es una plataforma de transmisión de eventos de código abierto mantenida por Apache Software Foundation. Inicialmente concebido en LinkedIn , Apache Kafka fue creado en colaboración por Jay Kreps , Neha Narkhede y Jun Rao , y posteriormente lanzado como un proyecto de código abierto en 2011. Página Wiki

Hoy en día, Kafka es una de las plataformas de transmisión de eventos más populares diseñada para manejar transmisiones de datos en tiempo real. Se utiliza ampliamente para crear canalizaciones de transmisión de datos escalables, tolerantes a fallos y de alto rendimiento.

Los usos de Kafka se amplían continuamente; los cinco casos principales están muy bien ilustrados por Brij Pandey en la imagen adjunta.

Como breve introducción, es importante comprender los componentes de la plataforma Kafka y cómo funcionan.

Kafka funciona como una plataforma distribuida de transmisión de eventos, diseñada para manejar fuentes de datos en tiempo real de manera eficiente. Opera según el modelo de mensajería de publicación-suscripción y sigue una arquitectura distribuida y tolerante a fallas. Mantiene una secuencia de registros persistente, ordenada y particionada llamada "temas". Los productores escriben datos sobre estos temas y los consumidores los leen. Esto permite el desacoplamiento entre productores y consumidores de datos y permite que múltiples aplicaciones consuman el mismo flujo de datos de forma independiente.

Los componentes clave de Kafka incluyen:

1. Temas y particiones: Kafka organiza los datos en temas. Cada tema es un flujo de registros y los datos dentro de un tema se dividen en varias particiones. Cada partición es una secuencia ordenada e inmutable de registros. Las particiones permiten la escalabilidad horizontal y el paralelismo al permitir que los datos se distribuyan entre múltiples corredores de Kafka.

   
   

2. Productores : los productores son aplicaciones que escriben datos en temas de Kafka. Publican registros de temas específicos, que luego se almacenan en las particiones del tema. Los productores pueden enviar registros a una partición particular explícitamente o permitir que Kafka determine la partición usando una estrategia de partición.

   
   

3. Consumidores : los consumidores son aplicaciones que leen datos de temas de Kafka. Se suscriben a uno o más temas y consumen registros de las particiones a las que están asignados. Los grupos de consumidores se utilizan para escalar el consumo y cada partición dentro de un tema solo puede ser consumida por un consumidor dentro de un grupo. Esto permite que varios consumidores trabajen en paralelo para procesar los datos de diferentes particiones del mismo tema.

   
   

4. Corredores : Kafka se ejecuta como un grupo de servidores y cada servidor se denomina corredor. Los corredores son responsables de manejar las solicitudes de lectura y escritura de productores y consumidores, así como de administrar las particiones de temas. Un clúster Kafka puede tener varios intermediarios para distribuir la carga y garantizar la tolerancia a fallos.

   
   

5. Particiones/Replicación : para lograr tolerancia a fallas y durabilidad de los datos, Kafka permite configurar la replicación para particiones de temas. Cada partición puede tener varias réplicas, una réplica designada como líder y las demás como seguidoras. La réplica líder maneja todas las solicitudes de lectura y escritura para esa partición, mientras que los seguidores replican los datos del líder para permanecer sincronizados. Si un corredor con una réplica líder falla, uno de los seguidores se convierte automáticamente en el nuevo líder para garantizar una operación continua.

   
   

6. Gestión de compensaciones : Kafka mantiene el concepto de compensaciones para cada partición. Un desplazamiento representa un identificador único para un registro dentro de una partición. Los consumidores realizan un seguimiento de su compensación actual, lo que les permite reanudar el consumo desde donde lo dejaron en caso de falla o reprocesamiento.

   
   

7. ZooKeeper : aunque no forma parte de Kafka, ZooKeeper se utiliza a menudo para gestionar los metadatos y coordinar a los intermediarios en un clúster de Kafka. Ayuda con la elección de líderes, la información de temas y particiones y la gestión de la coordinación del grupo de consumidores. [Nota: la herramienta de gestión de metadatos Zookeeper pronto se eliminará gradualmente en favor de Kafka Raft , o KRaft, un protocolo para metadatos gestionados internamente ]

   
   

En general, el diseño y la arquitectura de Kafka la convierten en una plataforma altamente escalable, tolerante a fallas y eficiente para manejar grandes volúmenes de flujos de datos en tiempo real. Se ha convertido en un componente central en muchas aplicaciones e infraestructuras de datos, facilitando la integración de datos, el procesamiento de eventos y el análisis de transmisiones.

Una arquitectura típica de Kafka sería entonces la siguiente:

La agrupación en clústeres de Kafka se refiere a la práctica de ejecutar varios corredores de Kafka juntos como un grupo para formar un clúster de Kafka. La agrupación en clústeres es un aspecto fundamental de la arquitectura de Kafka y proporciona varios beneficios, incluida la escalabilidad, la tolerancia a fallos y la alta disponibilidad. Se utiliza un clúster Kafka para manejar flujos de datos a gran escala y garantizar que el sistema permanezca operativo incluso ante fallas.

En el clúster, los temas de Kafka se dividen en múltiples particiones para lograr escalabilidad y paralelismo. Cada partición es una secuencia de registros inmutable y ordenada linealmente. Por lo tanto, las particiones permiten que los datos se distribuyan entre varios intermediarios del clúster.

Cabe señalar que un clúster de Kafka como mínimo consta de 3 agentes de Kafka, cada uno de los cuales se puede ejecutar en un servidor independiente (virtual o físico). La guía de 3 nodos tiene como objetivo ayudar a evitar un escenario de cerebro dividido en caso de falla del corredor.

Kafka y Kubernetes

A medida que más empresas adoptan Kafka, también existe un interés creciente en implementar Kafka en Kubernetes.

De hecho, el informe Kubernetes in the Wild más reciente de 2023 de Dynatrace muestra que más del 40% de las grandes organizaciones ejecutan su plataforma de mensajería de código abierto dentro de Kubernetes ; la mayoría de ellas son Kafka.

Fuente .

El mismo informe también hace una afirmación audaz: "Kubernetes está emergiendo como el 'sistema operativo' de la nube".

Entonces, es imperativo que los administradores de Kafka comprendan la interacción entre Kafka y Kubernetes, y cómo implementarlos de manera adecuada para la escala.

El caso de Kafka en múltiples grupos

Ejecutar un clúster Kafka en una única configuración de clúster Kubernetes es bastante sencillo y permite la escalabilidad según sea necesario en teoría. Sin embargo, en producción, la imagen puede volverse un poco turbia.

Debemos distinguir el uso del término cluster entre Kafka y Kubernetes. Una implementación de Kubernetes también utiliza el término clúster para designar una agrupación de nodos conectados, denominado clúster de Kubernetes. Cuando la carga de trabajo de Kafka se implementa en Kubernetes, terminará con un clúster de Kafka ejecutándose dentro de un clúster de Kubernetes, pero lo que es más relevante para nuestra discusión es que también puede tener un clúster de Kafka que abarque múltiples clústeres de Kubernetes, para mayor resiliencia, rendimiento y soberanía de datos. etc.

Para empezar, Kafka no está diseñado para configuraciones multiinquilino. En términos técnicos, Kafka no comprende conceptos como los espacios de nombres de Kubernetes o el aislamiento de recursos. Dentro de un tema en particular, no existe un mecanismo sencillo para imponer restricciones de acceso de seguridad entre múltiples grupos de usuarios.

Además, diferentes cargas de trabajo pueden tener diferentes frecuencias de actualización y requisitos de escala, por ejemplo, aplicaciones por lotes versus aplicaciones en tiempo real. Combinar las dos cargas de trabajo en un solo clúster podría causar impactos adversos o consumir muchos más recursos de los necesarios.

La soberanía de los datos y el cumplimiento normativo también pueden imponer restricciones a la ubicación conjunta de datos y temas en una región o aplicación específica.

Por supuesto, la resiliencia es otra fuerte fuerza impulsora detrás de la necesidad de múltiples clusters Kafka. Si bien los clústeres de Kafka están diseñados para la tolerancia a fallas de los temas, todavía tenemos que planificar una falla catastrófica de un clúster completo. En tales casos, la necesidad de un clúster completamente replicado permite una planificación adecuada de la continuidad del negocio.

Para las empresas que están migrando cargas de trabajo a la nube o que tienen una estrategia de nube híbrida, es posible que deseen configurar varios clústeres de Kafka y realizar una migración de cargas de trabajo planificada a lo largo del tiempo en lugar de una migración Kafka riesgosa a gran escala.

Estas son sólo algunas de las razones por las que, en la práctica, las empresas se ven obligadas a crear múltiples clústeres de Kafka que, sin embargo, necesitan interactuar entre sí.

Kafka de múltiples grupos

Para tener varios clústeres de Kafka conectados entre sí, los elementos clave de un clúster deben replicarse en los otros clústeres. Estos incluyen los temas, compensaciones y metadatos. En términos de Kafka, esta duplicación se considera Mirroring. Hay dos enfoques posibles para configuraciones de múltiples clústeres. Clústeres estirados o clústeres conectados.

Clústeres estirados: replicación sincrónica

Un clúster ampliado es un clúster lógico que está "ampliado" en varios clústeres físicos. Los temas y réplicas se distribuyen entre los clústeres físicos, pero como se representan como un clúster lógico, las aplicaciones mismas no son conscientes de esta multiplicidad.

Los clústeres ampliados tienen una gran coherencia y son más fáciles de gestionar y administrar. Dado que las aplicaciones desconocen la existencia de múltiples clústeres, son más fáciles de implementar en clústeres extendidos, en comparación con los clústeres conectados.

Las desventajas de los clústeres ampliados son que requieren una conexión sincrónica entre los clústeres. No son ideales para una implementación de nube híbrida y requerirán un quórum de al menos tres clústeres para evitar un escenario de "cerebro dividido".

Clústeres conectados: replicación asincrónica

Un clúster conectado, por otro lado, se implementa conectando múltiples clústeres independientes. Estos clústeres independientes podrían ejecutarse en diferentes regiones o plataformas en la nube y se administran individualmente.

El principal beneficio del modelo de clúster conectado es que no hay tiempo de inactividad en caso de falla del clúster, ya que los otros clústeres se ejecutan de forma independiente. Cada clúster también se puede optimizar para sus recursos particulares.

La principal desventaja de los clústeres conectados es que dependen de una conexión asincrónica entre los clústeres. Los temas que se replican entre los clústeres no se "copian al escribir", sino que dependen de la coherencia final. Esto puede provocar una posible pérdida de datos durante el proceso de duplicación asíncrona.

Además, las aplicaciones que funcionan en clústeres conectados deben modificarse para tener en cuenta los múltiples clústeres.

Antes de abordar la solución a este enigma, cubriré brevemente las herramientas comunes en el mercado para habilitar la conectividad del clúster Kafka.

El propio Open Source Kafka viene con una herramienta de duplicación llamada Mirror Maker.

Mirror Maker duplica temas entre diferentes grupos a través de un productor integrado. De esta manera, los datos se replican de forma cruzada entre clústeres con eventual coherencia, pero sin interrumpir los procesos individuales.

Es importante tener en cuenta que, si bien Mirror Maker tiene un concepto simple, configurar Mirror Maker a escala puede ser todo un desafío para las organizaciones de TI. La gestión de direcciones IP, convenciones de nomenclatura, número de réplicas, etc. se debe realizar correctamente o podría dar lugar a lo que se conoce como "replicación infinita", donde un tema se replica infinitamente, lo que eventualmente provocaría una falla.

Otras desventajas de Mirror Maker es la falta de configuración dinámica de listas permitidas/no permitidas para actualizaciones. Mirror Maker tampoco sincroniza correctamente las propiedades de los temas, lo que lo convierte en un dolor de cabeza operativo a escala al agregar o eliminar temas para replicar. Mirror Maker 2 intenta solucionar algunos de estos desafíos, pero muchos talleres de TI todavía tienen dificultades para configurar Mirror Maker correctamente.

Otras herramientas de código abierto para la replicación de Kafka incluyen Mirus de Salesforce, uReplicator de Uber y Flink personalizado de Netflix .

Para opciones con licencia comercial, Confluent ofrece dos opciones: Confluent Replicator y Cluster Linking. Confluent Replicator es esencialmente un conector Kafka Connect que proporciona una forma resistente y de alto rendimiento de copiar datos de temas entre clústeres. Cluster Linking es otra oferta, desarrollada internamente y está dirigida a la replicación en múltiples regiones preservando al mismo tiempo las compensaciones de temas.

Aun así, Cluster Linking es una herramienta de replicación asincrónica en la que los datos tienen que cruzar los límites de la red y atravesar rutas de tráfico público. Como ya debería quedar claro, la replicación de Kafka es una estrategia crucial para aplicaciones de producción a escala; la pregunta es qué opción elegir.

Los administradores imaginativos de Kafka se darán cuenta rápidamente de que es posible que necesite clústeres conectados y clústeres ampliados, o una combinación de estas implementaciones, según el rendimiento de la aplicación y los requisitos de resiliencia.

Sin embargo, lo que resulta desalentador son los desafíos exponenciales que supone establecer las configuraciones de los clústeres y gestionarlas a escala en múltiples clústeres. ¿Cuál es una forma más elegante de resolver esta pesadilla?

KubeSlice de Avesha es una forma sencilla de obtener lo mejor de ambos mundos. Al crear una conectividad de servicio directa entre clústeres o espacios de nombres, KubeSlice elimina la necesidad de configurar manualmente la conectividad individual entre clústeres de Kafka.

En esencia, KubeSlice crea una puerta de enlace de red de Capa 3 segura y sincrónica entre clústeres; aislado en el nivel de aplicación o espacio de nombres. Una vez configurado esto, los administradores de Kafka son libres de implementar agentes de Kafka en cualquiera de los clústeres.

Cada corredor tiene una conectividad sincrónica con todos los demás corredores que se unen a través del segmento, aunque los propios corredores puedan estar en clústeres separados. Esto crea efectivamente un grupo ampliado entre los corredores y proporciona el beneficio de una fuerte coherencia y bajos gastos administrativos.

¡Toma tu pastel y cómelo también!

Para aquellos que quieran implementar Mirror Maker en sus clústeres, esto se puede hacer con un esfuerzo mínimo ya que la conectividad entre los clústeres se delega a KubeSlice. Por lo tanto, las aplicaciones Kafka pueden tener los beneficios de la replicación sincrónica (velocidad, resiliencia) Y asincrónica (independencia, escala) en la misma implementación con la capacidad de combinar y combinar las capacidades según sea necesario. Esto se aplica a los centros de datos locales, a través de nubes públicas o cualquier combinación de estos en una configuración híbrida.

La mejor parte es que KubeSlice es una implementación no disruptiva, lo que significa que no es necesario desinstalar ninguna herramienta ya implementada. Es simplemente una cuestión de establecer una porción y agregar la implementación de Kafka a esa porción .

Conclusión

Este blog proporcionó una breve descripción general de Apache Kafka y abordó algunos de los casos de uso más comunes. Cubrimos las herramientas actuales disponibles para escalar las implementaciones de Kafka en múltiples clústeres y discutimos las ventajas y desventajas de cada una. Finalmente, el artículo también presentó Kubeslice, la solución de conectividad de servicios emergente que simplifica las implementaciones de múltiples clústeres de Kafka y elimina los dolores de cabeza asociados con la configuración de la replicación de Kafka en múltiples clústeres a escala.

Un par de enlaces que los lectores pueden encontrar útiles:

Un blog antiguo sobre las mejores prácticas para ejecutar Kafka en AWS (antes de que se introdujera KubeSlice)

Configuración guiada de KubeSlice

Implementación de Kafka en GKE