Fastly Origin Shielding : configuration, vérification et déploiement sûrs

Sans shielding, chaque POP Fastly peut récupérer indépendamment un objet absent de son cache local. Avec le shielding, un miss de périphérie local va d'abord vers un POP de shield désigné. Si le shield possède l'objet, il répond au POP de périphérie sans requête à l'origine ; seul un miss de shield atteint l'origine. Cela crée une deuxième couche de cache partagé et concentre le trafic à destination de l'origine via un POP.

Cette topologie est utile pour le contenu pouvant être mis en cache et demandé mondialement, ainsi que pour contrôler la pression de connexion sur l'origine. Ce n'est pas un contrôle d'accès, cela n'empêche pas le trafic direct vers l'origine et ce n'est pas une amélioration universelle de la latence. Un edge hit reste le chemin le plus court. Un miss local qui se déplace vers un shield ajoute un saut interne, et un shield mal situé peut dégrader le chemin de miss. Mesurez le résultat pour vos routes et régions d'utilisateurs plutôt que de traiter la fonctionnalité comme une valeur par défaut.

Prérequis et périmètre

Avant de modifier le service, disposez d'un service Fastly actif avec une version connue comme fiable, d'un inventaire documenté des backends, de l'autorisation de cloner et d'activer des versions, de l'accès aux logs d'origine et Fastly, et d'un domaine de test représentatif. Identifiez pour chaque backend sa région physique ou cloud, son nom DNS, le nom de certificat TLS, l'en-tête Host attendu, la politique de cache, le chemin de contrôle de santé et la limite de capacité.

Choisissez un périmètre initial d'un backend pouvant être mis en cache, à forte lecture, et d'un petit ensemble de chemins. Excluez les pages authentifiées, les écritures, les flux de paiement ou d'inventaire et le trafic PASS volontairement non mis en cache de la première expérience. Ces requêtes peuvent toujours transiter par un shield lorsqu'elles sont transmises à un backend, mais ne bénéficient pas du même cache partagé et peuvent accroître le trafic interne.

Enregistrez une référence sur au moins un cycle de trafic normal : taux de requêtes et de sortie d'origine, nombre de connexions d'origine et latence p95, distribution de l'état du cache Fastly, erreurs de périphérie et d'origine, latence client p95/p99 par région et bande passante de diffusion. Définissez un seuil de restauration avant de modifier la configuration.

1. Sélectionner une région de shield par origine

Utilisez l'API Fastly POP ou le panneau de contrôle Fastly pour obtenir les identifiants de shield valides. Le nom humain du POP et l'identifiant de shield ne sont pas nécessairement les mêmes. Par exemple, la documentation de shielding Fastly distingue le nom du POP Amsterdam de son identifiant de shield amsterdam-nl.

Sélectionnez le shield principalement selon la proximité et la qualité réseau du backend, non selon la localisation moyenne des visiteurs. Un shield proche de l'origine peut réduire le coûteux segment vers l'origine et rendre un cache partagé plus efficace. Testez ensuite le chemin complet depuis les régions utilisateur importantes. Une audience mondialement distribuée avec une origine unique bénéficie souvent d'un shield près de cette origine ; les origines géographiquement séparées doivent normalement avoir des shields choisis indépendamment.

Utilisez cette table de décision avant de choisir un emplacement :

La documentation Fastly recommande de sélectionner un centre de données proche du backend et note que chaque backend peut posséder son propre shield. Ne sélectionnez pas un shield sur la seule base d'une carte. Testez la résolution DNS, le handshake TLS, le premier octet et le débit d'origine soutenu via le chemin visé.

2. Cloner la version active et affecter le shield

Effectuez ce changement dans une nouvelle version de service. Dans le panneau de contrôle Fastly, sélectionnez le service, choisissez Edit configuration et clonez la version active. Ouvrez Origins, choisissez le backend et sélectionnez l'emplacement de shield dans le menu Shielding. Enregistrez le changement de backend. Répétez pour chaque backend dans le périmètre, en utilisant l'emplacement choisi pour ce backend plutôt que de copier aveuglément un emplacement.

Pour une configuration gérée par API ou CLI, définissez la propriété shield de l'objet backend sur l'identifiant de shield. L'exemple Fastly CLI suit cette forme :

fastly backend create \
  --name=app_origin \
  --address=origin.example.net \
  --shield=amsterdam-nl \
  --service-id="$FASTLY_SERVICE_ID" \
  --version=latest

Utilisez cette commande uniquement comme modèle pour un nouveau backend dans la version modifiable visée. L'automatisation de production doit aussi définir ses paramètres requis de TLS, délai d'attente, contrôle de santé, host override et connexion. Mettre à jour seulement shield sur un backend existant est généralement plus sûr que de le recréer, car un paramètre omis peut modifier le comportement du backend.

Si vous modifiez l'en-tête de requête Host avant qu'il atteigne le shield, ajoutez le nom d'hôte modifié à la liste des domaines du service. Fastly utilise l'hôte entrant pour identifier le service au shield ; un hôte modifié inconnu peut produire un 500. Préférez le paramètre backend override_host pour le saut final vers l'origine plutôt que de modifier Host tôt dans une logique personnalisée.

