Gestion du cycle de vie des objets

Configuration Exemples de configuration

Pour vous aider à gérer les coûts, Cloud Storage vous propose une fonctionnalité de gestion du cycle de vie des objets pour les cas d'utilisation courants, tels que la définition d'une valeur TTL (Time To Live) pour les objets, la conservation de versions obsolètes d'objets ou la "rétrogradation" des classes de stockage d'objets

Cette page présente cette fonctionnalité et ses options. Pour connaître le format général d'un fichier de configuration de cycle de vie, consultez la page décrivant la représentation des ressources de bucket pour JSON ou le format de configuration de cycle de vie pour XML.

Présentation

Pour utiliser la gestion du cycle de vie des objets, vous devez définir une configuration de cycle de vie, qui doit être définie sur un bucket. La configuration intègre un ensemble de règles qui s'appliquent aux objets actuels et futurs du bucket. Lorsqu'un objet répond aux critères de l'une des règles, Cloud Storage exécute automatiquement l'action spécifiée sur l'objet. Voici quelques exemples d'utilisation :

  • Rétrograder la classe de stockage des objets datant de plus de 365 jours à la classe de stockage Coldline
  • Supprimer les objets créés avant le 1er janvier 2019
  • Conserver seulement les trois versions les plus récentes de chaque objet d'un bucket en activant la gestion des versions

Configuration du cycle de vie

Chaque configuration de gestion du cycle de vie contient un ensemble de règles. Chaque règle contient une action et une ou plusieurs conditions.

  • Un objet doit satisfaire toutes les conditions spécifiées dans une règle pour que l'opération aboutisse.

  • Si vous spécifiez plusieurs règles pour une même opération, celle-ci est exécutée sur un objet correspondant aux conditions de l'une des règles.

  • Si les conditions de plusieurs règles sont simultanément remplies pour un objet unique, Cloud Storage effectue l'opération associée à une seule de ces règles comme suit :

    • L'opération Delete prévaut sur toute opération SetStorageClass.
    • L'opération SetStorageClass est prioritaire si elle fait basculer l'objet sur la classe de stockage avec le prix de stockage au repos le plus bas.

    Par exemple, si l'une des règles fait passer la classe de l'objet au stockage Nearline et qu'une autre règle fait passer la classe de l'objet au stockage Coldline, mais que les deux règles utilisent exactement la même condition, la classe de l'objet passe toujours au stockage Coldline lorsque la condition est remplie.

  • Nous vous recommandons de tester les règles de cycle de vie sur les données de développement avant de les appliquer en production pour vous assurer qu'elles n'effectuent pas d'opérations dans des ensembles de conditions inattendus. Si cela n'est pas possible, vous devez effectuer un test sur un petit sous-ensemble de vos données de production en utilisant les conditions matchesPrefix ou matchesSuffix dans vos règles.

  • La prise en compte des modifications apportées à la configuration du cycle de vie d'un bucket peut prendre jusqu'à 24 heures. Pendant ce temps, la gestion du cycle de vie des objets peut encore effectuer des actions basées sur l'ancienne configuration.

    Par exemple, si vous modifiez une condition age de 10 jours pour la passer à 20 jours, un objet de 11 jours pourra être supprimé par la gestion du cycle de vie des objets jusqu'à 24 heures plus tard, sur la base de l'ancienne configuration.

Pour les cas d'utilisation, consultez la page Exemples de configuration de gestion du cycle de vie des objets.

Opérations du cycle de vie

Une règle de cycle de vie spécifie exactement l'une des actions suivantes :

Supprimer

L'action Delete supprime un objet lorsque celui-ci remplit toutes les conditions spécifiées dans la règle de cycle de vie. Par défaut, lorsque vous supprimez un objet actif, il est supprimé de façon réversible et Cloud Storage le conserve pendant sept jours. Vous pouvez restaurer cet objet supprimé de façon réversible pendant la durée de conservation de la suppression réversible.

