Le démarrage initial a été lent et après le premier mois de fonctionnement, LinkedIn comptait environ 4300 membres. La plupart sont venus grâce à des invitations personnelles des membres fondateurs.

Cependant, la base d’utilisateurs de LinkedIn a rapidement augmenté de manière exponentielle, tout comme le contenu hébergé sur la plateforme. En quelques années, LinkedIn servait des dizaines de milliers de pages Web chaque seconde de chaque jour à des utilisateurs du monde entier.

Cette croissance sans précédent a eu une implication majeure. LinkedIn a dû relever des défis extraordinaires pour adapter son application à la demande croissante. Bien que cela ait été difficile pour les développeurs impliqués dans les multiples projets, c’est une mine d’or de leçons pour tout développeur.

Dans cet article, nous examinerons les différents outils et techniques que LinkedIn a adoptés pour faire évoluer la plateforme.

Des Débuts Modestes avec Leo

Comme de nombreuses startups, LinkedIn a également commencé avec une architecture monolithique. Il y avait une grande application qui prenait en charge toutes les fonctionnalités nécessaires pour le site Web. Elle hébergeait des servlets Web pour les différentes pages, gérait la logique métier et se connectait également à la couche de base de données.

Cette application monolithique était connue en interne sous le nom de Leo. Oui, elle était aussi magnifique que Leo le Lion de MGM.

Le schéma ci-dessous représente le concept de Leo à un niveau élevé.

Le Premier Besoin de Scalabilité

• Gestion des connexions entre membres
• Capacités de recherche

Examinons les deux.

Service de Graph des Membres

Un réseau social dépend des connexions entre les personnes. Il était donc crucial pour LinkedIn de gérer efficacement les connexions entre les membres. Par exemple, LinkedIn affiche la distance du graph et les connexions communes lorsque nous consultons le profil d’un utilisateur sur le site. Pour afficher ce petit morceau de données, ils devaient effectuer des calculs de graph en mémoire avec une faible latence, créant ainsi le besoin d’un système capable d’interroger les données de connexion en utilisant des traversées de graph en mémoire. La nécessité de l’utilisation en mémoire est essentielle pour atteindre les objectifs de performance du système.

Un tel système avait un profil d’utilisation et un besoin de scalabilité complètement différents de Leo. Par conséquent, les ingénieurs de LinkedIn ont construit un système de graph distribué et partitionné capable de stocker des millions de membres et leurs connexions. Il pouvait également gérer des centaines de milliers de requêtes par seconde (QPS).

Le système s’appelait Cloud et c’était le premier service chez LinkedIn. Il se composait de trois sous-composants majeurs :

1. GraphDB – une base de données de graph partitionnée et répliquée pour une haute disponibilité et durabilité
2. Network Cache Service – un cache distribué qui stocke le réseau d’un membre et sert les requêtes nécessitant une connaissance de second degré
3. API Layer – le point d’accès pour le front-end pour interroger les données.

Le schéma ci-dessous montre l’architecture de haut niveau du service de graph des membres.

Pour le séparer de Leo, LinkedIn a utilisé Java RPC pour la communication entre le monolithe et le service de graph.

Service de Recherche

À peu près à la même époque, LinkedIn devait supporter une autre fonctionnalité critique – la capacité de rechercher des personnes et des sujets. C’est une fonctionnalité essentielle pour LinkedIn où les membres peuvent utiliser la plateforme pour rechercher des personnes, des emplois, des entreprises et d’autres ressources professionnelles. De plus, cette fonctionnalité de recherche devait fournir des résultats de recherche profondément personnalisés en fonction de l’identité et des relations d’un membre.

Pour répondre à cette exigence, un nouveau service de recherche a été construit en utilisant Lucene. Lucene est une bibliothèque open-source qui fournit trois fonctionnalités :

• Construction d’un index de recherche
• Recherche dans l’index des entités correspondantes
• Détermination de l’importance de ces entités via des scores de pertinence

Une fois le service de recherche construit, le monolithe et le nouveau service de graph des membres ont commencé à alimenter ce service en données.

