Gerenciamento do ciclo de vida de objetos

Configuração Amostras de configuração

Para atender aos casos de uso comuns no armazenamento de objetos, como definir um time to live (TTL), arquivar versões não atuais ou fazer "downgrade" de classes de armazenamento para facilitar o gerenciamento dos custos, o Cloud Storage oferece o recurso Gerenciamento do ciclo de vida de objetos.

Nesta página, descrevemos este recurso e as opções que ele oferece. Veja informações sobre o formato geral do arquivo de configuração do ciclo de vida na representação de recursos de bucket para JSON ou no formato de configuração do ciclo de vida para XML.

Introdução

Para usar o Gerenciamento do ciclo de vida de objetos, defina uma configuração de ciclo de vida, que precisa ser definida em um bucket. A configuração contém um conjunto de regras que se aplicam a objetos atuais e futuros do bucket. Quando um objeto atende aos critérios de uma das regras, o Cloud Storage executa automaticamente uma ação específica no objeto. Veja alguns exemplos de casos de uso:

  • Fazer downgrade da classe de armazenamento de objetos com mais de 365 dias para o Coldline Storage.
  • Excluir objetos criados antes de 1º de janeiro de 2019.
  • Manter apenas as três versões mais recentes de cada objeto de um bucket com controle de versão ativado.

Configuração do ciclo de vida

Cada configuração de gerenciamento do ciclo de vida contém um conjunto de regras. Cada regra contém uma ação e uma ou mais condições.

  • Um objeto precisa corresponder a todas as condições especificadas em uma regra para que a ação seja realizada na regra.

  • Se você especificar várias regras com a mesma ação, a ação será executada em um objeto quando ele corresponder às condições em qualquer uma das regras.

  • Se várias regras tiverem as condições atendidas simultaneamente para um único objeto, o Cloud Storage executará a ação associada a apenas uma das regras, com base nas seguintes considerações:

    • A ação Delete tem precedência sobre qualquer ação SetStorageClass.
    • A ação SetStorageClass que alterna o objeto para a classe de armazenamento com o menor preço de armazenamento em repouso tem precedência.

    Se houver uma regra que altera a classe do objeto para Nearline Storage e outra que altera a classe do objeto para Coldline Storage, mas as duas usarem a mesma condição, a classe do objeto sempre mudará para Coldline Storage quando a condição for atendida.

  • Teste as regras de ciclo de vida nos dados de desenvolvimento antes de aplicá-las à produção para garantir que não executem ações em conjuntos de condições não intencionais. Se isso não for possível, teste em um pequeno subconjunto dos dados de produção usando as condições matchesPrefix ou matchesSuffix nas regras.

  • As alterações na configuração do ciclo de vida de um bucket podem levar até 24 horas para entrar em vigor, e o gerenciamento do ciclo de vida de objetos ainda pode executar ações com base na configuração antiga durante esse período.

    Por exemplo, se você alterar uma condição age de 10 para 20 dias, um objeto com 11 dias poderá ser excluído pelo gerenciamento do ciclo de vida de objetos até 24 horas depois, com base na configuração antiga.

Para casos de uso, consulte Exemplos de configuração do gerenciamento do ciclo de vida de objetos.

Ações de ciclo de vida

Uma regra de ciclo de vida especifica exatamente uma das seguintes ações:

Excluir

A ação Delete exclui um objeto quando ele atende a todas as condições especificadas na regra de ciclo de vida. Por padrão, quando você exclui um objeto ativo, ele é excluído de maneira reversível e o Cloud Storage o retém por sete dias. É possível restore esse objeto excluído de maneira reversível dentro da duração da retenção da exclusão reversível.

Exceção: em buckets com o controle de versões de objetos ativado, a exclusão da versão ativa de um objeto faz com que ele se torne uma versão desativada, enquanto a exclusão de uma versão desativada exclui essa versão do bucket. Consulte a configuração para excluir objetos para ver um exemplo de como usar a ação Delete junto com o controle de versão de objeto.

A páginaDelete ação não tem efeito em um objeto enquanto ele tem uma retenção de objetos colocada nele ou em umapolítica de retenção que ainda não tenha sido atendida. Desde que as condições na ação Delete permaneçam atendidas para o objeto, a ação Delete ocorre depois que qualquer retenção de objeto é removida e qualquer política de retenção é atendida.

SetStorageClass

A ação SetStorageClass muda a classe de armazenamento de um objeto e atualiza o horário de modificação dele quando o objeto atende a todas as condições especificadas na regra de ciclo de vida de dados.

