Pour savoir où on va, il faut savoir d'où l'on vient

Vous avez
une question ?
Un projet ?

Contactez nous !
 

Contactez-nous

Vous avez une question ? un projet ? 
Vous souhaitez plus d'informations sur un produit ? sur notre offre ? 
Contactez-nous, on vous répond sous 4H.

eZHumanCAPTCHACode reload
retour

Woozweb

Woozweb

Nous avons évoqué Woozweb en tant qu’outil de monitoring et d’observatoire du web, mais il peut être aussi un cas d’école pour étudier l’extensibilité d’une plateforme.

Car Woozweb est une plateforme que l’on a voulue extensible à l’infini.

La problématique Woozweb

En quelques mots, les grandes fonctionnalités de Woozweb :

  • Woozweb surveille des « ressources » du web. Une « ressource » est caractérisée par son URI.
  • Des serveurs spécifiques, appelés « Sondes », adressent des requêtes afin de tester les ressources.
  • On distingue deux types de sondes : des sondes haute-fréquence (HF), qui testent chaque ressource toutes les 15 minutes, et des sondes basses-fréquence (LF), qui testent chaque ressource toutes les semaines.
  • Les sondes HF ne font que charger la page Html correspondant à l’URI, et vérifier la conformité de la page, le code retour Http, et le temps de réponse observé.
  • Les sondes LF, elles, effectuent un chargement complet de la page, et de toutes ses ressources, au moyen d’un vrai navigateur, exécutant aussi bien le javascript que le Flash, ou tous autres objets embarqués. Elles relèvent donc une information différente, qui va au delà de la seule disponibilité ou qualité de service.
  • Toutes les informations relevées par les sondes sont conservées et mises à disposition au travers d’interfaces web.

Partitionnement et consolidation

Woozweb a recours au principe déjà évoqué, combinant partitionnement et consolidation :

  • On découpe la plateforme Woozweb en sous-systèmes que l’on appelle nœuds, ou « nodes », parfois abrévié en « NOD ». Un NOD est un sous-système qui est en charge de N ressources. Le NOD est constitué de plusieurs serveurs, nous y reviendrons plus loin. Le NOD assure à la fois le monitoring LF et HF des ressources dont il a la charge, le stockage et la restitution de ces données.
  • Nous avons besoin de requêtes transverses, pour deux raisons. D’une part Woozweb autorise des recherches multi-critères sur l’ensemble des ressources. Indépendamment donc, de quel NOD en a la charge. D’autre part Woozweb met à disposition des statistiques transverses, portant sur la totalité des ressources. Par exemple quelle est la part des sites qui utilisent du PHP. Comme on l’a vu plus haut, les fonctionnalités de se type sont mieux mises en œuvre sur un datawarehouse consolidant les données.

Dans l’architecture Woozweb, le datawarehouse est appelé « WDR », Woozweb Data Repository.

Rappelons que le datawarehouse n’est pas la somme de toutes les données de tous les NODs : il ne consolide qu’un petit échantillon de données, celles utiles aux fonctionnalités transverses.

On a donc le schéma global classique :

image184

Architecture de chaque « NOD »

Chaque NOD assure à la fois les fonctionnalités :

  • De monitoring, par les sondes LF et HF adressant des requêtes aux ressources sous surveillance.
  • De stockage de l’information de monitoring recueillie, qui peut être volumineuse.
  • D’interface de consultation, elle peut accueillir un visiteur et gérer les interfaces web de sa session.

Chaque sous-système NOD a l’architecture suivante :

image186

 

Où M1 est un serveur dit « Manager », noté « MGR », qui porte la base de données du NOD. M2 est le secours de M1, en réplication.

P1 et P2 sont des sondes, que ce soit LF ou HF. Un même MGR peut être configuré pour gérer plusieurs sondes, selon la capacité unitaire d’une sonde.

W1 et W2 sont des frontaux web associés au NOD, utilisés en répartition de charge, partageant la base de MGR.

Architecture globale

On peut donc représenter l’architecture globale, combinant un certain nombre de NODs, et un WDR, comme suit :

image188

On note que le sous-système WDR peut lui-même être constitué de N serveurs en cluster. WDR n’utilise pas de base de données, il utilise seulement un moteur de recherche, qui est Lucene/SolR. SolR peut fonctionner en cluster, et gérer de très gros volumes et de très fortes capacité d’accueil.

Répartition de charge

Pour Woozweb, nous avons adopté les principes suivants :

  • Il n’y a pas de contexte de session, et donc pas d’affinité de serveur ; n’importe quel internaute peut être traité par n’importe quel frontal web, et il peut changer de frontal au cours d’une même session.
  • Cela nous permet de retenir un principe de load-balancing par DNS round-robin, qui est économique en infrastructure, et compatible avec de l’hébergement peu coûteux et multi-datacenters.
  • Malgré tout, certains internautes membres sont identifiés. Leur session est alors gérée dans un cookie de domaine, qui est adressé à n’importe quel frontal avec chacune des requêtes. Le cookie porte un cryptogramme qui permet de valider l’authentification et la durée de vie de la session.
image190

Agrégation de contenus

Il n’y a pas d’affectation des users aux NODs, mais comme on l’a vu chaque ressource est affectée à un NOD. Ainsi les ressources préférées ou privées d’un utilisateur peuvent être réparties sur différents NODs. Néanmoins, il faut être en mesure de lui présenter un tableau de bord consolidé, qui réunisse des informations relatives à différentes ressources.

Pour élaborer ces pages « tableau de bord », il faut donc réunir des fragments d’informations issues de différents serveurs.

Nous avons vu plus haut les différentes options qui se présentent pour réaliser cela. L’une des plus simples est l’agrégation côté client, c’est à dire réalisée sur le poste client, au sein du navigateur.

C’est la voie qui a été retenue pour Woozweb, que l’on peut représenter comme ceci :

image192

A gauche, on distingue une page tableau de bord vue par un utilisateur de Woozweb. On voit qu’elle réunit des fragmentes d’information correspondant à différentes ressources. Ces ressources sont gérées par différents NODs.

C’est au niveau du navigateur, sur le poste de l’utilisateur, que les différents frontaux sont invoqués pour obtenir les fragments correspondant à chacune des ressources, afin de constituer la page finale.

Synthèse

Woozweb est un cas d’école intéressant, car il réunit une diversité de techniques que nous avons passées en revue :

  • Partitionnement et consolidation
  • Découpage fonctionnel
  • Absence de contextes
  • Répartition par DNS-RR
  • Agrégation de fragments côté client.

Au final, nous avons une plateforme réellement extensible, qui pourra monitorer plusieurs millions de ressources.