Configuration de votre application : comment choisir la meilleure configuration de serveur ?

Introduction

La technologie et l'internet sont devenus des présences centrales dans nos vies quotidiennes, académiques et professionnelles. C'est pourquoi le nombre impressionnant de sites web et d'applications qui coexistent ne surprend pas. Si vous êtes une entreprise, vous souhaiteriez disposer d'une plateforme web associée. Une application vous permet de commercialiser et de fournir facilement vos services à vos clients cibles.

Quelle que soit la raison pour laquelle vous créez une application web, vous devez déterminer comment la construire. De nombreuses options s'offrent à vous lorsqu'il s'agit de choisir la meilleure configuration de serveur. L'architecture de serveur pour laquelle vous optez déterminera la manière dont vous exécutez et gérez tout dans votre environnement. C'est pourquoi cette décision doit être prise après mûre réflexion.

Comment choisir la bonne configuration de serveur

Alors, comment décider quelle architecture est la « bonne » pour votre application ? Pour ce faire, vous devez d'abord réfléchir aux exigences de votre application web. Il doit y avoir certaines fonctionnalités que vous devez intégrer pour qu'elle fonctionne efficacement pour votre cas d'utilisation spécifique. Por exemple, vous recherchez peut-être une application facile à mettre à l'échelle. Ou peut-être avez-vous besoin que votre application fonctionne de manière fluide sur les navigateurs ainsi que sur les appareils mobiles. En même temps, votre budget peut également être votre principale préoccupation.

Quelles que soient vos exigences, sachez que vous pouvez créer une solution personnalisée pour votre application. Dans ce tutoriel, nous explorerons les différents types de serveurs que de nombreuses personnes utilisent couramment pour leurs applications web. Nous aborderons les différents cas d'utilisation et les moments où une configuration particulière est la plus appropriée. Pour vous aider à décider si elle vous convient, nous vous présenterons également les avantages et les inconvénients de chaque architecture de serveur.

1. Tout sur un seul serveur

Comme son nom l'indique, vous chargez l'intégralité de l'environnement sur un seul et unique serveur. L'environnement comprendrait votre serveur web, votre serveur d'application, ainsi que le serveur de base de données. Par exemple, cela fonctionne sur la configuration de pile Linux, Apache, MySQL, et PHP (LAMP). Vous pouvez suivre nos tutoriels sur la façon d'installer la pile LAMP sur un serveur Ubuntu et sur la façon d'installer la pile LAMP sur CentOS.

Quand l'utiliser :

Ce type de configuration fonctionne le mieux si vous manquez de temps. Il est simple et rapide à mettre en place. C'est pourquoi il convient aux applications web simples.

Avantages :

• Simple et facile à comprendre et à mettre en œuvre.
• Prend peu de temps à configurer dans son intégralité.

Inconvénients :

• Ne permet pas l'évolutivité horizontale.
• Offre très peu en termes d'isolation des composants.
• L'application et la base de données sont essentiellement en concurrence pour les mêmes ressources puisqu'elles se trouvent sur un seul serveur.
• Par conséquent, vous risquez de rencontrer des performances médiocres.

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

Le principal problème lié à l'utilisation d'un serveur unique est la concurrence pour des ressources limitées. Cette configuration vise à résoudre ce problème. Ici, le système de gestion de base de données, ou SGBD, est séparé du serveur d'application. Le serveur de base de données se trouve dans un réseau privé et dispose de ses propres ressources. Cela se traduit par de meilleures performances et une sécurité accrue.

Quand l'utiliser :

Là encore, si vous souhaitez déployer une configuration rapide, celle-ci est assez simple à configurer. C'est la solution idéale si vous craignez que la base de données et l'application ne se disputent les mêmes ressources.

Avantages :

