Gestion du cycle de vie des objets

Configurer la gestion du cycle de vie des objets 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 décrit la fonctionnalité ainsi que les options disponibles lors de son utilisation. 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.

Introduction

Pour utiliser la gestion du cycle de vie des objets, vous devez définir une configuration de cycle de vie, laquelle doit être définie sur un bucket. La configuration inclut 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'action soit effectuée.

  • Si vous spécifiez plusieurs règles contenant une même action, celle-ci est exécutée sur un objet s'il satisfait aux conditions de n'importe laquelle de ces règles.

  • Si les conditions de plusieurs règles sont simultanément remplies pour un même objet, Cloud Storage effectue l'action associée à une seule de ces règles, en fonction des éléments suivants :

    • L'opération Delete prévaut sur toute opération SetStorageClass.
    • L'action 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 l'objet à la classe de stockage Nearline et qu'une autre règle le fait passer à la classe de stockage Coldline, alors que les deux règles utilisent exactement la même condition, 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'actions selon des jeux 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 laps de temps, la gestion du cycle de vie des objets peut encore opérer 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 datant 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 Exemples de configuration de gestion du cycle de vie des objets.

Actions 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 associée à 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 obligation de conservation 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 est exécutée une fois que l'obligation de conservation de l'objet est levée et qu'une règle de conservation est satisfaite.

SetStorageClass

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

SetStorageClass permet les transitions de classe de stockage suivantes :

Classe de stockage d'origine Nouvelle classe de stockage
Stockage à disponibilité limitée durable (DRA) 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 vérifie pas l'exactitude de la transition entre classes 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 listé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 action 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 satisfaite 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 valeur correspond à la date et l'heure auxquelles 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 satisfaite pour la ressource à partir du 20/01/2022 à 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. La condition customTimeBefore n'est jamais satisfaite pour un objet dans lequel aucune métadonnée Custom-Time n'est définie.

daysSinceCustomTime

La condition daysSinceCustomTime est satisfaite lorsque le nombre de jours spécifié est écoulé après 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 satisfaite 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 active 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 surtrue.

matchesPrefix et matchesSuffix

Les conditions matchesPrefix et matchesSuffix sont satisfaites lorsque le début ou la fin du nom d'un objet présente 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 la 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 spécifier jusqu'à 1 000 préfixes et suffixes au total pour toutes les règles. Dans la console Google Cloud , vous pouvez copier et coller jusqu'à 1 000 préfixes ou suffixes au total. Un préfixe/Un suffixe ne peut pas être utilisé deux fois dans une même condition.

matchesStorageClass

La condition matchesStorageClass est satisfaite lorsqu'un objet du bucket est stocké sous la 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 la condition matchesStorageClass sur les objets en classe de stockage standard, vous devez également :

  • inclure REGIONAL et DURABLE_REDUCED_AVAILABILITY dans la condition si le bucket se trouve dans un emplacement régional ;

  • inclure MULTI_REGIONAL et DURABLE_REDUCED_AVAILABILITY dans la condition si le bucket se trouve dans un emplacement multirégional ou birégional.

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 sur 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 satisfaite pour un objet actif.

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

Lorsque la gestion du cycle de vie des objets est configurée pour les buckets Cloud Storage, Cloud Storage inspecte régulièrement tous les objets et exécute toutes les actions applicables en fonction des règles définies pour le bucket. Cloud Storage exécute les actions de manière asynchrone. Il peut donc exister un décalage entre le moment où des conditions sont satisfaites et celui où l'action associée est exécutée. Vos applications ne doivent pas dépendre d'actions de cycle de vie ne se produisant qu'après un certain délai une fois qu'une condition de cycle de vie est satisfaite.

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'action de cycle de vie soit exécutée sur l'objet.

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 où la suppression réversible est désactivée.

  • L'objet est soumis à une règle avec une action Delete.

  • La seule "condition" de la règle est soit une condition age, soit une combinaison des conditions age et matchesStorageClass.

  • La condition age est satisfaite pour l'objet dans les règles qui ne comportent que la condition d'âge. Si la règle de suppression comporte les conditions age et matchesStorageClass, ces deux conditions doivent être satisfaites pour l'objet.

  • L'objet n'est soumis à aucune obligation de conservation.

Comportement du cycle de vie des objets avec gestion des versions

Dans les buckets pour lesquels la gestion des versions d'objets est activée, un objet actif supprimé conformément aux règles de cycle de vie existe dans un état "archivé" pendant un certain temps. Si la version archivée de l'objet satisfait également les conditions de la règle de suppression, elle sera également supprimée une fois le délai écoulé.

Par exemple, supposons qu'il existe une règle de cycle de vie qui supprime les objets de plus de 180 jours. Si un objet actif date de 200 jours, il est supprimé et passe à l'état "archivé". Comme l'objet désormais archivé date toujours de plus de 180 jours, il sera également supprimé au bout d'un certain temps.

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 l'objet. Par conséquent, la gestion du cycle de vie des objets offre certains avantages en termes de tarification :

  • Le changement de classe de stockage n'entraîne aucuns frais de réplication interrégionale, frais de récupération ni frais de suppression anticipée. Toutefois, des frais de suppression anticipée s'appliquent si des objets d'une classe de stockage avec une durée de stockage minimale spécifiée sont supprimés avant la fin de cette durée.

  • Le temps passé par l'objet dans sa classe de stockage d'origine est comptabilisée dans la durée minimale de stockage applicable à la nouvelle classe.

Supposons, par exemple, que vous importiez un objet vers un 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, étant donné que 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.

À titre de comparaison, supposons maintenant que vous importiez un objet vers un 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 dure peu de temps. Toutefois, pour les importations couvrant 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 l'envoi de la requête d'importation finale. En pareil 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 correspond à la fin de l'importation. Cela a une incidence sur les conditions de cycle de vie age et createdBefore.
  • Lorsque vous définissez une valeur Custom-Time pour l'objet, vous le faites au début de l'importation. Si vous définissez un Custom-Time en fonction de l'heure d'envoi de la requête, la valeur de Custom-Time peut être bien 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 action 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 auxquelles la gestion du cycle de vie des objets peut (ou pouvait) supprimer l'objet. Le délai d'expiration peut changer en cas de modification de la configuration du cycle de vie du bucket ou de la règle 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 soumis à une obligation de conservation, du fait que Cloud Storage ne peut pas déterminer quand celle-ci sera levé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 est soumis à une règle de conservation, le délai d'expiration correspond soit à la condition age de la gestion du cycle de vie d'un objet, soit au délai pendant lequel l'objet respecte la durée spécifiée par la règle de conservation, la date la plus tardive étant retenue.

  • 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.

Étapes suivantes