#Kafka2Kafka

Passerelle de transmission des messages entre deux bus Kafka (voir archi globale).

#Principe

La passerelle permet de transmettre les messages entre l’environnement central et les complexes.

Elle est hébergée sur le central.

On doit pouvoir configurer quels sont les flux à échanger :

• serveur source
• topic source
• serveur cible
• topic cible

#Exemple de fonctionnement

• Une instance de passerelle par kafka (une qui tombe n’impacte pas les autres) :

  • central <-> nouméa
  • central <-> koné
  • central <-> …

• La configuration des topics est la même pour chaque instance

  • cineges.user.save : complexe -> central
  • cineges.user.data : central -> complexe
  • notifications : central -> complexe

• La configuration doit être facilement/rapidement modifiable

#Solution

Kafka-mirror est utilisé pour faire le kafka2kafka. kafka-mirror est un job java (lancé via $KAFKA_HOME/bin/kafka-make-mirror.sh) qui instancie un consumer kafka sur un cluster et un producer kafka, sur un autre cluster et qui copie tous les messages des topics (sauf topic interne) du cluster source vers le cluster cible. Si tous les topics ne doivent pas être synchronisé, le parametre –whitelist ou –blacklist peuvent être utilisé (l’un ou l’autre) pour spécifier les topics à prendre en compte sous forme de liste, et expression regulière.

Pour réaliser une passerelle kafka2kafka, nous avons instancié 2 kafka-mirror, un dans chaque sens de central <-> complexe.

Il est facile de déployer une passerelle via helm : cf git kafka2kafka.

Par default le helm déploie une passerelle, mais il est possible de déployer plusieurs passerelles en une fois, si tous les complexes sont renseignés dans le value.yaml.

une passerelle est constituée :

• d’un service (fake, sert d’avantage à voir le pod dans l’IC manager)
• d’un configmap où sont paramétrés les fichiers properties des consumers et des producers kafka des 2 kafka-mirror
• d’un deployment consitué de 2 pods
• dans chaque pod est lancé un kafka-mirror avec les fichiers properties spécifiques aux consumer et producer suivant le sens de la synchronisation, et avec les topics en whitelist à syncroniser dans ce sens.

Le helm permet via un seul fichier de parametrage (values.yaml) de définir les mêmes paramètres pour toutes les passerelles (parametre de topic, de host kafka ,…).

Chaque passerelle est de cette manière décorélée et peut etre installée, suprimée, relancée, indépendemment des autres passerelles.

#les parametres consumer et producer :

La passerelle est censée être déployée sur l’environnement du central. En l’état ce n’est pas une obligation architecturale de kafka-mirror … mais suivant cette recommendation, les parametres des consumer et producer prennent en compte que ceux-ci sont plus proches du cluster de central :

• les producer vers complexe, et consumer complexe ont des parametres qui prennent en compte la forte probabilité d’être déconnecté.

Si les messages à écrire n’arrivent pas à être absorbés par un seul consumer, il est possible d’augmenter le replicationfactor du deployment : en effet les consumer faisant parti du même group (group.id) ils peuvent à plusieurs consommer les messages des topics sans créer des doublons. De la même manière, les group.id sont différents pour les différentes passerelles.

Les topic sont lus depuis earliest : ainsi la totalité des topics disponibles sera lu

Si le producer de la synchro doit créer le topic, la configuration du topic ne sera pas la même que dans le cluster source, mais celle de la création par défaut de son cluster… Peut être que certain topic doivent être créer préalablement avant la mise en place de kafka2kafka.

#Sécurité kafka

Pour le bon fonctionnement de kafka2kafka, il faut que les cluster kafka soient accessible via le net … hors il serait surement indispensable de mettre en place la securistaion de ces cluster… kafka-mirror devra prendre en compte ces elements de securité dans les properties des consumers et producers des complexes

#Flux

#service.notif.done.json

Ce topic contient les notifications de fin de traitement.

#cineges.*.data

Contient les données des entités.

#cineges.*.saveLocal

Contient les entités à enregistrer pour traitement

#cineges.*.saveToComplexe

Contient les entités traitées à envoyer vers les complexes

#cineges.*.saveToCentral

Contient les entités traitées à envoyer vers le central