Accueil › Les 7 phases du cycle de vie d'un site Web

Les 7 phases du cycle de vie d'un site Web

Soumis par Sylvain Lasnier le 07/08/2009 , modifié le 04/01/2011
in
Test de charge avec httperf

No brain, lot of Pain

John Engates, CTO de Rackspace, a fait une présentation intéressante sur l'évolution dans le temps des infrastructures de sites Web à succès.

Je trouve son exposé est très réaliste.

Les objectifs

Le site Internet idéal doit :

  • être évolutif pour tenir la montée en charge, scalability en anglais
  • être hautement disponible, 24/7
  • être administrable
  • être économique
  • permettre des services riches
  • générer du cash

Les rumeurs populaires.

Je clarifie une confusion classique.
La performance d'un site représente sa vitesse d'exécution.
La scalability ou extensibilité d'un site représente le nombre d'actions qu'il peut traiter simultanément. C'est le besoin d'un site Internet à forte audience.

Un serveur n'est pas évolutif grace à sa CPU, à son OS, au langage de développement, la taille du code ou encore au support de stockage. Ces éléments impactent la performance.
La extensibilité n'est qu'un problème d'architecture :

  • le site ne tiendra pas s'il n'a pas été pensé pour tenir la montée en charge
  • même s'il a été prévu pour monter en charge, vous allez souffrir

Les 7 phases d'un site Web

  1. Le démarrage :

    • Un firewall, un serveur Web, un système de fichier, une base de données
    • Architecture simple, rapide et économique

  2. L'audience arrive :

    • Ajout de load-balancer et redondance des serveurs Web et de la base de données
    • L'évolution reste simple mais la tolérance au panne est faible

  3. L'audience augmente, le site est maintenant lancé et le ROI est suivi

    • Ajout de proxy pour les contenus statiques, augmentation de la redondance des firewall, serveur Web et base de données, séparation des accès en lecture seule et en lecture écriture à la base de données
    • Début des souffrances. Une partie de l'application doit être ré-écrite.

  4. L'audience augmente toujours et l'ajout de serveurs ne résout plus le problème

    • Ajout de système de cache mémoire de données, avec memcached, segmentation des bases de données par fonction, utilisation de serveurs SAN pour le stockage
    • La structure de la base de données et de l'application est impactée de plein fouet. Il faut ré-écrire. A ce niveau, la majorité des SSII qui confondent Intranet/Extranet et site Internet échoue. Les problèmes des média online à forte audience ne font pas partis de la culture des informaticiens traditionnels.

  5. Les limites des solutions techniques sont atteintes. L'architecture apparait indiscutablement non pensée pour être évolutive.

    • Définir une architecture scalable et reconstruire totalement le site, géolocaliser et partitionner les données, cloisonner les fonctions, associer les utilisateurs à des fermes dédiées
    • Les SSII précités vous ont abandonné. Vous souffrez seul. Quelques années.homme seront nécessaire pour parvenir à l'étape 6.

  6. Le bout du tunnel

    • L'application et les bases sont maintenant pensées pour être évolutives. Les performances sont correctes. Il est temps d'ajouter de nouvelles fonctions et d'optimiser le code et les pages.
    • L'architecture est nettement plus complexe mais reste administrable si elle est bien documentée

  7. Bienvenue chez les pros ;)

    • Maintenant que les fondations sont en place, il est temps d'optimiser les serveurs, d'utiliser un CDN comme Akamai, de résoudre les bottleneck, de remettre en cause le choix de la base de données, de penser salle blanche...

Bonnes pratiques

  • Règle d'or : faites simple

    Everything should be made as simple as possible. But not simpler.
    Albert Einstein

  • Pensez horizontal et non vertical sur tous les sujets
    Combien ? versus A quelle vitesse ?

  • Utilisez la totalité de la capacité de vos infrastructures
    Les solutions de cloud-computing marquent des points sur ce sujet.

  • Permettre une haute traçabilité du fonctionnement de votre site

    • fichier de log lisibles et accessibles simplement en temps réel
    • Services fonctionnels isolés
    • Changer une chose à la fois

  • Optimisez peu mais souvent

  • Faites des tests de charges réalistes

  • Vérifiez l'impact sur les performances et la montée en charge pour chaque ajout de fonction

  • Utilisez des serveurs professionnels : architecture 64 bits avec beaucoup de mémoire, disques rapides

  • Enfin, pour vous évitez d'avoir souffert pour rien, accompagnez le changement : documentez, communiquez, organisez les demandes, conservez un historique vos développements