Retour d'experience de 20minutes.fr autours des problématiques de développement, de tenue de la charge, de l'infrastructure, du cache, de mise en production,...

1. 20minutes.fr
 retour sur expérience

2. Qui sommes nous?
Nicolas Silberman Sébastien Lucas
 Responsable technique  Directeur associé
new media 20minutes.fr Oxalide.com
 nsilberman@20minutes.fr  slu@oxalide.com
   

3. Oxalide
 Conseil, infogérance & hébergement
 Gestion d’infrastructures dites « Critiques »
 Conception et gestion d’infrastructures sur-mesure
 Délégation de la production
 Hébergement de proximité : équipe projet dédié

4. 20minutes.fr

5. Le succès d’une nouvelle formule
Croissance
annuelle
VU MNR
160%
+149%
140%
120%
100%
80%
60%
Visiteurs uniques
40% MNR
0 1 000 000 2 000 000 3 000 000 4 000 000 5 000 000 6 000 000 Septembre 2008
SOURCES : VU MEDIAMETRIE // NETRATINGS Septembre 2008
VU NIELSEN NETRATINGS HOME & WORKSeptembre 2007

6. Une place dans le TOP 3
3°
3° Site de presse
en France
3 560 000
3 560 000
Visiteurs Uniques
qui viennent souvent et restent longtemps
SOURCE : VU MEDIAMETRIE // NETRATINGS Septembre 2008
(Uniquement sites de Presse)

7. Un site qui rend accroc
Pages vues par visiteur Temps passé par visiteur
Le Figaro 21 Le Monde 13:09
Le Monde 14 Le Figaro 12:38
20 minutes 14 Liberation 10:38
Liberation 11 20 minutes 9:09
La Croix 9 nouvelobs.com 6:46
nouvelobs.com 9 LePoint 6:05
Metrofrance.com 8 La Croix 5:29
L Express.fr 8 L Express.fr 4:25
LePoint 7 Le JDD 4:23
Le JDD 7 l Humanite 4:10
l Humanite 6 Le Post 3:53
France Televisions
Le Post 5 3:39
News
SOURCE : MEDIAMETRIE // NETRATINGS Septembre 2008 Uniquement sites de presse
* XITI Septembre 2008

8. Toutes les infos tout le
temps mises à jour en
temps réel, diaporamas,
sondages, commentaires
des internautes
(indifféremment sur le
web et sur le mobile)...

9. Performance sur le mobile
3° Site mobile
d’info
Hors portails
opérateurs
Une rentrée
encourageante
: croissance
mois sur mois
(+30%)
SOURCES : Médiamétrie - Les Mobinautes - Mars Avril 2008
Échantillon : 3 000 individus

10. 20minutes.fr – contraintes
 0% de downtime et donc 100% available
 Toujours penser/prévoir l’effet « 11 Septembre »
 Publication instantanée qui respecte les contraintes
de publication de la rédaction
 Information déstructurée : mix des sources
d’information
 Une marque de fabrique un homepage reprise sur
chaque page

11. 20minutes.fr - objectifs
 Lancer et instaurer une homepage énorme
– 300 Requêtes HTTP
– 2 Mo
– Index de 60KB (originellement 300 KB)
 Une reprise de cette lourde homepage sur chaque
article
 Une actu chaude 24/7
 Beaucoup beaucoup d’images
 Un média communautaire & participatif : Motiver le
User Generated Content

12. Un ADN open source

13. Pourquoi PHP?
 Accessible (on trouve codeurs et prestataires)
 Communauté active (française!!!)
 Documentation fournie // mailing list active
 Les gens partagent...
 Il a fait ses preuves
 La roadmap PHP donne confiance
 ...
05/12/08

14. Avant…
50 000 articles
3 000 images
5 jours sur 7 161 000
visiteurs uniques
4 sources de contenus
1 serveur
72 000 inscrits
à la newsletter
2 Mbps
de bande passante
1 tech - 3 journalistes

15. Aujourd’hui
300 000 articles
2 000 000 images
1 500 000 commentaires 3 560 000
7 jours sur 7
24h / 24
visiteurs uniques
11 sources de contenus
30 serveurs 500 000 inscrits
à la newsletter
900 Mbps projets satellites
de bande passante (5 000 blogs,
5 tech - 25 journalistes TOP-listes)

