Livraison d’un contenu global stratégique

Les réseaux de distribution de contenu (CDN) offrent une gamme de fonctionnalités permettant d’optimiser les performances pour les utilisateurs, notamment l’équilibrage de charge de la couche 7 globale et le routage réseau optimisé. La mise en cache est également un moyen courant de réduire la charge sur les services principaux et de fournir une résilience supplémentaire à un éventail de problèmes. Les CDN, y compris Azure Front Door, fournissent une mise en cache sur la périphérie du réseau.

Les CDN sont un composant essentiel dans certaines architectures de solution. Il s’agit donc d’une pratique recommandée pour les charges de travail stratégiques afin d’utiliser plusieurs CDN pour atteindre un niveau de temps d’activité plus élevé. Si un CDN rencontre une panne ou une dégradation des performances, votre trafic est automatiquement redirigé vers un autre CDN.

Comme mentionné dans l’article précédent de cette série, Azure Front Door est conçu pour fournir la plus grande résilience et la disponibilité non seulement pour nos clients externes, mais également pour plusieurs propriétés dans Microsoft. Bien que Microsoft offre un contrat de niveau de service (SLA) de premier plan pour Azure Front Door, si vous disposez d’une application stratégique qui exige un contrat SLA encore plus élevé, vous devez vous appuyer sur plusieurs CDN. Tenez compte des implications de cette approche. Chaque CDN fournit un chemin réseau distinct vers vos serveurs d’applications, et vous devez configurer et tester chaque CDN séparément.

Cet article décrit une approche de l’utilisation d’Azure Front Door avec un autre CDN. Cette approche convient aux solutions qui s’appuient fortement sur la mise en cache pour fournir des applications de distribution de contenu statique, de média et de commerce électronique à grande échelle.

Remarque

Ce cas d’usage fait partie d’une stratégie de conception globale qui couvre une autre approche lorsque Azure Front Door n’est pas disponible. Pour plus d’informations sur le contexte et les considérations, consultez les applications web globales critiques.

Approche

Un CDN tiers peut être intégré à votre solution Azure pour fournir une isolation de l’infrastructure de Microsoft. Cette isolation offre un degré élevé de résilience face aux scénarios de sinistre. Si une panne ou un sinistre se produit, le trafic est automatiquement déplacé entre Azure Front Door et l’autre CDN. Vous pouvez utiliser Azure Traffic Manager pour détecter une panne et rediriger le trafic vers l’autre CDN.

Remarque

Microsoft propose un service d’interconnexion CDN pour acheminer votre trafic d’origine vers un autre CDN avec zéro frais de transfert de données. Pour plus d’informations, consultez Préférences de routage.

Le diagramme suivant montre comment le trafic circule entre les CDN :

• Traffic Manager utilise le mode de routage pondéré, a deux points de terminaison et est configuré pour toujours servir le trafic.

  Pendant les opérations normales, Traffic Manager envoie toutes les requêtes via Azure Front Door.

  Si Azure Front Door devient indisponible, désactivez le point de terminaison Azure Front Door. Traffic Manager envoie ensuite toutes les requêtes via le CDN de remplacement.

• Azure Front Door traite et route la plupart du trafic de votre application. Azure Front Door achemine le trafic vers le serveur d’applications d’origine approprié et fournit le chemin principal de votre application. Si Azure Front Door n’est pas disponible, le trafic est automatiquement redirigé via le chemin secondaire.

• Un autre CDN est configuré pour envoyer le trafic à chaque serveur d’origine.

• Vos serveurs d’applications d’origine doivent être prêts à accepter le trafic à partir d’Azure Front Door et d’un autre CDN, à tout moment.

Considérations

Les considérations décrites dans les applications web globales stratégiques s’appliquent toujours à ce cas d’usage. Voici quelques points supplémentaires :

Choix du CDN

Microsoft propose plusieurs produits CDN. Notre offre phare est Azure Front Door Standard et Premium, et la mise hors service a été annoncée pour tous les autres produits CDN. Les autres produits partagent également l’infrastructure physique avec Azure Front Door. Nous vous recommandons donc de sélectionner un autre produit CDN pour le type d’architecture décrit dans cet article. Veillez à sélectionner un autre CDN répondant à vos besoins en matière de fonctionnalités, de temps d’activité et de coût.

