Nous maintenons une application WEB grand public développée en JEE avec de fortes exigences en terme de volume de statistiques. Récemment, une nouvelle demande de modification d'architecture de la plateforme par notre client, combinée à de nouveaux objectifs de fréquentation nous a poussé à remettre en cause la gestion de ces statistiques.

L'application en elle-même devait rester iso-fonctionnelle, il s'agissait en quelque sorte d'un refactoring d'architecture.

Les contraintes techniques étaient les suivantes :

  • volumétrie importante : environ 10 millions d'événements par jour, puis 12 fois plus à moyen terme
  • aucun impact sur le service en terme de performance (traitements asynchrones)
  • aucune perte de données, même en mode dégradé (perte de la base de données par exemple)
  • exploitation aisée et transparence de la solution

Les aspects suivants nous ont fait pencher pour une solution de type bus de données :

  • les statistiques de notre service correspondent à des évènements indépendants
  • l'asynchronisme des traitements
  • le découplage nécessaire avec les applicatifs de façade (les webapps) pour les performances, ainsi qu'avec la base de données pour la haute disponibilité
  • les difficultés rencontrées lors de la refonte précédente des statistiques avec des solutions "maison", en terme de maintenance et d'administration

Nous avons répertorié 3 types de bus :

Ce bus de données est maintenant en production et répond aux attentes (avec des petits ajustements restant à faire). Une série d'articles vous expliquera les étapes parcourues depuis le choix de la solution jusqu'à sa mise en production.