Présentation de l'invalidation de cache

Cette page présente l'invalidation de cache Cloud CDN.

Qu'est-ce qu'une invalidation de cache ?

Une fois qu'un objet est mis en cache, il reste normalement dans le cache jusqu'à son expiration ou sa suppression pour laisser la place à un nouveau contenu. Vous pouvez vouloir supprimer un objet du cache avant son délai d'expiration normal. Vous pouvez forcer le cache à ignorer un objet ou un ensemble d'objets en demandant l'invalidation du cache.

L'invalidation de cache, parfois appelée suppression définitive de cache, est le processus permettant de déclarer un contenu mis en cache comme non valide. Cela entraîne la suppression de l'entrée du cache, puis le remplissage à partir du serveur backend la prochaine fois que le contenu est demandé.

Cloud CDN accepte l'utilisation de tags de cache et des outils de mise en correspondance des invalidations, tels que l'hôte et le chemin d'URL, pour les demandes d'invalidation.

Vous pouvez combiner ces paramètres d'invalidation pour cibler des réponses mises en cache spécifiques et minimiser la charge sur le backend lors du prochain remplissage du cache.

Il est important de vous assurer que le serveur backend renvoie le bon contenu avant de demander l'invalidation de cache. Sinon, lorsque Cloud CDN redemande le contenu, il peut mettre en cache le mauvais contenu.

Les demandes d'invalidation ont un débit limité. Vous pouvez envoyer jusqu'à 500 demandes d'invalidation par minute. Chaque demande d'invalidation prend effet en 10 secondes environ.

Cloud CDN ne limite pas le nombre d'objets ni la taille totale de tous les objets invalidés pour chaque demande.

Invalidation par URL

Chaque demande d'invalidation spécifie un format de chemin identifiant l'objet ou l'ensemble d'objets à invalider. Le format de chemin d'accès peut être un chemin spécifique, tel que /cat.jpg, ou une structure de répertoires complète, telle que /pictures/*. Les règles suivantes s'appliquent aux formats de chemin :

  • Le format de chemin doit commencer par /.
  • Il ne peut pas inclure ? ni #.
  • Il ne doit pas inclure d'astérisque *, sauf comme caractère final après une barre oblique /.
  • S'il se termine par /*, la chaîne qui précède est un préfixe et tous les objets dont le chemin commence par ce préfixe sont invalidés.

Le format de chemin s'apparente au composant de chemin de l'URL, correspondant aux éléments placés entre le nom d'hôte et tout caractère ? ou # éventuellement présent.

Si des URL contiennent une chaîne de requête telle que /images.php?image=fred.png, vous ne pouvez pas invalider de manière sélective des objets qui diffèrent uniquement par cette chaîne de requête. Par exemple, si vous disposez de deux images, /images.php?image=fred.png et /images.php?image=barney.png, vous ne pouvez pas invalider uniquement fred.png. Pour invalider toutes les images diffusées par images.php, utilisez /images.php comme format de chemin.

Invalidation pour un seul hôte

L'invalidation de cache invalide le chemin pour tous les noms d'hôte. Par exemple, si example.com et example2.com pointent vers le même équilibreur de charge et que vous invalidez /images/cat.jpg, example.com/images/cat.jpg et example2.com/images/cat.jpg sont tous deux invalidés.

Vous pouvez limiter l'invalidation à un seul hôte en le spécifiant.

Invalidation par tags de cache

Les tags de cache (ou clés de substitution) vous permettent d'invalider du contenu en fonction de métadonnées arbitraires.

Ces tags sont définis avec l'en-tête HTTP Cache-Tag dans une réponse de backend. Les tags de cache du backend dans l'en-tête de réponse HTTP Cache-Tag sont envoyés au client.

Les tags de cache sont soumis aux limites suivantes :

  • Un tag ne doit pas dépasser 120 octets.
  • Le total des noms de tags ne doit pas dépasser 4 Kio (4 096 octets) par objet mis en cache.
  • Un objet ne peut pas comporter plus de 50 tags.

Si ces limites de tags sont dépassées, la réponse n'est pas mise en cache et cette décision est enregistrée en tant que RESPONSE_CACHE_TAG_INVALID dans LoadBalancerLogEntry.cacheDecision.

