Explorer les avantages de l'utilisation d'une passerelle API pour Kafka

Yuan Bao

March 31, 2023

Technology

Brève introduction de Kafka

Kafka a été initialement créé par LinkedIn en tant que système de messagerie distribué reposant sur la coordination de Zookeeper et incluant plusieurs partitions et réplicas. Il a ensuite été offert à la Apache Software Foundation. Grâce à son débit exceptionnel, sa persistance et ses capacités de mise à l'échelle horizontale, Kafka est devenu une plateforme de traitement de flux distribuée largement adoptée dans l'industrie.

Kafka a trois cas d'utilisation principaux :

  • Système de messagerie : C'est le cas d'utilisation le plus courant, où il est utilisé pour la communication de messages entre les microservices backend. Kafka permet la découplage des systèmes, la mise en forme du trafic et la communication asynchrone.
  • Système de stockage : Kafka stocke les messages sur disque et inclut une fonctionnalité de multi-réplicas, ce qui en fait une option adaptée pour être utilisé comme système de persistance de données. Cela réduit considérablement le risque de perte de données.
  • Plateforme de traitement de flux : Kafka fournit une bibliothèque complète pour le traitement de flux, incluant des opérations comme le fenêtrage, la jointure et les transformations.

Architecture technique de Kafka

Un cluster Kafka standard est composé de plusieurs Producteurs, Consommateurs, Brokers et un cluster Zookeeper. Zookeeper est le composant de contrôle central du cluster Kafka, responsable de la gestion des métadonnées du cluster et des élections de contrôleurs. Les Producteurs envoient des messages aux Brokers, qui stockent les messages sur disque, tandis que les Consommateurs s'abonnent et consomment les messages des Brokers.

Concepts de base

Topic et Partition Kafka

Dans Kafka, les messages sont catégorisés par topics. Les Producteurs spécifient généralement un topic lors de l'envoi de messages, tandis que les Consommateurs s'abonnent généralement à un topic pour consommer les messages.

Un topic est généralement composé de plusieurs partitions, chaque partition contenant des messages différents. Lorsqu'un message est envoyé à Kafka, il est stocké dans la partition appropriée en fonction des règles de partitionnement. En définissant des règles de partitionnement appropriées, les messages peuvent être répartis de manière uniforme sur différentes partitions.

Producteur et Consommateur

Producteur désigne l'entité qui envoie des messages, responsable de la création des messages et de leur envoi aux brokers Kafka.

Consommateur désigne l'entité qui reçoit des messages, responsable de la connexion au broker du cluster Kafka, de l'abonnement à un topic particulier et de la consommation des messages.

Brokers Kafka

Un Broker peut être considéré comme un nœud ou une instance indépendante de Kafka. Un cluster Kafka est composé d'un ou plusieurs Brokers.

cluster kafka

Pourquoi Kafka a besoin d'une API Gateway

Dans la plupart des cas, lorsque Kafka est utilisé comme système de messagerie entre les microservices backend, les développeurs doivent choisir différents SDK Kafka pour développer des clients producteurs ou consommateurs, en fonction du langage utilisé dans le projet.

Cependant, cette approche présente des limites dans certains scénarios, comme lorsque le client doit se connecter directement à Kafka. Dans de tels cas, l'ajout d'une API gateway entre l'appelant et Kafka peut aider à découpler les services. Ainsi, l'appelant n'a pas besoin de se soucier de Kafka ou des protocoles de communication spécifiques, ce qui réduit les coûts d'appel. De plus, une API gateway peut fournir un support de sécurité et des capacités de contrôle de trafic pour les API exposées par Kafka, assurant la stabilité des services Kafka.

Connexion directe à Kafka