Exception : Dans les buckets où la gestion des versions d'objets est activée, le fait de supprimer la version active d'un objet entraîne la création d'une version archivée, tandis que la suppression d'une version archivée supprime cette version du bucket. Reportez-vous à la documentation sur la configuration de la suppression d'objets pour obtenir un exemple d'utilisation de l'action Delete avec la gestion des versions d'objets.

L'action Delete ne prend pas effet sur un objet tant qu'une préservation à titre conservatoire est placée sur cet objet ou que sa règle de conservation n'est pas encore satisfaite. Tant que les conditions de l'action Delete sont satisfaites pour l'objet, l'action Delete prend effet une fois que la préservation à titre conservatoire des objets est supprimée et que toute règle de conservation est remplie.

SetStorageClass

L'action SetStorageClass modifie la classe de stockage d'un objet et met à jour la date et heure de modification lorsque celui-ci remplit toutes les conditions spécifiées dans la règle de cycle de vie.

SetStorageClass est compatible avec les transitions de classe de stockage suivantes :

Classe de stockage d'origine Nouvelle classe de stockage
Stockage à disponibilité limitée durable (DRA, Durable Reduced Availability) Stockage Nearline
Stockage Coldline
Stockage Archive
Stockage multirégional/Stockage régional1
Stockage standard, stockage multirégional ou stockage régional Stockage Nearline
Stockage Coldline
Stockage Archive
Stockage Nearline Stockage Coldline
Stockage Archive
Stockage Coldline Stockage Archive

1 Pour les buckets appartenant à un emplacement régional, la nouvelle classe de stockage ne peut pas correspondre à un stockage multirégional. Pour les buckets appartenant à un emplacement multirégional ou birégional, la nouvelle classe de stockage ne peut pas correspondre à un stockage régional.

Cloud Storage ne valide pas l'exactitude de la transition de la classe de stockage. Cela signifie que vous pouvez spécifier une transition de classe de stockage non répertoriée dans le tableau ci-dessus, mais que la transition ne se produira pas. Nous vous recommandons de vérifier que vos règles de cycle de vie utilisent l'une des transitions de classe de stockage répertoriées.

Annuler les importations en plusieurs parties incomplètes

L'action AbortIncompleteMultipartUpload annule une importation en plusieurs parties incomplète et supprime les parties associées lorsque l'importation en plusieurs parties remplit les conditions spécifiées dans la règle de cycle de vie.

Seules les conditions de cycle de vie suivantes peuvent être utilisées avec cette action :

Toute tentative de création d'une règle utilisant l'action AbortIncompleteMultipartUpload conjointement avec d'autres conditions entraîne une erreur.

Conditions du cycle de vie

Une règle de cycle de vie inclut des conditions qu'un objet doit remplir avant que l'action définie dans la règle ne s'exécute. Les règles de cycle de vie sont compatibles avec les conditions suivantes :

Toutes les conditions sont facultatives, mais au moins une condition est requise. Si vous tentez de définir une configuration de cycle de vie non valide, en utilisant par exemple une opération ou une condition inexistante, vous recevez une réponse d'erreur 400 Bad request et toute configuration de cycle de vie existante reste en place.

age

La condition age est remplie lorsqu'une ressource atteint l'âge spécifié (en jours). L'âge est mesuré à partir de l'heure et de la date de création de la ressource.

  • Pour les objets, cette date correspond à l'heure à laquelle l'objet a été écrit dans le bucket, par exemple à la fin de l'importation.

    • L'âge d'un objet n'est pas affecté par le fait que l'objet devienne une version archivée.

  • Pour les importations en plusieurs parties, l'heure de création correspond à l'heure à laquelle l'importation est lancée.

Par exemple, si une ressource est créée le 10/01/2022 à 10:00 UTC et que la condition age est définie sur 10 jours, la condition est remplie pour la ressource à partir du 20/01/2022 à 20 10:00 UTC.

createdBefore

La condition createdBefore est remplie lorsqu'un objet est créé avant minuit à la date spécifiée au format UTC.

customTimeBefore

