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 :-)

Ce billet va vous faire découvrir un peu plus la cuisine et c’est pas beau à voir.
Dans l’internet by Orange, les clients payent un abonnement -généralement plus cher que chez les concurrents- pour avoir un accès à Internet de qualité. Le meilleur du marché m’a même confié un préposé à une enquête de satisfaction.

Avec cet argent issue des abonnements, Orange couvre ses frais : publicité, marketing, technique, taxes et aussi une marge (comme toute société !). Le cercle vertueux du commerce veut qu’un marchand cherche à se faire apprécier par ses clients pour ensuite proposer des services encore meilleurs.

Et pourquoi mes vidéos elles rament ?

La vidéo en ligne est très consommatrice de ressources techniques. La fameuse bande passante qu’on vous vend à coup de « méga » est une denrée chère, surtout si vous la consommez. La publicité veut vous faire croire le contraire en vous vendant 20 Méga pour quelques dizaines euros. Sachez que si vous consommer en moyenne 1 Méga, vous faites un heureux. Si vous consommer 5 voire 10 Méga, vous allez ruiner les marges de votre fournisseur.

Et le fournisseur, il accuse donc le couple internaute (son client !) — éditeur de site web video de ruiner ses marges.

Coté éditeurs de sites web « video », on a Google mais il y a aussi Dailymotion, Vimeo, WAT et plein d’autres.

Les abonnés d’Orange sont en droit de s’attendre à une qualité de service digne d’un vrai best-effort. Quand on lit une vidéo YouTube on s’attend à ce qu’elle se lise dans de bonne condition. Après un petit hocquet de temps en temps, soit.

Un peu de technique

Orange ne fait pas de best-effort vis à vis de Google contrairement aux bons usages de l’internet qui prend aujourd’hui souvent le nom de Neutralité des Réseaux. Techniquement parlant (on y arrive), lorsque votre Livebox (et les serveurs DNS d’Orange) essaient de charger une vidéo sur YouTube, vous êtes dirigé vers des serveurs généralement basés aux Etats-Unis. Loin, très loin. L’objectif de l’opération : faire plier Google pour que ce dernier mette la main à la poche pour financer le réseau d’Orange.

Google comme tous les gros fournisseurs de services consommateurs de bande passante, s’efforce de faire au mieux pour que ses utilisateurs soient satisfaits. Pour cela, il utilise un système de répartition de charge basé sur la géographie du DNS de l’utilisateur. Ainsi Google choisit de vous faire pointer vers des serveurs disponibles et surtout ayant une bonne connectivité pour que votre vidéo s’affiche sans accroc… ce même en HD.

Si comme 99.9% des clients d’Orange vous faite confiance à votre fournisseur d’accès, vous utilisez les serveurs DNS d’Orange. Ceux-ci induisent en erreur Google qui alors vous donne l’adresse d’un serveur lointain et peu performant. A l’inverse, si vous configurez votre ordinateur pour utiliser les DNS de Google, comme par magie vous allez voir les vidéos dans d’excellentes conditions : adieu buffer et coupures ! C’est la solution de contournement.

Ce qui se passe ici, c’est que les serveurs DNS de Google dialoguent correctement avec le système de géolocalisation de la maison, sans l’intervention des DNS d’Orange. On est jamais mieux servi que par soit même.

Je vous laisse en tirer les conclusions qui s’imposent. A ceux qui pensent que Google aurait du mal à diriger les internautes d’Orange vers le bon data-center Google, sachez quand même que chez Free ou chez SFR, YouTube fonctionne à merveille sans aucune modification de DNS.

Soucieux de la qualité, Google propose aux fournisseurs d’accès d’installer quelques serveurs pour faciliter l’écoulement du trafic vidéo vers ses abonnés. Les derniers kilomètres sont ceux qui coûtent le plus en terme d’infrastructure. Des solutions existent pour se rapprocher de l’abonné, parfois directement dans les grosses agglomérations.

Que faire ?

La première chose est de suivre les « instructions » données par Korben.

La seconde est plus fraîche : prenez votre plus belle plume et contribuez à la consultation publique ouverte par l’ARCEP autour de la Neutralité des Réseaux :

Les commentaires doivent être transmis à l’Autorité, de préférence par courriel à cp_neutralite@arcep.fr avant le 2 juillet 2010 à 17h00. Il sera tenu le plus grand compte des commentaires transmis à l’Autorité.

La troisième action : parlez-en autour de vous : Orange est comme toutes les sociétés commerciales, elle a horreur de la mauvaise publicité. Si Orange ne trouve pas de solution avec Google, vous serez condamné à consommer des services des marques de la société Orange ? Pas très sain. Allez un petit effort pour vos abonnés !

A méditer

Je parle ici d’un cas concret, vécu, réel et vérifiable à l’heure où ce billet est publié. D’autres exemples existent peut être mais de cette ampleur, pas à ma connaissante. Je ne suis pas un ultra-défenseur de Google. Je trouve comme beaucoup que cette société en fait beaucoup, trop je ne sais pas. Ce succès fait peur.

Le consommateur doit garder son esprit critique, il doit pouvoir avoir le choix.

[Mise à jour du 2 mai 2010] Suite à un commentaire de Mr Xhark, voici la très pertinente page de monitoring de YouTube. Clairement Orange est deux fois plus lent que les fournisseurs concurrents :

En noir vous pouvez admirer les performance de la fibre optique d’Orange.

A l’origine produit commercial issu d’Inktomi et désormais hébergé en tant que projet Apache Incubator, Traffic Server dispose de pas mal d’atouts qui pourrait en faire une arme de choix pour les sites à gros trafic tenté de servir les contenus par eux-mêmes.

Parmis les fonctionnalités clé on retrouve :

• Serveur haute performance (on parle de 30 000 req/s sur un quadri coeur à 1.86 Ghz)
• Modulaire (on pourra imaginer branché FTP, RTSP ou encore SMTP)
• Des outils de conversion pour assurer la transition depuis Squid

Plus d’infos sur le billet consacré à Traffic Server sur O’Static

On y découvre les secrets de Google, Twitter, Facebook ou encore des sites de e-commerce (américains) pour améliorer leur audience et leur chiffre d’affaire. Une véritable mine d’or.