Validez la version clonée et examinez le diff. Confirmez que le backend sélectionné possède toujours l'adresse attendue, la validation de certificat TLS, SNI, le contrôle de santé, le budget de délai d'attente, les conditions, endpoints de journalisation et la politique de cache. Gardez la version active intacte et immédiatement activable pour la restauration.

3. Comprendre le chemin de cache miss avant de l'activer

Pour un objet avec une clé de cache partagée correcte, les chemins de requête sont :

1. Edge HIT : le POP de périphérie renvoie son objet en cache. Le shielding et l'origine ne sont pas impliqués.
2. Edge MISS, shield HIT : le POP de périphérie transmet au shield. Le shield renvoie son objet en cache, qui peut alimenter le POP de périphérie. L'origine ne reçoit aucune requête.
3. Edge MISS, shield MISS : le POP de périphérie transmet au shield, et le shield récupère depuis l'origine. La réponse peut être mise en cache aux deux niveaux selon la politique de cache.
4. Requête backend PASS ou non cacheable : la requête utilise toujours le chemin de shield lorsqu'elle est transmise au backend, mais ne bénéficie pas d'un cache hit réutilisable. Évaluez ce trafic séparément.

C'est pourquoi le shielding peut réduire la charge d'origine sans augmenter chaque edge cache hit des visiteurs. Cela explique aussi pourquoi le taux global de cache hit Fastly peut sembler plus faible que prévu : un edge miss et shield hit comptent à la fois comme un miss et un hit, tandis qu'une récupération d'origine via le shield peut enregistrer deux misses. Utilisez les métriques brutes de requête, hit, miss, shield et origine plutôt qu'un seul ratio agrégé comme unique critère de réussite.

Assurez-vous que la clé de cache ne mélange pas les utilisateurs, droits, variantes de langue ou en-têtes sensibles à la sécurité. N'utilisez pas le shield pour masquer une politique Vary non sûre. Si vous modifiez les directives de cache, préférez un Surrogate-Control explicite pour la fraîcheur côté Fastly et Cache-Control pour la fraîcheur côté navigateur lorsque ces exigences diffèrent.

4. Tester prudemment sur un domaine hors production

Activez d'abord la configuration clonée sur un service de développement ou de staging, ou utilisez un domaine et une origine isolés représentatifs. Réchauffez un ensemble d'objets publics connus par des requêtes répétées, puis émettez des requêtes depuis plus d'une région externe. Gardez les objets de test séparés du contenu spécifique aux clients et utilisez un TTL court et documenté afin que le test soit facile à invalider.

Utilisez curl -I ou votre exécuteur de tests HTTP pour capturer les en-têtes et conserver la sortie avec l'horodatage, la région de test, l'URL, l'état de réponse, Age, les en-têtes liés au cache, l'ID de requête et la version de déploiement. Les en-têtes de débogage exacts de Fastly et la présentation de l'état du cache dépendent de la configuration du service ; traitez donc les noms d'en-tête comme des signaux de diagnostic, pas comme un contrat applicatif. N'exposez pas les en-têtes de débogage temporaires à tous les utilisateurs.

À l'origine, journalisez un ID de corrélation sûr avec le modèle de chemin, l'état, la latence, la source de requête et l'identité d'amont sélectionnée. Exécutez cette séquence :

1. Demandez un objet public froid depuis la région A et confirmez une récupération d'origine attendue.
2. Demandez le même objet depuis la région B après que la région A a rempli le shield ; confirmez la réponse attendue et recherchez un service de cache shield plutôt qu'une autre récupération d'origine.
3. Répétez après l'expiration du TTL et pendant une purge contrôlée pour observer le comportement de regroupement des misses et la capacité d'origine.
4. Testez une route non cacheable et une route privée pour garantir qu'aucune ne devient du contenu de cache partagé.
5. Rendez temporairement l'origine de staging lente ou non saine et confirmez le délai configuré, le comportement d'erreur visible par l'utilisateur, l'alerte et la décision de restauration.

Les tests Compute locaux peuvent simuler des sites de shielding dans fastly.toml, mais ne peuvent pas prouver le routage global Fastly, la topologie réelle de cache ou la latence inter-POP. Utilisez-les pour les tests de logique ; utilisez un service isolé en direct pour la vérification du chemin et du cache.

5. Observer les en-têtes, logs et la charge d'origine

Ajoutez un tableau de bord qui compare la référence et la période de déploiement par route, backend et région utilisateur :

• edge hits, edge misses, shield hits, shield misses et taux de requêtes d'origine
• réponses Fastly et d'origine 4xx/5xx, délais d'attente des backends et état des contrôles de santé
• latence client et backend p50/p95/p99, séparée par hit et miss lorsque possible
• connexions d'origine, CPU, files d'attente, sortie et événements de limite de débit d'amont
• utilisation Fastly des requêtes et de la bande passante, y compris les implications de trafic inter-POP