Bien que la création de ces services ait résolu des exigences clés, la croissance continue du trafic sur le site principal signifiait que Leo devait également évoluer. Examinons comment cela a été réalisé.

Faire Évoluer Leo

À mesure que LinkedIn gagnait en popularité, le site Web se développait et les rôles et responsabilités de Leo augmentaient également. Naturellement, l’application Web autrefois simple est devenue plus complexe. Alors – comment Leo a-t-il été évolué ?

Une méthode simple consistait à lancer plusieurs instances de Leo et à les exécuter derrière un répartiteur de charge qui routait le trafic vers ces instances. C’était une bonne solution, mais elle ne concernait que la couche application de Leo et non la base de données. Cependant, la charge de travail accrue impactait négativement la performance du système le plus critique de LinkedIn – sa base de données des profils des membres qui stockait les informations personnelles de chaque utilisateur enregistré. Inutile de dire que c’était le cœur de LinkedIn.

Une solution rapide et facile consistait à opter pour la mise à l’échelle verticale classique en ajoutant de la capacité de calcul et de la mémoire pour exécuter la base de données. C’est une bonne approche pour gagner du temps et permettre à l’équipe de réfléchir à une solution à long terme pour la mise à l’échelle de la base de données.

La base de données des profils des membres avait un problème majeur. Elle gérait à la fois le trafic de lecture et d’écriture, ce qui entraînait une charge lourde. Pour la faire évoluer, l’équipe s’est tournée vers la réplication de base de données. De nouvelles bases de données répliques ont été créées. Ces répliques étaient une copie de la base de données principale et restaient synchronisées avec la principale en utilisant Databus. Alors que les écritures étaient toujours gérées par la base de données principale, l’astuce consistait à envoyer la majorité des demandes de lecture aux bases de données répliques.

Cependant, la réplication de données entraîne toujours un certain décalage de réplication. Si une requête lit à la fois de la base de données principale et de la base de données réplique en même temps, elle peut obtenir des résultats différents car la réplication peut ne pas être terminée. Un exemple classique est un utilisateur mettant à jour ses informations de profil et ne pouvant pas voir les données mises à jour lors de l’accès au profil juste après la mise à jour. Pour faire face à des problèmes comme celui-ci, une logique spéciale a été construite pour décider quand il était sûr ou cohérent de lire à partir de la base de données réplique par rapport à la base de données principale.

Le schéma ci-dessous tente de représenter l’architecture de LinkedIn avec la réplication de base de données.

Bien que la réplication ait résolu un défi majeur de mise à l’échelle pour LinkedIn, le site Web commençait à voir de plus en plus de trafic. De plus, du point de vue du produit, LinkedIn évoluait rapidement. Cela a créé deux défis majeurs :

• Leo tombait souvent en panne en production et il devenait plus difficile de recouvrir les pannes
• Le déploiement de nouvelles fonctionnalités devenait difficile en raison de la complexité de l’application monolithique

Une haute disponibilité est une exigence critique pour LinkedIn. Une panne d’un réseau social peut créer des effets d’entraînement sérieux pour l’adoption des utilisateurs. Il est vite devenu évident qu’ils devaient tuer Leo et décomposer l’application monolithique en morceaux plus gérables.

Tuer Leo avec l’Architecture Orientée Services SOA

Bien que cela semble facile de décomposer l’application monolithique, ce n’est pas facile à réaliser en pratique. Vous voulez effectuer la migration de manière transparente sans impacter les fonctionnalités existantes. Pensez-y comme changer les pneus d’une voiture alors qu’elle roule sur l’autoroute à 100 km/h.

Les ingénieurs de LinkedIn ont commencé à extraire des fonctionnalités du monolithe dans leurs propres services séparés. Chaque service contenait des API et une logique métier spécifiques à une fonctionnalité particulière. Ensuite, des services pour gérer la couche de présentation ont été construits comme les profils publics ou les produits pour recruteurs. Pour tout nouveau produit, de nouveaux services ont été créés complètement en dehors de Leo.

Au fil du temps, l’effort vers une architecture orientée services a conduit à l’émergence de tranches verticales (Vertical Slice Architecture) où chaque tranche gérait un domaine fonctionnel spécifique.

