Pour beaucoup d'entre nous, Twitter est devenu un moyen de communication essentiel. Les particuliers et les sociétés utilisent chaque jour Twitter de manières encore plus larges et plus profondes, et nous avons tous intérêt à ce que Twitter soit scalable. Récemment ce mois-ci, Twitter a géré sans accroc un nouveau pic de charge de 143 199 tweets par seconde - une augmentation conséquente de son état actuel stable de 5 700 tweets par seconde. Raffi Krikorian, VP de l'Ingénierie Plate-Forme à Twitter a annoncé le nouveau record et a pris le temps de commenter les modifications techniques qu'ils ont réalisées pour s'adapter à ce nouveau niveau de traffic.
Il y a trois ans, des pics de 2000 tweets par seconde générés par l'activité autour de la Coupe du Monde 2010 avaient causé des problèmes de stabilité majeurs pour Twitter et cela avait engendré une prise de conscience qu'ils devaient ré-architecturer leurs systèmes. Une revue technique postérieure a mis en lumière que Twitter possédait la plus grande installation Ruby on Rails du monde, que tout était dans une seule base de code, et que l'application et l'équipe d'ingénieurs étaient toutes deux monolithiques. Leur système de stockage MySQL avait atteint ses limites, le matériel n'était pas utilisé de manière optimale et les "optimisations" répétées étaient en train de scléroser la base de code. Krikorian rapporte que Twitter est sorti de leur analyse avec quelques objectifs ambitieux : réduire le nombre de machines par 10, migrer vers une architecture orientée services faiblement couplée avec des frontières clairement délimitées et plus de cohésion, et être en mesure de livrer plus rapidement des nouvelles fonctionnalités avec des équipes plus petites mais ayant plus de pouvoir.
Twitter s'est détourné de Ruby pour migrer sur la JVM. Ils avaient atteint les limites du modèle de concurrence au niveau du processus de Ruby et avaient besoin d'une plate-forme de développement permettant de fournir un débit plus élevé et de faire un meilleur usage des ressources matérielles. La ré-écriture de la base de code sur la JVM a donné une amélioration de plus de 10 fois des performances et ils envoient maintenant 10-20k requêtes/seconde/serveur.
Le changement d'architecte le plus important de Twitter a été de passer à une architecture orientée services focalisée sur les "noms métier" de tweet, de la timeline et des services utilisateur. Leur approche du développement repose sur la "conception par contrat" où l'on s'entend sur les définitions des interfaces en premier lieu, puis les équipes travaillent indépendamment sur l'implémentation. Les services sont autonomes et auto-suffisants, et celà se répercute sur la structure de la nouvelle équipe d'ingénierie. Une plate-forme RPC asynchrone, Finagle a été développée pour gérer la concurrence, le failover et l'équilibrage de charge d'une manière standard pour toutes les équipes d'ingénierie.
[NDT : la redite de ce paragraphe provient de la version originale] La nouvelle architecture se répercute dans l'organisation des équipes d'ingénierie de Twitter. Les services et leurs équipes sont autonomes et auto-suffisants. Chaque équipe est propriétaire de ses interfaces et des problématiques de son domaine. Il n'est pas nécessaire d'être un expert de l'intégralité du système, et tout le monde n'a pas à se préoccuper de la scalabilité des Tweets. Les capacités critiques sont abstraites derrière des APIs qui les rendent accessibles à tous ceux qui en ont besoin.
Mais Krikorian dit que même avec une architecture moins monolithique, la persistence reste un important goulot d'étranglement. L'unique base de données MySQL master de Twitter a été remplacée par un framework distribué de bases de données tolérantes aux pannes utilisant Gizzard.
En renfort du thème classique de scalabilité des gros systèmes, l'observabilité et les statistiques sont des outils clés pour gérer le système et fournir des données concrètes aux efforts d'optimisation. La plate-forme de développement de Twitter intègre des outils qui facilitent la tâche aux développeurs pour fournir le traçage de requête et le reporting statistique.
Le dernier élément de l'histoire de la scalabilité chez Twitter est l'effort investi dans la configuration à l'exécution et à l'environnement de test. Tester Twitter à "l'échelle de Twitter" peut uniquement être réalisé en production. Le déploiement de nouvelles fonctionnalités peut également nécessiter un niveau de coordination très important entre les équipes. Ainsi Twitter a développé un mécanisme appelé Decider pour mettre à disposition les nouvelles fonctionnalité seulement une fois qu'elle ont été déployées. Les fonctionnalités peuvent être déployées dans une configuration "off", puis être rendues disponibles soit de manière binaire (toutes à la fois) ou graduellement pour une portion d'opérations.
Le résultat global pour Twitter est d'être aujourd'hui plus scalable, plus résistant et plus agile qu'avant. Les volumes de trafic battent de nouveaux records et de nouvelles fonctionnalités peuvent être proposées sans interruption significative. Krikorian finit son article de blog en insistant que nous gardions un oeil sur @twittereng pour plus de détails sur la ré-architecture de Twitter.