Explorando os Benefícios de Usar um API Gateway para Kafka

Yuan Bao

March 31, 2023

Technology

Breve Introdução ao Kafka

Kafka foi originalmente criado pelo LinkedIn como um sistema de mensagens distribuído que dependia da coordenação do Zookeeper e incluía múltiplas partições e réplicas. Posteriormente, foi doado à Apache Software Foundation. Graças à sua excepcional capacidade de throughput, persistência e escalabilidade horizontal, o Kafka se tornou uma plataforma de processamento de fluxo distribuído amplamente adotada na indústria.

O Kafka tem três principais casos de uso:

  • Sistema de mensagens: Este é o caso de uso mais comum, onde é utilizado para comunicação de mensagens entre microsserviços de backend. O Kafka permite a desacoplação de sistemas, modelagem de tráfego e comunicação assíncrona.
  • Sistema de armazenamento: O Kafka armazena mensagens em disco e inclui um recurso de múltiplas réplicas, tornando-o uma opção adequada para uso como um sistema de persistência de dados. Isso reduz significativamente o risco de perda de dados.
  • Plataforma de processamento de fluxo: O Kafka fornece uma biblioteca abrangente para processamento de fluxo, incluindo operações como janelas, junções e transformações.

Arquitetura Técnica do Kafka

Um cluster Kafka padrão consiste em múltiplos Produtores, Consumidores, Brokers e um cluster Zookeeper. O Zookeeper é o componente central de controle do cluster Kafka, responsável por gerenciar metadados do cluster e eleições de controladores. Os Produtores enviam mensagens para os Brokers, que armazenam as mensagens em disco, enquanto os Consumidores se inscrevem e consomem mensagens dos Brokers.

Conceitos Principais

Tópico e Partição no Kafka

No Kafka, as mensagens são categorizadas por tópicos. Os Produtores geralmente especificam um tópico ao enviar mensagens, enquanto os Consumidores normalmente se inscrevem em um tópico para consumir mensagens.

Um tópico geralmente consiste em múltiplas partições, com cada partição contendo diferentes mensagens. Quando uma mensagem é enviada ao Kafka, ela é armazenada na partição apropriada com base nas regras de particionamento. Ao definir regras de particionamento adequadas, as mensagens podem ser distribuídas uniformemente entre diferentes partições.

Produtor e Consumidor

Produtor refere-se à parte que envia mensagens, responsável por criar mensagens e enviá-las para os brokers do Kafka.

Consumidor refere-se à parte que recebe mensagens, responsável por se conectar ao broker do cluster Kafka, inscrever-se em um tópico específico e consumir mensagens.

Brokers Kafka

Um Broker pode ser considerado como um nó ou instância independente do Kafka. Um cluster Kafka consiste em um ou mais Brokers.

cluster kafka

Por que o Kafka Precisa de um API Gateway

Na maioria dos casos, ao usar o Kafka como um sistema de mensagens entre microsserviços de backend, os desenvolvedores precisam escolher diferentes SDKs do Kafka para desenvolver clientes produtores ou consumidores, dependendo da linguagem usada no projeto.

No entanto, essa abordagem tem limitações em certos cenários, como quando o cliente precisa se conectar diretamente ao Kafka. Nesses casos, adicionar um API gateway entre o chamador e o Kafka pode ajudar a desacoplar serviços. Dessa forma, o chamador não precisa se preocupar com o Kafka ou protocolos de comunicação específicos, o que reduz os custos de chamada. Além disso, um API gateway pode fornecer suporte de segurança e controle de tráfego para as APIs expostas pelo Kafka, garantindo a estabilidade dos serviços Kafka.

Conectando-se Diretamente ao Kafka

Conectar-se diretamente ao Kafka pode resultar em uma série de limitações e riscos ao usá-lo como um middleware de fila de mensagens:

  1. Diferentes consumidores devem se adaptar ao protocolo de comunicação do Kafka.
  2. O Kafka não fornece soluções para proteger APIs expostas, controle de tráfego e outros problemas. Sem políticas de limitação de taxa, alguns produtores ou consumidores podem consumir poder de computação e largura de banda excessivos.
  3. Tanto consumidores quanto produtores devem estar cientes da topologia do cluster Kafka, que pode ser impactada por mudanças no cluster Kafka.

