Florent Ramière

Florent Ramière

Conduktor

Florent Ramière a plus de vingt années d'expérience dans le développement logiciel et la conduite de projets informatiques. Après plus de 10 ans d'entrepreunariat, Florent à rejoint la société Confluent la société derrière Apache Kafka où il a accompagné pendant 5 ans les grands comptes en Europe. Il s'occupe désormais de simplifier l'usage du streaming chez Conduktor.

Twitter : @framiere

Blog: https://conduktor.io

bigd

Track : Big Data, Machine Learning, Analytics

Type de présentation : Conference

Le multi-tenancy chez Apache Kafka, navigation dans un sujet majeur

Quand Kafka devient progressivement le « système nerveux central pour les données », la simplicité des brokers peut passer d'une bénédiction à une malédiction. Les services qui étaient auparavant découplés doivent de plus en plus se connaître les uns les autres pour éviter les problèmes de collisions: topic, consumer groups, schema, connecteurs, métadonnées etc.

Chez Conduktor, nous avons eu le défi d'accueillir des milliers de tenants Kafka performants et isolés.

Pour trouver une solution viable et économique, nous avons exploré un large éventail de solutions possibles, notamment :

  • Plus de clusters Kafka - Chaque nouveau service peut-il avoir son propre cluster?
  • Convention - Choisissez des prefix, des headers, etc. pour éviter les conflits
  • Application côté client - Personnaliser les clients pour garantir la compatibilité
  • Application côté serveur - Configurez les brokers pour n'autoriser que les clients qui se comportent correctement
  • Proxy - Un outil efficace

Embarquez avec nous dans un voyage d'idées, de leçons et de solutions sur la façon dont nous avons résolu le multi-tenancy et comment vous pouvez l'appliquer à presque tous les déploiements Kafka.

archisec

Track : Architecture, Performance and Security

Type de présentation : Tools-in-Action

Détectez et corrigez automatiquement les problèmes les plus fréquents avec Apache Kafka

Kafka est un système super flexible et hyper configurable: c'est autant une bénédiction qu'une malédiction.

Comment pouvez-nous nous assurer que les applications utilisent efficacement les ressources Kafka, sachant qu'une majeure partie de la configuration est effectuée côté client... si loin des yeux attentif des chers ops et architectes?

Parmi les problèmes les plus courants, citons les

  • producteurs dont la taille des batch, linger est configurée de manière inefficace
  • producteurs qui n'utilisent pas de compression, ou ont un ack inadéquat
  • consommateurs un peu trop optimistes
  • consumer groups avec plus de membres que de partitions
  • création de topic sans convention de nommage, ou avec trop de partitions
  • topics qui mélangent involontairement des données avec des schémas ...
  • applications qui ne gèrent pas les erreurs de déserialization
  • applications qui ne gèrent pas l'idempotence
  • applications qui ne gèrent pas les rebalance storm
  • etc.

Rejoignez-nous pour discuter de ces problèmes, mais surtout des outils qui peuvent être mis en place pour les tuer ... net!