Explorando los beneficios de usar un API Gateway para Kafka

Yuan Bao

March 31, 2023

Technology

Breve Introducción a Kafka

Kafka fue creado originalmente por LinkedIn como un sistema de mensajería distribuido que dependía de la coordinación de Zookeeper e incluía múltiples particiones y réplicas. Posteriormente, fue donado a la Apache Software Foundation. Gracias a su excepcional rendimiento, persistencia y capacidades de escalabilidad horizontal, Kafka se ha convertido en una plataforma de procesamiento de flujos distribuidos ampliamente adoptada en la industria.

Kafka tiene tres casos de uso principales:

  • Sistema de mensajería: Este es el caso de uso más común, donde se utiliza para la comunicación de mensajes entre microservicios en el backend. Kafka permite la desacoplamiento de sistemas, la conformación de tráfico y la comunicación asíncrona.
  • Sistema de almacenamiento: Kafka almacena mensajes en disco e incluye una función de múltiples réplicas, lo que lo convierte en una opción adecuada para su uso como un sistema de persistencia de datos. Esto reduce en gran medida el riesgo de pérdida de datos.
  • Plataforma de procesamiento de flujos: Kafka proporciona una biblioteca completa para el procesamiento de flujos, incluyendo operaciones como ventanas, uniones y transformaciones.

Arquitectura Técnica de Kafka

Un clúster estándar de Kafka consta de múltiples Productores, Consumidores, Brokers y un clúster de Zookeeper. Zookeeper es el componente central de control del clúster de Kafka, responsable de gestionar los metadatos del clúster y las elecciones del controlador. Los Productores envían mensajes a los Brokers, que almacenan los mensajes en disco, mientras que los Consumidores se suscriben y consumen mensajes de los Brokers.

Conceptos Básicos

Tema y Partición en Kafka

En Kafka, los mensajes se clasifican por temas. Los Productores suelen especificar un tema al enviar mensajes, mientras que los Consumidores suelen suscribirse a un tema para consumir mensajes.

Un tema generalmente consta de múltiples particiones, y cada partición contiene diferentes mensajes. Cuando se envía un mensaje a Kafka, se almacena en la partición adecuada según las reglas de particionamiento. Al establecer reglas de particionamiento apropiadas, los mensajes pueden distribuirse uniformemente en diferentes particiones.

Productor y Consumidor

Productor se refiere a la parte que envía mensajes, responsable de crear mensajes y enviarlos a los brokers de Kafka.

Consumidor se refiere a la parte que recibe mensajes, responsable de conectarse al broker del clúster de Kafka, suscribirse a un tema particular y consumir mensajes.

Brokers de Kafka

Un Broker puede considerarse como un nodo o instancia independiente de Kafka. Un clúster de Kafka consta de uno o más Brokers.

clúster de Kafka

Por qué Kafka Necesita una Puerta de Enlace API

En la mayoría de los casos, cuando se utiliza Kafka como un sistema de mensajería entre microservicios backend, los desarrolladores necesitan elegir diferentes SDKs de Kafka para desarrollar clientes productores o consumidores, dependiendo del lenguaje utilizado en el proyecto.

Sin embargo, este enfoque tiene limitaciones en ciertos escenarios, como cuando el cliente necesita conectarse directamente a Kafka. En tales casos, agregar una puerta de enlace API entre el llamador y Kafka puede ayudar a desacoplar los servicios. De esta manera, el llamador no necesita preocuparse por Kafka o los protocolos de comunicación específicos, lo que reduce los costos de llamada. Además, una puerta de enlace API puede proporcionar soporte de seguridad y capacidades de control de tráfico para las API expuestas por Kafka, asegurando la estabilidad de los servicios de Kafka.

Conexión Directa a Kafka

Conectarse directamente a Kafka puede resultar en una serie de limitaciones y riesgos cuando se utiliza como un middleware de cola de mensajes:

  1. Diferentes consumidores deben adaptarse al protocolo de comunicación de Kafka.
  2. Kafka no proporciona soluciones para asegurar las API expuestas, control de tráfico y otros problemas. Sin políticas de limitación de tasa, algunos productores o consumidores pueden consumir excesiva capacidad de cómputo y ancho de banda.
  3. Tanto los consumidores como los productores deben conocer la topología del clúster de Kafka, que puede verse afectada por cambios en el clúster de Kafka.

La Puerta de Enlace API Mejora la Usabilidad de Kafka

Conversión de Protocolo de Comunicación

