Imagem de dennizn via Shutterstock
Um cliente nosso enfrentou recentemente um problema no bucket do S3 ao transferir objetos do armazenamento Standard para o Glacier Deep Archive. Mesmo depois de mover os objetos para o Glacier Deep Archive, eles continuavam aparecendo no Standard.
Ao investigar o bucket do S3 desse cliente, confirmei que o armazenamento Standard de fato não havia diminuído em relação ao tamanho original de 4,9 TB. Dá para ver isso na imagem abaixo, extraída da métrica de armazenamento do bucket.
Métrica do S3 — Total Bucket Size
Pela métrica Total Bucket Size do S3, dá para ver que o Standard estava com 4,9 TB. A linha laranja na imagem representa o armazenamento Standard. O cliente tinha iniciado a transferência dos objetos para o Glacier Deep Archive em 06/05, mas até 10/05 a métrica ainda não refletia essa mudança.
Métrica do S3 para o Standard
Quando abri a métrica Total Bucket Size no CloudWatch, notei uma divergência entre as métricas do S3 e as do CloudWatch. A métrica do S3 mostrava 4,9 TB de Standard no bucket, enquanto a do CloudWatch indicava 5,3 TB.
Métricas do CloudWatch por classe de armazenamento
Detalhamento das métricas por classe de armazenamento
Da investigação, identifiquei dois problemas na transição de objetos entre as classes de armazenamento feita pelo cliente:
(1) A métrica do S3 Standard não diminuiu depois que os objetos foram movidos para outra classe de armazenamento.
(2) As métricas do S3 e do CloudWatch apresentavam uma variação significativa no total do Standard.
Resolvendo os problemas
Ao entender em detalhes como o cliente transferiu os objetos do Standard para o Glacier Deep Archive, descobri que a operação foi feita manualmente pelo console do S3. Eles abriram o objeto no console e clicaram em Action, Edit actions, Edit storage class.
Alteração manual da classe de armazenamento do objeto
Mudar a classe de armazenamento de um objeto pelo console apenas cria uma cópia do objeto e mantém o original como versão anterior (caso o versionamento esteja habilitado no bucket).
Quando você edita a classe de armazenamento pelo console, ela não é alterada de fato — o que acontece é a criação de um novo arquivo na classe selecionada.
Como o bucket tem versionamento habilitado, passam a existir duas versões do arquivo: uma no Glacier Deep Archive (a versão atual) e outra no Standard (a versão não atual). É por isso que o tamanho do Standard não diminuiu.
Regra de Lifecycle
Ao analisar a divergência entre as métricas do S3 e do CloudWatch para a classe Standard, descobri que as métricas do S3 exibidas na página do bucket mostram apenas o tamanho somado dos arquivos atuais no bucket, enquanto o CloudWatch mostra não só os arquivos atuais, mas também os não atuais e os multipart uploads que falharam.
Como o cliente editou manualmente a classe de armazenamento dos objetos, foi criada uma nova cópia do objeto no Glacier Deep Archive como versão atual, e o objeto no Standard passou a ser a versão não atual.
Como o cliente não precisava manter a versão não atual no Standard, recomendei que ele criasse uma regra de lifecycle para limpar o bucket e remover as versões não atuais do Standard.
O cliente então implementou a regra de Lifecycle a seguir. A regra determina que, dois dias depois de um objeto se tornar não atual (ou seja, ser substituído por uma versão mais nova), todas as versões não atuais desse objeto sejam excluídas em definitivo.
Regra de Lifecycle para excluir versões não atuais
**O resultado**
Depois de implementar a regra de Lifecycle em 14/05, observamos que o S3 começou a remover automaticamente as versões não atuais.
O Standard diminuiu após a implementação da regra de Lifecycle
A regra de lifecycle reduziu de forma significativa o armazenamento do bucket S3, que caiu de 4,9 TB para 1,3 TB. Isso gerou economia para o cliente nos custos do bucket e ainda melhorou seu desempenho.
Essa ação simples não só reduziu os gastos com armazenamento como também otimizou o desempenho do bucket. No gráfico abaixo, dá para ver como os custos do S3 do cliente subiram quando ele fez a transição manual dos objetos para o Glacier Deep Archive em 06/05, e a queda nos custos de armazenamento depois da implementação da regra de lifecycle em 14/05. O gráfico vem do DoiT Cloud Navigator — Cloud Analytics.
Principais lições
Este caso mostra a importância das regras de S3 Lifecycle para uma boa gestão do bucket S3 e para transições entre classes de armazenamento. A alteração manual feita pelo cliente gerou uma duplicação desnecessária entre Glacier Deep Archive e Standard — algo que poderia ter sido evitado com regras de Lifecycle.
Além disso, acompanhar as métricas do S3 e do CloudWatch é fundamental para entender o conteúdo do bucket, o que ajuda tanto na gestão de custos quanto na otimização do desempenho.
Fale com a gente
Se você tem dúvidas sobre otimização do S3 ou precisa de ajuda para revisar sua arquitetura na AWS, fale com a gente na DoiT International. Nosso time de especialistas está sempre pronto para ajudar.