• Les serveurs frontaux récupéraient les données de différents domaines et géraient la logique de présentation pour construire le HTML via des JSP.
• Les services intermédiaires fournissaient un accès API aux modèles de données.
• Les services de données back-end fournissaient un accès cohérent à la base de données.

En 2010, LinkedIn avait déjà construit plus de 150 services séparés et en 2015, ils avaient plus de 750 services.

Le schéma ci-dessous représente un aperçu de la conception basée sur l’architecture orientée services chez LinkedIn.

• Premièrement, ces services ont été construits de manière sans état (stateless). La mise à l’échelle peut être réalisée en lançant de nouvelles instances d’un service et en les mettant derrière un répartiteur de charge. Une telle approche est connue sous le nom de mise à l’échelle horizontale et elle était plus rentable par rapport à la mise à l’échelle de l’application monolithique.
• Deuxièmement, chaque service devait définir la charge qu’il pouvait supporter et l’équipe d’ingénierie était en mesure de mettre en place des capacités de provisionnement anticipé et de surveillance des performances pour prendre en charge toute déviation.

Gérer l’Hypercroissance avec la Mise en Cache

C’est toujours une bonne chose pour un business owner d’atteindre une croissance exponentielle. Bien sûr, cela crée un tas de problèmes. Des problèmes heureux mais toujours des problèmes qui doivent être résolus.

Malgré le passage à une architecture orientée services et la mise en place de bases de données répliquées, LinkedIn devait encore évoluer. Cela a conduit à l’adoption de la mise en cache. De nombreuses applications ont commencé à introduire des couches de cache intermédiaires comme memcached ou couchbase. Ces caches stockaient des données dérivées de plusieurs domaines. De plus, ils ont ajouté des caches aux couches de données en utilisant Voldemort pour stocker les résultats pré-calculés lorsque cela était approprié.

Cependant, si vous avez travaillé avec la mise en cache, vous savez que la mise en cache apporte avec elle un tas de nouveaux défis en termes d’invalidation, de gestion de la cohérence et de performance. Au fil du temps, l’équipe de LinkedIn a supprimé de nombreuses caches intermédiaires. Les caches ont été gardées proches de la base de données pour réduire la latence et supporter la mise à l’échelle horizontale sans la charge cognitive de maintenir plusieurs couches de cache.

Collecte de Données avec Kafka

À mesure que l’empreinte de LinkedIn grandissait, elle se trouvait également à gérer une énorme quantité de données. Naturellement, lorsque toute entreprise acquiert beaucoup de données, elle veut utiliser ces données pour développer son activité et offrir des services plus précieux aux utilisateurs. Cependant, pour tirer des conclusions significatives des données, elles doivent être collectées et réunies en un seul endroit, comme un entrepôt de données.

LinkedIn a commencé à développer de nombreux pipelines de données personnalisés pour le streaming et la mise en file d’attente des données d’un système à un autre. Certaines des applications étaient les suivantes :

• Agrégation des journaux de chaque service
• Collecte des données concernant les événements de suivi tels que les pages vues
• Mise en file d’attente des e-mails pour le système de messagerie inMail de LinkedIn
• Mise à jour du système de recherche chaque fois que quelqu’un met à jour son profil

À mesure que LinkedIn grandissait, elle avait besoin de plus de ces pipelines personnalisés et chaque pipeline individuel devait également évoluer pour faire face à la charge. Quelque chose devait être fait pour répondre à cette exigence.

Cela a conduit au développement de Kafka, une plateforme de messagerie pub-sub distribuée. Elle a été construite autour du concept d’un journal de commit et son objectif principal était de permettre la vitesse et la scalabilité. Kafka est devenu un pipeline de données universel chez LinkedIn et a permis un accès quasi en temps réel à n’importe quelle source de données. Elle a permis de renforcer les divers Jobs Hadoop et a permis à LinkedIn de construire des analyses en temps réel, d’améliorer la surveillance du site et les alertes.

Le schéma ci-dessous montre le rôle de Kafka chez LinkedIn.

Au fil du temps, Kafka est devenu une partie intégrante de l’architecture de LinkedIn. Voici quelques faits récents sur l’adoption de Kafka chez LinkedIn :

