Un peu dans l'esprit de l'article Penser architecture web que nous avions publié il y a 2 ans, nous allons aborder dans cet article les problématiques que nous savons récurrentes pour nos clients hébergement ainsi que dans le monde du web en général : que faire quand mon serveur web est surchargé ou mes sites web sont lents ?

Depuis quelques mois, vous avez peut-être pu utiliser des serveurs aux États-Unis. Le changement de l’infrastructure de stockage était un des points forts dans l'infrastructure pour l'hébergement.
Avant ça, il a fallu adapter notre infrastructure afin qu'elle puisse comprendre "n" datacenters. La mise en place de la nouvelle plateforme de stockage n'a pas été si compliquée puisqu'elle était indépendante de celle existante en France. Le datacenter était nouveau, c'était donc assez simple à mettre en place : tous les nouveaux serveurs aux États-Unis ont bénéficié de cette nouvelle technologie.

La liste des noyaux disponibles sur l’hébergement de Gandi s'allonge. Vous avez maintenant la possibilité d'utiliser un 2.6.36 ou un 2.6.32 avec le patch grsecurity.

Notre infrastructure de stockage nouvelle génération est en cours de déploiement.

La gestion des disques, elle aussi, passe à la moulinette de la virtualisation... et nous sommes impatients de vous en faire profiter !

Quelles sont les modifications appliquées par l'équipe de Gandi sur les installations standard d'OS pour être utilisé avec l'hébergement Gandi ?

L'hébergement sur des serveurs Gandi permet à ses clients de choisir parmi une sélection d'image d'OS disponible à la création de la machine. Après la préparation en interne de l'image et après une batterie de test, l'image est mise à disposition d'un groupe de client 'alpha' pour l'hébergement Gandi. Ces clients peuvent ainsi créer des serveurs utilisant ces images en 'release candidate'. De notre coté, cela nous permet d'élargir le champs des tests effectués sur les images et de dénicher les bugs et problèmes en touchant un plus petit groupe de client.

Aujourd'hui - 21 Mai - sort donc l'image d'OS basée sur une Mandriva 2010.0. Cette nouvelle version de la distribution Mandriva démarre avec un kernel 2.6.27 par défaut. Cette image est pour le moment disponible pour le groupe de client hosting en 'alpha'. Cette image de système sera bientôt disponible pour tous. N'hésitez pas à nous contacter si vous souhaitez participer à nos phases de test alpha.

16 aout 2010 : L'image est maintenant disponible pour tous

Un ami m'expliquait qu'il venait de terminer l'installation d'un serveur web. Ayant décidé de changer et de ne pas utiliser le géant Apache que tout le monde connait, mon ami semblait avoir trouvé une bonne alternative. Portant le doux nom de Cherokee, il paraissait plus léger et plus performant qu'Apache. Voir les benchmarks provenant du site du projet à la fin de l'article. ^[1]

Personnellement, je ne le connaissais pas du tout, j'avais certainement déjà entendu son nom une ou deux fois, mais je n'y avais pas prêté attention. Pour voir ce qu'il donnait, j'ai décidé de l'installer en local. Je fus agréablement surpris ! Sur une distribution Debian like, l'installation se fait très simplement avec un apt-get install cherokee (ou aptitude).

L'interface web qu'il fournit est claire et plutôt agréable. L'idée est intéressante. Il sera possible d'activer l'interpréteur PHP avec un simple clic, pareil pour l'activation de différents virtualhost ou autres options. Il y a un assistant qui permet d'installer des technologies comme Django, Rails, ou Wordpress, etc.

Je me suis dit que présenter ce projet à une réunion devs chez Gandi pouvait être intéressant, notamment pour les personnes utilisant GandiAI. Le projet a bien été perçu. Après discussion et un coup d'œil rapide sur le code source, rien ne nous a choqués. Cela ne signifie pas qu'il n'y a pas de bugs, toutefois un code propre c'est plutôt bon signe ! Le cœur est écrit en C et l'interface d'administration en Python.

C'est donc de cette manière que Cherokee a fait son apparition chez Gandi et qu'une image a été réalisée, vous permettant ainsi de le tester rapidement.

Nous avons ajouté une distribution en mode expert avec Cherokee de préinstallé... il vous suffit de choisir cette distribution lors de la création de votre serveur. Je vous rappelle aussi que si vous n'avez pas encore essayé notre service, vous pouvez faire une demande sur notre formulaire de demande de test.

Pour avoir plus d'informations sur Cherokee, vous pourrez vous rendre sur le site du projet . Un article lui a également été consacré dans Gnu/linux magazine France par Carl Chenet dans le numéro 125.

À l'occasion des dix ans de Gandi, l'idée un peu folle de donner, sur dix jours, 55000 domaines, a posé une question pratique. Comment, en ouvrant les vannes d'une telle opération, maintenir une qualité irréprochable sur le site ? L'ambiance festive aurait aussi bien pu se transformer en cauchemar pour nos clients si ils avaient été privés d'accès à leurs interfaces de gestion.