SetStorageClass é compatível com as seguintes transições de classe de armazenamento:

Classe de armazenamento original Nova classe de armazenamento
DRA Storage (Disponibilidade durável reduzida) Nearline Storage
Coldline Storage
Archive Storage
Multi-Regional Storage/Regional Storage1
Standard Storage, Multi-Regional Storage ou Regional Storage Nearline Storage
Coldline Storage
Archive Storage
Nearline Storage Coldline Storage
Archive Storage
Coldline Storage Archive Storage

1 Para buckets localizados em uma região, a nova classe de armazenamento não pode ser Multi-Regional Storage. Já para buckets em um local birregional ou multirregional, a nova classe de armazenamento não pode ser Regional Storage.

O Cloud Storage não valida a correção da transição da classe de armazenamento. Isso significa que você pode especificar uma transição de classe de armazenamento não listada na tabela acima, mas a transição não ocorrerá. Verifique se as regras de ciclo de vida usam uma das transições de classe de armazenamento listadas.

Cancelar uploads incompletos de várias partes

A ação AbortIncompleteMultipartUpload cancela um upload de várias partes incompleto e exclui as partes associadas quando o upload de várias partes atende às condições especificadas na regra de ciclo de vida.

Somente as seguintes condições de ciclo de vida podem ser usadas com essa ação:

Tentar criar uma regra que usa a ação AbortIncompleteMultipartUpload em combinação com outras condições resulta em um erro.

Condições do ciclo de vida

Uma regra de ciclo de vida inclui condições que um objeto precisa atender antes que a ação definida na regra ocorra no objeto. As regras de ciclo de vida são compatíveis com as seguintes condições:

Todas as condições são opcionais, mas é obrigatório especificar pelo menos uma. Se você tentar definir uma configuração de ciclo de vida inválida, por exemplo, usando uma ação ou condição que não existe, receberá uma resposta de erro 400 Bad request e qualquer configuração de ciclo de vida atual permanecerá em vigor.

age

A condição age é atendida quando um recurso atinge a idade especificada (em dias). A idade é medida a partir do horário de criação do recurso.

  • Para objetos, a hora de criação é o momento em que o objeto é gravado com sucesso no bucket, como quando um upload é concluído.

    • A idade de um objeto não é afetada pelo objeto se tornar uma versão não atual.

  • Para uploads de várias partes, a hora da criação é o momento em que o upload é iniciado.

Por exemplo, se um recurso foi criado em 10/01/2022 às 10h UTC e a condição age é de 10 dias, ela será atendida para esse recurso a partir de 20/01/2022 às 10h UTC.

createdBefore

A condição createdBefore é atendida quando um objeto é criado antes da meia-noite da data especificada em UTC.

customTimeBefore

A condição customTimeBefore é atendida quando a parte da data dos metadados Custom-Time de um objeto é anterior à data especificada nessa condição. Essa condição é definida usando o formato de data YYYY-MM-DD. customTimeBefore nunca é atendido por um objeto sem conjunto de metadados Custom-Time.

daysSinceCustomTime

A condição daysSinceCustomTime é atendida quando o número de dias especificado tiver passado desde a data e hora especificadas no campo de metadados Custom-Time de um objeto. Por exemplo, se um Custom-Time de um objeto for 2020-05-16T10:00:00Z e a condição daysSinceCustomTime for 10 dias, a condição será atendida para o objeto em e depois de 26/05/2020 às 10h UTC.

daysSinceCustomTime nunca é atendido por um objeto sem conjunto de metadados Custom-Time.

daysSinceNoncurrentTime

A condição daysSinceNoncurrentTime normalmente é usada apenas em conjunto com o controle de versões de objeto. A condição é atendida quando o número especificado de dias tiver passado desde que o objeto se tornou inativo, porque a versão ativa foi excluída ou substituída. Por exemplo, se um objeto ficou inativo em 2020/07/08 15:00 UTC e a condição daysSinceNoncurrentTime é de 10 dias, a condição é atendida para o objeto em e após 2020/07/18 15:00 UTC.

isLive

A condição isLive normalmente é usada apenas junto com o controle de versões de objeto. Quando definida como false, a condição é atendida para qualquer versão não atual de um objeto. Quando definida como true, ela é atendida para a versão ativa de um objeto. Se você não usar o controle de versões, todos os seus objetos serão considerados ativos e corresponderão quando isLive for true.

matchesPrefix e matchesSuffix

As condições matchesPrefix e matchesSuffix são atendidas quando o início ou o fim do nome de um objeto é uma correspondência exata que diferencia maiúsculas de minúsculas com o prefixo ou sufixo especificado. É possível especificar várias strings como uma lista (por exemplo, "matchesSuffix": [".jpg", ".png"]).