API Gateway Melhora a Usabilidade do Kafka

Conversão de Protocolo de Comunicação

Quando um API gateway é usado para fazer proxy do Kafka, o cliente se comunica com o API gateway usando o protocolo HTTP, enquanto o API gateway se comunica com o Kafka usando o protocolo do Kafka. O API gateway converte as mensagens do cliente para o protocolo do Kafka, eliminando a necessidade de o cliente se adaptar a diferentes protocolos de mensagens do Kafka. Isso reduz significativamente os custos de desenvolvimento e torna o uso mais conveniente.

Limitação de Taxa

Quando os recursos são limitados, a capacidade de serviço dos nós Kafka também é restrita. Exceder esse limite pode causar a queda do serviço e resultar em uma reação em cadeia. Limitação de taxa pode evitar que isso aconteça. Na arquitetura tradicional do Kafka, os clientes se comunicam com o Kafka via SDKs. No entanto, se o número de clientes ou solicitações for alto, isso pode impactar a carga da máquina dos nós Kafka e afetar a estabilidade da funcionalidade do Kafka. Adicionar um API gateway à arquitetura facilita a incorporação de suporte a funções de limitação de taxa em várias dimensões ao cluster Kafka, já que os API gateways são excelentes nisso. Essas capacidades incluem:

  • Usar o algoritmo de janela de tempo fixo para limitar o número total de solicitações que um único cliente pode fazer ao serviço dentro de um período de tempo especificado.
  • Restringir o número de solicitações simultâneas que um cliente pode fazer a um único serviço.
  • Usar o algoritmo do balde de vazamento para limitar a taxa de solicitação de um único cliente ao serviço.

Ao implementar essas funções de limitação de taxa, os nós Kafka podem ser efetivamente protegidos, garantindo sua estabilidade.

Suporte a Autenticação

Autenticação também é uma forte característica de um API gateway. Na arquitetura tradicional do Kafka, a maioria das portas Kafka são acessadas dentro de uma rede interna. Se o acesso a partir de uma rede pública for necessário, configurações complexas são necessárias para garantir a segurança. Usar a funcionalidade de autenticação do API gateway ao fazer proxy do Kafka pode proteger as portas expostas do Kafka, ao mesmo tempo em que permite ou nega seletivamente o acesso do cliente.

Capacidade de Monitoramento

Atualmente, existem muitos produtos de monitoramento disponíveis para o Kafka, como Kafka Eagle, Kafka Monitor, Kafka Manager, etc. Cada um deles tem suas vantagens e desvantagens. É desafiador alcançar uma capacidade de monitoramento universal, e os custos de personalização são relativamente altos. Além disso, integrá-los com sistemas de monitoramento internos pode ser difícil. Construir um sistema de monitoramento do Kafka do zero também é caro, pois as informações de monitoramento do Kafka cobrem muitos aspectos, e as métricas de monitoramento fornecidas pelo próprio Kafka exigem processamento complexo através do Java Management Extension (JMX).

Ao adicionar um API gateway à arquitetura, a comunicação entre o cliente e o API gateway é baseada no protocolo HTTP. Como resultado, o ecossistema de software de monitoramento baseado no protocolo HTTP é muito rico. Isso permite a provisão de observabilidade abrangente para serviços Kafka a custos muito baixos.

Atualizações Graduais do Kafka

Os serviços Kafka são expostos através de endereços de broker, que produtores e consumidores precisam fornecer em suas informações de configuração para se conectar a um cluster Kafka. A lista de endereços é tipicamente formatada como host1:port1, host2:port2, e pode conter um ou mais endereços separados por vírgulas.

