Quand Goliath s’attaque à David, ça fait mal.

En pointant en message en page d’accueil du moteur vers le site de la CNIL, qui vient de condamner Google à une modeste amende de 150 000 euros (une micro paille pour ce géant qui réalise 200 milliards de chiffre d’affaires par an), Google a abattu par un déni de service non intentionnel l’institution française régissant les règles informatiques et liberté.

CNIL DDoS by Google

Le message a eu son effet  : le site de la CNIL est tombé, en quelques secondes, sous la masse de trafic qui s’est abattue sur le site . C’est une action bien évidemment involontaire de la part de Google, mais le coup aurait pu être évité si les responsables techniques de la CNIL avaient pris quelques précautions.

Source images  : Korben

En parlant de ma propre expérience, subissant tous les jours des trafic de +100 000 connectés en simultané, voici quelques-unes des recommandations que je peux  suggérer à la CNIL :

– Du Reverse Proxying et toujours du  Reverse Proxying  !

Un serveur Web passe une bonne partie de son temps CPU à gérer l’acquittement des connections Web (TCP). Le soulager de cette tâche augmente sa capacité de montée en charge.

– Si le code ne tient pas la charge… Alors le cache  !

– Après du profiling   (identifications des goulets d’étranglement), et si les refontes de code sont trop lourdes, il faut mettre le site en cache. Pas le choix.

Différentes méthodes s’offrent à vous  :

1. Le Reverse Proxy Cache  : l’application doit discuter avec le reverse proxy cache pour savoir quand délivrer les pages aux internautes. A savoir  : s’ils sont authentifiés ou non authentifiés.
   Si ce n’est pas possible alors seuls les objets statiques (images, css, js) devront être mis en cache.
2. Une méthode « vieille école » mais néanmoins redoutable  :  la génération des pages statiques ou de blocs de pages statiques. Ce seul point aurait sans doute évité au site de la CNIL de  « tomber ».
3. Séparez la partie de l’interprétation du code de la partie du serveur Web.Concrètement  : il ne faut pas de modules PHP intégrés dans Apache. Préférez un serveur d’interprétation PHP et un Serveur Web distinct.
4. Choisissez et benchez vos serveur Web.Par exemple Nginx a une architecture logicielle éprouvée, et est «  reverse proxyfiable  » derrière un équipement réseau supportant 100 000 connectés.
5. Renforcez les bases de données, via du clustering (réplication active – active) et mettez en place de la répartition de charge sur ces bases de données. Mais d’un point de vue d’architecture Web «  philosophique  » c’est un peu sortir le char d’assaut pour tuer le lapin blanc dans le champ  !La mise en cache de requêtes SQL (via du NoSQL ou  de l’allocation de mémoire aux index) est une option à regarder de très très prêt.
6. Le choix du hardware reste fondamental.Un serveur de sauvegarde avec 36 To n’a pas la même vocation qu’un serveur frontal web avec ses 20 cores et ses 256 Go de RAM.

Bref, en synthèse, vous l’aurez compris, il est impératif de revoir intégralement l’architecture Web. Sans nécessairement réaliser une modifications du code du site Web.

A savoir aussi que certains clouds s’effondrent très rapidement dès que ça chauffe sur le net.

Messieurs, Mesdames, les responsables techniques de la CNIL, j’espère que ces quelques lignes vous apporteront du « uptime ».

Pierre-Alain – Administrateur Système ooworx.com

NDLR : Pierre-Alain est mon sysadmin sur divers projets, dont du e-commerce et je vous le recommande chaudement. Il n’y en pas plus d’une poignée d’aussi balaises que lui sur le territoire français.

Edit : le spinoff de Qwant est tout simplement délicieux.