16. Evolution
 200 articles / jour
 3 500 commentaires par jour
 plus de 100 pages vues à la seconde
 plus de 5 000 requêtes http à la seconde
des prévisions de croissance d’audience encore
fortes à l’avenir

17. Développer et gérer la croissance
160
140
120
100 indice
80 trafic
60 lignes de code
40
20
0
2005 2006 2007 2008 2009
Développement de Rationalisation et
nouvelles fonctionnalités gestion du trafic

18. L’infrastructure
du sur mesure…

19. Une infra qui épouse l’applicatif...
…et pas l’inverse
 Cloisonner et Optimiser les flux internes
 Éviter les goulets d’étranglement
 Fine tuner la partie réseau
 Construire des piles applicatives redondées

20. Séparer média et applicatif...
…pour
 Améliorer la flexibilité sur la scalabilité
 Les processus du serveur web qui servent les pages
n'interfèrent pas avec ceux qui servent les images
 Vis-versa
 Optimiser le socle technique en fonction des contenus
 Configuration spécifiques des serveurs
 Serveur web moins gourmands pour les médias (aucun module
chargé qui ne soit utilisé)
 Pool de processus plus important
 Cloisonner les risques

21. … voire même par projet
 Conserver le cœur de métier sur une infrastructure
propre
 Héberger les sites satellites (sur lesquels on ne
maîtrise pas forcément la qualité) sur une
infrastructure dédiée à cet effet
 Externaliser certains services spécialisés (vidéos,
mailing, blogs, etc.)

22. Ne pas faire confiance aux sources tiers
présentes dans le core
 Souvent indispensables les éléments tiers de
votre page sont susceptibles de ne pas avoir la
même qualité de service (temps de réponse,
disponibilité, etc.)
 La perception de l'utilisateur sera celle du plus
faible maillon de la chaine des éléments qui
constituent votre page.

23. Solution : débrayer les sources tiers
 Rapatrier en asynchrone et héberger le contenu
 Gérerle chargement du contenu côté client pour
minimiser l'impact du chargement (ou pas) sur la
page (implémentation javascript).

24. Rester souple et dispo

25. LVS pour un équilibrage transparent
 Invisible pour l’internaute
Trafic
entrant
 Aucun changement pour
le serveur
IP virtuelle
 Prise en charge pour
LVS LVS
(actif) (passif) chaque serveur de 1/n
du trafic global (n = nb
Equilibrage Round robin
de serveurs actifs)
 Répartition parfaite
Serveur Serveur Serveur Serveur (round robin)
 Possibilité de sticky
 Applicable pour chaque
service (pas uniquement
web aussi service
interne)

26. Archi scalable et haute-dispo
 Séparation par couche : un groupe de serveurs par
rôle applicatif pour
 injecter la scalabilité et haute disponibilité à chaque
couche
 limiter les goulets d'étranglement et augmenter la
capacité
 Plusieurs serveurs pour 1 service (LVS / IP Virtuelle)
 Incident sans impact pour l'internaute
 Mise à jour ou tâche de maintenance invisible
 Privilégier la répartition (serveurs actif-actif) sur les
services fortement sollicités/exposés à la montée en
charge

27. Un design d'archi pour zéro limite
 Matériel
 De la mémoire à foison
 Des disques rapides si fortement sollicités le disque est
souvent un facteur limitant (souvent plus que le CPU)
 Un carte réseau par flux/réseau (idéalement)
 Réseau
 Dimensionner correctement les liens inter-serveurs
 Un réseau (Vlan) entre chaque couche
 Du matériel de commutation performant et adapté
 Vérifier les facteurs limitants (monitoring)

28. Développement guidé par la performance
Un PHP plus rapide

29. Un publication asynchrone...
… pour minimiser les ressources consommées
Front-office
 Pour les blocs les plus utilisés
P qui changent peu
Back-office u
static  Génération à la publication
s
h
Front  Sollicitation de la BDD à la
publication
PHP
 Diminution des requêtes à la
