Considérations relatives aux architectures multiniveaux
Nous avons vu ce qui constitue une architecture multiniveau et nous avons déployé un exemple d’architecture à trois niveaux. Examinons certains des avantages et certaines des difficultés de ce style d’architecture ainsi que les bonnes pratiques permettant de l’optimiser pour les performances et la sécurité.
Avantages
Ce style d’architecture est avantageux parce qu’il est simple. Il s’agit d’un modèle d’architecture souvent utilisé et bien défini, à la fois pour les déploiements locaux et cloud. De plus, il peut fonctionner avec un large éventail d’applications.
C’est une architecture spécifique à une plateforme et adaptée aux applications déployées sur Windows ou Linux. Comme nous l’avons montré dans notre exemple d’environnement, vous pouvez utiliser les services PaaS ou IaaS dans n’importe quel niveau.
L’application étant divisée en niveaux, chaque niveau peut être ajusté, mise à jour ou mis à niveau indépendamment. Si les demandes sur notre site web augmentent, nous pouvons ajouter des serveurs web à la charge sans impacter les autres niveaux. De même, si les demandes sur notre niveau Données augmentent, nous pouvons adapter notre base de données afin de disposer de plus de capacité pour les traiter.
La séparation du réseau est une conséquence naturelle de cette architecture. Étant donné que l’application est divisée en niveaux, nous devons isoler chaque niveau et autoriser seulement l’accès réseau strictement nécessaire. Le niveau Présentation peut être exposé sur Internet, et la base de données peut être entièrement sécurisée derrière plusieurs niveaux du réseau, tout comme les fonctions de notre application. En sécurisant l’accès réseau entre les niveaux, nous réduisons la surface d’attaque de l’application et nous renforçons sa sécurité.
Difficultés et considérations
Quand vous séparez votre application en plusieurs niveaux, évitez des niveaux intermédiaires qui effectuent uniquement des opérations de base de données. Chaque niveau doit ajouter une valeur spécifique. Les niveaux supplémentaires ajoutent de la complexité, du temps de traitement, de la latence et, à terme, des retards pour l’utilisateur.
Du fait que les API de chaque domaine de niveau Application ne sont pas séparées en services individuels, elles doivent être mises à l’échelle conjointement. Si une seule méthode d’application nécessite plus de puissance de traitement ou a besoin de traiter plus de demandes que d’autres, le niveau Application doit faire l’objet d’un scale-out dans son ensemble pour traiter la charge, au lieu d’un service individuel.
Dans certains cas, vous pouvez développer une application sous la forme d’une architecture multiniveau, mais continuer à effectuer des déploiements sous la forme d’application monolithique. En dissociant totalement chaque niveau, vous devez déployer chacun d’eux indépendamment. La dissociation complète implique la suppression des dépendances partagées et un recours accru aux appels d’API entre les niveaux. Quand elle est correctement effectuée, cette opération garantit la flexibilité de vos déploiements d’applications.
Dans une architecture multiniveau, les applications sont souvent déployées sur des machines virtuelles. Il s’agit d’une première étape, mais le fait de faire évoluer votre application pour qu’elle utilise les services PaaS offre de nombreux avantages liés à la sécurité, à la scalabilité et à l’administration. Cette évolution est souvent négligée et les architectures multiniveaux restent sur des machines virtuelles.
L’architecture multiniveau est un style d’architecture classique, mais dans de nombreux scénarios, elle est remplacée par d’autres modèles de conception modernes, comme une architecture de microservices. Il est souvent important de consacrer du temps à évaluer d’autres architectures pour voir si elles conviennent mieux à votre application.
Bonnes pratiques concernant les architectures multiniveaux
Vous avez plusieurs opérations à effectuer pour garantir que le fonctionnement de votre architecture multiniveau est optimal. Le diagramme suivant montre visuellement comment vous pouvez apporter des améliorations à une architecture multiniveau.
Optimiser les performances
Examinons les façons d’optimiser une architecture multiniveau concernant les performances et la sécurité.
Mise à l’échelle automatique
L’application étant séparée en plusieurs niveaux, nous pouvons utiliser des fonctionnalités de cloud, comme la mise à l’échelle automatique, pour l’adapter à la charge du système. À mesure que le nombre d’utilisateurs ou de demandes augmente, utilisez la mise à l’échelle automatique sur plusieurs niveaux afin d’ajouter davantage de ressources pour traiter les demandes. À mesure que les demandes diminuent, la mise à l’échelle automatique réduit les ressources de calcul, ce qui réduit également votre facture. La mise à l’échelle automatique vous permet de garantir facilement que vos utilisateurs bénéficient de la meilleure expérience possible et que vos coûts restent faibles. Azure Virtual Machine Scale Sets peut être utilisé pour les charges de travail basées sur des machines virtuelles et, par ailleurs, de nombreux services PaaS, comme Azure App Service, offrent des fonctionnalités de mise à l’échelle automatique intégrées.
Équilibrage de charge
Quand vous effectuez un scale-out de votre application avec mise à l’échelle automatique, l’utilisation de l’équilibrage de charge devient un élément nécessaire de votre architecture. Avec l’équilibrage de charge, quand vous ajoutez des ressources de calcul à votre niveau, elles sont ajoutées à votre distribution d’équilibreur de charge pour tirer parti de la puissance de traitement supplémentaire. À l’inverse, en cas de défaillance d’un système, il est supprimé de la charge pour minimiser l’impact pour l’utilisateur en raison de performances médiocres ou de demandes erronées. Cela garantit que les demandes des utilisateurs parviennent aux systèmes dans un état intègre. L’équilibreur de charge Azure est une fonctionnalité intégrée des fonctionnalités de réseau et Application Gateway fournit une solution d’équilibrage de charge HTTP plus riche en fonctionnalités.
Messagerie
L’utilisation d’un service de messagerie entre les niveaux a un effet positif sur les performances, en particulier sur les demandes qui sont asynchrones par nature. Le service place un message dans une file d’attente où il reste jusqu’à ce qu’il soit traité, ce qui compense l’impact de la charge en aval. En cas de panne du système, un service de messagerie garantit que votre message est toujours traité. Le message reste dans la file d’attente et est traité quand le système redevient opérationnel. Azure propose plusieurs solutions de messagerie que vous pouvez choisir en fonction de vos besoins. Azure Service Bus, les files d’attente du Stockage Azure et Azure Event Hubs sont certaines de celles qui doivent être examinées quand vous recherchez un service de messagerie.
Mise en cache de données
Utilisez un cache pour les données qui sont fréquemment consultées et qui ont un faible taux de modification, ou pour les données ne nécessitant pas une persistance à long terme, comme un état de session. Les systèmes de mise en cache se trouvent entre les niveaux et réduisent les temps d’extraction des données pour ces types de données. Le Cache Azure pour Redis est un service PaaS bien adapté pour ce scénario.
Optimiser la sécurité
L’optimisation de la sécurité dans une application est souvent un travail « sans fin ». Même si l’application est divisée en niveaux, des pratiques de sécurité bien planifiées doivent toujours être mises en application un peu partout dans l’architecture. Plus vous ajoutez de niveaux, plus vous devez prendre des mesures de sécurité et plus vous introduisez de complexité dans le système. Vous avez plusieurs opérations à effectuer en vue de garantir que votre architecture fournit un environnement sécurisé pour exécuter votre application.
Isolement réseau
Lors de l’exécution d’une architecture multiniveau sur des machines virtuelles, vérifiez que chaque niveau se trouve dans son propre sous-réseau. Ce sous-réseau agit comme une limite de sécurité et vous permet d’isoler la connectivité par le biais de listes de contrôle d’accès au réseau. Le sous-réseau facilite également la gestion en garantissant que les nouveaux systèmes du sous-réseau reçoivent les mêmes règles. Dans Azure, cette opération se fait en mode natif avec des groupes de sécurité réseau (NSG). Les services PaaS doivent faire l’objet de considérations similaires, mais les fonctionnalités d’intégration réseau varient selon les services et doivent être évaluées individuellement. Il est recommandé de vérifier que chaque niveau peut communiquer uniquement avec le niveau inférieur. Le niveau Présentation doit pouvoir communiquer uniquement avec le niveau Application, et le niveau Application doit pouvoir communiquer uniquement avec le niveau Données. La réduction de cette connectivité fournit une approche de disposition en couches pour la sécurité du réseau et améliore l’état de sécurité global d’une architecture.
Pare-feu d’application web
Avec l’isolation de sécurité entre les sous-réseaux en place, vous voulez garantir que votre front-end exposé publiquement est sécurisé et qu’il autorise seulement l’accès strictement nécessaire. Vous devez uniquement exposer votre niveau de présentation au trafic Internet entrant. La mise en place d’un pare-feu d’application web (WAF) devant votre niveau de présentation améliore la sécurité à ce niveau. Les pare-feu WAF inspectent le trafic pour détecter les activités malveillantes, vérifient que les communications sont chiffrées et vous alertent s’ils détectent quelque chose d’anormal. Dans Azure, Application Gateway est un équilibreur de charge HTTP disposant d’un pare-feu WAF intégré que vous pouvez activer.