Conférence AFUP 20minutes.Fr

741 views
669 views

Published on

Support de la conférence AFUP du 8 décembre 2008 sur le retour d'expérience de 20minutes.fr et Oxalide du site 20minutes.fr.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
741
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • NS
  • Conférence AFUP 20minutes.Fr

    1. 1. 20minutes.fr <ul><li>retour sur expérience </li></ul>
    2. 2. Qui sommes nous? <ul><li>Nicolas Silberman </li></ul><ul><li>Sébastien Lucas </li></ul><ul><li>Responsable technique new media 20minutes.fr </li></ul><ul><li>[email_address] </li></ul><ul><li> </li></ul><ul><li>Directeur associé Oxalide.com </li></ul><ul><li>[email_address] </li></ul><ul><li> </li></ul>
    3. 3. Oxalide <ul><li>Conseil, infogérance & hébergement </li></ul><ul><li>Gestion d’infrastructures dites « Critiques » </li></ul><ul><li>Conception et gestion d’infrastructures sur-mesure </li></ul><ul><li>Délégation de la production </li></ul><ul><li>Hébergement de proximité : équipe projet dédié </li></ul>
    4. 4. 20minutes.fr
    5. 5. Le succès d’une nouvelle formule +149% Croissance annuelle VU MNR Visiteurs uniques MNR Septembre 2008 SOURCES : VU MEDIAMETRIE // NETRATINGS Septembre 2008 VU NIELSEN NETRATINGS HOME & WORKSeptembre 2007
    6. 6. Une place dans le TOP 3 3 560 000 3° 3 560 000 Visiteurs Uniques qui viennent souvent et restent longtemps Site de presse en France 3° SOURCE : VU MEDIAMETRIE // NETRATINGS Septembre 2008 (Uniquement sites de Presse)
    7. 7. Un site qui rend accroc Pages vues par visiteur Temps passé par visiteur SOURCE : MEDIAMETRIE // NETRATINGS Septembre 2008 Uniquement sites de presse * XITI Septembre 2008
    8. 8. <ul><li>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)... </li></ul>
    9. 9. Site mobile d’info 3° Hors portails opérateurs Une rentrée encourageante : croissance mois sur mois (+30%) Performance sur le mobile SOURCES : Médiamétrie - Les Mobinautes - Mars Avril 2008 Échantillon : 3 000 individus
    10. 10. 20minutes.fr – contraintes <ul><li>0% de downtime et donc 100% available </li></ul><ul><li>Toujours penser/prévoir l’effet « 11 Septembre » </li></ul><ul><li>Publication instantanée qui respecte les contraintes de publication de la rédaction </li></ul><ul><li>Information déstructurée : mix des sources d’information </li></ul><ul><li>Une marque de fabrique un homepage reprise sur chaque page </li></ul>
    11. 11. 20minutes.fr - objectifs <ul><li>Lancer et instaurer une homepage énorme </li></ul><ul><ul><ul><ul><li>300 Requêtes HTTP </li></ul></ul></ul></ul><ul><ul><ul><ul><li>2 Mo </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Index de 60KB (originellement 300 KB) </li></ul></ul></ul></ul><ul><li>Une reprise de cette lourde homepage sur chaque article </li></ul><ul><li>Une actu chaude 24/7 </li></ul><ul><li>Beaucoup beaucoup d’images </li></ul><ul><li>Un média communautaire & participatif : Motiver le User Generated Content </li></ul>
    12. 12. Un ADN open source
    13. 13. Pourquoi PHP? <ul><li>Accessible (on trouve codeurs et prestataires) </li></ul><ul><li>Communauté active (française!!!) </li></ul><ul><li>Documentation fournie // mailing list active </li></ul><ul><li>Les gens partagent... </li></ul><ul><li>Il a fait ses preuves </li></ul><ul><li>La roadmap PHP donne confiance </li></ul><ul><li>... </li></ul>05/12/08
    14. 14. Avant… 161 000 visiteurs uniques 2 Mbps de bande passante 4 sources de contenus 72 000 inscrits à la newsletter 1 tech - 3 journalistes 50 000 articles 3 000 images 5 jours sur 7 1 serveur
    15. 15. Aujourd’hui 900 Mbps de bande passante 11 sources de contenus 5 tech - 25 journalistes 300 000 articles 2 000 000 images 1 500 000 commentaires 7 jours sur 7 24h / 24 30 serveurs projets satellites (5 000 blogs, TOP-listes) 3 560 000 visiteurs uniques 500 000 inscrits à la newsletter
    16. 16. Evolution <ul><li>200 articles / jour </li></ul><ul><li>3 500 commentaires par jour </li></ul><ul><li>plus de 100 pages vues à la seconde </li></ul><ul><li>plus de 5 000 requêtes http à la seconde </li></ul><ul><li>des prévisions de croissance d’audience encore fortes à l’avenir </li></ul>
    17. 17. Développer et gérer la croissance Développement de nouvelles fonctionnalités Rationalisation et gestion du trafic indice
    18. 18. L’infrastructure du sur mesure…
    19. 19. Une infra qui épouse l’applicatif... <ul><li>Cloisonner et Optimiser les flux internes </li></ul><ul><li>Éviter les goulets d’étranglement </li></ul><ul><li>Fine tuner la partie réseau </li></ul><ul><li>Construire des piles applicatives redondées </li></ul>… et pas l’inverse
    20. 20. Séparer média et applicatif... <ul><li>Améliorer la flexibilité sur la scalabilité </li></ul><ul><ul><li>Les processus du serveur web qui servent les pages n'interfèrent pas avec ceux qui servent les images </li></ul></ul><ul><ul><li>Vis-versa </li></ul></ul><ul><li>Optimiser le socle technique en fonction des contenus </li></ul><ul><ul><li>Configuration spécifiques des serveurs </li></ul></ul><ul><ul><ul><li>Serveur web moins gourmands pour les médias (aucun module chargé qui ne soit utilisé) </li></ul></ul></ul><ul><ul><ul><li>Pool de processus plus important </li></ul></ul></ul><ul><li>Cloisonner les risques </li></ul>… pour
    21. 21. … voire même par projet <ul><li>Conserver le cœur de métier sur une infrastructure propre </li></ul><ul><li>Héberger les sites satellites (sur lesquels on ne maîtrise pas forcément la qualité) sur une infrastructure dédiée à cet effet </li></ul><ul><li>Externaliser certains services spécialisés (vidéos, mailing, blogs, etc.) </li></ul>
    22. 22. Ne pas faire confiance aux sources tiers présentes dans le core <ul><li>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.) </li></ul><ul><li>La perception de l'utilisateur sera celle du plus faible maillon de la chaine des éléments qui constituent votre page. </li></ul>
    23. 23. Solution : débrayer les sources tiers <ul><li>Rapatrier en asynchrone et héberger le contenu </li></ul><ul><li>Gérer le chargement du contenu côté client pour minimiser l'impact du chargement (ou pas) sur la page (implémentation javascript). </li></ul>
    24. 24. Rester souple et dispo
    25. 25. LVS pour un équilibrage transparent <ul><li>Invisible pour l’internaute </li></ul><ul><li>Aucun changement pour le serveur </li></ul><ul><li>Prise en charge pour chaque serveur de 1/n du trafic global (n = nb de serveurs actifs) </li></ul><ul><li>Répartition parfaite (round robin) </li></ul><ul><li>Possibilité de sticky </li></ul><ul><li>Applicable pour chaque service (pas uniquement web aussi service interne) </li></ul>LVS (actif) LVS (passif) IP virtuelle Serveur Equilibrage Round robin Serveur Serveur Serveur Trafic entrant
    26. 26. <ul><li>Séparation par couche : un groupe de serveurs par rôle applicatif pour </li></ul><ul><ul><li>injecter la scalabilité et haute disponibilité à chaque couche </li></ul></ul><ul><ul><li>limiter les goulets d'étranglement et augmenter la capacité </li></ul></ul><ul><li>Plusieurs serveurs pour 1 service (LVS / IP Virtuelle) </li></ul><ul><ul><li>Incident sans impact pour l'internaute </li></ul></ul><ul><ul><li>Mise à jour ou tâche de maintenance invisible </li></ul></ul><ul><li>Privilégier la répartition (serveurs actif-actif) sur les services fortement sollicités/exposés à la montée en charge </li></ul>Archi scalable et haute-dispo
    27. 27. Un design d'archi pour zéro limite <ul><li>Matériel </li></ul><ul><ul><li>De la mémoire à foison </li></ul></ul><ul><ul><li>Des disques rapides si fortement sollicités le disque est souvent un facteur limitant (souvent plus que le CPU) </li></ul></ul><ul><ul><li>Un carte réseau par flux/réseau (idéalement) </li></ul></ul><ul><li>Réseau </li></ul><ul><ul><li>Dimensionner correctement les liens inter-serveurs </li></ul></ul><ul><ul><li>Un réseau (Vlan) entre chaque couche </li></ul></ul><ul><ul><li>Du matériel de commutation performant et adapté </li></ul></ul><ul><ul><li>Vérifier les facteurs limitants (monitoring) </li></ul></ul>
    28. 28. Développement guidé par la performance Un PHP plus rapide
    29. 29. Un publication asynchrone... <ul><li>Front-office </li></ul>Front PHP BDD static P u s h <ul><li>Pour les blocs les plus utilisés qui changent peu </li></ul><ul><li>Génération à la publication </li></ul><ul><li>Sollicitation de la BDD à la publication </li></ul><ul><li>Diminution des requêtes à la consultation </li></ul><ul><li>Meilleur index du cache </li></ul>Back-office … pour minimiser les ressources consommées
    30. 30. Implémenter le cache à tous les niveaux...
    31. 31. Implémenter le cache à tous les niveaux... <ul><li>Diminuer le nombre de requêtes </li></ul><ul><li>Diminuer la charge des serveurs MySQL </li></ul><ul><li>Augmenter la vitesse de traitement </li></ul><ul><li>Améliorer les temps de réponses </li></ul><ul><li>… mais aussi ... </li></ul><ul><li>Répartir le cache entre les serveurs </li></ul><ul><li>Implémenter le cache à chaque strat </li></ul>
    32. 32. Les principales strates <ul><li>Le navigateur est bon pour : </li></ul><ul><ul><li>Garder les images en cache </li></ul></ul><ul><ul><li>Garder les css en cache </li></ul></ul><ul><li>Diminuer la charge des serveurs MySQL </li></ul><ul><li>Augmenter la vitesse de traitement </li></ul><ul><li>Améliorer les temps de réponses </li></ul><ul><li>… mais aussi ... </li></ul><ul><li>Répartir le cache entre les serveurs </li></ul><ul><li>Implémenter le cache à chaque strat </li></ul>
    33. 33. Attention... <ul><li>La gestion de la pérennité de la donnée peut devenir complexe </li></ul><ul><li>Ne pas tout mettre en cache ! </li></ul><ul><li>Choisir d'après les règles suivantes : </li></ul><ul><ul><li>SQL : données utilisées souvent => garder l'index en cache </li></ul></ul><ul><ul><li>Objet : données utilisées souvent pré-calculées </li></ul></ul><ul><ul><li>Page : données modifiées moins souvent </li></ul></ul>
    34. 34. Cycle de développement guidé par la performance
    35. 35. Mise en place d'un processus de staging <ul><li>Environnement développement pour les développeurs </li></ul><ul><ul><ul><li>Environnement de pré-production virtualisé pour chaque développeur </li></ul></ul></ul><ul><ul><ul><li>Validation par test unitaire </li></ul></ul></ul><ul><ul><ul><li>Syndication par outil de versioning (SVN) </li></ul></ul></ul><ul><li>Environnement de pré-production </li></ul><ul><ul><ul><li>validation de la procédure de déploiement (faite par du personnel accrédité) </li></ul></ul></ul><ul><ul><ul><li>test en environnement semi-réel </li></ul></ul></ul><ul><ul><ul><li>test de montée en charge sur (apache bench, pilot) </li></ul></ul></ul><ul><li>Environnement de production </li></ul><ul><ul><ul><li>Accès exclusif aux administrateurs </li></ul></ul></ul>
    36. 36. Les avantages <ul><li>Limite les bourdes de mise en ligne </li></ul><ul><li>Améliore la qualité des mises en production </li></ul><ul><li>Rationalise le processus de mise en ligne </li></ul><ul><li>Chapitre les mise en ligne </li></ul>
    37. 37. Automatiser le déploiement <ul><li>Pour : </li></ul><ul><li>Diminuer le temps de mise en ligne </li></ul><ul><li>Implémenter facilement la procédure de staging </li></ul><ul><li>Limiter les erreurs de déploiement </li></ul><ul><li>Diminuer les intervenants nécessaires pour la mise en ligne </li></ul>Notre choix :
    38. 38. Déploiement standard… 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 … sur une architecture moyenne. Durée : 1 jour (avec les patchs des devs) Ressources : dev + admin Rollback Délicat
    39. 39. Déploiement avec capistrano… … sur une architecture moyenne. Rollback Délicat 2 jours pour écrire la conf, tester et qualifier 1 commande Rollback en 10 secondes Garbage collecting sur les archives Durée : 5 minutes Ressources : admin … pourquoi ne pas l’avoir fait plus tôt?
    40. 40. Avoir une bonne visibilité de la production <ul><li>Surveiller </li></ul><ul><ul><li>La qualité du service final </li></ul></ul><ul><ul><li>Les services internes </li></ul></ul><ul><ul><li>Le comportement des serveurs et des programmes </li></ul></ul><ul><ul><li>Les ressources associées </li></ul></ul><ul><ul><li>Choisir des seuils adaptés </li></ul></ul><ul><li>Être attentif </li></ul><ul><ul><li>A la consommation des ressources </li></ul></ul><ul><ul><li>Aux comportements anormaux </li></ul></ul><ul><ul><li>Analyser l’augmentation de trafic </li></ul></ul><ul><li>Réagir </li></ul><ul><ul><li>Toute anomalie ne reste pas impunie </li></ul></ul><ul><ul><li>Chasse aux scripts / requêtes gourmands (slow queries, tracer, sniffer, etc.) </li></ul></ul><ul><ul><li>Lire son php_err. log (il doit rester vide) </li></ul></ul><ul><ul><li>Bien évaluer la réponse : infrastructure, développement ou les deux </li></ul></ul>
    41. 41. Urbaniser le développement <ul><li>Versionning </li></ul><ul><li>Refactoring // XP // finetuning sur la base des retours d’exploitation </li></ul><ul><li>Cycle dev, préproduction, prod </li></ul><ul><ul><li>valider fonctionnellement </li></ul></ul><ul><ul><li>testing </li></ul></ul><ul><ul><li>stress tester l’applicatif / montée en charge </li></ul></ul>
    42. 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. 43. Merci! Des questions?

    ×