Ao usar matchesPrefix, não inclua o nome do bucket ou a / que antecede aos nomes de objetos na maioria dos caminhos de solicitação. Por exemplo, na CLI do Google Cloud, o caminho para um objeto em um bucket chamado my_bucket tem um formato semelhante a gs://my_bucket/pictures/paris_2022.jpg. Para corresponder ao objeto, use uma condição como "matchesPrefix":["pictures/paris_"].

É possível especificar até 50 prefixos e 50 sufixos especificados em todas as regras. Um prefixo ou sufixo não pode ser usado duas vezes em uma única condição.

matchesStorageClass

A condição matchesStorageClass é atendida quando um objeto do bucket é armazenado conforme a classe de armazenamento especificada. É possível usar os seguintes valores para matchesStorageClass: STANDARD, NEARLINE, COLDLINE, ARCHIVE, MULTI_REGIONAL, REGIONAL e DURABLE_REDUCED_AVAILABILITY.

Em geral, se você pretende usar a condição matchesStorageClass para objetos em Standard Storage, inclua também os parâmetros a seguir:

  • Se o bucket estiver em um local regional, inclua REGIONAL e DURABLE_REDUCED_AVAILABILITY na condição.

  • Se o bucket estiver em um local birregional ou multirregional, inclua MULTI_REGIONAL e DURABLE_REDUCED_AVAILABILITY na condição.

Ao incluir essas outras classes, você garantirá que a regra do ciclo de vida abranja os objetos mais antigos nos seus buckets, que podem estar definidos em classes de armazenamento legadas.

noncurrentTimeBefore

A condição noncurrentTimeBefore normalmente é usada apenas em conjunto com o controle de versões de objeto. A condição é satisfeita para objetos que se tornaram desatualizados em uma data anterior à especificada nessa condição. A condição é definida usando o formato de data YYYY-MM-DD. noncurrentTimeBefore nunca é atendido para um objeto ativo.

numNewerVersions

A condição numNewerVersions normalmente é usada apenas junto com o controle de versões de objeto. Se o valor da condição for definido como N, uma versão do objeto atenderá a condição quando houver pelo menos N versões (incluindo a ativa) mais novas. No caso de uma versão ativa do objeto, o número de versões mais novas é considerado 0. No caso da versão não atual mais recente, o número de versões mais novas é 1 (ou 0 se não houver uma versão ativa), e assim por diante.

Comportamento do ciclo de vida de objetos

O Cloud Storage inspeciona regularmente todos os objetos de um bucket para os quais o Gerenciamento do ciclo de vida de objetos está configurado e executa todas as ações aplicáveis de acordo com as regras do bucket. O Cloud Storage executa uma ação de maneira assíncrona. Portanto, pode haver um atraso entre o momento em que as condições são atendidas e o momento em que a ação é realizada. Seus aplicativos não devem confiar em ações de ciclo de vida que ocorram dentro de um determinado período de tempo após o cumprimento de uma condição de ciclo de vida.

Por exemplo, se um objeto atende às condições de exclusão, ele pode não ser excluído imediatamente e você verá o objeto até que a ação do ciclo de vida seja executada no objeto. Em buckets com o controle de versões de objetos ativado, isso significa que um objeto ativo existirá em um estado não atual por um determinado período, mesmo que a versão não atual do objeto também atenda à exclusão. condições da regra.

As cobranças aplicáveis ainda se aplicam enquanto o objeto permanecer no estado original, com uma exceção: os custos de armazenamento em repouso serão dispensados se o objeto atender a todos os critérios a seguir:

  • O objeto está em um bucket com a exclusão reversível desativada
  • O objeto está sujeito a uma regra com uma ação Delete
  • A única condição da regra é uma condição age
  • A condição age é atendida para o objeto

Considerações sobre o custo SetStorageClass

Semelhante à alteração da classe de armazenamento de um objeto manualmente, o uso de SetStorageClass conta como uma operação de classe A e é faturado de acordo com a taxa determinada pelo classe de armazenamento de destino.

Ao contrário da alteração da classe de armazenamento de um objeto manualmente, o uso de SetStorageClass não reescreve um objeto. Isso dá algumas vantagens de preço ao Gerenciamento do ciclo de vida de objetos:

Por exemplo, imagine que você fez o upload de um objeto como Nearline Storage e, 20 dias depois, a configuração do ciclo de vida alterou a classe de armazenamento do objeto para Coldline Storage. Essa alteração não gera taxas de recuperação e nem de exclusão antecipada. Se você excluir o objeto 60 dias após a alteração da classe de armazenamento, haverá apenas uma cobrança por exclusão antecipada de 10 dias, porque o Coldline Storage tem uma duração de armazenamento mínima de 90 dias e o objeto existiu por um total de 80 dias.

Para comparar, digamos que você fez o upload de um objeto como Nearline Storage e, 20 dias depois, alterou a classe de armazenamento usando uma regravação (novamente para Coldline Storage). Essa alteração gera uma taxa de recuperação e uma cobrança de exclusão antecipada de 10 dias. Se você excluir o objeto 60 dias após a regravação, haverá uma cobrança por exclusão antecipada de 30 dias.

Em ambos os exemplos, se a exclusão reversível estiver ativada no bucket, as cobranças de armazenamento aumentarão, mas as cobranças por exclusão antecipada serão reduzidas com base na duração do período de armazenamento desse recurso.

Horário de criação do objeto

Em muitos casos, o upload de um objeto é concluído logo após seu início. No entanto, para uploads que ocorrem em várias solicitações, como os uploads retomáveis, pode haver dias entre o envio da solicitação de upload inicial e o envio da solicitação de upload final. Nesses casos, tenha em mente os seguintes itens:

  • Um objeto não está sujeito às regras de ciclo de vida até que o upload seja concluído.
  • O tempo de criação do objeto é baseado no momento em que o upload é concluído. Isso afeta as condições do ciclo de vida age e createdBefore.
  • Defina o Custom-Time do objeto no início do upload. Se você definir um Custom-Time com base no horário da solicitação, o Custom-Time poderá ser muito anterior ao horário da criação do objeto. Isso afeta as condições de ciclo de vida customTimeBefore e daysSinceCustomTime.

Metadados de prazo de validade

Se uma ação Delete é especificada para um bucket com a condição age (e não há outras condições além de matchesStorageClass), alguns objetos podem ser marcados com metadados de prazo de validade. O prazo de validade de um objeto indica quando o objeto se torna qualificado para exclusão pelo Gerenciamento do ciclo de vida de objetos. O prazo de validade pode mudar de acordo com as alterações na configuração do ciclo de vida ou na política de retenção do intervalo.

A ausência de metadados de prazo de validade não significa necessariamente que o objeto não será excluído, mas sim que não há informações suficientes disponíveis para determinar quando ou se ele será excluído. Por exemplo, se um objeto foi criado em 10/01/2020, às 10h UTC e a condição age for definida como 10 dias, o prazo de validade do objeto será às 10h UTC de 20/01/2020. No entanto, o prazo de validade não estará disponível para o objeto se:

  • houver outras condições especificadas na regra Delete, com exceção de matchesStorageClass;

  • você usar uma condição matchesStorageClass que não inclui a classe de armazenamento do objeto.

  • O objeto está contido, porque o Cloud Storage não sabe quando essa contenção será removida.

  • A exclusão reversível está ativada no bucket.

O armazenamento após o prazo de validade do objeto não é faturado, mesmo que o objeto não seja excluído imediatamente. É possível continuar acessando o objeto antes de ele ser excluído e outras cobranças continuam sendo válidas (solicitação, largura de banda da rede). Se algum objeto não tiver hora de expiração disponível, o armazenamento desse objeto será cobrado até a hora em que ele for excluído.

Quando você usar prazos de validade, lembre-se disto:

  • Se o bucket tiver uma política de retenção, o prazo de validade será posterior ao da condição age do Gerenciamento do ciclo de vida de objetos e à hora em que o objeto atender ao período de armazenamento especificado pela política de retenção.

  • Se houver vários tempos de expiração conflitantes aplicáveis a um mesmo objeto devido a diferentes regras de gerenciamento do ciclo de vida, será usado o prazo de validade aplicável mais próximo.

Opções para rastrear ações do ciclo de vida

Use as opções a seguir para rastrear as ações de gerenciamento do ciclo de vida realizadas pelo Cloud Storage:

  • Use os registros de uso do Cloud Storage. Esse recurso registra a ação e quem a executou. Um valor de GCS Lifecycle Management no campo cs_user_agent da entrada de registro indica que a ação foi realizada pelo Cloud Storage, de acordo com uma configuração de ciclo de vida.
  • Ative as Notificações do Pub/Sub para o Cloud Storage no bucket. Esse recurso enviará notificações para o tópico do Pub/Sub de sua escolha quando ocorrerem ações específicas. Esse recurso não registra quem executou as ações.

A seguir