Cuando se utiliza una puerta de enlace API para hacer de proxy de Kafka, el cliente se comunica con la puerta de enlace API utilizando el protocolo HTTP, mientras que la puerta de enlace API se comunica con Kafka utilizando el protocolo de Kafka. La puerta de enlace API convierte los mensajes del cliente al protocolo de Kafka, eliminando la necesidad de que el cliente se adapte a diferentes protocolos de mensajes de Kafka. Esto reduce significativamente los costos de desarrollo y hace que sea más conveniente de usar.

Limitación de Tasa

Cuando los recursos son limitados, la capacidad de servicio de los nodos de Kafka también está restringida. Exceder este límite podría hacer que el servicio se caiga y resulte en una reacción en cadena. La limitación de tasa puede evitar que esto suceda. En la arquitectura tradicional de Kafka, los clientes se comunican con Kafka a través de SDKs. Sin embargo, si el número de clientes o solicitudes es alto, puede afectar la carga de la máquina de los nodos de Kafka y afectar la estabilidad de la funcionalidad de Kafka. Agregar una puerta de enlace API a la arquitectura facilita la incorporación de varias dimensiones de soporte de función de limitación de tasa al clúster de Kafka, ya que las puertas de enlace API sobresalen en esta área. Estas capacidades incluyen:

  • Usar el algoritmo de ventana de tiempo fijo para limitar el número total de solicitudes que un solo cliente puede hacer al servicio dentro de un marco de tiempo especificado.
  • Restringir el número de solicitudes concurrentes que un cliente puede hacer a un solo servicio.
  • Usar el algoritmo de cubo con fugas para limitar la tasa de solicitudes de un solo cliente al servicio.

Al implementar estas funciones de limitación de tasa, los nodos de Kafka pueden protegerse eficazmente, asegurando su estabilidad.

Soporte de Autenticación

La autenticación también es una característica fuerte de una puerta de enlace API. En la arquitectura tradicional de Kafka, la mayoría de los puertos de Kafka se acceden dentro de una red interna. Si se requiere acceso desde una red pública, se necesitan configuraciones complejas para garantizar la seguridad. Usar la funcionalidad de autenticación de la puerta de enlace API al hacer de proxy de Kafka puede proteger los puertos expuestos de Kafka mientras también permite o deniega selectivamente el acceso del cliente.

Capacidad de Monitoreo

Actualmente, hay muchos productos de monitoreo disponibles para Kafka, como Kafka Eagle, Kafka Monitor, Kafka Manager, etc. Cada uno tiene sus propias ventajas y desventajas. Es difícil lograr una capacidad de monitoreo universal, y los costos de personalización son relativamente altos. Además, integrarlos con sistemas de monitoreo internos puede ser difícil. Construir un sistema de monitoreo de Kafka desde cero también es costoso, ya que la información de monitoreo para Kafka cubre muchos aspectos, y las métricas de monitoreo proporcionadas por Kafka en sí requieren un procesamiento complejo a través de Java Management Extension (JMX).

Al agregar una puerta de enlace API a la arquitectura, la comunicación entre el cliente y la puerta de enlace API se basa en el protocolo HTTP. Como resultado, el ecosistema de software de monitoreo basado en el protocolo HTTP es muy rico. Esto permite proporcionar una observabilidad completa para los servicios de Kafka a costos muy bajos.

Actualizaciones Graduales de Kafka

Los servicios de Kafka se exponen a través de direcciones de broker, que los productores y consumidores necesitan proporcionar en su información de configuración para conectarse a un clúster de Kafka. La lista de direcciones generalmente tiene el formato host1:port1, host2:port2, y puede contener una o más direcciones separadas por comas.

Sin embargo, este método de configuración tiene limitaciones: requiere que las direcciones de los brokers de Kafka permanezcan fijas y que los servicios permanezcan estables. Los clientes de Kafka asumen que todas las direcciones de los brokers están disponibles y seleccionan una al azar para usar. Esto puede causar problemas durante las actualizaciones graduales, ya que los clientes no saben qué broker usar, y cambiar las direcciones de los brokers requiere que todos los clientes productores y consumidores hagan cambios.

Con una puerta de enlace API para Kafka, las direcciones de los brokers se pueden configurar en la capa de la puerta de enlace, y los clientes ya no necesitan enfocarse en los detalles específicos de los brokers de Kafka. Incluso si la dirección del broker cambia, los clientes no se ven afectados. Esto facilita la realización de actualizaciones graduales para Kafka sin preocuparse por afectar a los clientes.

Resumen

