Urgence pour le système de découverte de services : la capacité actuelle du plan de contrôle pourrait être épuisée à l’horizon 2025.

LinkedIn avait fait ce constat à l’été 2022. En conséquence, il avait lancé un chantier de modernisation.

Élasticité, compatibilité… Le plan de contrôle ZooKeeper arrivait à ses limites

Le plan de contrôle reposait alors sur ZooKeeper. Il avait une structure plate. Les applications serveur y enregistraient leurs points de terminaison en tant que nœuds éphémères, sous forme d’URI D2 (Dynamic Discovery). Les applications clientes lui adressaient des requêtes en lecture pour suivre les clusters qui les intéressaient.

Cette approche présentait des limites en termes d’élasticité. ZooKeeper étant un système à cohérence forte, toutes les lectures et les écritures, ainsi que les vérifications d’intégrité des nœuds, passaient par la même file d’attente. Les requêtes étaient donc susceptibles de s’accumuler jusqu’au moment où certaines ne pourraient plus être traitées. En parallèle, des sessions pourraient être fermées en cas de timeout sur la vérification d’intégrité. S’ensuivraient une perte de capacité côté serveur et, in fine, des indisponibilités d’applications.

Autre limite : les entités D2 étant liées à des schémas spécifiques à LinkedIn, elles étaient incompatibles avec des data planes modernes comme gRPC et Envoy. De plus, l’implémentation de la logique de lecture/écriture dans les conteneurs applicatifs était focalisée sur Java. Par ailleurs, l’absence d’une couche intermédiaire entre le registre de services et les instances applicatives empêchait de développer des techniques de gestion RPC centralisées, par exemple pour le load balancing.

Kafka côté serveur, gRPC côté client

Le nouveau plan de contrôle introduit des composantes Kafka et Observer.

Kafka réceptionne les requêtes en écriture des serveurs et les informations d’intégrité sous forme d’événements, appelés URI de découverte de services.

La brique Observer consomme ces URI et les conserve en mémoire. Les applications clientes s’y abonnent en ouvrant un flux gRPC. Elles envoient leurs requêtes via le protocole xDS.

Les configurations D2 restent stockées dans ZooKeeper. Elles sont converties en entités xDS par les propriétaires d’applications puis distribuées à l’« observateur » de la même manière que les URI.

Les readiness probes de Kubernetes en ligne de mire

Dans cette architecture, l’élasticité et la disponibilité ont la priorité sur la cohérence. L’observateur, écrit en Go avec une concurrence forte, peut gérer 40 000 flux clients et 10 000 mises à jour par seconde tout en consommant 11 000 événements Kafka par seconde, selon LinkedIn.

Pour gagner encore en élasticité, il serait possible, au-delà d’augmenter le nombre d’observateurs, d’en créer deux types. D’un côté, des instances consommant les événements Kafka. De l’autre, des instances répondant aux requêtes des clients.

Comme il utilise xDS, le plan de contrôle est compatible avec Envoy ; ce qui ouvre la porte à un support multilangage. Et avec l’introduction de cette couche intermédiaire, il devient possible d’intégrer des fonctionnalités autour des maillages de services. Voire d’exploiter les readiness probes de Kubernetes pour faire passer les serveurs en mode passif et ainsi fiabiliser le système.

La latence P50 amenée sous la seconde

Le déploiement a été compliqué par la variété des clients (dépendances, accès réseau, SSL…). Pour beaucoup, il était difficile de prévoir le niveau de compatibilité.

Il a de surcroît fallu mener le chantier parallèlement sur les lectures et sur les écritures. Dans les grandes lignes, sans les unes, la migration des autres était bloquée. L’infrastructure d’origine a donc été conservée, dans une approche dual mode, Kafka étant la source primaire et ZooKeeper le backup (utilisé en cas d’absence de données Kafka). Une tâche cron a permis de jauger le niveau de dépendance des applications à ZooKeeper et de prioriser les migrations en conséquence.

Pour les lectures, les principaux éléments évalués côté client furent le délai entre l’envoi d’une requête d’abonnement et la réception des données, les erreurs de résolution de ces requêtes, ainsi que la cohérence entre la data de ZooKeeper et celle de Kafka. Côté observateur, LinkedIn a examiné le type, le nombre et la capacité des connexions clients, le délai entre la réception des requêtes et l’envoi des données vers la file d’attente, ainsi que les taux d’utilisation de ressources.

Pour les écritures, ont principalement été mesurés :

• Latence et pertes de connexion sur ZooKeeper et kafka
• Score de similarité des URI entre ZooKeeper et Kafka
• Délai de propagation du cache (temps entre réception des données et mise à jour du cache)

LinkedIn affirme que 50 % des clients obtiennent désormais les données en moins de 1 seconde et 99 % en moins de 5 secondes. Sur le plan de contrôle ZooKeeper, les latences P50 et P99 étaient respectivement à 10 et 30 secondes.

À consulter en complément, d’autres retex impliquant Kafka et/ou ZooKeeper :

Unification des déploiements de configuration chez Uber
Optimisation des coûts Kafka sur AWS chez Grab
Mise à l’échelle de Kafka chez PayPal
Passage à l’architecture cellulaire chez Slack

Illustration © Danloe – Adobe Stock

The post LinkedIn associe Kafka et gRPC pour la découverte de services appeared first on Silicon.fr.