La condition customTimeBefore est satisfaite lorsque la date indiquée dans les métadonnées Custom-Time d'un objet est antérieure à la date spécifiée dans cette condition. Cette condition est définie au format YYYY-MM-DD. customTimeBefore n'est jamais satisfait pour un objet dans lequel aucune métadonnée Custom-Time n'est définie.

daysSinceCustomTime

La condition daysSinceCustomTime est remplie lorsque le nombre de jours spécifié est écoulé depuis la date et l'heure spécifiées dans le champ de métadonnées Custom-Time d'un objet. Par exemple, si le Custom-Time d'un objet est 2020-05-16T10:00:00Z et que la condition daysSinceCustomTime est définie à 10 jours, la condition est remplie pour l'objet à partir du 26/05/2020 à 10:00 UTC.

La condition daysSinceCustomTime n'est jamais remplie pour un objet dans lequel aucune métadonnée Custom-Time n'est définie.

daysSinceNoncurrentTime

La condition daysSinceNoncurrentTime n'est généralement utilisée qu'en association avec la gestion des versions d'objets, La condition est remplie lorsque le nombre de jours spécifié est écoulé depuis que l'objet est devenu non obsolète en raison de la suppression ou du remplacement de la version en ligne. Par exemple, si un objet est obsolète depuis le 08/07/2020 à 15:00 UTC et que la condition daysSinceNoncurrentTime est définie à 10 jours, la condition est remplie pour l'objet à partir du 18/07/2020 à 15:00 UTC.

isLive

La condition isLive n'est généralement utilisée qu'en association avec la gestion des versions d'objets. Lorsque ce paramètre est défini sur false, cette condition est remplie pour toute version obsolète d'un objet. Lorsque ce paramètre est défini sur true, cette condition est remplie pour la version en ligne d'un objet. Si vous n'utilisez pas la gestion des versions, tous vos objets sont considérés comme actifs et correspondent lorsque isLive est défini sur true.

matchesPrefix et matchesSuffix

Les conditions matchesPrefix et matchesSuffix sont remplies lorsque le début ou la fin du nom d'un objet est une correspondance exacte sensible à la casse avec le préfixe ou le suffixe spécifié. Vous pouvez spécifier plusieurs chaînes sous forme de liste (par exemple "matchesSuffix": [".jpg", ".png"]).

Lorsque vous utilisez matchesPrefix, n'incluez pas le nom du bucket ni le / qui précède les noms d'objet dans la plupart des chemins de requête. Par exemple, dans Google Cloud CLI, le chemin d'accès à un objet dans un bucket nommé my_bucket adopte un format semblable à gs://my_bucket/pictures/paris_2022.jpg. Pour faire correspondre l'objet, vous devez utiliser une condition telle que "matchesPrefix":["pictures/paris_"].

Vous pouvez avoir jusqu'à 50 préfixes et 50 suffixes spécifiés dans toutes les règles. Un préfixe ou un suffixe ne peut être utilisé deux fois dans une même condition.

matchesStorageClass

La condition matchesStorageClass est remplie lorsqu'un objet du bucket est stocké en tant que classe de stockage spécifiée. Vous pouvez utiliser les valeurs suivantes pour matchesStorageClass : STANDARD, NEARLINE, COLDLINE, ARCHIVE, MULTI_REGIONAL, REGIONAL et DURABLE_REDUCED_AVAILABILITY.

En règle générale, si vous souhaitez utiliser cette condition matchesStorageClass sur les objets de stockage standard, vous devez également :

  • si le bucket se trouve dans une zone régionale, inclure REGIONAL et DURABLE_REDUCED_AVAILABILITY dans la condition ;

  • si le bucket se trouve dans une zone multirégionale ou birégionale, inclure MULTI_REGIONAL et DURABLE_REDUCED_AVAILABILITY dans la condition.

L'inclusion de ces classes supplémentaires garantit que la règle de cycle de vie s'applique également aux objets plus anciens de vos buckets, qui peuvent être définis avec des classes de stockage anciennes.

noncurrentTimeBefore