• Des ressources système distinctes et dédiées pour l'application et la base de données, y compris le processeur, la mémoire, les E/S, etc.
• Plus de potentiel d'évolutivité dans les niveaux de l'application ou de la base de données.
• Vous pouvez ajouter et supprimer des ressources selon vos besoins.
• Si vous retirez la base de données de l'internet public, vous pouvez également renforcer votre sécurité.

Inconvénients :

• Un peu plus complexe qu'une configuration à serveur unique.
• Une faible bande passante ou une latence réseau élevée entre les deux serveurs peut entraîner des problèmes de performances.

3. Proxy inverse ou répartiteur de charge

C'est là que les répartiteurs de charge entrent en jeu. Les répartiteurs de charge sont généralement utilisés dans les environnements de serveurs pour améliorer les performances et la fiabilité. Ils y parviennent en « répartissant la charge », c'est-à-dire en distribuant la charge de travail sur un ensemble de serveurs.

Quand l'utiliser :

Les répartiteurs de charge sont extrêmement utiles lorsque vous devez effectuer une mise à l'échelle horizontale. La mise à l'échelle horizontale consiste essentiellement à ajouter des serveurs supplémentaires à l'environnement. Vous pouvez également utiliser un proxy inverse de couche applicative pour servir plusieurs applications à la fois en utilisant un seul domaine et un seul port. HAProxy, Nginx, et Varnish sont des exemples de logiciels qui permettent la répartition de charge par proxy inverse.

Avantages :

• En cas de panne d'un serveur de la chaîne, les autres serveurs compensent sa fonction en répartissant la charge de travail.
• Permet d'effectuer une mise à l'échelle horizontale pour augmenter ou diminuer la capacité de l'environnement.
• Il limite également les connexions clients, ce qui offre une protection contre les attaques DDOS.

Inconvénients :

• Si les ressources du système ne sont pas suffisantes, le répartiteur de charge peut limiter les performances de votre application.
• Une configuration appropriée est nécessaire pour garantir des performances optimales.
• Nettement plus complexe que les configurations à serveur unique ou à serveurs séparés.
• Vous devez prendre en compte des facteurs tels que la terminaison SSL et les applications qui nécessitent des sessions persistantes.
• Le principal point de préoccupation lors de l'utilisation de répartiteurs de charge est qu'il s'agit d'un point de défaillance unique. Cela signifie que si le répartiteur de charge tombe en panne, l'ensemble de votre service s'arrêtera.

4. Accélérateur HTTP ou proxy inverse de mise en cache

Il s'agit d'une configuration que vous pouvez utiliser pour augmenter la vitesse à laquelle vous fournissez du contenu à un utilisateur de votre application. Elle utilise diverses techniques pour réduire ce temps. La plus importante consiste à mettre en cache la réponse du serveur d'application. L'accélérateur enregistre le contenu dans sa mémoire lorsqu'un utilisateur le demande pour la première fois. Par conséquent, lorsque des requêtes futures similaires arrivent, il fournit le contenu rapidement sans interagir avec le serveur d'application. Nginx, Varnish et Squid sont capables d'accélération HTTP.

Quand l'utiliser :

Naturellement, cette configuration est la plus adaptée aux fichiers et aux contenus que les utilisateurs demandent très fréquemment. Elle fonctionne également très bien pour les applications web dynamiques riches en contenu.

Avantages :

• La mise en cache et la compression augmentent considérablement la vitesse de l'application et du traitement des requêtes.
• La réduction de la charge sur le processeur améliore également les performances du site.
• Vous pouvez également l'utiliser comme répartiteur de charge proxy inverse.

Inconvénients :

• Vous devez bien le configurer pour en tirer les meilleures performances.
• Vous risquez de rencontrer de mauvaises performances si le taux de réussite du cache est faible.

5. Réplication de base de données primaire-réplica

Une configuration de réplication de base de données primaire-réplica est généralement très utile pour les systèmes qui effectuent plus de lectures que d'écritures. Par exemple, les systèmes de gestion de contenu peuvent réellement tirer parti d'une telle architecture. Vous avez besoin d'un nœud primaire et d'un ou plusieurs nœuds de réplication pour la réplication. Elle distribue les lectures sur l'ensemble des nœuds. Les mises à jour vont uniquement vers le nœud primaire.