Se connecter directement à Kafka peut entraîner un certain nombre de limitations et de risques lorsqu'il est utilisé comme middleware de file d'attente de messages :

  1. Différents consommateurs doivent s'adapter au protocole de communication de Kafka.
  2. Kafka ne fournit pas de solutions pour sécuriser les API exposées, le contrôle de trafic et d'autres problèmes. Sans politiques de limitation de débit, certains producteurs ou consommateurs peuvent consommer une puissance de calcul et une bande passante excessives.
  3. Les consommateurs et les producteurs doivent être conscients de la topologie du cluster Kafka, qui peut être impactée par des modifications du cluster Kafka.

L'API Gateway améliore l'utilisabilité de Kafka

Conversion de protocole de communication

Lorsqu'une API gateway est utilisée pour proxifier Kafka, le client communique avec l'API gateway en utilisant le protocole HTTP, tandis que l'API gateway communique avec Kafka en utilisant le protocole de Kafka. L'API gateway convertit les messages du client au protocole de Kafka, éliminant le besoin pour le client de s'adapter à différents protocoles de messages Kafka. Cela réduit considérablement les coûts de développement et rend l'utilisation plus pratique.

Limitation de débit

Lorsque les ressources sont limitées, la capacité de service des nœuds Kafka est également contrainte. Dépasser cette limite pourrait entraîner un crash du service et provoquer une réaction en chaîne. La limitation de débit peut empêcher cela. Dans l'architecture traditionnelle de Kafka, les clients communiquent avec Kafka via des SDK. Cependant, si le nombre de clients ou de demandes est élevé, cela peut impacter la charge machine des nœuds Kafka et affecter la stabilité des fonctionnalités de Kafka. L'ajout d'une API gateway à l'architecture permet d'intégrer facilement diverses dimensions de support de fonctionnalités de limitation de débit au cluster Kafka, car les API gateway excellent dans ce domaine. Ces capacités incluent :

  • Utilisation de l'algorithme de fenêtre de temps fixe pour limiter le nombre total de demandes qu'un seul client peut faire au service dans un laps de temps spécifié.
  • Limitation du nombre de demandes simultanées qu'un client peut faire à un seul service.
  • Utilisation de l'algorithme du seau percé pour limiter le taux de demandes d'un seul client au service.

En mettant en œuvre ces fonctions de limitation de débit, les nœuds Kafka peuvent être efficacement protégés, assurant leur stabilité.

Support d'authentification

L'authentification est également une fonctionnalité forte d'une API gateway. Dans l'architecture traditionnelle de Kafka, la plupart des ports Kafka sont accessibles au sein d'un réseau interne. Si un accès depuis un réseau public est nécessaire, des configurations complexes sont nécessaires pour assurer la sécurité. L'utilisation de la fonctionnalité d'authentification de l'API gateway lors du proxying de Kafka peut protéger les ports exposés par Kafka tout en permettant ou refusant sélectivement l'accès des clients.

Capacité de surveillance

Il existe actuellement de nombreux produits de surveillance disponibles pour Kafka, tels que Kafka Eagle, Kafka Monitor, Kafka Manager, etc. Chacun d'eux a ses avantages et inconvénients. Il est difficile d'atteindre une capacité de surveillance universelle, et les coûts de personnalisation sont relativement élevés. De plus, leur intégration avec les systèmes de surveillance internes peut être difficile. Construire un système de surveillance Kafka à partir de zéro est également coûteux, car les informations de surveillance pour Kafka couvrent de nombreux aspects, et les métriques de surveillance fournies par Kafka lui-même nécessitent un traitement complexe via Java Management Extension (JMX).

En ajoutant une API gateway à l'architecture, la communication entre le client et l'API gateway est basée sur le protocole HTTP. Par conséquent, l'écosystème des logiciels de surveillance basés sur le protocole HTTP est très riche. Cela permet de fournir une observabilité complète pour les services Kafka à très faible coût.

Mises à jour progressives de Kafka

Les services Kafka sont exposés via des adresses de broker, que les producteurs et consommateurs doivent fournir dans leurs informations de configuration pour se connecter à un cluster Kafka. La liste d'adresses est généralement formatée comme host1:port1, host2:port2, et peut contenir une ou plusieurs adresses séparées par des virgules.

