Comment PayPal a géré la mise à l’échelle de Kafka
Gestion de configuration, contrôle d’accès, environnement de test… PayPal a fait évoluer son déploiement Kafka au gré de sa mise à l’échelle.
É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
