Diagramme d'architecture trois tiers : présentation, application et données

L'architecture trois tiers est la forme que la plupart des applications web ont encore sous le capot : quelque chose qui sert l'interface utilisateur, quelque chose qui exécute la logique métier, et quelque chose qui stocke les données. Elle est ancienne, elle est ennuyeuse, et c'est le bon point de départ pour la plupart des systèmes, car chaque tier peut monter en charge et être sécurisé indépendamment.

Cet article explique les trois tiers, montre comment ils se traduisent dans un réseau cloud avec des sous-réseaux et des groupes de sécurité, et dessine un déploiement AWS typique sur deux zones de disponibilité. La même structure fonctionne sur n'importe quel cloud.

Les trois tiers

La règle qui en fait une architecture et pas seulement trois boîtes : chaque tier ne parle qu'à son voisin. Le navigateur n'atteint jamais la base de données, et le tier de présentation n'exécute jamais de SQL.

AWS décrit le pattern dans sa présentation de l'architecture trois tiers, y compris des variantes serverless où des fonctions remplacent les serveurs d'application.

Traduire les tiers dans le réseau

Les tiers deviennent de vraies frontières quand ils vivent dans des sous-réseaux différents, avec des routes différentes :

• Les sous-réseaux publics ne contiennent que ce qui doit être joignable depuis Internet : le load balancer et les passerelles NAT.
• Les sous-réseaux privés d'application contiennent les serveurs d'application. Ils peuvent sortir vers Internet via NAT pour les mises à jour et les API, mais rien ne peut les atteindre depuis l'extérieur, sauf via le load balancer.
• Les sous-réseaux privés de données contiennent les bases et les caches, sans aucune route vers Internet.

Les groupes de sécurité n'autorisent ensuite que le trafic du voisin : la base accepte le port 5432 uniquement depuis le groupe de sécurité du tier application, pas depuis une plage d'IP. Référencer des groupes plutôt que des adresses garde les règles justes à mesure que les instances vont et viennent.

Haute disponibilité entre zones

Faites tourner chaque tier dans au moins deux zones de disponibilité :

• Le load balancer couvre plusieurs zones par conception.
• Les serveurs d'application tournent dans un groupe d'autoscaling avec des instances dans chaque zone. Si une zone tombe, les autres prennent le trafic et le groupe remplace la capacité.
• La base de données tourne avec un standby synchrone dans une autre zone. Avec Amazon RDS Multi-AZ, la bascule vers le standby est automatique et le nom du point de terminaison ne change pas.

Gardez le tier application sans état pour que n'importe quelle instance puisse servir n'importe quelle requête : les sessions vont dans un cache partagé ou en base, les fichiers envoyés dans le stockage objet, et rien d'important ne vit sur le disque d'une instance. Testez-le en arrêtant un serveur d'application au hasard pendant les heures ouvrées ; si les utilisateurs le remarquent, un état se cache encore sur les instances.

Faire monter chaque tier en charge

Les tiers montent en charge différemment, et c'est la raison de les garder séparés :

• Présentation : un CDN absorbe l'essentiel du trafic statique. Les en-têtes de cache décident de la proportion.
• Application : ajoutez des instances. Montez en charge selon le nombre de requêtes ou le CPU, et gardez un démarrage d'instance rapide.
• Données : le plus difficile. Montez d'abord en gamme, ajoutez des réplicas en lecture pour une charge dominée par les lectures, un cache pour les clés chaudes, et gardez le sharding en dernier recours.

Une requête à travers les tiers

Suivez un utilisateur qui charge son historique de commandes :

1. Le DNS renvoie l'adresse du CDN. Le navigateur demande la page ; le HTML, les scripts et les images viennent du cache du CDN ou du bucket statique derrière lui.
2. La page appelle GET /api/orders. Le CDN transmet les chemins dynamiques au load balancer, qui termine le TLS et choisit un serveur d'application sain dans l'une des deux zones.
3. Le serveur d'application lit la session dans le cache, vérifie que l'utilisateur est connecté et interroge la base primaire pour obtenir les commandes.
4. La réponse revient par le load balancer et le CDN, qui ne la met pas en cache puisqu'elle est privée.

Chaque saut franchit une seule frontière de tier, et chaque frontière a exactement un point d'entrée autorisé. C'est ce qui rend la conception facile à comprendre et à sécuriser.

Coûts et dimensionnement

