5 configurations de serveur communes pour votre application Web

Introduction

Lors du choix de l'architecture de serveur à utiliser pour votre environnement, de nombreux facteurs doivent être pris en compte, tels que les performances, l'évolutivité, la disponibilité, la fiabilité, le coût et la facilité de gestion.

Voici une liste des configurations de serveur couramment utilisées, avec une brève description de chacune, y compris les avantages et les inconvénients. Gardez à l'esprit que tous les concepts abordés ici peuvent être utilisés dans diverses combinaisons les uns avec les autres, et que chaque environnement a des exigences différentes, il n'y a donc pas de configuration unique et correcte.

1. Tout sur un seul serveur

L'ensemble de l'environnement réside sur un seul serveur. Pour une application Web typique, cela inclurait le serveur Web, le serveur d'applications et le serveur de base de données. Une variante courante de cette configuration est une pile LAMP, qui signifie Linux, Apache, MySQL et PHP, sur un seul serveur.

Cas d'utilisation : idéal pour configurer rapidement une application, car il s'agit de la configuration la plus simple possible, mais elle offre peu d'évolutivité et d'isolation des composants.

Avantages :

Simple

Inconvénients :

L'application et la base de données se disputent les mêmes ressources de serveur (processeur, mémoire, E/S, etc.), ce qui, outre d'éventuelles performances médiocres, peut rendre difficile la détermination de la source (application ou base de données) des performances médiocres.
Pas facilement évolutif horizontalement

Tutoriels associés :

Comment installer LAMP sur Ubuntu 14.04

2. Serveur de base de données séparé

Le système de gestion de base de données (SGBD) peut être séparé du reste de l'environnement pour éliminer les conflits de ressources entre l'application et la base de données, et pour augmenter la sécurité en supprimant la base de données de la DMZ ou de l'Internet public.

Cas d'utilisation : bon pour configurer rapidement une application, mais empêche l'application et la base de données de se disputer les mêmes ressources système.

Avantages :

Les niveaux application et base de données ne se disputent pas les mêmes ressources serveur (processeur, mémoire, E/S, etc.)
Vous pouvez mettre à l'échelle verticalement chaque niveau séparément, en ajoutant plus de ressources au serveur qui a besoin d'une capacité accrue
Selon votre configuration, cela peut augmenter la sécurité en supprimant votre base de données de la DMZ

Inconvénients :

