Answers, de Twitter, est un service analytique pour applications mobiles, qui s’est vu devoir prendre en charge 5 milliards de sessions par jour. Ed Solovey, ingénieur chez Twitter, a décrit comment leur système permet de fournir des données "fiables, temps-réel et directement exploitables", s’appuyant sur des centaines de millions de terminaux mobiles envoyant des millions d’événements chaque seconde. Comme Solovey l’explique, les fonctions principales d’Answers sont les suivantes :
- Recevoir des événements
- Les archiver
- Réaliser des calculs en mode temps-réel et déconnecté
- Fusionner les résultats de ces calculs sous forme d’information cohérente
Le service en charge de la réception des événements depuis les terminaux est écrit en Go et utilise Amazon Elastic Load Balancer. Il place en file d’attente chaque message dans une queue Kafka durable. Compte tenu du gros volume d’événements à stocker, Kafka n’est utilisé que comme cache temporaire contenant seulement quelques heures de données utiles, tandis que Storm est utilisé pour transférer les données vers Amazon S3.
Une fois que les données sont sur S3, c’est Amazon Elastic MapReduce qui entre en jeu pour les traiter en batch. Le résultat est stocké dans un cluster Cassandra, afin que celui-ci soit disponible pour des requêtes via API.
Ce n’est pas la fin de l’histoire. En effet, Answer a aussi besoin de traitements temps-réel. Pour cela, le contenu de Kafka est redirigé vers Storm et traité par des algorithmes probabilistes comme des Bloom Filters et HyperLogLog afin de fournir des résultats rapides, au prix d’une "perte négligeable d’exactitude". Ces résultats sont aussi stockés dans Cassandra.
Une fois le processus fini, Cassandra contient les résultats des traitements en masse ainsi que les résultats temps-réel. L’API de requête a la responsabilité de combiner les deux flux pour fournir une vue cohérente pour les paramètres de requête. Lorsque ceux-ci sont disponibles, les résultats des traitements en masse sont préférés car plus précis. Autrement, ce sont les résultats temps-réel qui sont donnés.
Solovey explique que l’architecture décrite ici est aussi efficace lorsqu’il s’agit de la gestion des défaillances, grâce à l’utilisation des queues durables qui connectent les composants. Ceci garantit que toute panne sur un composant n’affectera pas les autres. De plus, ceci permet la reprise sur erreur et évite la perte de données lorsque le système revient à son état normal dans une période de temps donnée.