Cortando uma conta de armazenamento GCP em 95.9% com lifecycle policies
O armazenamento em nuvem é o custo que cresce sorrateiramente: ninguém apaga nada e todo byte cai na camada mais cara. Veja como um punhado de lifecycle policies cortou uma conta em 95.9%, uma redução histórica reportada, com lifecycle policies que respeitam a retenção.
Um lifecycle simplificado: a versão efetiva da política e os requisitos de exclusão precisam ser validados.
Contribuição em resumo
- Minha responsabilidade
- Revisão de acesso/retenção, configuração de lifecycle policy e trabalho no volume armazenado.
- Escopo
- Otimização histórica de armazenamento; a reconciliação financeira completa segue incompleta.
- Colaboração & limites
- Trabalhei com o time de produto nos requisitos de acesso e retenção antes de mudar o comportamento do armazenamento.
- Resultado
- O portfólio histórico reportou um custo de armazenamento 95.9% menor. A economia absoluta fica retida até que moeda, baseline e versão da política sejam reconciliados.
O armazenamento é o custo que cresce sorrateiramente. Ninguém apaga nada, todo byte cai na classe padrão (e mais cara), e a conta cresce silenciosamente até que alguém olhe. Este é um relato da técnica que usei para cortar uma dessas contas em 95.9%, com tiering guiado pelo acesso e mudanças de retenção.
Minha contribuição
Revisei os padrões de acesso e retenção com o time de produto, configurei mudanças de lifecycle e trabalhei no posicionamento regional e na redução do volume armazenado.
Resultados e medição
O portfólio histórico reportou um custo de armazenamento 95.9% menor e um volume armazenado 94.2% menor. Os registros de trabalho confirmam as mudanças de lifecycle e retenção, mas não estabelecem uma moeda, um baseline de cobrança e uma versão da política consistentes para a estimativa completa. A economia absoluta e acumulada é, portanto, omitida aqui enquanto a reconciliação está pendente.
O problema
Nem todos os dados eram quentes. A maior parte foi escrita uma vez e nunca mais lida, mas ficava na classe Standard, com preço para acesso frequente. Não havia tiering para classes mais baratas e nada expirava com o tempo, então o volume armazenado e a conta só iam numa direção.
O que eu mudei
Nenhuma infraestrutura nova, nenhuma ferramenta de migração de dados, apenas lifecycle policies aplicadas aos buckets:
- Mantenha os dados quentes no Standard. Baseie a janela quente nos padrões de acesso observados e nos requisitos de retenção aplicáveis.
- Mova os dados mais antigos para camadas mais frias automaticamente. Uma iteração registrada moveu objetos para Nearline após 30 dias e Archive após 365 dias. Políticas anteriores eram diferentes, então essas são decisões versionadas, e não uma regra universal.
- Revise a exclusão separadamente. Combine com o time de produto quais registros podem expirar; arquivamento e exclusão têm efeitos e requisitos diferentes.
- Aplicado em todo lugar. As mesmas políticas foram aplicadas tanto em buckets multirregião quanto em buckets de região única.
A parte importante: isso funciona sozinho. Uma vez que as políticas estão no lugar, o arquivamento e a exclusão rodam por conta própria. Padrões de acesso, requisitos de retenção e efeitos na cobrança ainda precisam de revisão periódica.
O resultado em uma linha
O portfólio histórico reportou uma redução de 95.9%. Moeda, período de cobrança e a contribuição exata do tiering versus exclusão precisam ser reconciliados antes de publicar um total de economia absoluta ou acumulada. O resultado transferível é um processo de lifecycle repetível, atrelado aos requisitos reais de acesso e retenção.
O que eu diria a quem está começando isso
- Olhe para a conta de armazenamento antes da conta de compute. Costuma ser mais simples de resolver e a economia se acumula mês a mês.
- Faça o tiering pelo padrão de acesso, não por achismo. Valide quais dados ainda são lidos antes de escolher a janela de transição.
- Adicione uma política de exclusão, não apenas arquivamento. O arquivamento desacelera o crescimento; a exclusão o interrompe.
- Deixe a plataforma fazer o trabalho. Lifecycle policies são "configure e esqueça", o que significa que a economia não depende de alguém lembrar.
Decisões e próximos passos
Uma visão retrospectiva da abordagem e seus limites. A próxima melhoria é uma proposta, não um resultado entregue.
Alternativa e justificativa
Manter tudo no Standard é simples; camadas mais frias e a expiração autorizada precisam corresponder aos requisitos reais de acesso e retenção.
Trade-off
Cobranças de recuperação, períodos mínimos de retenção e requisitos de exclusão afetam se uma conta de armazenamento menor é um resultado total melhor.
O que eu melhoraria em seguida
Próxima melhoria: reconciliar a versão da política e o período de cobrança e, então, calcular a economia líquida incluindo cobranças de recuperação e retenção.