Méthodes de routage du trafic vers l’origine

Important

Azure Front Door (classique) va être mis hors service le 31 mars 2027. Pour éviter toute interruption de service, il est important de migrer vos profils Azure Front Door (classique) vers le niveau Azure Front Door Standard ou Premium au plus en mars 2027. Pour plus d’informations, consultez Mise hors service d’Azure Front Door (classique).

Azure Front Door prend en charge quatre méthodes de routage du trafic pour gérer la répartition de votre trafic HTTP/HTTPS parmi différentes origines. Lorsque les requêtes utilisateur parviennent aux emplacements de périphérie Front Door, elles sont transférées à la meilleure ressource back-end en fonction de la méthode de routage configurée.

Remarque

Dans cet article, une origine fait référence au back-end ; un groupe d’origines renvoie au pool de back-ends de la configuration Azure Front Door (classique).

Les quatre méthodes de routage du trafic sont les suivantes :

• Latence : achemine les requêtes vers les origines dont la latence est la plus faible et comprise dans une plage de sensibilité acceptable, ce qui garantit que les requêtes sont envoyées aux origines les plus proches en termes de latence réseau.

• Priorité : permet de définir la priorité des origines. Ainsi, vous désignez une origine primaire pour gérer l’ensemble du trafic et une origine secondaire de secours pour prendre le relais au cas où l’origine primaire deviendrait indisponible.

• Pondéré : attribue un poids à chaque origine pour distribuer le trafic uniformément ou en fonction des coefficients de poids spécifiés. Le trafic est distribué en fonction des valeurs de poids si les latences des origines se trouvent dans la plage de sensibilité acceptable.

• Affinité de session : faites en sorte que les requêtes d’un même utilisateur soient envoyées à la même origine en configurant l’affinité de session pour vos hôtes ou domaines front-end.

Remarque

Dans le niveau Standard et Premium d’Azure Front Door, le nom de point de terminaison est appelé hôte front-end dans Azure Front Door (classique).

Toutes les configurations Front Door intègrent le monitoring de l’intégrité de back-end et le basculement global automatisé. Pour plus d’informations, consultez Monitoring des serveurs principaux Front Door. Azure Front Door peut utiliser une méthode de routage unique ou en combiner plusieurs afin de créer une topologie de routage optimale en fonction des besoins de votre application.

Remarque

Grâce au moteur de règles Front Door, vous pouvez configurer des règles pour remplacer les configurations d’itinéraires dans les niveaux Standard et Premium d’Azure Front Door ou pour remplacer le pool de back-ends dans Azure Front Door (classique) pour une requête. Le groupe d’origines ou le pool de back-ends définis par le moteur de règles remplacent le processus de routage décrit dans cet article.

Flux de décision global

Le diagramme suivant illustre le flux de décision global :

Les étapes de décision sont les suivantes :

1. Origines disponibles : sélectionnez toutes les origines activées et intègres (200 OK) en fonction de la sonde d’intégrité.
   • Exemple : si parmi les 6 origines existantes A, B, C, D, E et F, C n’est pas intègre et E est désactivée, les origines disponibles sont A, B, D et F.
2. Priorité : sélectionnez les origines de priorité supérieure parmi celles qui sont disponibles.
   • Exemple : si les origines A, B et D ont la priorité 1 et que l’origine F a la priorité 2, les origines sélectionnées sont A, B et D.
3. Signal de latence (basé sur la sonde d’intégrité) : sélectionnez les origines comprises dans la plage de latence autorisée à partir de l’environnement Front Door d’arrivée de la requête. Ce signal est basé sur le paramètre de sensibilité de latence du groupe d’origines et sur la latence des origines les plus proches.
   • Exemple : si la latence est de 15 ms pour l’origine A, de 30 ms pour B et de 60 ms pour D, et que la sensibilité de latence est définie sur 30 ms, les origines sélectionnées sont A et B, car D se trouve au-delà de la plage de 30 ms.
4. Poids : répartissez le trafic entre les origines sélectionnées finales en fonction des ratios de poids spécifiés.
   • Exemple : si l’origine A a un poids de 3 et l’origine B un poids de 7, le trafic est réparti à hauteur de 3/10 pour l’origine A et de 7/10 pour l’origine B.

Si l’affinité de session est activée, la première requête d’une session suit le flux expliqué précédemment. Les demandes suivantes sont envoyées à l’origine sélectionnée dans la première demande.

Routage du trafic basé sur les latences les plus faibles

Le déploiement d’origines à diverses localisations mondiales peut améliorer la réactivité de votre application dans la mesure où le trafic est acheminé vers l’origine « la plus proche » de vos utilisateurs finaux. La méthode de routage Latence est sélectionnée par défaut dans les configurations Azure Front Door. Cette méthode dirige les requêtes utilisateur vers l’origine dont la latence réseau est la plus faible, et non vers la localisation géographique la plus proche, garantissant ainsi des performances optimales.

L’architecture anycast d’Azure Front Door, couplée à la méthode de routage Latence, est la garantie que chaque utilisateur bénéficie du meilleur niveau de performance en fonction de sa localisation. Chaque environnement Front Door mesure de façon indépendante la latence pour les origines, ce qui signifie que les utilisateurs à différentes emplacements sont acheminés vers l’origine qui offre le meilleur niveau de performance pour leur environnement spécifique.

Remarque