La condition noncurrentTimeBefore n'est généralement utilisée qu'en association avec la gestion des versions d'objets, et est remplie pour les objets qui sont devenus obsolètes à une date antérieure à celle spécifiée dans cette condition. La condition est définie au format YYYY-MM-DD. La condition noncurrentTimeBefore n'est jamais remplie pour un objet en ligne.

numNewerVersions

La condition numNewerVersions n'est généralement utilisée qu'en association avec la gestion des versions d'objets. Si la valeur de cette condition est définie sur N, une version d'objet remplit la condition lorsqu'il existe au moins N versions (y compris la version en ligne) plus récentes que celle-ci. Pour une version d'objet en ligne, le nombre de versions plus récentes est égal à 0. Pour la version obsolète la plus récente, le nombre de versions plus récentes est 1 (ou 0 en l'absence d'objet actif), etc.

Comportement du cycle de vie d'un objet

Cloud Storage inspecte régulièrement tous les objets d'un bucket pour lesquels la gestion du cycle de vie des objets est configurée, et exécute toutes les opérations applicables en fonction des règles du bucket. Cloud Storage exécute les opérations de manière asynchrone. Il peut donc y avoir un décalage entre le moment où les conditions sont remplies et celui où l'opération est exécutée. Vos applications ne doivent pas dépendre d'opérations de cycle de vie se produisant dans un certain délai après la satisfaction d'une condition de cycle de vie.

Par exemple, si un objet remplit les conditions de suppression, il se peut qu'il ne soit pas supprimé immédiatement et que vous le voyiez jusqu'à ce que l'opération du cycle de vie soit exécutée sur l'objet. Dans les buckets pour lesquels la gestion des versions d'objets est activée, cela signifie qu'un objet actif existe dans un certain temps pendant un certain temps, même si la version archivée de l'objet satisfait également la suppression. conditions de la règle.

Les frais applicables restent valables tant que l'objet reste dans son état d'origine, à une exception près. Les coûts de stockage au repos sont levés si l'objet répond à tous les critères suivants :

  • L'objet se trouve dans un bucket avec la suppression réversible désactivée
  • L'objet est soumis à une règle avec une action Delete.
  • La seule condition de la règle est une condition age.
  • La condition age est remplie pour l'objet.

Considérations sur les coûts de SetStorageClass

Comme pour la modification manuelle de la classe de stockage d'un objet, l'utilisation de SetStorageClass est comptabilisée comme une opération de classe A et est facturée au tarif déterminé par la classe de stockage de destination.

Contrairement à la modification manuelle de la classe de stockage d'un objet, l'utilisation de SetStorageClass ne réécrit pas d'objet. Par conséquent, la gestion du cycle de vie des objets offre certains avantages de tarification :

Supposons, par exemple, que vous importiez un objet en tant que stockage Nearline et que 20 jours plus tard, votre configuration de cycle de vie fasse passer la classe de stockage de l'objet au stockage Coldline. Cette modification n'entraîne aucuns frais de récupération ni de suppression anticipée. Si vous supprimez ensuite l'objet 60 jours après le changement de la classe de stockage, seuls des frais de suppression anticipée de 10 jours seront facturés, car l'objet a existé pendant une durée totale de 80 jours tandis que la durée minimale de stockage Coldline est de 90 jours.

Par comparaison, supposons que vous importiez un objet en stockage Nearline et que, 20 jours plus tard, vous modifiiez la classe de stockage à l'aide d'une réécriture (à nouveau vers le stockage Coldline). Cette modification entraîne des frais de récupération et de suppression anticipée de 10 jours. Si vous supprimez l'objet 60 jours après la réécriture, des frais de suppression anticipée de 30 jours sont appliqués.

Dans ces deux exemples, si la suppression réversible est activée sur le bucket, les frais de stockage augmentent, mais les frais de suppression anticipée sont réduits en fonction de la durée de conservation de la suppression réversible.

Date et heure de création de l'objet

