S3 Files e a mudança na cara do S3

• Para reduzir a ineficiência na movimentação de grandes volumes de dados, foi introduzido o S3 Files, que permite acessar dados do S3 diretamente como se fossem um sistema de arquivos
• Esse recurso integra o Amazon EFS ao S3, permitindo montar buckets do S3 via NFS em EC2, contêineres, Lambda etc. para leitura e escrita
• Internamente, ele usa uma estrutura de stage e commit para refletir periodicamente as mudanças no S3 e oferece sincronização bidirecional entre arquivos e objetos
• O S3 Files funciona como um componente central, ao lado de S3 Tables e S3 Vectors, para expandir o S3 em uma plataforma de dados unificada
• O S3 agora evolui além de um simples armazenamento, tornando-se um espaço de trabalho unificado centrado em dados e fornecendo a base para que desenvolvedores utilizem os dados diretamente

---

A transformação do S3 e o design do S3 Files

• As dificuldades de movimentar dados e o ponto de partida do S3 Files

  • O processo de mover grandes volumes de dados continua sendo uma fonte persistente de ineficiência em vários setores, da pesquisa científica ao machine learning
  • No caso de pesquisa genômica da UBC, os pesquisadores gastavam muito tempo em operações de cópia entre o S3 e sistemas de arquivos locais
  • Esse atrito de dados (data friction) surge porque as ferramentas acessam os dados de maneiras diferentes
  • O S3 Files foi projetado para reduzir esse atrito, permitindo acessar dados do S3 diretamente como um sistema de arquivos

• Desenvolvimento baseado em agentes e a importância dos dados

  • Com o avanço das ferramentas agentic (agentic tooling), a velocidade e a diversidade do desenvolvimento de aplicações aumentaram drasticamente
  • Com a redução das barreiras para escrever código, surgiu um ambiente em que especialistas de domínio podem construir aplicações diretamente
  • O ciclo de vida das aplicações fica mais curto, e os dados emergem como o principal ativo de longo prazo
  • O storage não deve ser apenas um repositório, mas uma camada de abstração que separa os dados das aplicações e permite seu uso contínuo

Os novos primitivos de dados do S3

• S3 Tables

  • Para lidar com dados estruturados, o S3 introduziu o S3 Tables, baseado em Apache Iceberg
  • Mantendo os recursos do Iceberg, ele oferece proteção de integridade dos dados, compactação automática (compaction), replicação entre regiões e mais
  • Atualmente, mais de 2 milhões de tabelas estão armazenadas no S3 Tables, e várias aplicações são construídas sobre ele

• S3 Vectors

  • Com o avanço da IA, aumentou a demanda por índices vetoriais
  • Bancos de dados vetoriais tradicionais armazenam índices em memória ou SSD, mas isso traz limites de custo e escalabilidade
  • O S3 Vectors oferece um índice vetorial totalmente elástico com perfil de custo, desempenho e durabilidade semelhante ao dos objetos do S3
  • Ele escala de centenas a dezenas de bilhões de registros e fornece endpoints de API para busca por similaridade escalar (scalar similarity search)

A chegada do S3 Files

• Visão geral

  • O S3 Files integra o Amazon EFS ao S3, permitindo acesso direto aos dados do S3 como um sistema de arquivos de rede (NFS)
  • É possível montar buckets ou prefixos do S3 em EC2, contêineres, Lambda etc. e ler ou escrever como arquivos
  • As mudanças são refletidas automaticamente no S3, oferecendo sincronização bidirecional entre arquivos e objetos

• Os desafios de design

  • Sistemas de arquivos e armazenamento de objetos têm modelos de dados fundamentalmente diferentes
  • No início, tentou-se simplesmente combinar EFS e S3, mas isso resultou apenas em "compromissos desagradáveis (unpalatable compromises)"
  • Arquivos oferecem mudanças granulares e acesso concorrente, enquanto objetos partem da imutabilidade e de atualizações da unidade inteira
  • O sistema de notificações de eventos do S3 processa mais de 300 bilhões de notificações por dia e funciona com base em mudanças no nível do objeto

Princípios de design de Stage and Commit

• Transformando a fronteira em funcionalidade

  • Em vez de esconder a diferença entre arquivos e objetos, ela foi tratada como uma fronteira explícita no design
  • As mudanças são staged (armazenadas temporariamente) no EFS e, em intervalos regulares, são committed (commitadas) e refletidas no S3
  • Inspirada no conceito de versionamento do Git, essa abordagem permite controle de transferência de dados baseado em tempo e políticas

• Consistência e atomicidade

  • Há suporte simultâneo para operações atômicas do sistema de arquivos (rename, move) e atualizações no nível de objeto completo no S3
  • Ao separar as duas camadas, o sistema mantém o modelo de consistência de cada lado e ainda fornece uma visão única dos dados

• Gerenciamento de permissões

  • As políticas IAM do S3 e as permissões baseadas em inode do sistema de arquivos são estruturalmente diferentes
  • O S3 Files separa os dois modelos por meio de concessão de permissões no nível de montagem
  • As políticas IAM do S3 permanecem como backstop final, permitindo controlar o acesso quando os limites dos dados mudam

