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. Cela entraîne la suppression de l'entrée du cache, puis le remplissage à partir du serveur d'origine la prochaine fois que le contenu est demandé.

Media CDN accepte plusieurs méthodes pour sélectionner le contenu à invalider :

  • Invalidation par hôte et chemin d'URL.
  • Invalidation par préfixe d'URL (caractère générique).
  • Invalidation par tags de cache, y compris les tags intégrés pour status, origin et content-type.

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

Syntaxe d'invalidation acceptée

La syntaxe d'invalidation acceptée est la suivante :

Type Syntaxe Exemple
Invalidation par hôte Invalider les réponses mises en cache pour l'hôte spécifié. gcloud edge-cache services invalidate-cache SERVICE_NAME \
    --host="media.example.com"
Invalidation par chemin d'accès Invalider les réponses mises en cache pour le chemin d'accès ou le préfixe de chemin d'accès spécifié. gcloud edge-cache services invalidate-cache SERVICE_NAME \
    --path="/content/1234/hls/*"
gcloud edge-cache services invalidate-cache SERVICE_NAME \
    --path="/videos/funny.mp4"
Invalidation par tag de cache (code d'état HTTP, nom d'origine ou type MIME) Invalider les réponses mises en cache avec un tag correspondant. Les tags multiples sont traités avec un comportement identique à l'opérateur booléen OR. gcloud edge-cache services invalidate-cache SERVICE_NAME \
    --tags="status=404,origin=staging-origin"
gcloud edge-cache services invalidate-cache SERVICE_NAME \
    --tags="content-type=application/x-mpegurl"

Remarques :

  • Vous pouvez spécifier jusqu'à 10 tags de cache dans une même requête d'invalidation.
  • Vous pouvez combiner host, path et tags dans une même requête d'invalidation. Ils sont traités avec un comportement identique à l'opérateur booléen AND.
  • Lorsque plusieurs tags de cache sont spécifiés, ils sont traités avec un comportement identique à l'opérateur booléen OR. Par exemple, si vous spécifiez --tags="status=404,origin=staging-origin", toutes les réponses avec un tag de cache status=404 sont invalidées, à l'instar de toutes les réponses avec un tag de cache origin=staging-origin.

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 comme suit :

  • Définir l'en-tête HTTP Cache-Tag dans une réponse d'origine, avec des tags spécifiés en tant que liste de valeurs séparées par une virgule.
  • Tags intégrés basés sur le code d'état HTTP de la réponse, le type MIME de l'en-tête de réponse HTTP Content-Type ou le nom de l'origine à partir de laquelle la réponse a été extraite.

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 booléen OR.

Prenons l'exemple suivant :

  • Vous disposez des objets mis en cache suivants :

    • Objet en cache N°1, portant les tags status=200 et content-type=video/mp4.
    • Objet en cache N°2, portant les tags status=404 et content-type=text/plain.
    • Objet en cache N°3, portant les tags status=200 et content-type=application/x-mpegurl.

  • Vous envoyez une requête pour invalider les objets avec tags="status=200,content-type=text/plain".

  • Résultat : les trois objets mis en cache sont invalidés en même temps. Cela permet d'éviter d'avoir à spécifier toutes les combinaisons de tags possibles, dont certaines peuvent être inconnues.

