Como o Itaú reduziu custos de armazenamento no Amazon S3 | Cloud Computing

Por Rafaela Lovatti, engenheira de dados no Itaú Unibanco; Jaqueline Escoaiella, Gerente de Engenharia de Dados; Thiago Branco dos Santos, Coordenador de Engenharia de Dados; Henrique Papa, especialista em Engenharia de Dados do Itaú; Osvaldo Correia, engenheiro de dados sênior no Itaú Unibanco; Kauê Oliveira, CIO no Itaú e Rubens Macegossa Dias, Arquiteto de Soluções Senior Cloud na AWS.

Introdução

Com uma grande variedade de serviços e aplicações, é esperado que uma alta volumetria de dados seja gerada e transmitida dentro do ecossistema de uma empresa. Também é claro imaginar que armazenar e disponibilizar estes dados para a instituição seja importante para empresas que pretendem manter-se relevantes e na vanguarda tecnológica de Dados, Analytics e Inteligência Artificial (IA).

Foi neste cenário que o Itaú Unibanco construiu sua Plataforma de Dados em Prevenção a Fraudes, para recepcionar as informações de suas aplicações e transformar seus dados em ativos valiosos para o Data Mesh do banco, seguindo os mesmos padrões de excelência em segurança e privacidade que fazem parte de todos os seus produtos e serviços.

Início da Plataforma

As camadas SOR (System of Record), SOT (System of Transformation) e SPEC (Specialized Processing Engines) gerenciam diferentes estágios do ciclo de vida dos dados, desde o armazenamento bruto até a transformação e o processamento especializado. Abaixo breve descrição das camadas:

• Camada SOR (System of Record): Responsável pelo armazenamento inicial dos dados brutos, funcionando como a principal referência para informações ainda não processadas;
• Camada SOT (System of Transformation): Destinada à transformação, limpeza e preparação dos dados para análise. Nessa etapa, são aplicadas regras de negócios e ajustes necessários para garantir a qualidade das informações;
• Camada SPEC (Specialized Processing Engines): Focada em processamentos avançados ou especializados, como execução de algoritmos de machine learning, geração de novas features a partir dos dados e transformações específicas para aprofundar as análises e gerar insights.

Na construção de sua plataforma, o Itaú Unibanco levou em consideração aspectos como a latência de disponibilidade dos dados para o consumo analítico, critérios de qualidade entre camadas (SOR, SOT e SPEC) e quais ferramentas serviriam para ingerir, processar e analisar seus dados. Dessa forma, foi capaz de construir um ecossistema com alta resiliência e baixo overhead (sobrecarga) de operação.

Figura 1: Desenho de camadas de dados, processamento e ingestão

Uma vez que as equipes de engenharia levaram até produção este ecossistema, as atenções voltaram-se para o consumo dos ativos e para a evolução de produtos de dados mais refinados.

Surge o Problema

Com foco em novos produtos e casos de uso, o Itaú rapidamente chegou em um volume de PetaBytes de arquivos repousados em seu Amazon S3, o que resultou em um aumento acelerado em seus custos de armazenamento.

Dado esse cenário, o banco traçou um plano para não só controlar o custo, como também garantir um crescimento saudável na AWS. Mesmo com o entendimento de que a resposta para este problema poderia ser a política de ciclo de vida de seu Bucket (contêiner para objetos), as equipes também sabiam que uma decisão tomada sem o devido cuidado poderia causar um problema ainda maior.

Durante o planejamento, surgiram dúvidas sobre como garantir que os dados não conhecidos ou não explorados poderiam ser arquivados ou movidos para uma camada de armazenamento mais barata, qual o aumento no custo de processamento e operação para a recuperação de um dado já movido para um outro Tier (classe de armazenamento) e qual o ponto crítico em que os aumento de gastos com reprocessamento seriam compensados com a redução no custo de armazenamento. Sem uma análise minuciosa não seria possível responder estas perguntas com segurança.

Preparação para as Ações 

Para tanto, com o S3 Inventory habilitado, foi possível coletar semanalmente informações a respeito dos objetos armazenados no Bucket, como a data de última modificação, o tamanho em bytes e a classe de armazenamento de cada um dos arquivos. A partir desses e de outros metadados gerados, foram construídos indicadores que serviram como ponto de partida para a análise da estrutura do bucket e posterior definição das políticas de ciclo de vida.

Com isso, a fim de facilitar a visualização e entendimento desses aspectos, esses indicadores foram consolidados na forma de gráficos e tabelas em um painel na ferramenta de Business Intelligence (BI) Amazon Quicksight, oferecendo uma visão completa acerca da estruturação e do comportamento do bucket. Essa iniciativa foi essencial para sustentar decisões informadas sobre políticas de ciclo de vida e armazenamento em camadas, baseando-se nas seguintes características:

• Quantidade total de objetos armazenados;
• Tamanho total em Petabytes armazenado;
• Classes de armazenamento em uso;
• Volume de objetos modificados por período (6 meses, 1 ano e 3 anos);
• Volume de objetos por classe de armazenamento;
• Quantidade total de arquivos pequenos (small files);
• Quantidade de small files modificados por período (6 meses, 1 ano e 3 anos).