Par défaut, la propriété de sensibilité de latence est définie sur 0 ms. Grâce à ce paramètre, les requêtes sont toujours transférées vers les origines disponibles les plus rapides. Les poids définis pour les origines ne prennent effet que si deux origines ont la même latence réseau.

Si vous souhaitez en savoir plus, veuillez consulter Architecture de routage Azure Front Door.

Routage du trafic basé sur les priorités

Pour assurer une haute disponibilité, les organisations déploient souvent des services de secours pour prendre le relais en cas de défaillance des services principaux. Cette configuration est connue sous le nom de déploiement Actif/En attente ou Actif/Passif. La méthode de routage du trafic Priorité d’Azure Front Door vous permet d’implémenter efficacement ce modèle de basculement.

Par défaut, Azure Front Door achemine le trafic vers les origines ayant la priorité la plus élevée (valeur de priorité la plus basse). Si ces origines primaires deviennent indisponibles, le trafic est acheminé vers les origines secondaires (valeur de priorité la plus basse suivante). Ce processus continue avec les origines tertiaires si les origines primaires et secondaires ne sont pas disponibles. Les sondes d’intégrité surveillent la disponibilité des origines en fonction de leur état et de leur intégrité configurés.

Configuration de la priorité des origines

Chaque origine constituant votre groupe d’origines Azure Front Door possède une propriété Priorité, qui peut être définie sur une valeur comprise entre 1 et 5. Les valeurs inférieures indiquent une priorité plus élevée. Une même valeur de priorité peut être partagée par plusieurs origines.

Méthode de routage du trafic basé sur la pondération

La méthode de routage du trafic Pondéré vous permet de répartir le trafic en fonction des poids prédéfinis.

Dans cette méthode, vous attribuez un poids à chacune des origines composant votre groupe d’origines Azure Front Door. Le poids est un entier compris entre 1 et 1 000, avec une valeur par défaut de 50.

Le trafic est réparti entre les origines disponibles selon un mécanisme de tourniquet basé sur les ratios de poids spécifiés, à condition que les origines répondent à la sensibilité de latence acceptable. Si la sensibilité de latence est définie sur 0 millisecondes, les poids prennent effet uniquement si deux origines ont la même latence réseau.

La méthode pondérée prend en charge plusieurs scénarios :

• Mise à niveau progressive d’application : acheminez un certain pourcentage du trafic vers un nouvelle origine, puis augmentez progressivement cette part au fil du temps.
• Migration d’application vers Azure : créez un groupe d’origines avec à la fois des origines Azure et des origines externes. Ajustez les poids de façon à privilégier les nouvelles origines, en augmentant progressivement la part de trafic qu’elles en gèrent jusqu’à atteindre la majeure partie, puis désactivez et supprimez les origines moins privilégiées.
• Le cloud bursting pour une capacité additionnelle : élargissez les déploiements locaux au cloud en ajoutant ou en activant des origines supplémentaires et en spécifiant la répartition du trafic.

Affinité de session

Par défaut, Azure Front Door transfère les requêtes émanant d’un même client vers différentes origines. Cependant, l’affinité de session est utile pour les applications avec état ou les scénarios où les requêtes suivantes provenant d’un même utilisateur doivent être traitées par la même origine. Cette fonctionnalité est l’assurance qu’une même origine gère la session d’un utilisateur, ce qui est bénéfique dans certains scénarios comme l’authentification client.

Azure Front Door utilise l’affinité de session basée sur les cookies, où les cookies gérés avec SHA256 de l’URL d’origine sont utilisés en tant qu’identificateur. Le trafic suivant d’une session utilisateur est alors dirigé vers la même origine.

L’affinité de session peut être activée au niveau du groupe d’origines dans les niveaux Standard et Premium d’Azure Front Door, et au niveau de l’hôte front-end dans Azure Front Door (classique) pour chaque domaine ou sous-domaine configuré. Une fois cette fonctionnalité activée, Azure Front Door ajoute des cookies nommés ASLBSA et ASLBSACORS à la session de l’utilisateur. Ces cookies permettent d’identifier différents utilisateurs même s’ils partagent la même adresse IP, ce qui permet une distribution plus uniforme du trafic entre les origines.

La durée de vie des cookies est identique à celle de la session de l’utilisateur, car Front Door ne prend actuellement en charge que les cookies de session.

Remarque

L’affinité de session est maintenue via le cookie de session du navigateur au niveau du domaine. Les sous-domaines dépendant d’un même domaine générique peuvent partager l’affinité de session tant que le navigateur de l’utilisateur envoie des requêtes pour la même ressource d’origine.

Les proxies publics peuvent contrarier l’affinité de session, car l’établissement d’une session nécessite que Front Door ajoute un cookie d’affinité de session à la réponse. Cela n’est pas possible si la réponse est susceptible d’être mise en en cache, car cela perturberait les cookies pour les autres clients demandant la même ressource. Pour éviter cela, l’affinité de session n’est pas établie si l’origine envoie une réponse pouvant être mise en cache. Si la session est déjà établie, l’aptitude de la réponse à être mise en cache n’a pas d’importance.

L’affinité de session est établie dans les circonstances suivantes au-delà des scénarios non mis en cache standard :

• La réponse comprend l’en-tête Cache-Control avec no-store.
• La réponse contient un en-tête Authorization valide.
• La réponse est un code d'état HTTP 302.

Étapes suivantes

• Découvrez comment créer un service Azure Front Door.
• Découvrez comment fonctionne Azure Front Door.