• Descompasso de namespace

  • O S3 não tem conceito de diretório, e o delimitador de caminho (delimiter) também pode ser definido arbitrariamente
  • Para resolver a incompatibilidade com o sistema de arquivos, ele mantém intactas as regras de nomenclatura de ambos os lados
  • Objetos incompatíveis não são movidos; em vez disso, eventos são gerados para que os desenvolvedores tratem o caso

• Desempenho e latência

  • Sistemas de arquivos são otimizados para acesso centrado em metadados, enquanto o S3 é otimizado para acesso massivamente paralelo
  • Como a maioria das cargas de trabalho não acessa arquivos e objetos ao mesmo tempo, manter uma camada de sincronização é mais realista do que fundir os dois modelos
  • A visão de arquivos mantém a consistência NFS, a visão de objetos mantém a forte consistência do S3, e a camada de sincronização faz a ligação entre ambas

Como o S3 Files funciona

• Estrutura básica

  • O S3 Files usa o EFS como backend para oferecer a experiência de sistema de arquivos
  • Ao acessar diretórios, ele busca metadados do S3 para criar uma visão sincronizada, e arquivos de até 128 KB também têm os dados carregados imediatamente
  • Arquivos grandes usam lazy hydration para trazer os dados apenas quando necessário
  • As mudanças são commitadas para o S3 com um único PUT aproximadamente a cada 60 segundos, com sincronização bidirecional

• Conflitos e gerenciamento

  • Quando há modificações simultâneas dos dois lados, o S3 é tratado como source of truth
  • Arquivos em conflito são movidos para o diretório lost+found e registrados em métricas do CloudWatch
  • Arquivos não acessados por 30 dias são removidos da visão do sistema de arquivos para otimização de custos

• Otimização de desempenho

  • Por meio do recurso read bypass, em leituras sequenciais de grandes arquivos, a leitura é feita diretamente do S3 com requisições GET paralelas

    • É possível alcançar throughput de 3 GB/s por cliente e, com múltiplos clientes, obter escalabilidade em nível de terabits

• Limitações e melhorias previstas

  • Como o S3 não tem operação nativa de rename, renomear diretórios exige copiar e apagar tudo
  • Montagens com mais de 50 milhões de objetos exibem aviso
  • Controle explícito de commit não está incluído na versão inicial
  • Algumas chaves de objeto não podem ser representadas como nomes de arquivo POSIX, ficando de fora da visão de arquivos

Diversidade de dados e a evolução do S3

• Coexistência de formas de acesso aos dados

  • Como no caso de pesquisa da UBC, desenvolvedores gastam muito tempo com movimentação de dados, cache e gerenciamento de nomes
  • A equipe do S3 busca oferecer suporte integrado a diversas formas de acesso a dados por meio de Tables, Vectors e Files
  • Em vez de eliminar a diferença entre arquivos e objetos, a proposta é reconhecer as características de cada um e transformar a fronteira em funcionalidade

• O papel ampliado do S3

  • O S3 evolui de um simples armazenamento de objetos para uma plataforma de storage unificada que suporta diversos formatos de dados
  • Com Tables, Vectors e Files, passa a ser possível usar os dados diretamente de acordo com a forma de trabalho desejada
  • O objetivo é fazer com que o storage se torne uma infraestrutura-base transparente, e não um obstáculo ao trabalho
  • No futuro, a expansão deve continuar com recursos como controle de stage/commit e integração com pipelines

• Conclusão

  • O S3 Files combina os pontos fortes de ambos os lados, mantendo uma fronteira explícita entre arquivos e objetos
  • O S3, que começou há 20 anos como armazenamento de objetos, agora evolui para um espaço de trabalho unificado centrado em dados
  • Como sugere a mensagem "Agora, vá construir! (Go build!)", o S3 se firma como base para que desenvolvedores experimentem e construam com dados mais rapidamente

[xguru]

Ah, agora que a seção de leituras recomendadas conecta bem os posts oficiais relacionados, ficou bem mais prático.
Eu sempre ficava pensando em como isso deveria ser feito quando havia um texto de apresentação separado do post oficial,
e fico feliz que a seção de leituras recomendadas esteja funcionando tão bem.. haha

Agora o S3 está se expandindo para uma plataforma de dados que inclui arquivos, tabelas e vetores.

Dá a sensação de que o S3, que foi o ponto de partida da infraestrutura moderna de nuvem, está sendo redefinido novamente depois de 20 anos.

[rtyu1120]

Embora a estrutura de arquivos não seja compartilhada de forma transparente com o S3, também existe um projeto open source chamado ZeroFS, que usa o S3 como banco de dados para rodar um sistema de arquivos compatível com POSIX. Ele ficou bem popular por uma demo de PostgreSQL rodando sobre o S3.

https://www.zerofs.net/

[rtyu1120]

Também tem um texto da Archil, fundada por um ex-engenheiro do S3, comparando com o próprio produto deles, então vale a pena ver junto haha