Com a análise detalhada desses indicadores, foram observados ganhos em visibilidade sobre a frequência de acesso a cada tipo de dado e sua coerência com a classe de armazenamento utilizada, o que entregou ao banco uma maior capacidade de avaliar o custo-benefício de mover dados menos acessados para camadas de menor custo.

Além disso, para quem lida com grandes volumes de dados em buckets no Amazon S3, a análise dos small files e a organização eficiente dos dados são fundamentais para reduzir custos e otimizar o desempenho. É comum que, ao longo do tempo, dados acumulados ocupem espaço significativo, mas sem uso frequente. Esses arquivos pequenos (small files), embora aparentemente insignificantes individualmente, podem acumular custos consideráveis quando somados, além de impactar o desempenho de processamento.

Por isso, embora essas informações sobre a presença de small files em Bucket Stage não tenham interferido diretamente na definição das regras de lifecycle, ter a visibilidade do impacto da soma desses arquivos menores no custo final foi importante para a avaliação de oportunidades de otimização de armazenamento. Com isso, ao evitar o excesso de small files, o Itaú aumentou a eficiência de seus sistemas e o tempo de resposta das aplicações, refletindo diretamente em economia e desempenho.

Aplicando as Políticas

Uma vez que foram criadas métricas para entender o comportamento das aplicações no consumo dos dados, o banco se tornou capaz de determinar uma regra de ciclo de vida para seus dados.

No Amazon S3, regras de ciclo de vida são utilizadas para gerenciar automaticamente a transição e a expiração dos objetos armazenados. Essas regras permitem que você especifique ações de exclusão ou transição a serem realizadas em objetos com base na idade deles. Vale ressaltar que, para criar a regra ideal é necessário definir corretamente duas variáveis: classes de armazenamento e tempo de retenção em cada classe.

Hoje, a AWS disponibiliza 9 classes de armazenamento diferentes. Todas foram criadas para atender diferentes requisitos como tipo de uso, latência e preço. No contexto do Itaú, foram utilizadas as classes Standard, Glacier Instant Retrieval e Glacier Deep Archive.

• Standard: é a classe padrão de armazenamento do S3. Ela possui um custo maior de armazenamento em comparação as outras classes. No entanto, seu custo de leitura e escrita é bastante acessível. Por isso, a escolha foi utilizar a Standard para dados mais recentes e mais acessados.
• Glacier Instant Retrieval: Seu custo de armazenamento é menor em comparação com a Standard, mas por outro lado, o custo de leitura das informações é mais elevado. Uma particularidade importante para a escolha dessa classe foi o fato de que ela permite a recuperação de dados em milissegundos, tal qual a Standard.
• Glacier Deep Archive: Ideal para dados que são acessados muito raramente e podem tolerar tempos de recuperação mais longos. É uma escolha econômica para arquivamento de dados a longo prazo, em que o custo de armazenamento é uma prioridade sobre a velocidade de acesso.

Cuidados na hora de se aplicar uma política

A premissa do lifecyle consiste em movimentar os dados entre classes de armazenamento visando um ganho financeiro. Porém, essa movimentação possui custos que devem ser considerados, dado que o valor varia dependendo das classes de armazenamento envolvidas na transição. Atento a esse risco, a estratégia do Itaú foi aplicar a regra em etapas e ir diminuindo o tempo de retenção em cada classe gradativamente, o que o permitiu mitigar as chances de um erro comprometer seu orçamento.

Outro fator que deve ser considerado é o custo de leitura dos dados em classes como Glacier. Esses dados possuem armazenamento mais barato, mas caso suas aplicações sejam lidas com frequência, o custo no final do mês pode ficar superior ao uso da classe Standard. Para resolver esse problema, foram implementados processos internos que permitem maior controle sobre ações como reprocessamento de dados e leitura de bases históricas.

Nossa regra final ficou da seguinte forma:

Figura 2: Armazenamento e processamento da camada Stage com lifecycle.

Consolidando os Ganhos

O gráfico a seguir mostra os custos diários com a solução do S3, onde foi implementada a regra de lifecycle em duas etapas, nos dias 24/09 e 02/10, evidenciados pelo custo de transferência de dados (pico em vermelho). Ao final do processo, o banco atingiu uma diminuição de aproximadamente 26 % se comparado com o período sem nenhuma regra implementada.

Além disso, o time estimou que essa solução começará a dar benefícios financeiros após 14 dias da sua implementação, sendo esse o tempo em que a economia será superior ao custo de transferência dos dados iniciais.

Ao final desse trabalho, a expectativa é aumentar ainda mais o uso do S3, enriquecendo sua plataforma com cada vez mais informações, agora com o diferencial de que os custos não crescem mais na mesma proporção e é possível armazenar uma quantidade de dados relevantes sem que isso reflita diretamente no orçamento.

Figura 3: Redução de custos.

Autores