Gestion du cycle de vie des objets

Accéder aux exemples

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

Vous pouvez attribuer une configuration de gestion du cycle de vie à 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 2013
  • 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. Lorsque vous définissez une règle, vous pouvez spécifier un ensemble de conditions valable pour toute opération. Si vous spécifiez plusieurs conditions dans une règle, un objet doit satisfaire toutes les conditions 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 lorsqu'un objet satisfait la ou les conditions de l'une des règles. Chaque règle doit porter sur une seule opération.

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.

Lorsqu'une opération se produit, l'objet est réévalué avant toute autre opération.

Ainsi, si l'une des règles supprime un objet et qu'une autre règle modifie la classe de stockage de l'objet, mais que les deux règles utilisent exactement la même condition, l'opération de suppression s'exécute toujours lorsque la condition est remplie. 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.

Pour obtenir des exemples d'utilisation de configurations du cycle de vie, consultez Gérer les cycles de vie des objets.

Opérations du cycle de vie

Une règle de cycle de vie spécifie une action Delete ou une action SetStorageClass.

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.

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 définitivement. 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.

SetStorageClass

L'action SetStorageClass modifie la classe de stockage d'un objet 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 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.

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'un objet atteint l'âge spécifié (en jours). L'âge est mesuré à partir de l'heure et de la date de création de l'objet. Par exemple, si l'heure de création d'un objet est 2019/01/10 10:00 UTC et que la condition Age est définie à 10 jours, la condition est satisfaite pour l'objet à partir de 2019/01/20 10:00 UTC. Cela s'applique même dans le cas où l'objet est défini comme obsolète via la gestion des versions d'objet après sa création.

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 de l'écrasement 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.

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.

NumberOfNewerVersions

La condition NumberOfNewerVersions 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.

    Par exemple, si un objet remplit les conditions de suppression, il se peut qu'il ne soit pas supprimé immédiatement. Par conséquent, vous continuerez à voir l'objet jusqu'à ce que l'opération du cycle de vie soit exécutée. Les frais applicables restent valables tant que l'objet existe, à une exception près : les coûts de stockage au repos sont levés si l'objet est soumis à une opération Delete du fait d'une règle ne présentant qu'une condition Age.

  • L'application des mises à jour de votre configuration de cycle de vie peut prendre jusqu'à 24 heures. Cela signifie que lorsque vous modifiez votre configuration de cycle de vie, la gestion du cycle de vie des objets peut encore exécuter des opérations basées sur l'ancienne configuration pendant 24 heures maximum.

    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.

  • Une opération de suppression (Delete) du cycle de vie d'un objet ne prendra pas effet tant que l'objet est mis en attente ou que sa règle de conservation n'est pas encore satisfaite. Si une opération Delete avait lieu alors qu'un objet était soumis à une restriction de mise en attente ou de stratégie de conservation, cette opération serait appliquée une fois les restrictions sur l'objet levées.

  • Une opération de définition de classe de stockage (SetStorageClass) du cycle de vie d'un objet n'est pas affectée par l'existence de stratégies de conservation ou de mise en attente de l'objet.

Avantages de SetStorageClass en termes de coûts

Contrairement à la modification manuelle de la classe de stockage d'un objet, la gestion du cycle de vie des objets ne réécrit pas un objet lorsqu'elle modifie sa classe de stockage. Par conséquent, la gestion du cycle de vie des objets offre certains avantages en termes de tarification :

  • Le changement de la classe de stockage n'entraîne aucuns frais de récupération ou de suppression anticipée, même lorsque l'objet est initialement défini sur le stockage Nearline ou Coldline.

  • La durée de vie de l'objet (définie à la 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 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.

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.

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.

Étapes suivantes