No entanto, esse método de configuração tem limitações: ele exige que os endereços dos brokers Kafka permaneçam fixos e que os serviços permaneçam estáveis. Os clientes Kafka assumem que todos os endereços de broker estão disponíveis e selecionam aleatoriamente um para usar. Isso pode causar problemas durante atualizações graduais, pois os clientes não estão cientes de qual broker usar, e mudar os endereços dos brokers exige que todos os clientes produtores e consumidores façam alterações.

Com um API gateway para o Kafka, os endereços dos brokers podem ser configurados na camada do gateway, e os clientes não precisam mais se concentrar nos detalhes específicos dos brokers Kafka. Mesmo que o endereço do broker mude, os clientes permanecem inalterados. Isso facilita a realização de atualizações graduais para o Kafka sem preocupações sobre afetar os clientes.

Resumo

Assim, ao adicionar um API gateway ao Kafka, torna-se mais fácil fornecer capacidades de limitação de taxa, autenticação, monitoramento e atualizações graduais para serviços Kafka através da rica funcionalidade do API gateway.

Usando o Apache APISIX para Estender o Kafka

Apache APISIX é um API gateway de alto desempenho e em tempo real sob a Apache Software Foundation. Ele oferece uma gama de recursos sofisticados de gerenciamento de tráfego, incluindo balanceamento de carga, upstreams dinâmicos, lançamento canário, interrupção de circuito, autenticação e observabilidade. Como um API gateway, o APISIX ajuda as empresas a processar tráfego de API e microsserviços de forma rápida e segura e é amplamente usado em Kubernetes Ingress e service mesh. Ao adicionar uma camada APISIX na frente de um serviço Kafka, as empresas podem aproveitar o rico sistema de plugins da plataforma para habilitar proxy de mensagens, entrega de logs, limitação de taxa, monitoramento e outras capacidades. Com o APISIX, tanto o tráfego norte-sul de clientes para servidores quanto o tráfego leste-oeste entre microsserviços empresariais podem ser efetivamente processados.

APISIX e Kafka

Fazendo Proxy de Mensagens Kafka

O APISIX oferece a capacidade de fazer proxy de mensagens Kafka. Os clientes podem se comunicar diretamente com o APISIX, que lida com a conversão do protocolo de mensagens entre os clientes e o Kafka.

Para habilitar o recurso de proxy Kafka no APISIX, basta adicionar uma rota como mostrado abaixo:

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"
    }
}'

Essa solicitação cria uma rota com o URI /Kafka no APISIX, que está associada a três nós Kafka broker como serviços upstream. O plugin kafka-proxy é usado para adicionar autenticação SASL/PLAIN às solicitações Kafka. A configuração no APISIX suporta atualizações em tempo real, então os brokers Kafka podem ser modificados sem exigir uma reinicialização do API gateway ou interrupção do cliente.

Além disso, o plugin limit-count é habilitado para essa rota para fornecer suporte à limitação de taxa. A configuração do plugin especifica que apenas duas solicitações são permitidas dentro de um intervalo de 60 segundos, e quaisquer solicitações adicionais serão rejeitadas pelo APISIX com um código de status 503.

Envio de Logs

O plugin kafka-logger do APISIX permite que logs sejam enviados como objetos JSON para um cluster Apache Kafka.

Aqui está um exemplo de configuração:

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"
}'

O APISIX oferece mais do que a capacidade de fazer proxy de mensagens Kafka. Ele também fornece capacidades de rastreamento, métricas e registro através de vários plugins, cobrindo todos os aspectos da observabilidade. Com uma simples configuração de plugin no APISIX, a integração com outros serviços de observabilidade, como Prometheus, Skywalking e outros, é possível, aprimorando as capacidades de monitoramento de clusters Kafka.

Resumo

Este artigo destaca as vantagens de implementar um API gateway para o Kafka e usa o Apache APISIX como um estudo de caso para demonstrar como ele oferece recursos do Kafka, como limitação de taxa, autenticação, monitoramento e atualizações graduais.

Tags:
APISIX Basics
Plugin