Entrée HTTP globale stratégique
Les applications stratégiques doivent maintenir un niveau de disponibilité élevé, même lorsque les composants réseau sont indisponibles ou détériorés. Lorsque vous concevez l’entrée, le routage et la sécurité du trafic web, vous pouvez envisager de combiner plusieurs services Azure pour atteindre un niveau de disponibilité plus élevé et éviter d’avoir un point de défaillance unique.
Si vous décidez d’adopter cette approche, vous devez implémenter un chemin réseau distinct pour vos serveurs d’applications, et chaque chemin doit être configuré et testé séparément. Vous devez examiner attentivement toutes les implications de cette approche.
Cet article décrit une approche pour prendre en charge l’entrée du trafic HTTP global via Azure Front Door et Azure Application Gateway. Cette approche peut répondre à vos besoins si votre solution a besoin des éléments suivants :
- Azure Front Door pour le routage du trafic global. Cela peut signifier que vous avez plusieurs instances de votre application dans des régions Azure distinctes ou que vous servez tous les utilisateurs globaux d’une seule région.
- Pare-feu d’applications web (WAF) pour protéger votre application, quel que soit le chemin que votre trafic suit pour atteindre vos serveurs d’origine.
La mise en cache à la périphérie du réseau n’est pas une partie critique de la livraison de votre application. Si la mise en cache est importante, consultez Livraison d’un contenu global stratégique pour une autre approche.
Notes
Ce cas d’usage fait partie d’une stratégie de conception globale qui couvre une autre approche lorsqu’Azure Front Door est indisponible. Pour plus d’informations sur le contexte et divers considérations, consultez Applications web globales stratégiques.
Approche
Cette solution d’équilibrage de charge basée sur DNS utilise plusieurs profils Azure Traffic Manager pour superviser Azure Front Door. Dans le cas peu probable d’un problème de disponibilité, Traffic Manager redirige le trafic via Application Gateway.
La solution inclut les composants suivants :
Traffic Manager qui utilise un mode de routage prioritaire a deux points de terminaison. Par défaut, Traffic Manager envoie les requêtes via Azure Front Door. Si Azure Front Door n’est pas disponible, un deuxième profil Traffic Manager détermine où diriger la demande. Le deuxième profil est décrit ci-dessous.
Azure Front Door traite et achemine la majeure partie du trafic de votre application. Azure Front Door achemine le trafic vers le serveur d’applications d’origine approprié et fournit le chemin principal à votre application. Le WAF d’Azure Front Door protège votre application contre les menaces de sécurité courantes. Si Azure Front Door est indisponible, le trafic est automatiquement redirigé via le chemin secondaire.
Traffic Manager qui utilise le mode de routage des performances a un point de terminaison pour chaque instance d’Application Gateway. Ce Traffic Manager envoie des requêtes à l’instance d’Application Gateway avec les meilleures performances à partir de l’emplacement du client.
Application Gateway est déployé dans chaque région et envoie le trafic aux serveurs d’origine de cette région. Le WAF d’Application Gateway protège tout trafic qui transite par le chemin secondaire.
Vos serveurs d’applications d’origine doivent être prêts à accepter le trafic d’Azure Front Door et d’Azure Application Gateway, à tout moment.
Considérations
Les sections suivantes décrivent certaines considérations importantes pour ce type d’architecture. Vous devez également consulter les applications web globales stratégiques pour obtenir d’autres considérations et compromis importants lorsque vous utilisez Azure Front Door dans une solution stratégique.
Configuration de Traffic Manager
Cette approche utilise des profils Traffic Manager imbriqués pour obtenir ensemble un routage basé sur les priorités et basé sur les performances pour le chemin de trafic alternatif de votre application. Dans un scénario simple avec une origine dans une seule région, vous n’aurez peut-être besoin que d’un seul profil Traffic Manager configuré pour utiliser le routage basé sur la priorité.
Distribution régionale
Azure Front Door est un service mondial, alors qu’Application Gateway est un service régional.
Les points de présence d’Azure Front Door sont déployés globalement, et les connexions TCP et TLS se terminent au point de présence le plus proche du client. Ce comportement améliore les performances de votre application. En revanche, lorsque les clients se connectent à Application Gateway, leurs connexions TCP et TLS se terminent à l’Application Gateway qui reçoit la demande, quelle que soit l’origine du trafic.
Connexions des clients
En tant que service multilocataire global, Azure Front Door offre une protection inhérente contre diverses menaces. Azure Front Door accepte uniquement le trafic HTTP et HTTPS valide, et n’accepte pas le trafic sur d’autres protocoles. Microsoft gère les adresses IP publiques qu’Azure Front Door utilise pour ses connexions entrantes. En raison de ces caractéristiques, Azure Front Door peut vous aider à protéger votre origine contre différents types d’attaques, et vos origines peuvent être configurées pour utiliser la connectivité Private Link.
En revanche, Application Gateway est un service accessible sur Internet avec une adresse IP publique dédiée. Vous devez protéger vos serveurs réseau et d’origine contre divers types d’attaques. Pour plus d’informations, consultez Sécurité de l’origine.
Connexions de Private Link aux serveurs d’origine
Azure Front Door Premium fournit la connectivité Private Link à vos origines, ce qui réduit la surface d’accès de votre solution à l’Internet publique.
Si vous utilisez Private Link pour vous connecter à vos origines, envisagez de déployer un point de terminaison privé dans votre réseau virtuel et configurez Application Gateway pour utiliser le point de terminaison privé comme back-end pour votre application.
Mise à l'échelle
Lorsque vous déployez Application Gateway, vous déployez des ressources de calcul dédiées pour votre solution. Si de grandes quantités de trafic arrivent à votre Application Gateway de manière inattendue, vous pouvez observer des problèmes de performances ou de fiabilité.
Pour atténuer ce risque, réfléchissez à la façon dont vous mettez à l’échelle votre instance d’Application Gateway. Utilisez la mise à l’échelle automatique ou vérifiez que vous l’avez mise à l’échelle manuellement pour gérer la quantité de trafic que vous pouvez recevoir après le basculement.
Mise en cache
Si vous utilisez les fonctionnalités de mise en cache d’Azure Front Door, il est important de savoir qu’une fois que votre trafic passe à l’autre chemin et utilise Application Gateway, le contenu n’est plus servi à partir des caches Azure Front Door.
Si vous dépendez de la mise en cache pour votre solution, consultez Livraison d’un contenu global stratégique pour une autre approche qui utilise un CDN partenaire comme solution de secours vers Azure Front Door.
Sinon, si vous utilisez la mise en cache, mais qu’il ne s’agit pas d’une partie essentielle de votre stratégie de livraison d’applications, déterminez si vous pouvez effectuer un scale-out ou un scale-up de vos origines pour faire face à la charge accrue provoquée par le plus grand nombre d’absences dans le cache lors d’un basculement.
Compromis
Ce type d’architecture est particulièrement utile si vous souhaitez que votre chemin de trafic alternatif utilise des fonctionnalités telles que les règles de traitement des demandes, un WAF et un déchargement TLS. Azure Front Door et Application Gateway offrent des fonctionnalités similaires.
Toutefois, il existe des compromis :
Complexité opérationnelle. Lorsque vous utilisez l’une de ces fonctionnalités, vous devez les configurer à la fois sur Azure Front Door et Application Gateway. Par exemple, si vous apportez une modification de configuration à votre WAF Azure Front Door, vous devez également appliquer la même modification de configuration à votre WAF Application Gateway. Votre complexité opérationnelle devient beaucoup plus élevée lorsque vous devez reconfigurer et tester deux systèmes distincts.
Parité des fonctionnalités. Bien qu’il existe des similitudes entre les fonctionnalités proposées par Azure Front Door et Application Gateway, de nombreuses fonctionnalités n’ont pas de parité exacte. Gardez à l’esprit ces différences, car elles peuvent affecter la façon dont l’application est fournie en fonction du chemin de trafic qu’elle suit.
Application Gateway ne fournit pas de mise en cache. Pour plus d’informations sur cette différence, consultez Mise en cache.
Azure Front Door et Application Gateway sont des produits distincts et ont des cas d’usage différents. En particulier, les deux produits sont différents dans la façon dont ils sont déployés dans les régions Azure. Veillez à comprendre les détails de chaque produit et la façon dont vous les utilisez.
Coût : Vous devez généralement déployer une instance d’Application Gateway dans chaque région où vous avez une origine. Étant donné que chaque instance d’Application Gateway est facturée séparément, le coût peut devenir élevé lorsque vous avez des origines déployées dans plusieurs régions.
Si le coût est un facteur important pour votre solution, consultez Livraison d’un contenu global stratégique pour une autre approche qui utilise un réseau de distribution de contenu partenaire (CDN) comme solution de secours à Azure Front Door. Certains CDN facturent le trafic sur la base de la consommation, de sorte que cette approche peut être plus rentable. Toutefois, vous risquez de perdre certains des autres avantages de l’utilisation d’Application Gateway pour votre solution.
Vous pouvez également envisager de déployer une autre architecture dans laquelle Traffic Manager peut acheminer le trafic directement vers les services d’application PaaS (Platform as a Service), ce qui évite de nécessiter Application Gateway et réduit vos coûts. Vous pouvez envisager cette approche si vous utilisez un service comme Azure App Service ou Azure Container Apps pour votre solution. Toutefois, si vous suivez cette approche, il existe plusieurs compromis importants à prendre en compte :
- WAF : Azure Front Door et Application Gateway fournissent tous deux des fonctionnalités WAF. Si vous exposez vos services d’application directement à Internet, vous ne pourrez peut-être pas protéger votre application avec un WAF.
- Déchargement TLS : Azure Front Door et Application Gateway arrêtent tous deux les connexions TLS. Vos services d’application doivent être configurés pour arrêter les connexions TLS.
- Routage : Azure Front Door et Application Gateway effectuent le routage entre plusieurs origines ou back-ends, y compris le routage basé sur le chemin, et ils prennent en charge des règles d’acheminement complexes. Si vos services d’application sont exposés directement à Internet, vous ne pouvez pas effectuer le routage du trafic.
Avertissement
Si vous envisagez d’exposer votre application directement sur Internet, créez un modèle de menace complet et assurez-vous que l’architecture répond à vos exigences de sécurité, de performances et de résilience.
Si vous utilisez des machines virtuelles pour héberger votre solution, vous ne devez pas exposer les machines virtuelles à Internet.
Étapes suivantes
Passez en revue le scénario de distribution de contenu global pour comprendre s’il s’applique à votre solution.