Por lo tanto, al agregar una puerta de enlace API a Kafka, se facilita proporcionar capacidades de limitación de tasa, autenticación, monitoreo y actualizaciones graduales para los servicios de Kafka a través de la rica funcionalidad de la puerta de enlace API.

Usando Apache APISIX para Extender Kafka

Apache APISIX es una puerta de enlace API de alto rendimiento y en tiempo real bajo la Apache Software Foundation. Ofrece una gama de sofisticadas características de gestión de tráfico, incluyendo balanceo de carga, upstreams dinámicos, lanzamiento canario, corte de circuito, autenticación y observabilidad. Como puerta de enlace API, APISIX ayuda a las empresas a procesar el tráfico de API y microservicios de manera rápida y segura y es ampliamente utilizado en Kubernetes Ingress y malla de servicios. Al agregar una capa de APISIX delante de un servicio de Kafka, las empresas pueden aprovechar el rico sistema de plugins de la plataforma para habilitar capacidades de proxy de mensajes, entrega de logs, limitación de tasa, monitoreo y más. Con APISIX, tanto el tráfico norte-sur desde los clientes a los servidores como el tráfico este-oeste entre los microservicios de la empresa pueden procesarse eficazmente.

APISIX y Kafka

Proxy de Mensajes de Kafka

APISIX ofrece la capacidad de hacer de proxy de mensajes de Kafka. Los clientes pueden comunicarse directamente con APISIX, que maneja la conversión del protocolo de mensajes entre los clientes y Kafka.

Para habilitar la función de proxy de Kafka en APISIX, solo necesitamos agregar una ruta como se muestra a continuación:

curl -X PUT 'http://127.0.0.1:9180/apisix/admin/routes/Kafka' \
    -H 'X-API-KEY: <api-key>' \
    -H 'Content-Type: application/json' \
    -d '{
    "uri": "/Kafka",
    "plugins": {
        "Kafka-proxy": {
            "sasl": {
                "username": "user",
                "password": "pwd"
            }
        },
        "limit-count": {
            "count": 2,
            "time_window": 60,
            "rejected_code": 503,
            "key_type": "var",
            "key": "remote_addr"
        }
    },
    "upstream": {
        "nodes": {
            "Kafka-server1:9092": 1,
            "Kafka-server2:9092": 1,
            "Kafka-server3:9092": 1
        },
        "type": "none",
        "scheme": "Kafka"
    }
}'

Esta solicitud crea una ruta con la URI /Kafka en APISIX, que está asociada con tres nodos de broker de Kafka como servicios upstream. El plugin kafka-proxy se utiliza para agregar autenticación SASL/PLAIN a las solicitudes de Kafka. La configuración en APISIX admite actualizaciones en caliente, por lo que los brokers de Kafka pueden modificarse sin requerir un reinicio de la puerta de enlace API o interrumpir al cliente.

Además, el plugin limit-count está habilitado para esta ruta para proporcionar soporte de limitación de tasa. La configuración del plugin especifica que solo se permiten dos solicitudes dentro de un intervalo de 60 segundos, y cualquier solicitud adicional será rechazada por APISIX con un código de estado 503.

Envío de Logs

El plugin kafka-logger de APISIX permite enviar logs como objetos JSON a un clúster de Apache Kafka.

Aquí hay un ejemplo de configuración:

curl http://127.0.0.1:9180/apisix/admin/routes/1 \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '
{
    "plugins": {
       "kafka-logger": {
            "brokers" : [
              {
                "host" :"127.0.0.1",
                "port" : 9092
              },
              {
                "host" :"127.0.0.1",
                "port" : 9093
              }
            ],
           "kafka_topic" : "test2",
           "key" : "key1"
       }
    },
    "upstream": {
       "nodes": {
           "127.0.0.1:1980": 1
       },
       "type": "roundrobin"
    },
    "uri": "/hello"
}'

APISIX ofrece más que la capacidad de hacer de proxy de mensajes de Kafka. También proporciona capacidades de trazabilidad, métricas y registro a través de varios plugins, cubriendo todos los aspectos de la observabilidad. Con una configuración simple de plugins en APISIX, es posible la integración con otros servicios de observabilidad como Prometheus, Skywalking y otros, mejorando las capacidades de monitoreo de los clústeres de Kafka.

Resumen

Este artículo destaca las ventajas de implementar una puerta de enlace API para Kafka, y utiliza Apache APISIX como un caso de estudio para demostrar cómo ofrece características de Kafka como limitación de tasa, autenticación, monitoreo y actualizaciones graduales.

Tags:
APISIX Basics
Plugin