navigation
Parole d’Expert
par Nicolas Salih, Chef de Projet Agarik
Bonjour à tous,
Aujourd’hui nous allons aborder un sujet ancien mais toujours d’actualité : la tenue en charge d’une plateforme web évènementielle et les moyens mis en œuvre pour y parvenir. Revenons tout d’abord sur la nature d’une plateforme évènementielle et les fameux pics de fréquentation auxquels elle est soumise.
Raison d’être d’une plateforme événementielle : de la saisonnalité au trafic imprévisible
La mise en place d’une plateforme événementielle est motivée par un pic d’activité métier exceptionnelle. Dès lors la bonne tenue de l’architecture web est primordiale à la réussite du projet. Ainsi, une campagne de marketing viral, une collecte de fonds, une opération de communication pluri-media, etc. sont autant d’activités se déroulant sur une courte période pour lesquelles la perte de la plateforme qui les soutient serait désastreuse. Dans une telle éventualité, au mieux l’activité serait un échec – les objectifs n’ayant put être remplis – et au pire c’est l’effet inverse de celui recherché qui serait obtenu – perte d’image, de crédibilité ou de business.
Une caractéristique importante de ces situations est l’impossibilité de prévoir précisément l’audience du site web : par exemple, suite à la diffusion d’un spot télévisé à une heure de grande écoute, combien de personnes iront sur le site dans les minutes qui suivent ? Et si c’est bien ce trafic que les annonceurs commanditaires achètent la bonne exécution des pages web fera le succès de l’opération. La plateforme doit donc être spécialement étudiée pour gérer ses très attendus “pics de charge”.
Pour une infrastructure web performante…
La performance d’un site web repose sur plusieurs concepts complémentaires :
– l’optimisation du code applicatif,
– la scalabilité verticale des ressources,
– le design d’architecture,
– la scalabilité horizontale,
– l’optimisation des flux de données.
Pour tout applicatif, site web ou autres, l’optimisation du code est le critère à traiter en priorité car il est applicable à toute programmation logicielle. Si le traitement d’une demande web dans son intégralité monopolise la plateforme pendant 60ms et génère 100ko de trafic, il est alors évident que la plateforme pourra traiter au mieux 1000 requêtes en une minute pour un trafic de 100Mo. Les méthodes d’optimisation et les bonnes pratiques d’architecture logicielle sont bien connues des développeurs web et en perpétuelle évolution, aussi nous ne les aborderons pas ici. On peut toutefois citer les gains apportés par les CSS, l’utilisation d’index et l’optimisation des requêtes sur les bases de données, etc. De plus, des adaptations du code peuvent être nécessaires pour permettre les méthodes abordées ci-après.
Venons-en à présent aux traitements d’échelle des ressources : scalabilité verticale, design d’architecture et scalabilité horizontale.
La scalabilité dite verticale est l’action d’ajouter des composants dans le but d’améliorer les performances du serveur (ajout de mémoire, processeur plus puissant). Cette méthode efficace offre toutefois de faibles possibilités d’évolutions dans le cadre qui nous occupe, les reconfigurations se faisant généralement avec coupure de service et nécessitent des ajustements logiciels pour que les ressources supplémentaires soient pleinement exploitées.
Le design d’architecture permet de répartir les traitements sur plusieurs de serveurs en fonction des services rendus. Un des modèles de conception les plus répandus comprend par exemple :
– un étage pour communiquer avec les utilisateurs et délivrer du contenu en fonctions des demandes,
– un étage pour générer le contenu à partir de sources d’informations internes et/ou externes à la plateforme,
– un étage pour la gestion des données, sous forme de bases transactionnelles ou de fichiers plats.
Ce découpage permet de paramétrer chaque serveur en fonction des services qu’il héberge, tout en offrant le plus de ressources possibles à chacun de ces services pour optimiser son fonctionnement. On peut croiser les services de la plateforme avec ceux d’autres plateformes, dans le cas de l’utilisation de données externes ou de mise à disposition de contenus à des partenaires par exemple. Cela permet en outre, de mettre en évidence les points de congestion de l’application hébergée : la hausse de fréquentation de la plateforme n’entraine que rarement une augmentation linéaire de l’utilisation des ressources de chaque étage.
Ces points de congestions permettent la mise en œuvre d’une seconde forme de traitement d’échelle, la scalabilité dite horizontale. Il s’agit alors de mettre plusieurs serveurs sur un même étage afin d’en augmenter ses performances. Cela entraine la mise en œuvre de méthodes de répartition de charge afin que chaque étage reste vu comme une brique unitaire par les autres étages ou par les utilisateurs. Ces pratiques permettent de plus d’assurer un niveau de tolérance aux pannes de la plateforme par sur dimensionnement de chaque étage: si 5 serveurs délivrant des pages sont nécessaires pour répondre à la demande maximale, le fait d’en ajouter un 6e permet de garantir que la demande sera servie même en cas de perte d’un serveur en période critique : on parle alors de redondance à N+1 pour l’étage concerné. L’architecture mise en place doit être pensée en fonction des contraintes et des paramétrages spécifiques liés à chaque étage.
Dans le cas d’une plateforme évènementielle, la mise en œuvre de ces trois formes de traitements d’échelle, associés à une redondance pour tolérance de pannes et une surveillance pro-active de la consommation de ressources permet de réagir en cas de sous-dimensionnement imprévu de la plateforme. Il faut bien entendu en outre que les différents acteurs qui mettent en œuvre et exploitent la plateforme soient en mesure de faire évoluer rapidement la plateforme par mise en œuvre d’équipements supplémentaires.
Les solutions d’hébergement événementiels développées par Agarik reposent depuis longtemps sur la technologie « Ressources on Demand » qui met en parallèle des serveurs de production, d’autres serveurs « ready to start » prêts à intégrer l’un ou l’autre des étages de la plateforme. Une architecture ROD est une innovation spécialement conçue par Agarik pour affecter simplement des ressources à la demande. Une architecture réseau répondant à l’état de l’art assure une redondance totale ainsi qu’une protection globale de la plateforme. Chaque nœud est un serveur diskless interchangeable qui assure la production effective des services demandés. Les principes mis en œuvre de nos jours sur la couche hébergeur dans les plateformes de Cloud-computing en IaaS sont similaires, à ceci prêt que les services rendus par les serveurs physiques sont alors la mise en œuvre de machines virtuelles.
Enfin le dernier point, et non des moindres, est l’optimisation des flux réseaux. En effet, si la qualité du lien de raccordement doit être au rendez-vous – forte capacité, haute disponibilité, faible latence – il ne faut pas omettre de traiter les aspects de mise en cache là où cela est susceptible d’apporter des gains significatifs : utilisation du maximum de mémoire possible sur les serveurs pour un usage optimal des caches système, mise en cache des données fréquemment utilisées au niveau applicatif pour réduire les traitements, utilisation de CDN (Content Delivery Network) pour les contenus statiques ou qui évoluent lentement.
Pour conclure, les projets d’hébergements événementiels sont avant tout basés sur la qualité de la relation entretenue avec son hébergeur / infogérant qui doit savoir :
– concevoir une architecture permettant une reconfiguration à la demande
– conseiller en amont sur l’enveloppe budgétaire à provisionner
– accompagner et anticiper les besoins pendant toute la durée de la campagne
Et finalement devenir un véritable partenaire garant du succès web de son client !