La décision fût donc prise d'héberger l'événement sur un site dédié. Occasion rêvée pour se mettre un peu à la place de nos clients, et utiliser notre infrastructure d'hébergement. Règles du jeu : on utilise exclusivement les outils fournis au client, on prépare une archi qui monte en charge facilement, ça ne doit pas coûter un bras, ça peut illustrer notre flexibilité légendaire.

Keep it simple, stupid

De la décision à l'implémentation, on avait une semaine. L'idée charmante de monter un site "cloudish" à base de technos modernes, et peu maîtrisées, est donc oubliée d'office. Pour être honnête, vu les délais, le développeur désigné d'office se voit choisir la techno : "là où t'es à l'aise, tu as une semaine". Ça sera PHP/mysql, ce qui n'est pas du goût de tout le monde ! Mais permettra de sortir le site testé et dans les temps.

Pour tenir une charge correcte, plusieurs serveurs seront nécessaires.  Premier rappel de nos imperfections, Gandi ne fournit pas de load balancing ! Qu'importe, on ira donc sur un round robin DNS, à petit TTL pour pouvoir sortir facilement un frontal cassé de la production.

Notre distribution pour l'occasion, sera une ubuntu 9.10 - parce qu'elle est assez à jour, et qu'elle utilise un kernel 2.6.27.

Multiplier les petits serveurs

La meilleur façon de monter en charge sur notre infrastructure est d'isoler fonctionnellement l'architecture en nombreux petits serveurs. Là où nous assurons un minimum de "scalabilité" verticale (vous pouvez augmenter dynamiquement la RAM, le CPU alloués à un serveur), c'est à l'architecture de prévoir la scalabilité "horizontale".

Ainsi, on peut facilement monter les ressources là où les bottlenecks se font sentir, et ajouter/ou déplacer des parts d'un serveur vers l'autre lorsque la puissance allouée le demande. Les avantages des "nombreux petits serveurs" sont multiples :

• chaque serveur bénéficie au minimum d'un core CPU en burst (oui, un core entier, même sur une part : c'est nouveau)
• la redondance est assurée, et vos parts s'étalent un peu aléatoirement sur des centaine de serveurs physiques
• particulièrement en environnement virtualisé, la performance mémoire est meilleure sous 1G de RAM
• si vous avez 4 serveurs d'une part, au lieu d'un gros de 4 parts, ils montent à 8x4 parts dynamiquement, ou 24x4 parts en un reboot, tout ça sans toucher à l'archi - là ou le gros s'arrête à 8 sans reboot, ou 24
• les ressources sont faciles à déplacer vers les serveurs qui en ont besoin.

Nous partons sur l'infrastructure simpliste :