Remarques :

  • Les tags de cache par défaut ne sont pas inclus dans la réponse destinée au client, car ils reflètent des en-têtes existants (comme la ligne d'état ou le Content-Type) ou des détails de configuration interne.
  • Les tags de cache envoyés par l'origine dans l'en-tête de réponse HTTP Cache-Tag sont envoyés au client. Si vous souhaitez empêcher leur envoi au client, utilisez la fonctionnalité responseHeadersToRemove sur une routeRule pour supprimer l'en-tête Cache-Tag. Pour obtenir des exemples, consultez la documentation sur les en-têtes personnalisés.

Tags intégrés

Les réponses incluent automatiquement les tags de cache suivants pour permettre l'invalidation de contenu en fonction du code d'état, du type MIME ou de l'origine à partir de laquelle le contenu a été extrait. Vous n'avez pas besoin de spécifier ces tags dans vos réponses d'origine.

Tag Détails
status=HTTP_STATUS_CODE

Le tag de cache status est défini en fonction du code d'état HTTP renvoyé avec la réponse mise en cache.

Par exemple, vous pouvez invalider toutes les réponses HTTP 404 en spécifiant status=404 dans une requête d'invalidation.
content-type=MIME_TYPE

Le tag de cache content-type est défini en fonction du type MIME défini dans l'en-tête de réponse HTTP Content-Type.

Par exemple, le type MIME d'une playlist HLS est application/x-mpegURL ou vnd.apple.mpegURL.

Cela vous permet d'invalider des types de contenu spécifiques.
origin=ORIGIN_NAME

Le tag de cache origin est défini en fonction du nom de l'origine à partir de laquelle le contenu a été extrait.

La valeur origin référence la valeur de .routing.routeRules[].origin et permet d'invalider le contenu d'un serveur d'origine mal configuré ou potentiellement défaillant.

Limites des tags de cache

Les tags de cache sont soumis aux restrictions suivantes :

  • Un tag ne doit pas dépasser 120 octets.
  • Le total des noms de tags ne doit pas dépasser 1 Kio (1 024 octets) par objet mis en cache.
  • Un objet ne peut pas comporter plus de 10 tags, à l'exclusion des tags par défaut ajoutés par Media CDN.
  • Un tag doit être un nom de jeton HTTP valide, tel que défini dans la section 3.2.6 de la norme HTTP RFC 7230
  • Un tag ne doit pas inclure les préfixes intégrés status=, origin= ou content-type= (qui sont ignorés).

Les tags qui ne respectent pas ces limites ou ne répondent pas à ces exigences sont ignorés. Dans certains cas (par exemple, lorsque les en-têtes de réponse sont trop volumineux), la réponse échoue et n'est pas mise en cache.

Autorisations

L'autorisation networkservices.EdgeCacheServices.invalidateCache contrôle l'accès à l'API invalidateCache. Cette autorisation est incluse dans les rôles IAM (Identity and Access Management) networkservices.edgeCacheAdmin et networkservices.edgeCacheUser.

Examples

Les exemples suivants montrent comment invalider les réponses mises en cache pour un service Media CDN.

Vous pouvez combiner les champs host, path et tags dans une même requête d'invalidation pour invalider un ensemble de contenu spécifique.

Invalider par hôte

Console

  1. Accédez à la page "Media CDN" dans la console Google Cloud
    Accéder à Media CDN
  2. Cliquez sur l'onglet Services.
  3. Cliquez sur votre service.
  4. Cliquez sur l'onglet Invalidation de cache.
  5. Pour invalider le schéma de chemin d'accès, saisissez un nom d'hôte suivi d'un chemin d'accès. Par exemple : media.example.com/cats ou media.example.com/cat*. Le nom d'hôte ne peut pas inclure *.

gcloud

gcloud edge-cache services invalidate-cache SERVICE_NAME \
    --host=HOST

Remplacez les éléments suivants :

  • SERVICE_NAME par le nom du service de cache périphérique.
  • HOST par le nom d'hôte complet de l'entrée de cache à invalider.

Exemple :

gcloud edge-cache services invalidate-cache SERVICE_NAME \
    --host="media.example.com"

Invalider par chemin d'accès

Console

  1. Accédez à la page "Media CDN" dans la console Google Cloud
    Accéder à Media CDN
  2. Cliquez sur l'onglet Services.
  3. Cliquez sur votre service.
  4. Cliquez sur l'onglet Invalidation de cache.
  5. Pour le schéma de chemin d'accès à invalider, saisissez un chemin d'accès. Par exemple, /videos/funny.mp4 ou /segments/e94a6b1f731/*.

gcloud

gcloud edge-cache services invalidate-cache SERVICE_NAME \
    --path=PREFIX

Remplacez les éléments suivants :

  • SERVICE_NAME par le nom du service de cache périphérique.
  • HOST par le nom d'hôte des entrées de cache à invalider. Pour mettre en correspondance n'importe quel nom d'hôte, omettez l'option "host".
  • PREFIX par un préfixe de chemin se terminant par "*" et correspondant aux entrées de cache à invalider.

Exemple :

gcloud edge-cache services invalidate-cache SERVICE_NAME \
    --path="/segments/e94a6b1f731/*"

Vous pouvez également invalider un chemin d'accès exact en omettant le caractère * final. Transmettre --path="/videos/funny.mp4" invalide la réponse mise en cache correspondant à ce chemin (le cas échéant).

Invalider par tag de cache

Console

L'invalidation par tag de cache n'est pas possible dans la console Google Cloud.

gcloud

gcloud edge-cache services invalidate-cache SERVICE_NAME \
    --tags=TAGS

Remplacez les éléments suivants :

  • SERVICE_NAME par le nom du service de cache périphérique.
  • TAGS par une liste de tags séparés par une virgule.

Exemple :

gcloud edge-cache services invalidate-cache SERVICE_NAME \
    --tags="status=404,content-type=text/plain"

Latence d'invalidation

L'invalidation de cache sur les milliers d'emplacements de Media CDN se termine généralement en une minute.

Dans certains cas, l'invalidation peut prendre plus de temps en fonction de la charge du système, de la connectivité et du volume de contenu invalidé.

Journalisation

Si les journaux d'audit sont activés, les appels d'invalidation sont consignés dans Cloud Logging.

Limites

Les invalidations ont un débit limité. Vous pouvez soumettre au plus dix invalidations par minute. Si vous dépassez ce taux, vous recevez un message d'erreur HTTP 429 avec l'état RESOURCE_EXHAUSTED.

Une invalidation peut être de n'importe quelle taille. Par exemple, l'invalidation de /images/my-image.png compte comme une seule invalidation. L'invalidation de /images/* est également considérée comme une seule invalidation.

Ce comportement diffère du comportement dans Cloud CDN. Cloud CDN accepte une invalidation par minute.