wOueb by Romain DECKER / Another IT Guy Blog

Que se passerait-il si Google mettait un lien vers votre site/blog en page d’accueil ?

Votre serveur subirait un afflux massif de visiteurs curieux : la conséquence directe serait une surcharge importante, qui rendrait très certainement votre site indisponible.

Ce phénomène est appelé effet Slashdot, ou slashdotting (moins courant). Ce terme provient de l’afflux considérable de trafic web lorsqu’un site est linké par Slashdot.org, sorte de digg-like pour geek.

Pour réussir son Slashdot Effect, 3 étapes sont nécessaires :

1. 1. un site (très) populaire met un lien vers un site plus petit,
2. 2. les zombies du web et autres affamés du clic internautes cliquent à tout va,
3. 3. le serveur hébergeant le site plus petit subit de fortes lenteurs, ou devient indisponible du fait de la masse de connexions.

Le graphique suivant représente l’évolution de la bande passante par rapport à une échelle de temps. On voit qu’à partir d’un instant T, la bande passante est plus que décuplée : ça représente l’effet Slashdot.

Les goulots d’étranglement peuvent être multiples : bande passante, requêtes vers la base de données, limites de processus Apache, système de cache absent, mauvais développement, etc.

Il est légitime de se poser quelques questions :

• comment prévenir et conserver un minimum de disponibilité si ça arrive ?
• que faire si cela arrive et que votre site est complètement indisponible ?
• jusqu’à quel point être vous prêt à accepter une dégradation de service ?

Se poser ces questions est un bon début, car vous êtes conscient que le problème existe.

Facebook est une vraie machine de guerre : on a pu voir récemment que c’était le site le plus visité au monde, et tout ça seulement après quelques années. Contrairement à d’autres « supergrands » (Google, Microsoft, Apple, Youtube, etc.) un certain nombre d’informations filtrent lors de conférences, et dans des documents officiels.

J’ai visionné plusieurs heures de vidéos de conférences (long mais super intéressant) et ait compilé les informations. Vu la masse de détails obtenus, j’ai décidé de publier deux articles :

• celui-ci, présentant les chiffres clés sur l’infrastructure de Facebook,
• un second (à venir) : comment Facebook gère quotidiennement son (immense) infrastructure ?

En extrapolant

• certains graphiques d’évolution,
• des chiffres passés,
• des indications fournies pendant des conférences,

on estime entre 60 000 et 100 000 le nombre de serveurs de Facebook . Cependant, ce chiffre ne tient pas compte de deux nouveaux datacenters actuellement en cours construction (Oregon et Caroline du Nord).

Facebook : évolution du nombre de serveurs

Mais qu’est-ce qui peut bien tourner sur cette infrastructure ?

Données générales :

• 500 millions d’utilisateurs actifs (un utilisateur actif est un utilisateur qui se connecte au moins une fois par mois),
• 50% des utilisateurs se connectent au moins une fois par jour, soit 250 millions de personnes tout de même,
• 690 milliards de pages vues par mois,
• 6 milliards de contenus partagés par semaine (statuts, photos, liens, vidéos),
• 3 milliards de photos uploadées par mois, pour plus d’un pétaoctet de stockage uniquement destiné aux photos (chaque photo existe en 4 tailles),
• un dernier chiffre, le plus parlant peut-être : 16 milliards de minutes sont passées par jour sur Facebook. Ça représente 11 millions de jours ou encore plus de 30 000 années qui sont passées par jour sur le réseau social, c’est juste énorme !

Données techniques :

• plus de 300 To (téraoctets) de données en cache en RAM avec Memcached,
• 25 To (téraoctets) de log par jour,
• un ingénieur Facebook pour 1,1 millions d’utilisateurs. A titre de comparaison, Google emploi un ingénieur pour 190 000 utilisateurs,
• un opérateur Facebook pour 2,3 millions d’utilisateurs.

Quelques chiffres intéressants sur MySQL :

• 13 millions de requêtes par seconde en pic,
• 38 Go/s de trafic MySQL en pic,
• temps de réponse moyen en lecture : 4 ms,
• temps de réponse moyen en écriture : 5 ms,
• 450 millions de lignes lues par seconde en pic,
• 3,5 millions de lignes modifiées par seconde en pic,
• 5,2 millions d’I/O (disques) InnoDB par seconde.

Qui a d’autres chiffres intéressants et récents à partager ?

Dans le prochain article sur le sujet, je traiterai de la gestion quotidienne d’une infrastructure de cette taille.

Sources :

• A Day in the Life of Facebook Operations,
• Facebook on Bandwidth,
• MySQL Tech Talk.

Je parlais de Pingdom récemment, une solution de monitoring/supervision en ligne. Il se trouve qu’il existe trois autres outils gratuits en ligne également sur ce site :

• Full Page Test : test de vitesse de pages web (avec les temps de chargement de chaque élément),
  
• DNS Health,
• Ping and Traceroute : de l’ordre du gadget plutôt, vu qu’il est possible de le faire à partir de n’importe quel poste à peu près.

Ci-dessus, le résultat détaillé d’un test de vitesse pour une page web, en l’occurrence mon blog, et le résultat condensé ci-dessous.

Ci-dessous, un test DNS.

Les solutions de supervision sont nombreuses, qu’elles soient gratuites ou payantes, opensources ou non, internes à l’infrastructure ou externalisées.

Pour rappel :

La supervision est la surveillance du bon fonctionnement d’un système ou d’une activité.

Personnellement, je ne classe pas la supervision dans la même catégorie que le monitoring, qui est plutôt « une action de mesure d’une activité ou d’une ressource ».

Le choix d’une bonne solution est complexe, car toutes ont leurs avantages ou inconvénients. Je suis toujours partisan de solutions opensources (Nagios, Icinga, etc.), mais il est important de les coupler à une sonde externe qui permettra la notification en cas de blackout total.

Par exemple : si un bâtiment entier subit une explosion, le système de supervision interne ne pourra plus prévenir (mails, SMS, etc.), car il sera très certainement indisponible.

C’est dans ce cadre là que j’ai été amené à tester Pingdom, présenté comme une solution de monitoring/supervision de sites web.

(suite…)

PhpSysInfo est une interface PHP qui permet d’afficher un résumé d’informations sur le système et le matériel du serveur sur lequel est hébergé le script.

It will displays things like Uptime, CPU, Memory, SCSI, IDE, PCI, Ethernet, Floppy, and Video Information.

Les informations sont relativement complètes, et permettent d’avoir une vue rapide de votre système : j’ai l’habitude de l’utiliser des serveurs qui ne font pas partie de « fermes« .

(suite…)