Méthodes de routage du trafic vers l’origine

S’applique à : ✔️ Front Door Standard ✔️ Front Door Premium ✔️ Front Door (classique)

Important

Azure Front Door (classique) va être mis hors service le 31 mars 2027. Pour éviter toute interruption de service, il est important que vous migriez vos profils Azure Front Door (classique) vers les niveaux Azure Front Door Standard ou Premium d’ici 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 back-ends 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 de routage dans Azure Front Door Standard et Premium ou remplacer le pool de serveurs principaux dans Azure Front Door (Classique) pour une requête. Le groupe d’origine ou le pool principal défini par le moteur de règles remplace le processus de routage décrit dans cet article.

Flux de décision global

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

Diagramme expliquant le mode de sélection des origines en fonction des paramètres de priorité, de latence et de poids dans Azure Front Door.

Les étapes de décision sont les suivantes :

  1. Origines disponibles : sélectionnez toutes les origines activées et saines (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 sain 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électionner les origines situées dans la plage de latence autorisée de l'environnement Front Door où la requête est arrivée. Cette plage est basée sur le paramètre de sensibilité de latence du groupe d’origine et 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 vous activez l’affinité de session, la première requête d’une session suit le flux expliqué précédemment. Les requêtes suivantes sont envoyées à l’origine sélectionnée dans la première requête.

Routage du trafic basé sur les latences les plus faibles

Le déploiement d’origines dans plusieurs emplacements globaux peut améliorer la réactivité de votre application en acheminant le trafic vers l’origine « la plus proche » de vos utilisateurs finaux. La méthode de routage par latence est sélectionnée par défaut dans les configurations d'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 vers les origines, ce qui signifie que les utilisateurs situés à différents emplacements sont acheminés vers l'origine qui offre la meilleure 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 garantir la haute disponibilité, déployez des services de sauvegarde pour prendre le relais en cas d’échec du service principal. Cette configuration est connue sous le nom de déploiement Actif/En attente ou Actif/Passif. La méthode de routage du trafic Priority dans Azure Front Door permet d'implémenter 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 de votre groupe d’origines Azure Front Door a une propriété Priority que vous pouvez définir 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

Remarque

Pour les clients avec des RPS très faibles (demandes par seconde), en raison de la nature de la distribution des POP et des machines AFD, Azure Front Door ne peut pas garantir que les pondérations que vous configurez sont strictement respectées, et la répartition de charge peut sembler déséquilibrée.

La méthode de routage du trafic pondéré distribue le trafic en fonction des pondérations prédéfinies.

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 distribué parmi les sources disponibles à l’aide d’un mécanisme de répartition circulaire basé sur les ratios de poids spécifiés, à condition que les sources satisfassent aux exigences de sensibilité à la latence acceptable. Si vous définissez la sensibilité de latence sur 0 millisecondes, les pondérations 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.
  • 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. Cette méthode dirige le trafic suivant d’une session utilisateur vers la même origine.

Vous pouvez activer l’affinité de session au niveau du groupe d’origine dans Azure Front Door niveaux Standard et Premium, ainsi qu’au niveau de l’hôte front-end dans Azure Front Door (classique) pour chaque domaine ou sous-domaine configuré. Lorsque vous activez cette fonctionnalité, 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 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

Le cookie de session du navigateur conserve l’affinité de session 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 proxys publics peuvent interférer avec 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. Cette action ne peut pas être effectuée si la réponse est mise en cache, car elle perturberait les cookies pour d’autres clients demandant la même ressource. Pour éviter ce problème, l’affinité de session n’est pas établie si l’origine envoie une réponse mise en cache. Si la session est déjà établie, la mise en cache de la réponse 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