Les coulisses techniques de Twitter Une nouvelle architecture à base de micro-services
Comme tous les grands services Internet, alors que le succès était grandissant, l'architecture mise en place aux débuts de Twitter est peu à peu devenue inadaptée. Devant la montée exponentielle du nombre de tweets échangés, l'architecture Ruby on Rails couplée à une base de données MySQL a montré ses limites. Baptisée en interne "Monorail", cette architecture monolithique assurait tant la logique métier de Twitter que le routage des tweets et la couche de présentation.
De fait, Twitter devait faire face à des problèmes de performance dus au faible parallélisme de son application et les entrées-sorties présentaient des goulets d'étranglement insolubles. Des problèmes qui fragilisaient le service et tout le monde se souvient encore de l'image de sa baleine volante. En outre, l'équipe de développeurs de l'équipe "Tweeter Service" passant de 200 à 2 000 personnes, le travail en simultané d'autant de développeurs sur le code a poussé le site à engager un grand projet de factorisation de son application "Monorail".
Le projet a démarré en 2010/2011 par le volet stockage avec l'utilisation de la base NoSQL FlockDB pour stocker les graphes et désengorger MySQL, puis le caching avec Memcache pour placer en cache les utilisateurs et tweets, et le cache Redis pour les Timelines (c'est-à-dire le fil de tweets que chacun consulte en permanence).
4 millions de tweets lus chaque seconde en moyenne
L'architecture de Twitter compte aujourd'hui quatre couches avec le routage, la couche de présentation, une couche logique métier, et enfin le stockage. Le routage des tweets est désormais assuré par un service baptisé TFE pour "Tweeter Front End". Monorail existe encore, mais son rôle a été réduit à la portion congrue et les équipes de développement continuent à retirer des fonctions de l'application pour les transformer en services.
Une cascade d'appels à différents services
Au sein de la logique métier, des services assurent la constitution des timelines, la gestion du social graph, les messages directs, etc. Lorsqu'un utilisateur écrit un simple tweet, c'est une cascade d'appels à ses micro-services qui est déclenchée. Le tweet passe par l'API http de Twitter qui sollicite le "Tweet Service". Celui-ci réalise un appel à Snowflake, service qui délivre un ID au tweet, puis à l'URL Service, au User Service, à un service de Géotagging, puis au service Media, au service MySQL, au service anti-spam et enfin au langage. Dès que la structure du tweet est ainsi constituée, la couche de stockage entre en jeu, avec des appels au cache, au service de stockage, à TFlock, l'index basé sur Gizzard, l'infrastructure de stockage. Suivent ensuite des appels au service Timeline, à Hosebird (l'API de streaming de Twitter), au moteur de recherche, de mail et de réplication.
Une brique assure la cohérence de cette cascade d'appels, la solution open source Finegale. Elle assure la découverte des services dans l'architecture, gère les files d'attente d'appels vers ces services, le load balancing, etc. C'est cette solution qui permet à Twitter d'atteindre un haut niveau de parallélisme dans les traitements. C'est comme cela que le service "Tweet Service" peut écrire plus de 400 millions de tweets par jour mais aussi lire 350 milliards de tweets par jours avec une moyenne de 4 millions de tweets lus chaque seconde. La latence moyenne en lecture est de 7 ms.