Vous pouvez spécifier jusqu'à 10 tags de cache par requête d'invalidation. Lorsque plusieurs tags sont spécifiés dans une même requête d'invalidation, ils sont traités avec un comportement identique à l'opérateur logique OR. Imaginons un exemple dans lequel vous disposez des objets mis en cache suivants :

  • Objet en cache N°1, portant les tags js, 2020-12-23 et prod
  • Objet en cache N°2, portant les tags css, 2020-11-30 et prod
  • Objet en cache N°3, portant les tags img, 2020-11-30 et staging

Lorsque vous envoyez une demande pour invalider les objets correspondant à tags="prod,2020-11-30", les trois objets mis en cache sont invalidés. Cette approche signifie que vous n'avez pas besoin de connaître ni de spécifier toutes les combinaisons de tags possibles lorsque vous souhaitez invalider un objet.

Si vous spécifiez des critères de correspondance pour l'invalidation en même temps que des tags de cache, la demande d'invalidation ne s'applique qu'aux objets tagués qui correspondent aux critères de correspondance pour l'invalidation. Prenons l'exemple des objets mis en cache suivants :

  • Objet en cache n°1 avec l'URL https://staging.example.com/img/cat.jpg et le tag a
  • Objet en cache n°2 avec l'URL https://example.com/img/cat.jpg et le tag a
  • Objet en cache n°3 avec l'URL https://staging.example.com/js/cat.js et le tag a
  • Objet en cache n°4 avec l'URL https://staging.example.com/img/logo.jpg et le tag b

Lorsque vous envoyez une demande pour invalider des objets dont l'hôte est staging.example.com, le chemin d'accès /img/* et le tag a, seul l'objet n°1 est invalidé. Les objets n°2, n°3 et n°4 ne correspondent pas à l'hôte, au chemin d'accès ni au tag, respectivement.

Latence d'invalidation

Cloud CDN étant un système distribué, il peut signaler qu'une invalidation est terminée même si un petit nombre de caches n'ont pas encore traité la demande d'invalidation. Cette situation est extrêmement rare et se corrigera automatiquement.

Bonnes pratiques

N'effectuez une invalidation que si cela est indispensable : un nombre excessif d'invalidations peut provoquer un important pic de demandes diffusées par les caches et entraîner un impact soudain sur les instances ou les buckets.

L'invalidation est destinée à être utilisée dans des circonstances exceptionnelles et non dans le cadre de votre flux de travail normal. Les invalidations sont sans incidence sur les copies stockées dans les caches de navigateur Web ou dans les caches exploités par des fournisseurs de services Internet tiers.

À titre d'alternative aux invalidations de routine, vous pouvez définir de manière proactive des délais d'expiration appropriés pour les réponses ou employer des URL distinctes pour les différentes versions du contenu. Pour en savoir plus sur les délais d'expiration, consultez la section Délais d'expiration et requêtes de validation.

Invalidation avec le référencement de services inter-projets dans un VPC partagé

L'invalidation de cache est configurée dans le projet d'interface, c'est-à-dire le projet contenant la règle de transfert, le proxy cible et le mappage d'URL de l'équilibreur de charge. Lorsque vous utilisez un équilibreur de charge d'application externe global avec une référence de service inter-projets de VPC partagé, par défaut, les administrateurs de projet de service ne disposent pas des autorisations requises pour invalider un cache.

Les invalidations de cache ne peuvent être émises que par des comptes principaux disposant des rôles IAM permettant de configurer des ressources d'équilibreur de charge dans les projets d'interface (par exemple, le rôle Administrateur de réseau Compute [roles/compute.networkAdmin]).

Les administrateurs de services, qui contrôlent le provisionnement des services de backend dans un projet distinct, peuvent collaborer avec l'administrateur de l'équilibreur de charge du projet d'interface pour émettre une invalidation de cache pour leurs services inter-projets. Pour les réécritures d'URL, assurez-vous que l'invalidation correspond à l'hôte et au chemin d'accès avant réécriture que le client envoie.

Étapes suivantes