consultation
BDD
 Meilleur index du cache

30. Implémenter le cache à tous les niveaux...

31. Implémenter le cache à tous les niveaux...
 Diminuer le nombre de requêtes
 Diminuer la charge des serveurs MySQL
 Augmenter la vitesse de traitement
 Améliorer les temps de réponses
… mais aussi ...
 Répartir le cache entre les serveurs
 Implémenter le cache à chaque strat

32. Les principales strates
 Le navigateur est bon pour :
 Garder les images en cache
 Garder les css en cache
 Diminuer la charge des serveurs MySQL
 Augmenter la vitesse de traitement
 Améliorer les temps de réponses
… mais aussi ...
 Répartir le cache entre les serveurs
 Implémenter le cache à chaque strat

33. Attention...
 Lagestion de la pérennité de la donnée peut devenir
complexe
 Ne pas tout mettre en cache !
 Choisir d'après les règles suivantes :
 SQL : données utilisées souvent => garder l'index en
cache
 Objet : données utilisées souvent pré-calculées
 Page : données modifiées moins souvent

34. Développement Déploiement
Exploitation
Cycle de développement
guidé par la performance

35. Développem
ent Déploiement
Mise en place d'un processus de staging Exploitation
 Environnement développement pour les
développeurs
 Environnement de pré-production virtualisé pour chaque
développeur
 Validation par test unitaire
 Syndication par outil de versioning (SVN)
 Environnement de pré-production
 validation de la procédure de déploiement (faite par du
personnel accrédité)
 test en environnement semi-réel
 test de montée en charge sur (apache bench, pilot)
 Environnement de production
 Accès exclusif aux administrateurs

36. Développem
ent Déploiement
Les avantages Exploitation
 Limite les bourdes de mise en ligne
 Améliore la qualité des mises en production
 Rationalise le processus de mise en ligne
 Chapitre les mise en ligne

37. Développem
ent Déploiement
Automatiser le déploiement Exploitation
Pour :
 Diminuer le temps de mise en ligne
 Implémenter facilement la procédure de staging
 Limiter les erreurs de déploiement
 Diminuer les intervenants nécessaires pour la mise
en ligne
Notre choix :

38. Développem
ent Déploiement
Déploiement standard… Exploitation
… sur une architecture moyenne.
10 pages de procédure de
déploiement
Minimum 5 SSH
5 exports SVN manuels
11 modifications de fichiers de
conf
13 fichiers à faire attention de
ne pas effacer
7 cafés et une bonne dose de
stress
5 archives temporaires qui
trainent et polluent
Durée : 1 jour (avec les patchs des devs)
Ressources : dev + admin
Rollback Délicat

39. Développem
ent Déploiement
Déploiement avec capistrano… Exploitation
… sur une architecture moyenne.
2 jours pour écrire
la conf, tester et
qualifier
1 commande
Rollback en 10
secondes
Garbage collecting
sur les archives
Durée : 5 minutes
… pourquoi ne pas l’avoir fait plus
Ressources : admin tôt?
Rollback Délicat

40. Développem
ent Déploiement
Avoir une bonne visibilité de la production Exploitation
 Surveiller
 La qualité du service final
 Les services internes
 Le comportement des serveurs et des programmes
 Les ressources associées
 Choisir des seuils adaptés
 Être attentif
 A la consommation des ressources
 Aux comportements anormaux
 Analyser l’augmentation de trafic
 Réagir
 Toute anomalie ne reste pas impunie
 Chasse aux scripts / requêtes gourmands (slow queries, tracer, sniffer,
etc.)
 Lire son php_err. log (il doit rester vide)
 Bien évaluer la réponse : infrastructure, développement ou les deux

41. Développem
ent Déploiement
Urbaniser le développement Exploitation
 Versionning
 Refactoring // XP // finetuning sur la base des
retours d’exploitation
 Cycle dev, préproduction, prod
 valider fonctionnellement
 testing
 stress tester l’applicatif / montée en charge

42. On l'a fait! 
Une plate forme PHP scalable qui tient la charge et facile à déployer
(quelque soit le nombre de serveurs) !

43. Merci!
Des questions?