Mise en cache Fastly avec VCL : tutoriel sécurisé pour la production

Fastly peut rendre une réponse publique rapide et peu coûteuse à servir, mais une clé de cache ou un TTL incorrect peut exposer la représentation d'un utilisateur à un autre ou conserver du contenu obsolète plus longtemps que le produit ne l'autorise. Ce tutoriel propose un déploiement restreint et observable pour les ingénieurs DevOps et web qui exploitent un service Fastly VCL.

Prérequis

Avant de modifier le trafic de production, disposez de tous les éléments suivants :

• Un accès permettant de créer et d'activer une nouvelle version du bon service Fastly. Confirmez son ID de service, ses domaines et l'équipe propriétaire de l'origine.
• Une version active connue comme fiable et une personne nommément autorisée à la réactiver. Les configurations de service Fastly sont versionnées ; l'activation est une action opérationnelle distincte de la modification.
• Une URL de test d'origine ou un objet public à faible risque dont la réponse est stable, non personnalisée et sûre à mettre en cache.
• Un moyen de comparer la charge d'origine, le taux d'erreur, l'état du cache et un parcours utilisateur représentatif avant et après le changement.
• Un contrat d'origine pour la route : méthodes autorisées, comportement d'authentification, cookies, paramètres de requête, variantes de contenu, responsable de l'invalidation et obsolescence maximale acceptable.

Ne commencez pas par la connexion, le paiement, le compte, les résultats de recherche, les API dépendantes de l'autorisation, ni toute réponse qui définit ou reflète un état utilisateur. Une amélioration de cache qui modifie la justesse n'est pas une amélioration.

1. Cartographier le service et le chemin d'activation du backend

Dans Fastly, un service contient la configuration de diffusion. Un backend décrit l'emplacement depuis lequel Fastly récupère la réponse lorsqu'il doit joindre l'origine. Rendez cette relation explicite avant d'écrire du VCL :

1. Identifiez la version de service qui sert actuellement le nom d'hôte et conservez son numéro de version comme cible de restauration immédiate.
2. Confirmez quel backend sert la route de test, y compris son adresse, les attentes concernant l'en-tête Host, le comportement de santé, les paramètres TLS, les délais d'attente et toute configuration de shielding existante.
3. Clonez ou créez autrement une version de service modifiable conformément aux recommandations de Fastly sur le versionnement des services. Ne modifiez pas une configuration de production sans connaître la version que vous activerez et celle que vous rétablirez.
4. Ajoutez la modification de backend ou de VCL uniquement à la nouvelle version, examinez le diff généré avec le propriétaire de l'origine, puis activez cette version dans un créneau planifié. Le guide des backends de Fastly présente les concepts et le comportement de configuration des backends.

L'activation modifie le trafic réel ; la création d'une version de brouillon ne le fait pas. Conservez un court enregistrement du changement contenant l'ID de service, les anciennes versions et candidates, les routes concernées, l'état de cache attendu, la requête de validation et la version de restauration.

2. Définir d'abord le contrat de cache effectif

