Gestion du cycle de vie des objets

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 savoir comment activer la gestion du cycle de vie des objets et obtenir des exemples de règles de cycle de vie, consultez la section relative à la gestion des cycles de vie.

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 un seul objet est soumis à plusieurs opérations, Cloud Storage n'exécute qu'une seule de ces opérations et l'objet sera réévalué avant toute autre opération. Une opération de suppression a priorité sur une opération de définition de classe de stockage. Si plusieurs opérations de définition de classe de stockage sont spécifiées, c'est l'opération basculant sur la classe de stockage avec le prix de stockage au repos le plus bas qui est choisie.

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.

Opérations du cycle de vie

Les règles du cycle de vie intègrent les opérations suivantes :

  • Delete : supprime des objets.

    Exception : Dans les buckets où la gestion des versions d'objets est activée, le fait de supprimer la version en ligne d'un objet entraîne la création d'une version obsolète, tandis que la suppression d'une version obsolète supprime cette version définitivement.

  • SetStorageClass : modifie la classe de stockage des objets. Cette opération permet d'effectuer les transitions de classe de stockage suivantes :

    Classe de stockage d'origine Nouvelle classe de stockage
    Stockage à disponibilité limitée durable Stockage Nearline
    Stockage ColdlineStockage ArchiveStockage multirégional/Stockage régional1
    Stockage multirégional Stockage Nearline
    Stockage ColdlineStockage Archive
    Stockage Régional Stockage Nearline
    Stockage ColdlineStockage Archive
    Stockage standard Stockage Nearline
    Stockage ColdlineStockage Archive
    Stockage Nearline Stockage Coldline
    Stockage Archive
    Stockage Coldline Stockage des archives

    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.

Conditions du cycle de vie

Les règles de cycle de vie peuvent intégrer les conditions suivantes :

  • Age : cette condition 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 : cette condition est remplie lorsqu'un objet est créé avant minuit à la date spécifiée au format UTC.

  • IsLive : cette condition est généralement utilisée conjointement 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 d'objets, tous vos objets sont considérés comme étant en ligne et en correspondance lorsque IsLive est défini sur true.

  • MatchesStorageClass : cette condition 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.

  • NumberOfNewerVersions : cette condition est généralement utilisée conjointement 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.

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.

Pour obtenir des exemples d'utilisation de configurations du cycle de vie, consultez la section Gérer les cycles de vie des objets. 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.

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.

Comportement de suppression précoce

La gestion du cycle de vie des objets ne réécrit pas d'objet lorsque sa classe de stockage change. Ainsi, lorsqu'un objet est migré vers le stockage Nearline, Coldline ou Archive à l'aide de la fonctionnalité SetStorageClass, toute suppression ultérieure anticipée (et les frais associés) est basée sur l'heure et la date de création initiale de l'objet, peu importe le moment du changement de classe de stockage.

Supposons, par exemple, que vous importiez un objet en tant que stockage standard et que 20 jours plus tard, votre configuration de cycle de vie fasse passer la classe de stockage de l'objet au stockage Nearline. Si vous supprimez alors l'objet immédiatement, des frais de suppression anticipée sont appliqués sur 10 jours, car l'objet a existé pendant 20 jours. Si vous supprimez l'objet 10 jours après la transition de sa classe de stockage au stockage Nearline, aucun frais de suppression anticipée n'est appliqué, car l'objet a existé pendant 30 jours.

Par comparaison, supposons que vous importiez un objet en stockage standard et que 20 jours plus tard, vous modifiez la classe de stockage à l'aide d'une réécriture (à nouveau vers le stockage Nearline). Si vous supprimez alors l'objet immédiatement après, des frais de suppression anticipée de 30 jours vous seront facturés, car le délai de réécriture devient le nouveau délai de création. De même, si vous attendez 10 jours après la réécriture pour supprimer l'objet, des frais de suppression anticipée vous seront facturés sur 20 jours.

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

Si une opération de suppression (Delete) est spécifiée pour un bucket avec la condition Age (et sans condition NumberOfNewerVersions), 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 2013/01/10 10:00 UTC et que la condition Age est définie à 10 jours, la condition est satisfaite pour l'objet à partir de 2013/01/20 10:00 UTC. Toutefois, l'heure d'expiration ne sera pas disponible pour l'objet si :

  • la condition NumberOfNewerVersions est également spécifiée. Dans ce cas, les anciennes versions de l'objet peuvent encore être supprimées si de nouvelles versions sont ajoutées ;

  • la condition CreatedBefore est également spécifiée et définie sur "2013-01-01", car l'objet ne satisfait pas cette condition ;

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

Vous pouvez accéder au délai d'expiration d'un objet dans ses métadonnées si elles sont disponibles. L'API REST renvoie l'heure d'expiration de l'objet dans l'en-tête de réponse x-goog-expiration.

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 d'âge 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 :

  • Utilisez les journaux d'accès 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