Corrélez les logs Fastly et d'origine avec un ID de requête ou de trace. Capturez le résultat de cache, le POP ou la région lorsque permis, le nom du backend, la version, la durée d'origine et une raison d'échec sûre. Ne journalisez pas les cookies, en-têtes d'autorisation, chaînes de requête signées ni corps de réponse privés.

Vérifiez le comportement attendu par des preuves, pas seulement par une moyenne de tableau de bord. Un essai réussi montre moins de requêtes d'origine dupliquées pour le même objet cacheable, une saturation d'origine stable ou améliorée, aucune fuite de cache inattendue et une latence acceptable dans les régions utilisateur. Un shield hit évite une récupération d'origine mais peut néanmoins être plus lent qu'un edge hit local ; comparez chaque chemin séparément.

6. Déployer progressivement et restaurer rapidement

Activez d'abord le shielding pour un backend ou groupe de routes. Observez-le pendant une période de pointe complète, un cycle d'expiration de cache et un déploiement d'origine courant si possible. N'étendez que lorsque la réduction de charge d'origine et les résultats de latence utilisateur respectent les seuils convenus. Si un système de gestion de configuration prend en charge les environnements, promouvez la version revue à travers eux ; n'effectuez pas de modifications manuelles de production inexpliquées entre les étapes.

La restauration n'est simple que si elle est préparée :

1. Conservez dans l'enregistrement de changement le numéro de version active actuel et la version antérieure connue comme fiable.
2. Si les erreurs, la latence, la sécurité du cache ou le comportement d'origine dépassent une condition d'arrêt, activez la version antérieure sans affectation de shield.
3. Vérifiez l'état de version active, les requêtes synthétiques, le trafic d'origine et les logs liés au cache après propagation.
4. Conservez la version défaillante, les logs, les échantillons de requête dont les valeurs sensibles ont été retirées et les métriques pour l'analyse de cause racine.

N'essayez pas de résoudre aveuglément un incident d'origine en activant le shielding. Si l'origine est surchargée, le shielding peut réduire les cache misses dupliqués, mais il ne peut pas satisfaire une charge de travail non cacheable ni restaurer une dépendance non saine. Appliquez d'abord la politique de surcharge, de basculement et de contenu obsolète du service là où elles sont sûres.

Réserves de redondance, sécurité et configuration

Le shielding présente des compromis opérationnels importants :

• Accessibilité du shield : si un POP de shield configuré est inaccessible pour une requête, Fastly peut envoyer cette requête directement du POP de périphérie à l'origine. Les contrôles d'origine et la capacité doivent tolérer ce chemin de contournement.
• Sécurité de l'origine : le shielding n'est ni une liste d'autorisation ni un pare-feu. Maintenez l'accès direct à l'origine restreint par réseau privé ou contrôles de sources Fastly, ainsi qu'une authentification périphérie-vers-origine. Testez le chemin direct vers l'origine indépendamment.
• Origines multiples : configurez et évaluez le shielding par backend. Avec l'équilibrage de charge automatique, Fastly documente des contraintes de configuration autour de l'utilisation de plusieurs shields ; consultez la documentation produit actuelle avant de combiner les deux.
• Gestion de Host : Fastly identifie le service à l'aide de l'hôte sur la requête interne. Conservez un hôte reconnu par le service jusqu'au dernier saut d'origine ou utilisez override_host sur le backend.
• VCL et Compute personnalisés : VCL s'exécute à la fois à la périphérie et au shield lorsque le shielding est actif. Le shielding Compute est explicite dans le SDK et peut s'exécuter deux fois. Rendez le routage, les changements d'en-tête, les métriques et les effets de bord idempotents et conscients du contexte d'exécution.
• Adresse client : au shield, le client immédiat peut être un autre POP Fastly. Utilisez le comportement de transfert d'IP client documenté par Fastly seulement après avoir défini la frontière de confiance du proxy ; ne traitez pas un en-tête transféré arbitraire comme une identité authentifiée.
• Coût et capacité : le trafic inter-POP contribue aux requêtes et à la bande passante. Mesurez le trafic Fastly ajouté face aux économies de sortie et de capacité d'origine.

Liste de contrôle opérationnelle

Avant l'activation en production, confirmez que chaque backend possède un identifiant de shield justifié ; que les domaines et le host override fonctionnent sur le saut interne ; que TLS et les contrôles de santé sont intacts ; que les clés de cache isolent le contenu privé ; que l'origine peut tolérer le contournement du shield ; que les en-têtes et logs prouvent le chemin de cache miss attendu ; que les tableaux de bord séparent les résultats de périphérie, shield et origine ; et qu'une version connue comme fiable sans shielding est prête à être activée.

Références Fastly principales

• Guide de configuration du shielding
• Concepts, effets et scénarios avancés du shielding
• Référence API backend
• Référence API des versions de service Fastly
• Référence du serveur local fastly.toml
• Tester et déboguer sur la plateforme Compute