Lancement de site à fort trafic avec un CMS, ce qu’il faut retenir

Quelques heures après un lancement, un site peut rencontrer des problèmes de charge. C’est d’autant plus vrai quand ce dernier s’appuie sur une infrastructure complexe : base de données, frontaux intermédiaires, CMS…

Comment y faire face, quelles sont les solutions, les points à éviter ?

Les évènements récents sont sujet à des analyses de tout bord (voir par exemple : […].fr : les erreurs à éviter lors du lancement d’un site web d’envergure).  Si l’article fait l’effort de rassembler quelques spécialistes, certains points restent définitivement à éclaircir par une réalité pratique un peu différente.

Le bien et le mal des Content Management System (CMS)

Faire le choix d’un CMS. C’est un choix assez classique. Pourquoi réinventer la roue quand un produit existe sur le marché. Le choix d’un CMS open-source est somme toute assez standard et bon nombre d’expériences française témoignent de la relative maturité de ces produits pour peu que l’on se plonge dans les arcanes techniques.

Contrairement à ce qui est maladroitement expliqué dans l’article ci-dessus, les CMS supportent mal nativement les fortes charges. Ces outils sont avant tout une mine d’or en terme de fonctionnalités qui rendent non seulement la tâche des éditeurs de contenus plus facile mais aussi celle des webmasters/webdesigners qui doivent mettre en forme le site.

Ne pas se concentrer sur les fortes charges n’est pas pour autant un grave défaut car ce qu’on cherche dans un CMS, c’est avant tout une simplicité d’utilisation, d’extensibilité et de maintenance.

Tout ceci n’empêche pas les architectes logiciels & réseaux de se pencher sur la structure même du logiciel, notamment sa façon d’interagir avec son système : le serveur web mais aussi la base de données associée. Bien souvent on retrouve des goulets d’étranglement là où on ne s’y attend pas : capacité réseau entre les serveurs web et la base de données, configuration du serveur web par défaut limitée à un certains nombre de connexions, etc…

Chaque cas est unique mais, il existe des produits qui aident à supporter mieux la charge.

De l’utilisation des proxy cache

Au delà de l’architecture mise en place pour faire fonctionner le CMS, des serveurs relais (que l’on appellera reverse-proxy ou encore les solutions type CDN) peuvent épauler les serveurs centraux. L’objectif est de réduire la charge en mettant en cache les objets statiques (images, CSS, JavaScript) et parfois même les pages elle-même quand celles-ci n’évolue que périodiquement. Le succès d’une telle opération se mesure avec le taux de cache : au niveau de la bande passante (bandwith ratio) et au niveau du nombre de requête (cache hit ratio).

Un site éditorial va pouvoir atteindre des taux supérieurs à 90% alors qu’un site fortement transactionnel (e-commerce, forum) sera généralement en deçà. Le web est malgré tout par nature composé d’utilisateurs « lecteurs » plus que de créateur de contenu. Ceci est valable pour un site de e-commerce où finalement une minorité d’utilisateurs va ne serait-ce que mettre des objets dans le panier.

Quelques recommandations

• Lancement à fort risque de charge : privilégier la mise en cache de toutes les URLs
  Même si les temps de cache sont cours, mieux vaut quelques minutes de cache que rien du tout. Cela permet de soulager les infrastructures lors des pics qui sont généralement dangereux lorsqu’ils sont très verticaux. Cette solution permet aussi de se passer des tests des montées en charge qui sont très coûteux lorsqu’ils sont fait sérieusement.
• Séparer l’URL de consultation de l’url de back-office.
  Souvent les CMS permettent de tout faire depuis la même URL. Il convient de donner  l’accès aux éditeurs via une URL différente qui elle pointera directement vers le(s) serveur(s) CMS. Dans la même philosophie, on peut séparer les serveurs destinés à recevoir des informations (formulaire de contact, forums…) des serveurs destinés à simplement diffuser l’information.
• Conserver un nom de domaine unique
  Une url est souvent accesible par deux URLs : http://site.fr et http://www.site.fr. Pour les bienfaits du référencement mais aussi de la tenue en charge (seul le www. peut être utilisé avec un CDN), il est fortement recommandé de faire une redirection permanente de http://site.fr vers http://www.site.fr. Ainsi tout le trafic sera bien dirigé vers les reverses proxy/CDN.
• Prévoir une solution de secours (fail-over)
  On ne peut jamais tout prévoir même si on est surdimensionné. Prévoir une solution de backup avec une page d’excuse temporaire permet de soulager un serveur qui serait saturé. Généralement statiques, ces pages d’excuses peuvent être gérées coté serveurs CMS comme coté reverse-proxy/CDN. A noter qu’il est ici recommandé de conserver un code d’erreur (status code) HTTP qui indiquera notamment au robot d’indexation qu’il y a effectivement un problème et que la page d’excuse est temporaire et qu’elle ne doit pas figurer dans l’index du moteur. Si http://www.site.fr retourne un 200 en affichant une page d’erreur ou d’indisponiblité, il est préférable de maintenir un 500 ou un 503.
• Mesurer les points vitaux de l’infrastructure
  On a souvent tendance à regarder les signaux vitaux d’une infrastructure que lorsque ça va mal. Garder un historique de ces points de mesures pendant quelques jours permettra de mieux comprendre la limite de l’architecture lorsque celle-ci sera mise à l’épreuve. Parmi les points vitaux d’une infrastructure comme celle-ci ont retiendra le nombre de requêtes par seconde (HTTP et au niveau de la base de données), la bande passante mais pas uniquement en sortie du web, entre les serveurs de l’infrastructure et aussi la charge des processeurs (rarement en cause), la mémoire (l’important c’est la stabilité sinon il faut partir à la recherche des fuites mémoire dans le code).
• Sécurité
  Si nombre de sites n’ont finalement pas d’énormes risques stratégiques, les sites sensibles font souvent l’objet d’attaques. L’idéal est de faire passer le trafic à travers de firewalls applicatifs (Web Application Firewall). Généralement sous forme de boîtiers (mais aussi coté « cloud »), ces solutions permettent de prévenir des attaques diverses.

J’espère que ces conseils pourront aider certains d’entre vous.

PS: merci Manu :-)