Le tier de données domine en général la facture et c'est le plus difficile à réduire ensuite : dimensionnez-le d'après des mesures, pas des suppositions. Le tier application est le plus facile à ajuster : commencez petit, montez en charge selon la charge réelle et laissez l'autoscaling gérer les pics. Les passerelles NAT et le trafic entre zones sont les postes qui surprennent ; gardez le trafic bavard dans une seule zone quand c'est possible, et utilisez des points de terminaison VPC pour le stockage objet afin que les serveurs d'application ne paient pas de frais NAT à chaque envoi de fichier.

Le diagramme d'architecture

Comment le lire :

• En haut : les utilisateurs résolvent le DNS et se connectent au CDN, qui sert les fichiers statiques depuis un bucket et transmet les requêtes dynamiques.
• Tier présentation : l'application load balancer est le seul composant dans les sous-réseaux publics.
• Tier application : les serveurs d'application des zones A et B sont dans des sous-réseaux privés et ne reçoivent du trafic que du load balancer.
• Tier données : la base primaire en zone A se réplique de façon synchrone vers un standby en zone B ; les serveurs d'application utilisent aussi un cache de sessions. Ce tier n'a aucune route vers Internet.
• Le bloc Markdown liste les règles des groupes de sécurité, qui sont ce qui fait réellement respecter les tiers.

Erreurs courantes

• Des bases dans des sous-réseaux publics, « temporairement », pour une requête rapide depuis un portable. Utilisez plutôt un bastion ou un outil de session géré.
• Des groupes de sécurité qui autorisent toute une plage CIDR entre tiers au lieu de référencer le groupe du voisin.
• De l'état sur les serveurs d'application : sessions en mémoire, fichiers sur le disque local. L'autoscaling et la bascule perdent alors des données.
• Une seule zone de disponibilité pour la base afin d'économiser, alors que le tier application est réparti sur trois.
• Se passer du CDN et servir chaque image depuis les serveurs d'application.
• Aucun chemin de health check sur les serveurs d'application, si bien que le load balancer continue d'envoyer du trafic à des instances qui n'atteignent pas la base.

Quand trois tiers ne suffisent plus

Trois tiers décrivent une application. Quand un système grandit en plusieurs services, chaque service garde souvent sa propre forme trois tiers, et le diagramme monte d'un niveau pour montrer comment les services se parlent. Le diagramme d'architecture microservices couvre cette étape. Pour les détails réseau, voyez le diagramme de VPC AWS, et pour plusieurs régions, le diagramme d'architecture AWS multi-régions.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez une Personne du pack Modèle C4, un DNS du pack Réseau, ainsi qu'un CDN et un nœud Stockage objet du pack Cloud.
3. Ajoutez un VPC du pack Réseau et, à l'intérieur, trois nœuds Cadre du pack Base, un par tier.
4. Ajoutez un Répartiteur de charge cloud au tier présentation, deux nœuds Instance de calcul au tier application, et deux nœuds Base de données gérée plus Redis du pack Données au tier données.
5. Reliez chaque tier uniquement à son voisin et ajoutez un bloc Markdown du pack Base avec les règles des groupes de sécurité. Si votre installation existe déjà en Terraform, l'outil Terraform vers diagramme vous donne un premier jet.

L'exemple utilise 15 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Quels sont les trois tiers d'une architecture trois tiers ? La présentation (l'interface utilisateur et le point d'entrée), l'application (la logique métier et les API) et les données (bases de données, caches et stockage).

L'architecture trois tiers est-elle dépassée ? Non. C'est la forme par défaut des applications web. Les microservices et les systèmes serverless contiennent toujours les trois mêmes responsabilités, souvent par service.

Quelle est la différence entre une architecture trois tiers et une architecture en trois couches ? Les couches sont un découpage logique à l'intérieur du code ; les tiers sont un découpage physique entre des machines ou des services distincts, séparés par des frontières réseau.

La base de données doit-elle être dans un sous-réseau public ? Non. Gardez-la dans des sous-réseaux privés sans route vers Internet, joignable uniquement depuis le groupe de sécurité du tier application.

Comment rendre une application trois tiers hautement disponible ? Faites tourner chaque tier dans au moins deux zones de disponibilité, gardez les serveurs d'application sans état et utilisez une base avec un standby automatique dans une autre zone.

Commencez gratuitement — un siège, sans carte bancaire.