Mise à l'échelle du matériel du site Web
https://stackoverflow.com/questions/36534
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
J'écoutais donc le dernier podcast Stackoverflow (épisode 19), et Jeff et Joel ont parlé un peu de la mise à l'échelle du matériel serveur à mesure qu'un site Web se développe.D’après ce que disait Joel, les premières étapes sont assez classiques :
- Un serveur exécutant à la fois le serveur Web et la base de données (la configuration actuelle de Stackoverflow)
- Un serveur Web et un serveur de base de données
- Deux serveurs Web à charge équilibrée et un serveur de base de données
Cependant, ils n’ont pas beaucoup parlé de ce qui allait suivre.Ajoutez-vous plus de serveurs Web ?Un autre serveur de base de données ?Répliquer ce cluster de trois machines dans un autre centre de données à des fins de redondance ?Où va une startup Web à partir d’ici dans le département matériel ?
La solution
Une configuration raisonnable prenant en charge une application Web « moyenne » pourrait évoluer comme suit :
- Serveur unique combiné application/base de données
- Base de données séparée sur une autre machine
- Deuxième serveur d'applications avec DNS round-robin (équilibrage de charge du pauvre) ou, par ex. Perlbal
- Deuxièmement, un serveur de base de données répliqué (pour les charges de lecture, nécessite certaines modifications de la logique de l'application afin que les lectures de base de données éligibles soient transférées vers un esclave)
À ce stade, évaluer l’état actuel des choses permettrait de déterminer une meilleure voie de mise à l’échelle.Par exemple, si la charge de lecture est élevée et que le contenu ne change pas trop souvent, il serait peut-être préférable de mettre l'accent sur la mise en cache et d'introduire des caches frontaux dédiés, par ex. Calmar pour éviter les lectures inutiles de la base de données, même si vous devrez réfléchir à la manière de maintenir cohérence du cache, généralement dans l'application.
En revanche, si le contenu change assez souvent, vous préférerez probablement une solution plus étalée ;introduisez quelques serveurs d'applications et esclaves de base de données supplémentaires pour aider à atténuer les effets, et utilisez la mise en cache d'objets, tels que memcaché pour éviter d'accéder à la base de données pour le contenu le moins volatil.
Pour la plupart des sites, cela est probablement suffisant, mais si vous devenez un phénomène mondial, vous souhaiterez probablement commencer à envisager d'installer du matériel dans des centres de données régionaux et à utiliser des astuces telles que l'équilibrage de charge géographique pour diriger les visiteurs vers le « cluster » le plus proche. ".À ce stade, vous serez probablement en mesure d’embaucher des ingénieurs capables de vraiment peaufiner les choses.
Le conseil de mise à l’échelle le plus précieux auquel je puisse penser serait probablement d’éviter de s’en soucier trop tôt ;concentrez-vous sur le développement d'un service que les gens voudront utiliser et sur la création d'une application raisonnablement robuste.Certaines premières optimisations simples consistent à vous assurer que la conception de votre base de données est assez solide et que les index sont configurés de manière à ce que vous ne fassiez rien de douloureusement fou ;assurez-vous également que l'application émet des en-têtes de contrôle de cache qui indiquent aux navigateurs comment mettre les données en cache.Effectuer ce type de travail dès le début de la conception peut apporter des avantages plus tard, en particulier lorsque vous n'avez pas besoin de tout retravailler pour résoudre les problèmes de cohérence du cache.
Le deuxième conseil le plus précieux que je souhaite vous donner est que vous ne devez pas présumer que ce qui fonctionne sur un autre site Web fonctionnera pour vous ;vérifiez vos journaux, effectuez des analyses de votre trafic et profilez votre application - voyez où se trouvent vos goulots d'étranglement et résolvez-les.
Autres conseils
quelques vidéos intéressantes :
Joel a mentionné l'ajout d'un deuxième centre de données, avec la même configuration, puis l'attribution aléatoire de vos utilisateurs à chacun.Les modifications apportées aux données sont enregistrées et envoyées d'un emplacement à l'autre, de sorte que les deux emplacements contiennent toutes les données.
La conférence Scalable Web Architectures Common Patterns & Approaches de Cal Henderson (Yahoo) sur Web 2.0 Expo était assez intéressante.Je pensais qu'il y avait une vidéo, mais je ne l'ai pas trouvée.Mais voici les slides :
http://www.slideshare.net/techdude/scalable-web-architectures-common-patterns-and-approaches
Une prochaine étape certaine serait un cluster de serveurs Web (une ferme Web) et un système en cluster de serveurs de bases de données (réplication ou Oracle RAC, etc.etc.)
Si vous êtes intéressé par la mise en cache et l'utilisation de .Net, consultez le bloc de mise en cache des applications dans la bibliothèque d'entreprise (bien sûr, utilisez-le avec les autres points ci-dessus).
