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.

retour

Une plateforme de blogs de très forte capacité

Une plateforme de blogs de très forte capacité

Le problème posé

Considérons un autre cas d’école : nous avons à mettre en place une plateforme de blog de très forte capacité, capable d’accueillir plus d’un million de blogueurs. En fait, nous disons « plus d’un million », mais la véritable exigence est plutôt « un nombre illimité de blogueurs », que ce soit un million, 20 millions ou 200 millions.

Les internautes peuvent s’inscrire pour devenir blogueurs, et une fois passées les quelques formalités d’inscription, ils peuvent commencer leur blog. Chaque blogueur poste des articles sur son blog, qui sont mis en ligne a priori avec ou sans modération. Les autres internautes, lisant un article, peuvent eux-mêmes y poster des commentaires, qui seront ou non modérés par l’auteur du blog.

On ne s’attardera pas ici sur les fonctionnalités cosmétiques ou sans impact sur l’architecture. En revanche, il faut bien analyser les besoins en matière d’administration. Un administrateur de la plateforme doit avoir une vision globale des blogs. Autant du point de vue des fonctions liées à la gestion des blogs que du point de vue des statistiques (nombre de blogueurs inscrits, nombre d’inscriptions du jour, de la semaine, du mois, nombre d’articles nouveaux écrits, de commentaires postés, etc.). L’administrateur doit pouvoir retrouver n’importe quel blogueur, sur différents critères de recherche, et modifier ou bien supprimer son compte. L’administrateur doit avoir des interfaces de modération centralisées, qui lui présentent par exemple les derniers articles, ou bien les derniers articles comportant tels et tels mots à surveiller. Et cette tâche de modération doit également pouvoir être répartie entre différents intervenants.

image168

Quelles options d’architecture ?

Si le problème était d’entrée de jeu posé avec des limites de volumétrie définitives, on pourrait sauter sur l’architecture classique « deux tiers », incluant quelques frontaux et une base de données. Il est certain que ce choix impliquerait une limite sur la capacité globale de la plateforme. Si 100 000 blogueurs et lecteurs sont connectés et postent leurs articles, à raison disons de une contribution toutes les 5 minutes, alors nous avons 300 insertions par seconde dans la base de données, sans compter bien sûr toutes les mises à jours périphériques. On aura beaucoup de mal à soutenir ce rythme, même sur une configuration matérielle haut de gamme. Et quand bien même on y parviendrait, on ne tiendra pas un million de blogueurs en ligne.

On peut dire : peu importe où se situera exactement la limite, l’essentiel est qu’il y aura une limite, et c’est ce que ne voulons pas. Car lorsque la limite sera atteinte, ce sera une limite « dure », très difficile à franchir, nécessitant une révision d’ensemble de l’architecture.

Un problème partitionnable

Un blogueur n’agit que dans le périmètre de son blog. En première analyse, le problème posé est naturellement partitionnable. Si l’on sait mettre en place une plateforme relativement simple pour accueillir disons 10 000 blogueurs, alors qu’est-ce qui nous empêchera d’aligner autant de ces plateformes qu’il faudra, 10 pour 100 000 blogueurs, 100 pour un million ?

Faisons la liste de ce qui nous poserait problème dans cette simple juxtaposition de petites plateformes.

  • La répartition des internautes blogueurs : faudrait-il dire à certains d’accéder à www-01.mesblogs.fr, d’autres à www-02, d’autres finalement à www-10 ? Ce n’est pas très élégant assurément.
  • La gestion administrative des blogueurs : lorsqu’un administrateur recherche un blogueur, devra-t-il adresser une requête à chacune des N plateformes ?
  • De même pour la gestion de la modération : les modérateurs devront-ils se connecter à chacune des N plateformes ?
  • A ces problèmes d’organisation on pourrait ajouter des problèmes de coût. On sait que plus la tolérance aux pannes est gérée à grande échelle, moins elle est coûteuse. Faudra-t-il ici que chacune des petites plateformes élémentaires assure sa haute disponibilité de manière totalement autonome ?

Malgré ces questions à traiter, la remarque initiale reste prépondérante : il y a dans cette problématique, une capacité assez naturelle à diviser le problème, diviser pour régner. Ce sera donc bien le principe de base de notre architecture. Les problèmes cités ne sont pas suffisants pour remettre en question ce principe, nous leur trouverons des solutions.

Répartition arbitraire

Nous avons expliqué (cf. « Quelle logique de répartition ? », page 98), que dans un partitionnement, la répartition ne doit pas être basée sur des règles fonctionnelles. Elle doit être arbitraire, ou plutôt, fondée uniquement sur des critères techniques : un blogueur nouveau est affecté à tel serveur parce que ce serveur a de la capacité disponible.

Cela implique, comme on l’a vu, de tenir à jour une table d’affectation, qui sera utilisée pour la répartition des internautes.

Cette logique de remplissage des serveurs permet d’étendre la plateforme au fur et à mesure du besoin. Lorsque les serveurs en place manquant de capacité, on en ajoute quelques-uns. Des blogs peuvent aussi être supprimés, de sorte que de la capacité peut apparaître sur des serveurs anciens, qui sera utilisée par de nouvelles affectations.

Fonctions centrales via webservices