Écrivez la politique visée en langage clair avant de la traduire en en-têtes ou en VCL. Par exemple : « GET /assets/* est public, varie uniquement selon le chemin normalisé, reste frais chez Fastly pendant une heure, peut rester obsolète pendant cinq minutes pendant la revalidation et doit pouvoir être purgé lors d'une livraison. »

Fastly détermine la fraîcheur à partir des en-têtes de réponse d'origine dans l'ordre de priorité documenté : Surrogate-Control, puis Cache-Control: s-maxage, puis Cache-Control: max-age, puis Expires. Surrogate-Control est utile lorsque les navigateurs nécessitent une politique plus courte que Fastly. Pour l'ordre de priorité exact et les divergences documentées avec RFC 9111, consultez À propos des en-têtes de contrôle du cache et Fraîcheur du cache.

VCL peut remplacer la durée de vie en périphérie. Dans vcl_fetch, beresp.ttl contrôle le TTL de l'objet mis en cache par Fastly ; réécrire beresp.http.Cache-Control à cet endroit ne modifie pas rétroactivement le TTL déjà calculé par Fastly. Inversement, modifier uniquement beresp.ttl ne définit pas le comportement du navigateur. Séparez intentionnellement les politiques de périphérie et de navigateur.

sub vcl_fetch {
  if (bereq.url.path ~ "^/assets/") {
    set beresp.ttl = 1h;
    set beresp.stale_while_revalidate = 5m;
  }
}

Cet exemple est un point de départ, pas une politique à copier-coller. Définissez un comportement obsolète seulement lorsque le propriétaire du contenu accepte de servir une représentation plus ancienne. Conservez ou définissez délibérément les en-têtes destinés au navigateur séparément, et testez la réponse produite par votre véritable origine.

3. Garder la clé de cache minimale et sûre

La clé de cache par défaut de Fastly utilise l'URL et l'en-tête Host. Ne la modifiez que lorsque le contrat applicatif l'exige. Chaque dimension ajoutée réduit la réutilisation ; chaque dimension de représentation omise peut renvoyer le mauvais contenu.

Pour chaque route candidate, documentez les questions suivantes :

• Quelle normalisation de chemin est sûre ? Ne fusionnez pas les chemins si l'origine les distingue.
• Quels paramètres de requête modifient la représentation ? Ne supprimez les paramètres de suivi connus qu'après avoir prouvé qu'ils n'affectent pas la réponse.
• La langue, le format de l'appareil, l'affectation d'expérience ou un en-tête de requête modifie-t-il la réponse ? Préférez une politique Vary contrôlée lorsqu'elle est appropriée plutôt qu'une clé personnalisée non examinée.
• Des cookies, Authorization, un en-tête de session ou un identifiant de compte peuvent-ils influencer le corps ? Si oui, ne placez pas cette réponse dans un cache public partagé sans clé délibérément isolée et revue de sécurité.

Évitez d'utiliser une valeur brute de cookie ou d'autorisation dans une clé partagée. Cela fragmente le cache, risque d'exposer des données sensibles dans les surfaces opérationnelles et peut encore être incorrect si d'autres entrées d'identité sont omises. Les bonnes pratiques de mise en cache de Fastly abordent le comportement de clé par défaut et le compromis entre fragmentation et fusion dangereuse.

4. Utiliser pass délibérément, pas comme raccourci de débogage

return(pass) est un contrôle de justesse pour les requêtes ou réponses qui ne doivent pas être servies par le chemin normal du cache. Un pass de requête dans vcl_recv ignore la recherche et le regroupement des requêtes. Un pass de réponse dans vcl_fetch intervient après une recherche et une récupération d'origine ; Fastly indique que cela crée un objet hit-for-pass dont le TTL affecte les requêtes suivantes.

sub vcl_recv {
  if (req.method != "GET" && req.method != "HEAD") {
    return (pass);
  }

  if (req.http.Authorization || req.http.Cookie ~ "session=") {
    return (pass);
  }
}

Les noms de route et de cookie ci-dessus sont des exemples. N'ajoutez pas de pass général sur les cookies sans mesurer la perte de possibilité de mise en cache, et ne les supprimez pas tant que le contrat de réponse ne prouve pas que l'objet est public. Pour la différence entre les comportements de pass de requête et de réponse, y compris hit-for-pass, consultez les bonnes pratiques Fastly VCL.

Si vous devez forcer une récupération unique tout en conservant le comportement de cache normal, Fastly documente que req.hash_always_miss diffère de return(pass). Utilisez-le uniquement dans un test temporaire à périmètre étroit et supprimez-le après validation.

5. Ajouter le shielding seulement après avoir validé le chemin de base

Le shielding envoie les misses de périphérie vers un POP de shielding Fastly choisi avant l'origine. Il peut protéger l'origine et améliorer la réutilisation entre les POP de périphérie, mais il modifie le chemin de requête et peut faire exécuter le VCL plus d'une fois. Ajoutez-le après avoir compris le comportement de cache sans shielding, et non dans le même premier changement.

Lors de l'évaluation du shielding :

• Choisissez et testez un emplacement de shielding adapté à l'origine et à son chemin réseau.
• Vérifiez que les contrôles d'accès à l'origine autorisent le chemin de requête shielded et que les journaux d'origine conservent un ID de corrélation de requête exploitable.
• Rendez les mutations d'en-têtes de réponse sûres en cas de double exécution. Fastly recommande de distinguer le POP connecté au client lors de l'application de changements de réponse destinés au client.
• Interprétez les diagnostics de cache dans le contexte du shielding : un miss de périphérie suivi d'un hit de shield évite une requête à l'origine, tandis que les calculs globaux de cache-hit peuvent inclure les deux événements.

Lisez Shielding avant de l'activer. Cette documentation couvre la double exécution, l'interprétation de l'état du cache et le risque que les changements de réponse effectués au mauvais endroit soient mis en cache en aval.

6. Tester, activer et valider par étapes

Utilisez d'abord une route à faible risque et une version de service candidate. N'apportez pas un changement large de clé de cache et un changement large de TTL dans la même livraison.

1. Capturez une réponse de référence de l'URL de test, y compris l'état, le hash du corps, Cache-Control, Age, X-Cache, X-Cache-Hits, X-Served-By et le nombre de requêtes d'origine.
2. Exercez les variantes attendues : une requête anonyme simple, chaque langue ou représentation prévue, une requête avec paramètre de suivi et une requête authentifiée ou porteuse de cookie qui doit passer.
3. Activez la version candidate seulement après avoir consigné les résultats attendus. Envoyez un petit nombre de requêtes contrôlées, puis comparez les hashes de corps et les en-têtes avec la référence.
4. Confirmez la séquence attendue : un objet froid peut être un miss, une requête équivalente répétée devrait devenir un hit dans son TTL, et une requête qui doit passer ne devrait pas réutiliser l'objet public. Vérifiez le parcours applicatif ainsi que les en-têtes.
5. Si le shielding est activé, validez les diagnostics de périphérie et de shield, et confirmez que l'origine reçoit moins de requêtes équivalentes plutôt que de simples en-têtes de cache différents.
6. Étendez progressivement le trafic ou les routes, surveillez le taux de cache-hit avec le taux de requêtes d'origine, la latence, les erreurs et les conversions métier, puis documentez le comportement observé.

Le guide Vérifier le cache de Fastly explique les vérifications basées sur curl et les en-têtes de débogage. Considérez Fastly-Debug comme un accès de diagnostic : il peut exposer des informations normalement supprimées des réponses ; utilisez-le donc uniquement depuis des outils autorisés et ne l'exposez pas aux clients.

Restauration

La restauration doit être plus rapide que le diagnostic en cas de fuite de cache suspectée, de contenu critique obsolète ou de régression de l'origine :

1. Arrêtez d'étendre le déploiement et consignez les horodatages, les ID de requête, les motifs d'URL affectés et la version de service candidate.
2. Réactivez la version de service connue comme fiable. Vérifiez la version active, puis relancez les mêmes requêtes contrôlées.
3. Si des objets incorrects peuvent rester en cache, effectuez une purge ciblée seulement après avoir confirmé son périmètre et son propriétaire. Une purge ne corrige pas à elle seule une clé non sûre ; rétablissez d'abord un comportement sûr.
4. Confirmez que les parcours anonymes et authentifiés, la charge d'origine, le taux d'erreur et les diagnostics de cache sont revenus à l'état attendu.
5. Conservez les éléments de preuve et corrigez la version candidate hors ligne. Ne la réactivez pas sur la seule base d'un unique cache hit ou miss.

Pièges courants

• Supposer que no-cache ou no-store signifie que Fastly ne mettra pas en cache : Fastly documente une sémantique différente. Utilisez ses contrôles documentés et testez le résultat effectif.
• Modifier un en-tête de réponse et supposer que le TTL de périphérie a changé : En VCL, utilisez beresp.ttl pour le TTL Fastly ; les en-têtes de navigateur constituent une politique distincte.
• Mettre en cache une réponse qui varie selon l'identité : Une dimension de clé manquante peut divulguer des données. Passez d'abord ; concevez un contrat de cache sûr ensuite.
• Ajouter chaque paramètre de requête, cookie ou en-tête à la clé : Cela transforme un objet réutilisable en nombreux misses et peut surcharger l'origine.
• Utiliser pass partout pour faire disparaître un symptôme : Cela peut supprimer le regroupement de requêtes et masquer l'erreur sous-jacente du contrat de réponse tout en augmentant le trafic d'origine.
• Activer le shielding avec des mutations de réponse destinées au client : Le service peut s'exécuter deux fois, et une mutation au shield peut être stockée par les POP de périphérie.
• Valider uniquement X-Cache : Un hit ne prouve ni que le corps ni que la variante sont corrects. Comparez le contenu, les en-têtes, le comportement applicatif et la télémétrie d'origine.

Références Fastly principales

• Travailler avec les versions de service
• Travailler avec les backends
• À propos des en-têtes de contrôle du cache
• Fraîcheur du cache
• Écrire du code VCL
• Bonnes pratiques VCL
• Shielding
• Vérifier le cache