Vous pouvez choisir d’utiliser plus de deux CDN en fonction de vos besoins et de votre tolérance au risque.

Parité des fonctionnalités

Azure Front Door fournit des fonctionnalités distinctes de nombreux CDN et les fonctionnalités ne sont pas équivalentes entre les produits. Par exemple, il peut y avoir des différences dans la gestion des certificats TLS, du pare-feu d’applications web (WAF) et des règles de routage HTTP.

Examinez attentivement les fonctionnalités d’Azure Front Door que vous utilisez et indiquez si votre autre CDN dispose de fonctionnalités équivalentes. Pour plus d’informations, consultez Cohérence des chemins d’entrée.

Remplissage du cache

Pour de nombreuses situations, une approche de routage actif-passif est logique. Pendant les opérations normales, tout le trafic est dirigé vers Azure Front Door et contourne l’autre CDN. Pour obtenir cette configuration, activez le point de terminaison Traffic Manager pour Azure Front Door et désactivez le point de terminaison de votre autre CDN.

Toutefois, si vous exécutez plusieurs CDN en mode actif-passif, le CDN passif doit effectuer un remplissage de cache depuis votre serveur d'origine lorsque le basculement se produit.

Testez le basculement entre Azure Front Door et votre autre CDN pour détecter les anomalies ou les problèmes de performances. Si votre solution risque de rencontrer des problèmes de performances pendant les remplissages du cache, envisagez ces approches pour réduire le risque :

• Étendez horizontalement ou augmentez la capacité de vos sources d'origine pour gérer des niveaux de trafic plus élevés, notamment lors d’un rafraîchissement de cache.

• Remplissez les deux CDN en servant un pourcentage de votre contenu le plus populaire via le CDN passif avant qu’un événement de basculement ne se produise. Configurez le mode de routage du trafic pondéré pour envoyer une petite partie du trafic à l’autre CDN afin qu’il soit prêt à servir le trafic de production à tout moment.

Sous-domaines

Vous pouvez combiner le routage au niveau de l’application et la distribution de contenu. Par exemple, les ressources statiques peuvent tirer parti de la mise en cache, tandis que votre application web principale peut ne pas utiliser la mise en cache.

Dans ce scénario, envisagez de placer vos ressources de contenu sur un sous-domaine dédié afin de pouvoir les reconfigurer indépendamment du routage du serveur d’applications.

Compromis

L’utilisation de plusieurs CDN entraîne certains compromis.

• Il peut y avoir une augmentation du coût global de la solution. Lorsque vous déployez une architecture qui utilise plusieurs CDN, vous êtes facturé pour chacune d’elles. Vérifiez que vous comprenez comment vous êtes facturé pour chaque CDN de votre solution et tous les autres composants que vous déployez.

• Chaque composant supplémentaire que vous ajoutez à votre solution augmente votre surcharge de gestion.

• Il peut y avoir des problèmes de performances pendant le basculement entre Azure Front Door et votre autre CDN.

• En utilisant un gestionnaire de trafic DNS, vous pouvez aléatoirer le CDN choisi pour une demande. Si vous n’êtes pas prudent d’implémenter des paramètres de cache cohérents entre les CDN (par exemple, la mise en cache dans Azure Front Door), vous risquez de réduire les performances et les coûts plus élevés pour la bande passante de sortie d’origine.

• Un problème courant est le remplissage du cache lorsque les CDN s’exécutent en mode actif-passif. Le CDN configuré en mode passif doit remplir son cache à partir de l’origine. Il peut surcharger les systèmes d’origine pendant ce processus.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

• Dave Burkhardt | Responsable du programme principal, Azure Front Door
• John Downs | Ingénieur logiciel principal, modèles Azure & Pratiques
• Akhil Karmalkar | Responsable du programme principal, Azure Front Door
• Priyanka Wilkins | Principal Content Developer, Azure Patterns &Practices

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Passez en revue le scénario d’entrée HTTP global pour comprendre s’il s’applique à votre solution.