https://x.com/jhleath/status/2042613823522377933

[GN⁺]

Comentários no Hacker News

• Isso é, na prática, usar S3FS, mas com o EFS (o serviço NFS gerenciado da AWS) como camada de cache para dados ativos e acessos aleatórios pequenos
  O problema é que a estrutura de preços cara do EFS vem junto
  — todas as gravações custam US$ 0,06 por GB, o que pode ser fatal para workloads intensivos em escrita
  — leituras feitas a partir do cache custam US$ 0,03 por GB, e leituras grandes acima de 128 KB são transmitidas diretamente do bucket S3 sem custo
  — o cache custa US$ 0,30 por GB por mês, mas como ele provavelmente armazena de forma persistente principalmente arquivos pequenos de até 128 KB, o custo não deve ser tão alto

  • Fico curioso se é mesmo verdade que leituras de arquivos grandes (>128 KB) sempre evitam o cache
    Me preocupo porque a latência do S3 é bem ruim

• A frase “NFS provides the semantics your applications expect” foi uma das coisas mais engraçadas que já vi

  • Os aplicativos não esperam que uma simples queda de rede faça uma system call ficar bloqueada indefinidamente e torne impossível desmontar o sistema de arquivos

• O Hugging Face Buckets também adicionou recentemente um recurso para montar buckets como se fossem um sistema de arquivos
  changelog do hf-mount

• Fiquei curioso sobre a parte de sincronização
  Segundo a documentação da AWS,
  se eu modificar /mnt/s3files/report.csv e outra versão for enviada ao bucket S3, em caso de conflito minha versão será movida para o diretório .s3files-lost+found-file-system-id e substituída pela versão do bucket
  Ou seja, existe um diretório de recuperação automática para conflitos

• O FiberFS está praticamente na fase do primeiro lançamento oficial
  Tem cache embutido, compatibilidade com CDN, metadados em JSON e segurança de concorrência, e é voltado a todo armazenamento compatível com S3

  • Fico curioso sobre como ele se compara à própria implementação FUSE da Amazon. Já saiu até a terceira versão

• Seria bom se a AWS oferecesse uma ponte gerenciada com armazenamento NVMe local
  NVMe é muito mais rápido que EBS, e EBS é mais rápido que EFS
  Se colocassem uma camada de cache sobre NVMe, o desempenho provavelmente seria bem bom, embora uma opção totalmente integrada fosse ainda melhor

  • Se o EFS for apenas um mount NFS simples, talvez dê para montar um volume NVMe e configurar o cachefilesd manualmente
    Por exemplo

    mkfs.ext4 /dev/nvme0n1 && \
    mount /dev/nvme0n1 /var/cache/fscache && \
    mount -t s3files -o fsc fs-0aa860d05df9afdfe:/ /home/ec2-user/s3files
    

    Talvez funcione direto desse jeito
    Na prática, é um comando de três linhas, e lançar isso como serviço gerenciado é bem a cara da AWS

• Eu achava que a AWS antes dizia para não usar S3 como sistema de arquivos, então fico curioso sobre por que isso mudou agora

  • Desta vez, parece ser uma estrutura que coloca um sistema de arquivos real (EFS) na frente do S3 e faz uma sincronização transparente
    O blog também menciona cuidados com problemas de consistência e tratamento de nomes de objetos
    Como fã do S3, acho esse projeto um meio-termo bem razoável
  • Arquitetos de grandes clientes já usam S3 como se fosse sistema de arquivos há muito tempo
    A pressão de tickets de suporte que a AWS recebeu e o acúmulo de pedidos de “por que isso não funciona?” provavelmente acabaram levando a isso
    Pessoalmente, não gosto muito dessa abordagem de “embrulhar algo essencialmente diferente com uma nova embalagem”, mas parece um caso de pressão social do $$$
  • Isso parece uma estratégia para atrair usuários com menos conhecimento técnico
    Afinal, dá para transformar em clientes da AWS até quem usa ferramentas como “S3asYourFS.exe”
    Ainda assim, pensando na capacidade de suporte ao cliente da AWS, não sei se foi uma decisão inteligente
    Mesmo assim, a tentação de ter mais usuários pagando mensalmente deve ter sido grande
  • Se as pessoas vão usar S3 como sistema de arquivos de qualquer jeito, então talvez seja melhor oferecer suporte oficial
  • No fim, a AWS criou um modelo de receita colocando um cache na frente
    Para o usuário, o desempenho melhora, e a AWS reduz a carga
    Pode economizar dinheiro, ou não

• Fico curioso sobre o que aconteceria se alguém armazenasse um banco de dados SQLite nisso
  Talvez só dê para ter algo como réplicas somente leitura, e backup no estilo do Litestream provavelmente não funcionaria

  • O mecanismo de lock do SQLite não é seguro em NFS, então não funciona

• O comportamento de locking do NFS já é complicado por si só, e misturar nisso um backend remoto em S3 parece ainda mais confuso

• Werner Vogels é realmente impressionante
  Conheci os textos dele quando estava estudando DynamoDB, e desde então sou fã