Pour gérer vos consentements :
Categories: Big Data

Comment PayPal a géré la mise à l’échelle de Kafka

Étendre le moteur SSL ? Mieux identifier les topics affectés par le manque de réplicas ? Deux éléments pour lesquels PayPal a contribué au code de Kafka.

L’entreprise américaine avait adopté la plate-forme en 2015. Sa flotte approche aujourd’hui de la centaine de clusters. Pour environ 1500 brokers – hébergeant 20 000 topics – et 2000 nœuds MirrorMaker. Chaque cluster traite plus de 100 milliards de messages par jour.

Pour accompagner la mise à l’échelle de cette infrastructure, PayPal a notamment investi dans la gestion des clusters. Il a, par exemple, déployé un service de configuration pour les clients Kafka.
À l’origine, ces derniers codaient en dur les adresses IP des brokers auxquels ils se connectaient. Or, diverses tâches de maintenance pouvaient amener à remplacer les brokers… ce qui occasionnait des incidents. Kafka fournissait par ailleurs de multiples configurations que les clients contournaient parfois sans en connaître les implications. La bande passante sur le support produit se réduisait d’autant.
Avec le service en question, les clients ont un modèle plug & play pour se connecter aux serveurs d’initialisation, avec une condiguration standardisée. En cas de problème, redémarrer une application suffit à incorporer des changements.

Un environnement de test standardisé sur GCP

En parallèle de la mise en place d’ACL, PayPal développé diverses bibliothèques logicielles. L’une d’entre elles, intégrée à son service de découverte, permet la portabilité des topics entre clusters. Une deuxième aide à suivre le statut des applications – elle utilise Micrometer pour exposer les indicateurs. Une troisième récupère les certificats et les tokens nécessaires à l’authentification SSL.

L’environnement de test a aussi évolué. Auparavant, les devs créaient des topics ad hoc, avec le risque d’écart fonctionnels vis-à-vis de la prod. PayPal y a substitué une plate-forme centralisée à parité fonctionnelle avec l’environnement de production. Les clusters qui la constituent sont hébergés sur GCP, en multizone rack-aware.

Les topics sont configurés avec trois réplicas. Pour éviter que le patching des hôtes (brokers + VM Zookeeper et MirrorMaker, tous en bare metal) crée des partitions sous-répliquées au fil des redémarrages, PayPal a développé un plug-in. Celui-ci assure qu’on ne patche qu’un broker à la fois.

La contribution à l’extensibilité du moteur SSL a permis, entre autres, d’éliminer une limite : jusqu’à Kafka 2.6.0, le chargement de certificats ne pouvait se faire que depuis le système de fichiers.

Diverses automatisations sont aussi venues accompagner la mise à l’échelle. Aussi bien pour l’ajout de topics que leur mise en miroir ou la réallocation des partitions.

Illustration principale © Danloe – Adobe Stock

Recent Posts

IA générative : l’Autorité de la concurrence pointe de sérieux risques

Dans un avis consultatif, l'Autorité de la concurrence a identifié les risques concurrentiels liés à…

2 jours ago

OpenAI signe un accord de contenu avec Time

OpenAI signe un « partenariat de contenu stratégique » avec Time pour accéder au contenu…

2 jours ago

Atos : David Layani (Onepoint) veut sortir du capital

Au lendemain du rejet de sa proposition de restructuration, David Layani annonce sa démission du…

2 jours ago

Évaluer les LLM, un défi : le cas Hugging Face

Après un an, Hugging Face a revu les fondements de son leaderboard LLM. Quels en…

3 jours ago

Mozilla face au dilemme de la GenAI dans Firefox

Mozilla commence à expérimenter divers LLM dans Firefox, en parallèle d'autres initiatives axées sur l'intégration…

3 jours ago

VMware tente d’orienter vers VCF les déploiements pré-Broadcom

VMware met VCF à jour pour y favoriser la migration des déploiements qui, sur le…

4 jours ago