L’architecture du site LinkedIn : Java et hautes volumétries

Lors de la dernière conférence JavaOne (organisé par Sun Microsystems) un des membres de Linkedin à donné plusieurs informations à propos de l’architecture du site. Plusieurs points à retenir de cette intervention. Le Java, des statistiques sur les volumétries et la mise en mémoire du graphe.

Le premier point concerne donc les volumétries. Linkedin est un réseau social dont le but principal est la mise en relation professionnelle (en France il existe Viadeo). Actuellement le réseau Linkedin comporte plus de 25 millions de membres, cette communauté génère 40M de PV/jour, 2M de recherche par jour et plus de 50M d’email par mois.

Pour gérer ces volumes les concepteurs utilisent quasiment exclusivement Java (98% du code). Les services fonctionnent sur l’OS Solaris et sur des serveurs Sun x86 et Sparc. Les serveurs applicatifs tournent eux sous Tomcat et Jetty, enfin les bases sont gérées avec Oracle et MySql, le search fonctionne lui directement avec l’API Lucene.

Reste le coeur du système, le graphe des utilisateurs…

Pour gérer ce graphe Linkedin utilise une quarantaine de serveurs. Ils sont tous identiques et possèdent tous le graphe en mémoire, cela représente plus de 12Go de RAM par serveur. Le rechargement et la création du graphe en mémoire prend plus de 8H. Enfin pour la consolidation c’est un gros serveur Sparc M9000 doté de 2To de RAM, ce monstre est dimensionné pour gérer jusqu’à un milliard d’utilisateur.

Pour épauler ce système, il existe un système de cache en C++ permettant de garder le micro-réseau de chaque utilisateur. Ce réseau, en fait le point de vue de l’utilisateur sur graphe est calculé à chaque nouvelle connexion et il est gardé en mémoire pendant toute la session (je pense que ça donnera des idées à certains lecteurs :-) . Cela représente 2Mo et il reste valide tant que l’utilisateur n’ajoute ni ne supprime de contact.

L’utilisation de C++ pour le cache a été motivé par le blocage Java lors de l’exécution du Garbage Collector (même si les dernières JVM sont plus performantes aucunne raison de changer une architecture qui fonctionne bien, à l’époque les machines Java étaient moins efficaces  qu’aujourd’hui).

A retenir de ces informations : Que Java peut aussi être efficace sur des gros sites web et que pour des données complexes le développement d’un coeur solide est un véritable avantage concurrentiel. Le marketing et la communication doivent jouer leurs rôles, mais pour vraiment dérouler son plan sur plusieurs années il est indispensable de posséder et de maîtriser complètement la technologie au coeur de son système. Dans le cas contraire il sera difficile de maintenir le leadership.

Si vous souhaitez plus d’informations sur cette architecture, je vous invite à consulter ces liens :

Sources :

http://www.slideshare.net/linkedin/linkedins-communication-architecture

http://www.slideshare.net/linkedin/linked-in-javaone-2008-tech-session-comm

http://hurvitz.org/blog/2008/06/linkedin-architecture

Sur le même thème :

One Response to “L’architecture du site LinkedIn : Java et hautes volumétries”

  1. [...] ne cesse de progresser mais malheureusement ses périodes d’indisponibilité aussi. Pourtant LinkedIn dispose d’une bonne architecture technique et en général son ‘uptime‘ est dans la moyenne, mais depuis début septembre les [...]

Leave a Reply