Dans de nombreux cas, l'importation d'un objet prend fin peu après son démarrage. Toutefois, pour les importations effectuées sur plusieurs requêtes, telles que les importations avec reprise, il peut s'écouler plusieurs jours entre l'envoi de la requête d'importation initiale et le l'envoi de la requête d'importation finale. Dans ce cas, vous devez tenir compte des points suivants :

  • Un objet n'est soumis à aucune règle de cycle de vie jusqu'à la fin de l'importation.
  • L'heure de création d'un objet dépend de la fin de l'importation. Cela a une incidence sur les conditions de cycle de vie age et createdBefore.
  • Lorsque vous définissez un Custom-Time pour l'objet, vous le faites au début de l'importation. Si vous définissez un Custom-Time en fonction du moment de la requête, la valeur de Custom-Time peut être beaucoup plus antérieure à l'heure de création de l'objet. Cela a une incidence sur les conditions de cycle de vie customTimeBefore et daysSinceCustomTime.

Métadonnées de délai d'expiration

Si une opération Delete est spécifiée pour un bucket avec la condition age (sans aucune autre condition hormis matchesStorageClass), certains objets peuvent être étiquetés avec des métadonnées de délai d'expiration. Le délai d'expiration d'un objet indique l'heure et la date à laquelle la gestion du cycle de vie des objets peut (ou pouvait) supprimer l'objet. Le délai d'expiration peut changer en même temps que la configuration du cycle de vie du bucket ou que la stratégie de conservation.

Notez que l'absence de métadonnées de délai d'expiration ne signifie pas nécessairement que l'objet ne sera pas supprimé, mais plutôt que les informations disponibles sont insuffisantes pour déterminer quand et s'il sera supprimé. Par exemple, si l'heure de création d'un objet est 2020/01/10 10:00 UTC et que la condition age est définie à 10 jours, la condition est satisfaite pour l'objet à partir de 2020/01/20 10:00 UTC. Toutefois, l'heure d'expiration n'est pas disponible pour l'objet si :

  • d'autres conditions sont spécifiées dans la règle Delete, à l'exception de matchesStorageClass ;

  • vous utilisez une condition matchesStorageClass qui n'inclut pas la classe de stockage de l'objet ;

  • l'objet est en attente, car Cloud Storage ne peut pas savoir quand la mise en attente sera supprimée.

  • La suppression réversible est activée sur votre bucket.

Le stockage ne vous est pas facturé après le délai d'expiration de l'objet, même si l'objet n'est pas supprimé immédiatement. Vous pouvez continuer à accéder à l'objet avant sa suppression. Dans ce cas, d'autres frais (requête, bande passante réseau) vous seront facturés. Si le délai d'expiration n'est pas disponible pour un objet, le stockage de cet objet est facturé jusqu'au moment de sa suppression.

Lorsque vous travaillez avec des délais d'expiration, tenez compte des points suivants :

  • Si le bucket dispose d'une stratégie de conservation, le délai d'expiration correspond au dernier de la condition age de la gestion du cycle de vie d'un objet et au délai pendant lequel l'objet respecte la durée de conservation spécifiée par la stratégie de conservation.

  • S'il existe plusieurs délais d'expiration contradictoires applicables pour un objet en raison de règles de gestion du cycle de vie différentes, le délai d'expiration le plus ancien est utilisé.

Options de suivi des opérations du cycle de vie

Pour suivre les opérations de gestion du cycle de vie qu'effectue Cloud Storage, utilisez l'une des options suivantes :

  • Servez-vous des journaux d'utilisation de Cloud Storage. Cette fonctionnalité enregistre l'opération et le nom de son auteur. Une valeur de GCS Lifecycle Management dans le champ cs_user_agent de l'entrée de journal indique que l'opération a été exécutée par Cloud Storage conformément à une configuration de cycle de vie.
  • Activez les notifications Pub/Sub pour Cloud Storage pour votre bucket. Cette fonctionnalité envoie des notifications au sujet Pub/Sub de votre choix lorsque des opérations spécifiées se produisent. Notez que cette fonctionnalité ne consigne pas le nom ni l'identifiant de l'auteur des opérations.

Étape suivante