• 24 (!) serveurs d'une part, pour gérer le web et PHP : 10 en anglais, 10 en français, et 2 + 2 pour l'IPv6
• 2 serveurs de 4 parts, des memcached répliqués pour soulager la DB et gérer les sessions
• 1 serveur mysql de 4 parts, qui contiendra les coupons pré-générés (ils tiennent en RAM, la base doit théoriquement s'ennuyer)

Après quelques belles surcharges et un bout de code revu, la base de donnée sera finalement épargnée au maximum par memcached (voir chapitre « un code léger… »)

Soit 36 parts, pour une durée de dix jours : environ 140 euros.

C'est un admin qui s'usera les doigts sur notre site pour créer, et configurer les 24 serveurs en parallèle. Visiblement, la sortie de l'API hosting ou une fonction dans l'interface web seraient les bienvenus. (Merci à cssh pour l'occasion).

Sécuriser (un peu) les machines

Une distribution par défaut mérite toujours quelques retouches. Exporter mysql sur le réseau « public » du hosting gandi nous ennuyait un peu. À grands coups de netstat, fermer les services inutiles qui écoutent sur un port public. Avec l'aide de tcpwrappers (hosts.allow, hosts.deny), on ferme toutes les interfaces « privées » (sshd, mysql réservé aux machines frontales du web).

Restera à bien faire attention au code php et à nos queries mysql : le meilleur moyen d'éviter les injections est encore de binder tous les params après un prepare(). En plus, ça décharge la DB lorsqu'on effectue plusieurs execute.

Un détail important : notre site autorisant l'envoi de mail à un destinataire « arbitraire », il était critique de limiter au maximum son exploitation potentielle par un spammer malin : restrictions du nombre d'envoi par coupon, au minimum, et monitoring.

Prévoir l'environnement de dev et le déploiement

Partager les données entre les sites, c'est ajouter un "single point of failure" et un point de contention à l'archi. Nous optons donc pour un déploiement "local" à chaque serveur du contenu du site. Un site de développement et de "staging" sur une VM sert à tester et développer les mises à jour. Un script et quelques rsync permettent de déployer l'ensemble sur tous les frontaux de l'architecture. On a dit simple !

Surveiller ses ressources

Quelques minutes avant l'opération, pour prévenir plutôt que guérir, la totalité des machines virtuelles sont augmentées d'une à deux parts. En utilisant l'interface des stats, dès le premier jour, on peut constater l'ennui total qui habitait les machines virtuelles:

Il aurait été malin, à ce moment précis, de revenir à une part par machine. Ou d'exploiter gandi "autoflex", ou encore, vu le type de charge observée, de préparer des flexs programmés pour les heures de lâcher des coupons ! Malheureusement, beaucoup de monde sur beaucoup de ponts, on a raté l'occasion de vous faire cette belle démonstration (écono-techno-(éco ?)logique).

Un code léger vaut mieux que mille CPU costauds

Même si nous avions à notre disposition plusieurs milliers de CPU et beaucoup de teras de RAM, mardi fut suffisamment chaotique pour qu'on en reparle ici : après un lundi très bien tenu en charge, le plan d'exécution de notre unique SELECT COUNT changea brutalement et devint terriblement plus lent (300ms). Avec foi, nous avions pensé que ce query « unique », sur une table présente complètement en mémoire, ne poserait pas de problème : il était donc exécuté sur toutes les pages du site. La concurrence d'accès avec les UPDATEs des coupons finit par avoir raison de la base qui, malgré des stats systèmes proches de l'idle, entra discrètement en contention de lock.

La réaction habituelle est d'ajouter des parts pour monter en charge. C'est une solution temporaire acceptable, mais ça ne suffit pas !

Un analyse système, une remise en question du code, et une utilisation salvatrice de memcached permit de retrouver des performances acceptables. Une modification des queries utilisés aurait peut-être pu faire l'affaire également.

Une moralité à cet épisode: le code, les indexes, l'architecture, (…) sont les garants de votre montée en charge, et si ils sont « cpu friendly » vous épargneront, sinon une catastrophe, au moins un achat de parts inutiles.

En plus, comme on dit ici en plaisantant, c'est écolo.

Quelques chiffres

• 36 parts, mais on aurait pu tenir sur moins (snif)
• 5% de CPU en peak
• 4000 requêtes par frontal dans la première minute de chaque heure de pointe (environ 1400 req/seconde au total)
• un minimum de 11 secondes pour donner 1000 coupons
• pour le même nombre de coupons, un maximum de 40 minutes, pendant l'incident.

Comme vous le savez, notre système est flexible et vous permet de passer à n'importe quel moment et autant de fois que vous le souhaitez d'un serveur sur 1 part (1/64 de machine + 1/64 en boost, 256Mo de Ram) à un serveur de 16 parts (1/4 de machine + 1/4 en boost, 4Go de Ram), mais nous avons de plus en plus de clients qui après le lancement de leur service sont victimes de leur succès et se retrouvent en limite d'utilisation des 16 parts et viennent nous demander des serveurs de 24 ou 32 parts.

Notre réponse est souvent la même, nous leur conseillons alors de penser infrastructure web plutôt que serveur web.

En effet, notre solution vous permet de créer autant de serveurs que vous le souhaitez sur les ressources souscrites dans votre compte hébergement, la solution optimale consiste donc à séparer vos services pour une plus grande flexibilité et une plus grande robustesse.

Mais le plus simple est de prendre un exemple concret : comme certains le savent déjà, nous soutenons l'association Millenium pour la promotion des jeux et loisirs numériques en ligne.

Le succès grandissant du site millenium.org nous poussait à rapidement repenser l'architecture du site pour tenir la charge (de nombreuses vidéos, 17 000 visiteurs uniques/jours). Pour ne rien vous cacher, nous avons quelques priorités et projets Gandi à régler avant de nous occuper du site.

Suite à une importante mise à jour d'un des jeux suivis par Millenium (NDLR: WOW patch 3.1), et même si nous avions anticipé une charge importante en passant le serveur sur 16 parts, celle-ci a vite dépassé nos estimations avec plus de 50 000 visiteurs uniques le premier jour et surtout presque autant les jours suivants.

Le site recevait alors entre 500 et 1000 visiteurs en simultané, ce qui n'est pas viable pour un serveur unique de type LAMP avec, de plus, de très nombreuses vidéos. Nous avons donc changé l'infrastructure immédiatement, pour passer d'un modèle sur un serveur unique (qui est souvent le choix au démarrage) à un modèle en infrastructure. Nous sommes passés d'une extension verticale (plus de puissance) vers une extension horizontale (plus de serveurs) :


Comme le montre ce schéma, nous avons donc sorti la base de données sur un serveur à part et dupliqué le serveur web sur 2 machines, la répartition de charge se faisant via la zone DNS du domaine. Nous pouvions aussi envisager de dédier un serveur d'une part à la répartition de charge, mais cette solution était un peu plus longue à mettre en place. Dans notre cas, il a fallu 2 minutes pour ajouter des parts sur le compte, 6 minutes pour créer les 2 serveurs, 10 minutes pour transférer les données et 2 heures environ pour configurer les services.

Aujourd'hui, la plateforme tient 1 million de visiteurs uniques par mois pour plus de 3 millions de pages vues, ce qui est une bonne chose. Mais le mieux c'est que maintenant la plateforme est évolutive. Si la base de données souffre, il nous suffira d'augmenter le nombre de parts allouées au serveur, et si les frontaux web arrivent à saturation, il nous suffira d'en ajouter un.

Si vous vous trouvez confronté à ce genre de problématique, n'hésitez pas à nous consulter, nous nous ferons un plaisir de vous conseiller.