Configuration légèrement plus complexe qu'un serveur unique
Des problèmes de performances peuvent survenir si la connexion réseau entre les deux serveurs présente une latence élevée (c'est-à-dire les serveurs sont géographiquement éloignés les uns des autres), ou la bande passante est trop faible pour la quantité de données transférées

Tutoriels associés :

3. Équilibreur de charge (proxy inverse)

Des équilibreurs de charge peuvent être ajoutés à un environnement de serveur pour améliorer les performances et la fiabilité en répartissant la charge de travail sur plusieurs serveurs. Si l'un des serveurs dont la charge est équilibrée tombe en panne, les autres serveurs gèrent le trafic entrant jusqu'à ce que le serveur défaillant redevienne sain. Il peut également être utilisé pour servir plusieurs applications via le même domaine et le même port, en utilisant un proxy inverse de couche 7 (couche application).

Exemples de logiciels capables d'équilibrer la charge du proxy inverse : HAProxy, Nginx et Varnish.

Cas d'utilisation : Utile dans un environnement qui nécessite une mise à l'échelle en ajoutant plus de serveurs, également appelée mise à l'échelle horizontale.

Avantages :

Active la mise à l'échelle horizontale, c'est-à-dire la capacité de l'environnement peut être mise à l'échelle en y ajoutant plus de serveurs
Peut protéger contre les attaques DDOS en limitant les connexions client à une quantité et une fréquence raisonnables

Inconvénients :

L'équilibreur de charge peut devenir un goulot d'étranglement des performances s'il ne dispose pas de suffisamment de ressources ou s'il est mal configuré.
Peut introduire des complexités qui nécessitent une attention supplémentaire, telles que l'endroit où effectuer la terminaison SSL et la façon de gérer les applications qui nécessitent des sessions permanentes
L'équilibreur de charge est un point de défaillance unique ; s'il tombe en panne, tout votre service peut tomber en panne. Une configuration haute disponibilité (HA) est une infrastructure sans point de défaillance unique. Pour savoir comment implémenter une configuration HA, vous pouvez lire cette section de Comment utiliser les IP flottantes.

Tutoriels associés :

4. Accélérateur HTTP (Caching Reverse Proxy)

Un accélérateur HTTP, ou proxy inverse HTTP de mise en cache, peut être utilisé pour réduire le temps nécessaire pour fournir du contenu à un utilisateur grâce à diverses techniques. La principale technique utilisée avec un accélérateur HTTP consiste à mettre en cache les réponses d'un serveur Web ou d'applications en mémoire, afin que les demandes futures pour le même contenu puissent être traitées rapidement, avec moins d'interactions inutiles avec les serveurs Web ou d'applications.

Exemples de logiciels capables d'accélérer HTTP : Varnish, Squid, Nginx.

Cas d'utilisation : utile dans un environnement avec des applications Web dynamiques à fort contenu ou avec de nombreux fichiers couramment consultés.

Avantages :

Augmentez les performances du site en réduisant la charge du processeur sur le serveur Web, grâce à la mise en cache et à la compression, augmentant ainsi la capacité des utilisateurs
Peut être utilisé comme équilibreur de charge proxy inverse
Certains logiciels de mise en cache peuvent protéger contre les attaques DDOS

Inconvénients :

Nécessite un réglage pour en tirer les meilleures performances
Si le taux d'accès au cache est faible, cela peut réduire les performances

Tutoriels associés :

5. Réplication de la base de données du réplica principal

Une façon d'améliorer les performances d'un système de base de données qui effectue de nombreuses lectures par rapport aux écritures, comme un CMS, consiste à utiliser la réplication de base de données du réplica principal. La réplication nécessite un nœud principal et un ou plusieurs nœuds de réplique. Dans cette configuration, toutes les mises à jour sont envoyées au nœud principal et les lectures peuvent être réparties sur tous les nœuds.

Cas d'utilisation : Bon pour augmenter les performances de lecture pour le niveau base de données d'une application.

Voici un exemple de configuration de réplication de réplica principal, avec un seul nœud de réplica :

Avantages :

Améliore les performances de lecture de la base de données en répartissant les lectures sur les répliques
Peut améliorer les performances d'écriture en utilisant le primaire exclusivement pour les mises à jour (il ne passe pas de temps à servir les demandes de lecture)

Inconvénients :

L'application accédant à la base de données doit disposer d'un mécanisme pour déterminer à quels nœuds de base de données elle doit envoyer des demandes de mise à jour et de lecture.
Les mises à jour des répliques sont asynchrones, il est donc possible que leur contenu soit obsolète
Si le primaire échoue, aucune mise à jour ne peut être effectuée sur la base de données tant que le problème n'est pas corrigé
N'a pas de basculement intégré en cas de panne du nœud principal

Tutoriels associés :

Comment optimiser les performances de WordPress avec la réplication MySQL sur Ubuntu 14.04

Exemple : Combinaison des concepts

Il est possible d'équilibrer la charge des serveurs de mise en cache, en plus des serveurs d'application, et d'utiliser la réplication de base de données dans un environnement unique. Le but de combiner ces techniques est de récolter les bénéfices de chacune sans introduire trop de problèmes ou de complexité. Voici un exemple de diagramme de ce à quoi pourrait ressembler un environnement de serveur :

Supposons que l'équilibreur de charge est configuré pour reconnaître les requêtes statiques (comme les images, css, javascript, etc.) et envoyer ces requêtes directement aux serveurs de mise en cache, et envoyer d'autres requêtes aux serveurs d'application.

Voici une description de ce qui se passerait lorsqu'un utilisateur enverrait une demande de contenu dynamique :

L'utilisateur demande du contenu dynamique à http://example.com/ (équilibreur de charge)
L'équilibreur de charge envoie une demande à app-backend
app-backend lit à partir de la base de données et renvoie le contenu demandé à l'équilibreur de charge
L'équilibreur de charge renvoie les données demandées à l'utilisateur

Si l'utilisateur demande du contenu statique :

L'équilibreur de charge vérifie le cache-backend pour voir si le contenu demandé est mis en cache (cache-hit) ou non (cache-miss)
If cache-hit : renvoyez le contenu demandé à l'équilibreur de charge et passez à l'étape 7. Si cache-miss : le serveur de cache transmet la demande à l'app-backend, via l'équilibreur de charge
L'équilibreur de charge transmet la demande à l'app-backend
app-backend lit à partir de la base de données, puis renvoie le contenu demandé à l'équilibreur de charge
L'équilibreur de charge transmet la réponse à cache-backend
cache-backend met en cache le contenu puis le renvoie à l'équilibreur de charge
L'équilibreur de charge renvoie les données demandées à l'utilisateur

Cet environnement présente toujours deux points de défaillance uniques (équilibreur de charge et serveur de base de données principal), mais il offre tous les autres avantages en matière de fiabilité et de performances décrits dans chaque section ci-dessus.

Conclusion

Maintenant que vous êtes familiarisé avec certaines configurations de serveur de base, vous devriez avoir une bonne idée du type de configuration que vous utiliseriez pour vos propres applications. Si vous travaillez à l'amélioration de votre propre environnement, n'oubliez pas qu'un processus itératif est préférable pour éviter d'introduire trop de complexités trop rapidement.

Faites-nous part des configurations que vous recommandez ou souhaitez en savoir plus dans les commentaires ci-dessous !