Concevoir une architecture réseau distribuée géographiquement
Dans une application distribuée, il est essentiel de s’assurer que les composants peuvent communiquer de manière fiable et que les demandes peuvent être routées vers un autre composant ou région en cas de défaillance.
Nous avons décidé de remanier notre portail d’expédition dans Azure afin de réduire sa vulnérabilité aux défaillances régionales. Nous voulons nous assurer que l’application bascule sur les composants d’une région secondaire lorsque la région primaire n’est pas disponible. Le basculement doit entraîner une interruption minimale de la prestation des services aux utilisateurs.
Ici, nous découvrons comment Azure DNS, Traffic Manager, Front Door et Azure CDN prennent en charge l’architecture d’application de notre société de transport.
Azure DNS
Rappelez-vous que nous n’avons pas besoin d’apporter de modifications à notre implémentation d’Azure DNS. Nous utilisons Azure DNS pour héberger les enregistrements de nom de domaine qui identifient notre application.
Azure DNS offre une résolution de noms entièrement par le biais de l’infrastructure Azure. En raison de la nature multirégionale de ce service, il n’est pas nécessaire de modifier la configuration existante d’Azure DNS pour prendre en charge la fonctionnalité dans notre nouvelle conception architecturale.
De plus, le SLA Azure DNS garantit à 100 % que les demandes DNS valides reçoivent systématiquement une réponse d’au moins un de nos serveurs de noms Azure DNS.
Choisir un routeur de trafic
Nous avons besoin d’un service capable d’équilibrer la charge et de rediriger le trafic entre plusieurs régions avec des applications web distribuées.
Azure fournit plusieurs services différents qui peuvent router le trafic entre les composants front-end. Rappelez-vous que nous devons remplacer notre passerelle d’application Azure, car elle est limitée à une seule région. En cas de défaillance de cette région, rien ne permet d’assurer le routage.
Dans Azure, il existe deux routeurs de trafic qui peuvent effectuer un routage global entre plusieurs régions et ne sont pas vulnérables à une panne monorégion :
- Azure Traffic Manager
- Azure Front Door
Examinons ces services plus en détail afin de pouvoir choisir le bon routeur pour notre application.
Présentation d’Azure Traffic Manager
Azure Traffic Manager est un équilibreur de charge mondial qui utilise des enregistrements DNS pour router le trafic vers des destinations dans plusieurs régions Azure.
Nous pouvons configurer Traffic Manager pour router toutes les demandes vers notre région primaire et superviser la réactivité du service d’application dans cette région. Si le service d’application dans la région primaire échoue, Traffic Manager reroute automatiquement les demandes des utilisateurs vers le service d’application dans la région secondaire. Ce reroutage exécute le basculement qui garantit la continuité du service. Nous appelons cette configuration mode de routage par priorité.
Étant donné que Traffic Manager utilise le système DNS pour router le trafic, il route tout protocole, pas seulement le trafic HTTP. Toutefois, Traffic Manager ne peut pas router ou filtrer le trafic en fonction des propriétés HTTP, telles que les codes de pays clients ou les en-têtes User-Agent. Il ne peut pas non plus effectuer l’arrêt du protocole TLS (Transport Layer Security), opération par le biais de laquelle le routeur déchiffre les demandes et chiffre les réponses afin d’alléger la charge des serveurs virtuels App Service. Si nous avons besoin de l’une de ces fonctionnalités, nous devons utiliser Azure Front Door.
Traffic Manager utilise la supervision des points de terminaison hautement configurable. Par exemple, nous pouvons définir le protocole, le port, le chemin, les paramètres d’en-tête personnalisés, les plages de codes d’état attendues et le nombre d’échecs toléré. La supervision des points de terminaison nous donne une idée permanente de l’intégrité globale de toutes les parties de notre application.
Présentation d’Azure Front Door
Comme Traffic Manager, Azure Front Door est un équilibreur de charge mondial. Contrairement à Traffic Manager, il fonctionne au niveau de la couche Application du réseau, la couche 7, et utilise les propriétés HTTP et HTTPS pour effectuer le filtrage et le routage.
Avec Front Door, nous pouvons effectuer de nombreux types de routage que Traffic Manager ne prend pas en charge. Par exemple, nous pouvons router le trafic en fonction du code de pays du navigateur. Front Door prend également en charge l’arrêt du protocole TLS.
Toutefois, il existe une exception. Si nous souhaitons router le trafic pour n’importe quel protocole autre que HTTP et HTTPS, nous devons utiliser Traffic Manager.
Front Door nous permet d’attribuer des priorités aux différents back-ends qui constituent le portail de suivi. Ces priorités permettent à Front Door de router les demandes en fonction des besoins. Nous attribuons aux services de la région primaire une priorité supérieure et au service de la région secondaire une priorité plus basse.
Front Door met en œuvre des sondes d’intégrité pour superviser l’état d’intégrité de nos services et, en cas de défaillance, il peut router le trafic correctement. Le mode de routage par priorité et la supervision des points de terminaison dans Front Door sont similaires à ces fonctionnalités dans Traffic Manager, à la différence que les sondes d’intégrité fonctionnent toujours sur HTTP.
Tout le trafic de l’interface utilisateur web de notre portail d’expédition et de ses API est effectué via HTTPS, ce qui nous permet de remplacer Azure Traffic Manager par Front Door. Nous pouvons également configurer Front Door avec l’affectation de back-ends par priorité.
Azure CDN
Dans notre architecture monorégion, nous avons utilisé Azure CDN pour mettre en cache le contenu statique à partir de Stockage Blob Azure. Le service Azure CDN est un réseau mondial de serveurs qui met en cache le contenu statique à proximité des utilisateurs. Nous n’avons pas besoin de modifier ce service pour l’architecture multirégion. Toutefois, il existe des considérations relatives à notre compte de Stockage Azure, que nous aborderons dans l’unité suivante.