• Plus de 100 clusters Kafka avec plus de 4000 brokers
• 100K topics et 7 millions de partitions
• 7 trillions de messages traités par jour

Scalabilité de l’Organisation avec Inversion

Bien que la scalabilité soit souvent considérée comme une préoccupation logicielle, LinkedIn a très vite compris que ce n’était pas vrai. À un moment donné, vous devez également évoluer au niveau organisationnel.

Chez LinkedIn, la scalabilité organisationnelle a été réalisée grâce à une initiative interne appelée Inversion. Inversion a mis en pause le développement de fonctionnalités (Code Freeze) et a permis à toute l’organisation d’ingénierie de se concentrer sur l’amélioration des outils et du déploiement, de l’infrastructure et de la productivité des développeurs. En d’autres termes, ils ont décidé de se concentrer sur l’amélioration de l’expérience développeur.

L’objectif d’Inversion était d’augmenter la capacité d’ingénierie des équipes de développement afin que de nouveaux produits évolutifs pour l’avenir puissent être construits efficacement et de manière rentable.

Examinons quelques outils importants qui ont été créés dans le cadre de cette initiative :

Rest.li

Pendant la transformation de Leo vers une architecture orientée services, les API extraites étaient basées sur Java RPC. Java RPC avait du sens à l’époque, mais il n’était plus suffisant à mesure que les systèmes de LinkedIn évoluaient vers un écosystème polyglotte avec des services écrits en Java, Node.js, Python, Ruby, etc.

Par exemple, il devenait difficile pour les services mobiles écrits en Node.js de communiquer avec les services RPC basés sur des objets Java. De plus, les premières APIs étaient étroitement couplées avec la couche de présentation, ce qui rendait difficile les changements.

Pour résoudre ce problème, les ingénieurs de LinkedIn ont créé un nouveau modèle d’API appelé Rest.li. Qu’est-ce qui rendait Rest.li si spécial ?

Rest.li était un framework pour développer des APIs RESTful à grande échelle. Il utilisait un simple JSON sur HTTP, ce qui facilitait la communication entre les clients non basés sur Java et les APIs basées sur Java. De plus, Rest.li était une étape vers une architecture basée sur les modèles de données qui apportait un modèle d’API cohérent dans toute l’organisation.

Pour rendre les choses encore plus faciles pour les développeurs, ils ont commencé à utiliser la Découverte Dynamique (D2) avec les services Rest.li. Avec D2, il n’était pas nécessaire de configurer les URL pour chaque service avec lequel vous devez communiquer. Il fournit plusieurs fonctionnalités telles que l’équilibrage de charge basé sur le client, la découverte de service et la scalabilité.

Le schéma ci-dessous montre l’utilisation de Rest.li avec la Découverte Dynamique.

Super Blocks

Une architecture orientée services est excellente pour découpler les domaines et évoluer indépendamment les services. Cependant, il y a aussi des inconvénients.

De nombreuses applications chez LinkedIn dépendent des données de multiples sources. Par exemple, toute demande pour une page de profil utilisateur ne se contente pas de récupérer les données du profil mais inclut d’autres détails tels que les photos, les connexions, les groupes, les informations sur l’abonnement, les informations de suivi, les billets de blog et ainsi de suite. Dans une architecture orientée services, cela signifie faire des centaines d’appels pour récupérer toutes les données nécessaires. Cela est généralement connu sous le nom de “graph d’appel” et vous pouvez voir que ce graph d’appel peut devenir difficile à gérer à mesure que de plus en plus de services sont créés.

Pour atténuer ce problème, LinkedIn a introduit le concept de super bloc.

Un super bloc est un regroupement de services backend liés avec une seule API d’accès. Cela permet aux équipes de créer des interfaces optimisées pour un ensemble de services et de maintenir le graph d’appel sous contrôle.

Vous pouvez considérer le super bloc comme la mise en œuvre du design pattern façade.

Multi-Data Center