Cependant, cette méthode de configuration a des limites : elle nécessite que les adresses des brokers Kafka restent fixes et que les services restent stables. Les clients Kafka supposent que toutes les adresses de broker sont disponibles et en sélectionnent une au hasard pour l'utiliser. Cela peut causer des problèmes lors des mises à jour progressives, car les clients ne savent pas quel broker utiliser, et le changement d'adresses de broker nécessite que tous les clients producteurs et consommateurs effectuent des modifications.

Avec une API gateway pour Kafka, les adresses de broker peuvent être configurées au niveau de la gateway, et les clients n'ont plus besoin de se concentrer sur les détails spécifiques des brokers Kafka. Même si l'adresse du broker change, les clients ne sont pas affectés. Cela facilite les mises à jour progressives de Kafka sans craindre d'affecter les clients.

Résumé

Ainsi, en ajoutant une API gateway à Kafka, il devient plus facile de fournir des capacités de limitation de débit, d'authentification, de surveillance et de mises à jour progressives pour les services Kafka grâce aux fonctionnalités riches de l'API gateway.

Utilisation d'Apache APISIX pour étendre Kafka

Apache APISIX est une API gateway haute performance et en temps réel sous la Apache Software Foundation. Elle offre une gamme de fonctionnalités sophistiquées de gestion de trafic, incluant l'équilibrage de charge, les upstreams dynamiques, la mise en production canari, la rupture de circuit, l'authentification et l'observabilité. En tant qu'API gateway, APISIX aide les entreprises à traiter rapidement et en toute sécurité le trafic des API et des microservices, et est largement utilisé dans Kubernetes Ingress et le service mesh. En ajoutant une couche APISIX devant un service Kafka, les entreprises peuvent tirer parti du système de plugins riche de la plateforme pour activer le proxying de messages, la livraison de logs, la limitation de débit, la surveillance et d'autres capacités. Avec APISIX, le trafic nord-sud des clients vers les serveurs et le trafic est-ouest entre les microservices de l'entreprise peuvent être efficacement traités.

APISIX et Kafka

Proxying des messages Kafka

APISIX offre la capacité de proxifier les messages Kafka. Les clients peuvent communiquer directement avec APISIX, qui gère la conversion du protocole de message entre les clients et Kafka.

Pour activer la fonctionnalité de proxy Kafka dans APISIX, il suffit d'ajouter une route comme suit :

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

Cette requête crée une route avec l'URI /Kafka dans APISIX, qui est associée à trois nœuds de broker Kafka en tant que services upstream. Le plugin kafka-proxy est utilisé pour ajouter l'authentification SASL/PLAIN aux demandes Kafka. La configuration dans APISIX supporte les mises à jour à chaud, donc les brokers Kafka peuvent être modifiés sans nécessiter un redémarrage de l'API gateway ou perturber le client.

De plus, le plugin limit-count est activé pour cette route pour fournir un support de limitation de débit. La configuration du plugin spécifie que seulement deux demandes sont autorisées à passer dans un intervalle de 60 secondes, et toute demande supplémentaire sera rejetée par APISIX avec un code d'état 503.

Poussée de logs

Le plugin kafka-logger d'APISIX permet de pousser les logs sous forme d'objets JSON vers un cluster Apache Kafka.

Voici un exemple de configuration :

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 offre plus que la simple capacité de proxifier les messages Kafka. Elle fournit également des capacités de tracing, de métriques et de logging via divers plugins, couvrant tous les aspects de l'observabilité. Avec une simple configuration de plugin sur APISIX, l'intégration avec d'autres services d'observabilité tels que Prometheus, Skywalking et d'autres est possible, améliorant les capacités de surveillance des clusters Kafka.

Résumé

Cet article met en avant les avantages de la mise en œuvre d'une API gateway pour Kafka, et utilise Apache APISIX comme étude de cas pour démontrer comment elle offre des fonctionnalités Kafka telles que la limitation de débit, l'authentification, la surveillance et les mises à jour progressives.

Tags:
APISIX Basics
Plugin