Quand l'utiliser :

Comme nous l'avons mentionné, une configuration de base de données basée sur la réplication permet d'améliorer les performances de lecture d'un système. Vous pouvez l'utiliser pour des applications telles que les CMS.

Avantages :

• Elle améliore les performances de lecture de la base de données en les répartissant sur les réplicas.
• Si vous utilisez le nœud primaire uniquement pour les mises à jour, vous pouvez également améliorer les performances d'écriture.

Inconvénients :

• Toute application qui tente d'accéder à la base de données doit être capable de décider vers quel nœud envoyer les mises à jour et les requêtes de lecture.
• En cas de défaillance du réplica primaire, les mises à jour s'arrêtent. Vous devez résoudre le problème pour permettre aux mises à jour de continuer.
• Il n'y a pas de mécanisme de basculement pour faire face à une éventuelle défaillance du nœud primaire.

Utilisation combinée des configurations de serveurs

Heureusement, il vous est également possible de combiner différentes techniques pour obtenir le résultat souhaité. Cela signifie que vous pouvez répartir la charge des serveurs d'application avec les serveurs de cache dans un seul environnement et répliquer la base de données. Cela vous permet de tirer parti des fonctionnalités des deux serveurs. Cependant, cela ne rend pas la configuration plus compliquée ou fastidieuse.

Exemple :

Nous allons essayer de comprendre un tel environnement à l'aide d'un exemple :

Dans un tel environnement, le répartiteur de charge enverra les requêtes statiques aux serveurs de cache. Le contenu statique comprend notamment le CSS, les images et le Javascript. Il dirigera plutôt tout autre type de demande de contenu vers les serveurs d'application.

Supposons qu'un utilisateur demande du contenu statique à l'environnement. Voici ce qui se passerait :

• Le répartiteur de charge va d'abord déterminer si le contenu est un cache-hit ou un cache-miss. Le contenu cache-hit est présent dans le cache, tandis que le contenu cache-miss n'y est pas. Il le fait en vérifiant auprès du backend de cache.
• En cas de cache-hit, le répartiteur de charge envoie le contenu à l'utilisateur.
• En cas de cache-miss, le serveur de cache transmet la requête au backend de l'application.
• Le backend de l'application trouvera et enverra le contenu depuis la base de données.
• Le backend de cache reçoit le contenu de la part du répartiteur de charge. Il met également ce contenu en cache avant de le renvoyer au répartiteur de charge.
• Ce dernier transmet ensuite la réponse à l'utilisateur.

D'un autre côté, voici ce qui se passera si l'utilisateur demande du contenu dynamique :

• La requête de l'utilisateur arrivera au répartiteur de charge.
• Cette requête arrive au backend de l'application.
• Le backend de l'application localise le contenu demandé et le renvoie au répartiteur de charge.
• L'utilisateur reçoit le contenu.

L'un des principaux avantages d'un tel environnement combiné est qu'il est plus fiable. De plus, il offre également des capacités de performance supérieures. Il reste cependant deux points de défaillance uniques : le répartiteur de charge et le serveur de base de données principal.

Conclusion

Vous pouvez utiliser chaque configuration de serveur individuellement dans votre environnement. D'un autre côté, vous pouvez également en combiner plusieurs pour créer une solution personnalisée. Il n'y a pas de « bonne » réponse. Tout dépend des fonctionnalités que vous souhaitez tirer de l'architecture.

Avoir des connaissances de base sur le fonctionnement de chaque configuration de serveur vous aidera à prendre la décision pour votre propre application. La meilleure chose à faire est de commencer petit et simple. Vous pouvez continuer à augmenter la complexité de votre configuration au fur et à mesure que vous gagnez en expérience.

Bonne informatique !