Quelques années après son lancement, LinkedIn est devenu une entreprise mondiale avec des utilisateurs rejoignant du monde entier. Ils devaient évoluer au-delà de la gestion du trafic à partir d’un seul centre de données. Plusieurs centres de données sont incroyablement importants pour maintenir une haute disponibilité et éviter tout point de défaillance unique. De plus, cela n’était pas nécessaire seulement pour un seul service, mais pour l’ensemble du site Web.

La première étape a été de commencer à servir des profils publics à partir de deux centres de données (Los Angeles et Chicago). Une fois que cela a prouvé que cela fonctionnait, ils ont amélioré tous les autres services pour prendre en charge les fonctionnalités suivantes :

• Réplication de données
• Rappels depuis différentes origines
• Événements de réplication de données unidirectionnels
• Attribuer des utilisateurs à des centres de données géographiquement proches

À mesure que LinkedIn a continué de croître, ils ont migré l’infrastructure de périphérie vers Azure Front Door (AFD). Pour ceux qui ne le savent pas, AFD est le réseau global de livraison d’applications et de contenus de Microsoft et sa migration a offert de grands avantages en termes de latence et de résilience.

Cette initiative les a fait passer à plus de 165 points de présence (PoPs) et a contribué à améliorer les temps de chargement des pages médianes jusqu’à 25 pour cent. L’infrastructure de périphérie est en fait la façon dont nos appareils se connectent à LinkedIn aujourd’hui. Les données de notre appareil traversent Internet jusqu’au PoP le plus proche qui abrite des proxys HTTP qui transmettent ces requêtes à un serveur d’application dans l’un des centres de données de LinkedIn.

Développements Avancés autour de la Scalabilité

Exploiter une application aussi complexe et évolutive que LinkedIn exige de l’équipe d’ingénierie de continuer à investir dans la construction de solutions évolutives. Dans cette section, nous examinerons certains des développements récents que LinkedIn a subis.

Analyse en Temps Réel avec Pinot

Il y a quelques années, l’équipe d’ingénierie de LinkedIn a rencontré une impasse en matière d’analytique. L’ampleur des données chez LinkedIn croissait bien au-delà de ce qu’ils pouvaient analyser. Les fonctionnalités d’analytique étaient construites en utilisant des systèmes de stockage génériques comme Oracle et Voldemort. Cependant, ces systèmes n’étaient pas spécialisés pour les besoins OLAP et le volume de données chez LinkedIn augmentait à la fois en largeur et en profondeur.

À ce stade, vous vous demandez peut-être la nécessité d’une analyse en temps réel chez LinkedIn.

Voici trois cas d’utilisation très importants :

1. La fonctionnalité “Qui a consulté votre profil” est le produit analytique phare de LinkedIn qui permet aux membres de voir qui a consulté leur profil en temps réel. Pour fournir ces données, le produit doit exécuter des requêtes complexes sur de grands volumes de données de consultation de profils pour identifier des insights intéressants.
2. Les Analyses de Pages d’Entreprise sont un autre produit premium offert par LinkedIn. Les données fournies par ce produit permettent aux administrateurs d’entreprises de comprendre la démographie des personnes suivant leur page.
3. LinkedIn utilise également énormément l’analytique en interne pour répondre à des exigences critiques telles que les tests A/B

Pour supporter ces produits analytiques clés et bien d’autres à grande échelle, l’équipe d’ingénierie a créé Pinot. Pinot est un moteur d’analyse en temps réel à l’échelle Web conçu et construit chez LinkedIn. Il leur permet de trier, découper et parcourir des quantités massives de données provenant d’une grande variété de produits en temps réel.

Mais comment Pinot résout-il le problème ?

Le schéma ci-dessous montre une comparaison entre la configuration pré-Pinot et post-Pinot.

Comme vous pouvez le voir, Pinot prend en charge l’indexation des données en temps réel depuis Kafka et Hadoop, simplifiant ainsi tout le processus. Certains autres avantages de Pinot sont les suivants :

• Pinot prend en charge les requêtes OLAP à faible latence et à haut QPS. Par exemple, il est capable de servir des milliers de requêtes “Qui a consulté mon profil” tout en respectant des SLA de l’ordre de dizaines de millisecondes.
• Pinot simplifie également les aspects opérationnels tels que le rééquilibrage des clusters, l’ajout ou la suppression de nœuds et la re-bootstrap.
• Enfin, Pinot a été préparé pour l’avenir pour gérer de nouvelles dimensions de données sans se soucier de l’échelle.