Pour les fonctions centrales, en particulier d’administration, une première voie consiste à s’appuyer une application d’administration globale échangeant avec chacune des plateformes de blog indépendantes en invoquant des webservices. Ce peut être aussi bien pour collecter de l’information de manière centralisée que pour adresser des commandes.

Ce qui est représenté ci-après :

image170

Si notre application de blogs est moderne et bien conçue, elle aura déjà implémenté des interfaces REST pour chacune de ses fonctionnalités. Sinon, dans le cas d’un progiciel en général, mettre en place ces webservices pourrait être difficile, mais pour un produit open source, on y parviendra généralement.

Malgré tout, dans ce mode, l’administration ne sait pas quel blog est sur quel serveur, de sorte qu’elle doit fréquemment adresser sa requête en parallèle à la totalité des serveurs, alors qu’un seul est concerné.

Lorsque le nombre de ces serveurs augmente, ces invocations pèsent de plus en plus lourd, et deviennent un réel frein à l’extensibilité.

Fonctions centrales via datawarehouse

On a dit déjà que le datawarehouse est le complément naturel du partitionnement.

Ici, il s’agit de constituer une base centrale consolidant une partie des données portées par chacun des serveurs, les données utiles à l’administration.

Cette base consolidée est utilisée :

  • Pour faire des recherches transverses, multi-critères, sans solliciter tous les serveurs.
  • Pour construire la table d’affectation, qui permettra ensuite d’aiguiller les requêtes.
  • Pour disposer de statistiques globales.

Ce que l’on représente comme suit :

image172

Les outils de cette consolidation peuvent varier. On a dit déjà que la réplication de base de données devait être utilisée seulement entre systèmes homologues, ce qui n’est pas le cas ici. On préfèrera donc appuyer cette collecte sur un middleware, que ce soit en mode push sur une message queue, ou bien en mode pull, par interrogation d’un webservice spécifique.

Webservices + datawarehouse

En fait, nous avons besoin de combiner les deux approches :

  • La base consolidée, afin de ne pas invoquer tous les serveurs pour la moindre interrogation, et pour tenir à jour la table d’allocation ;
  • Les webservices afin d’agir sur les serveurs.

Ce que l’on représentera comme ceci :

image174

 

On a ici un dispositif extrêmement extensible, qui s’accommodera d’une centaine de serveurs si besoin.

Répartition de charge

Dans cette architecture partitionnée, chaque entité, chaque sous-plateforme est à la fois une entité de stockage et une entité de traitement. En tant qu’entité de stockage, elle a la charge d’un certain nombre de blogueurs et de toutes les informations associées : leur personnalisation, leurs articles, les commentaires, etc. En tant qu’entité de traitement, elle a la charge de gérer toutes les interactions avec ces blogueurs, de présenter les articles en lecture aux internautes, et d’accepter leurs contributions. Ce double rôle, stockage et traitement, implique une bonne analyse du dimensionnement selon ces deux besoins.

Dans cette architecture, la répartition des internautes ne se gère pas selon la charge, mais selon la cible. Imaginons que le blog du blogueur Jean-Paul soit publié à l’adresse http://www.mesblogs.fr/blog-de-jean-paul/. On mettra en place une répartition de niveau 7 qui, après analyse de l’URL et consultation de la table d’affectation, dirigera toutes les requêtes du type /blog-de-jean-paul/* vers le serveur approprié.

Pas d’autre axe d’extensibilité

Une fois qu’on a retenu le principe de partitionnement, est-il utile de le combiner avec d’autres axes d’extensibilité ?

On pourrait en effet augmenter la capacité de chacune des plateformes élémentaires, que ce soit verticalement, en séparant application et base, ou horizontalement, en disposant plusieurs frontaux.

Du point de vue de l’extensibilité, ce n’est pas nécessaire : le partitionnement nous apporte toute l’extensibilité désirée, et il sera plus simple d’avoir 100 petits serveurs de blog autonomes, plutôt que 20 plateformes de 5 serveurs.

Mais il reste la question du secours.

Secours

Nous avions signalé déjà que le partitionnement rendait le secours plus difficile.

Si nous alignons 100 serveurs de blog autonomes, comment offrir de la haute disponibilité pour chacun d’eux ? En le dupliquant ?

Clairement, doubler tous nos serveurs serait extrêmement coûteux.

Il nous reste deux voies :

  • Soit construire, comme on l’a évoqué ci-avant, 20 petites plateformes de 5 serveurs (ou une autre combinaison), chacune disposant des solutions classiques de haute disponibilité, déjà recensées.
  • Soit mettre en œuvre un secours mutualisé pour les 100 serveurs : on dispose d’un petit lot de serveurs de secours, en spare, qui peuvent servir à remplacer n’importe lequel des serveurs défaillants. Si l’infrastructure est totalement virtualisée, on pourra restaurer l’ensemble de la VM au dernier point de sauvegarde, en quelques secondes.

SAN

Nous avons dit plus haut que le SAN n’était en général pas la solution pour construire une plateforme de très haute capacité. Néanmoins, ici, ce pourrait être une voie intéressante.

En disposant d’un système de stockage qui soit à la fois :

  • De très haute disponibilité, car intrinsèquement redondant
  • Et qui puisse être associé à n’importe quel serveur

On peut gérer un secours mutualisé pour l’ensemble de la plateforme. En cas de panne d’un serveur, on alloue un serveur parmi le pool de spare, et on lui associe le système disque du serveur qu’il remplace.