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 une invalidation de 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. Ce processus 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 (Aperçu) et de correspondances d'invalidation, telles que l'hôte et le chemin d'accès de l'URL, pour les requêtes d'invalidation.
Vous pouvez combiner ces paramètres d'invalidation pour cibler des réponses mises en cache spécifiques et minimiser la charge du 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 requêtes d'invalidation sont limitées en débit comme suit:
- Pour les tags de cache (Aperçu), vous pouvez envoyer jusqu'à 500 requêtes d'invalidation par minute. Chaque requête d'invalidation prend effet en environ 10 secondes.
- Pour les autres outils de mise en correspondance des invalidations, vous ne pouvez envoyer qu'une seule invalidation par minute. Chaque requête d'invalidation prend effet en une à trois minutes environ.
Cloud CDN ne limite pas le nombre d'objets ni la taille totale de tous les objets invalidés pour chaque requête.
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 vos 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 ajoutant l'option --host
à la commande.
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 balises sont définies avec l'en-tête HTTP Cache-Tag
dans une réponse 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 balise 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 comme un OR
logique. Prenons l'exemple suivant:
- Objet en cache N°1, portant les tags
js
,2020-12-23
etprod
. - Objet en cache N°2, portant les tags
css
,2020-11-30
etprod
. - Objet en cache N°3, portant les tags
img
,2020-11-30
etstaging
.
Lorsque vous envoyez une requête pour invalider les objets correspondant à tags="prod,2020-11-30"
, les trois objets mis en cache sont invalidés.
Cette approche vous évite d'avoir à connaître ou à spécifier toutes les combinaisons de balises possibles lorsque vous souhaitez invalider un objet.
Si vous spécifiez des outils de correspondance d'invalidation avec des tags de cache, la requête d'invalidation ne s'applique qu'aux objets tagués correspondant aux outils de correspondance d'invalidation. Prenons l'exemple des objets mis en cache suivants:
- Objet en cache 1 avec l'URL
https://staging.example.com/img/cat.jpg
et la balisea
- Objet en cache 2 avec l'URL
https://example.com/img/cat.jpg
et la balisea
- Objet en cache 3 avec l'URL
https://staging.example.com/js/cat.js
et la balisea
- Objet en cache 4 avec l'URL
https://staging.example.com/img/logo.jpg
et la baliseb
Lorsque vous envoyez une requête pour invalider les objets correspondant à --host="staging.example.com" --path="/img/*" --tags="a"
, seul l'objet 1 est invalidé. Les objets 2, 3 et 4 ne correspondent pas respectivement à l'hôte, au chemin d'accès ou à la balise.
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 la référence de service inter-projets du 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. Par conséquent, 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 frontend (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.
Étape suivante
Pour découvrir comment invalider votre contenu Cloud CDN mis en cache, consultez la page Invalider un contenu mis en cache.
Pour savoir quels contenus peuvent être mis en cache ou non, consultez la page Présentation de la mise en cache.