Autorisation at Scale de LinkedIn

Les utilisateurs confient à LinkedIn leurs données personnelles et il était extrêmement important pour eux de maintenir cette confiance. Après la transformation en SOA, LinkedIn exécute une architecture de microservices où chaque microservice récupère des données d’autres sources et les sert aux clients. Leur philosophie est qu’un microservice ne peut accéder aux données que s’il a une utilisation commerciale valide. Cela empêche la diffusion inutile de données et minimise les dégâts si un service interne est compromis.

Une solution courante dans l’industrie pour gérer l’autorisation est de définir des Listes de Contrôle d’Accès (ACL). Une ACL contient une liste d’entités autorisées ou non à accéder à une ressource particulière.

Par exemple, disons qu’il existe une ressource Rest.li pour gérer les “salutations”. L’ACL pour cette ressource peut ressembler à ceci.

• Vérifier l’autorisation rapidement
• Diffuser les changements d’ACL rapidement
• Suivre et gérer un grand nombre d’ACL

Le schéma ci-dessous montre une vue d’ensemble de la manière dont LinkedIn gère l’autorisation entre services.

Quelques points clés à considérer ici sont les suivants :

• Pour rendre les vérifications d’autorisation rapides, ils ont construit un module client d’autorisation qui s’exécute sur chaque service chez LinkedIn. Ce module décide si une action doit être autorisée ou refusée. Les nouveaux services récupèrent ce client par défaut dans le cadre de l’architecture de service de base.
• La latence est un facteur critique lors d’une vérification d’autorisation et faire un appel réseau à chaque fois n’est pas acceptable. Par conséquent, toutes les données d’ACL pertinentes sont conservées en mémoire par le service.
• Pour maintenir les données d’ACL à jour, chaque client contacte le serveur à intervalles fixes et met à jour sa copie en mémoire. Cela se fait à un rythme suffisamment rapide pour que tout changement d’ACL soit réalisé rapidement.
• Toutes les ACL sont stockées dans la base de données Espresso de LinkedIn. C’est une base de données NoSQL distribuée tolérante aux pannes qui fournit une interface simple.
• Pour gérer la latence et la scalabilité, ils maintiennent également un cache Couchbase devant Espresso. Cela signifie que même du côté serveur, les données sont servies depuis la mémoire. Pour gérer les données obsolètes dans Couchbase, ils utilisent un système de Capture de Données de Changement (CDC) basé sur Brooklin de LinkedIn pour notifier le service lorsqu’une ACL a changé afin que le cache puisse être vidé.
• Chaque vérification d’autorisation est enregistrée en arrière-plan. Cela est nécessaire pour le débogage et l’analyse du trafic. LinkedIn utilise Kafka pour la journalisation asynchrone à grande échelle. Les ingénieurs peuvent vérifier les données dans un système de surveillance séparé connu sous le nom d’inGraphs.

Conclusion

Dans cet article, nous avons examiné brièvement le parcours d’évolution de LinkedIn. De ses débuts modestes en tant que système monolithique autonome servant quelques milliers d’utilisateurs, LinkedIn a parcouru un long chemin. C’est l’un des plus grands réseaux sociaux au monde pour les professionnels et les entreprises, permettant des connexions transparentes entre individus à travers le monde.

Pour répondre aux demandes croissantes, LinkedIn a dû entreprendre des transformations audacieuses à plusieurs étapes.

En faisant celà, ils ont fourni de nombreuses leçons pour la communauté des développeurs qui peuvent vous aider dans vos propres projets.

Références :

• Scaling LinkedIn’s Edge with Azure Front Door
• How LinkedIn customizes Apache Kafka for 7 trillion messages per day
• Using Set Cover Algorithm to optimize query latency for a large-scale distributed graph
• Authorization at LinkedIn’s Scale
• Rest.li: RESTful Service Architecture at Scale
• Real-time analytics at a massive scale with Pinot

Notre sponsor : https://defi-central.net