5 pontos por GN⁺ 2024-11-19 | 1 comentários | Compartilhar no WhatsApp
  • Regatta Storage é um serviço para usar armazenamento compatível com S3 como se fosse um sistema de arquivos em nuvem com sincronização automática, voltado a quem precisa lidar com grandes volumes de dados sem expandir discos locais
  • Busca permitir acesso direto aos datasets no S3 em workloads com Spark, PyTorch e pandas, reduzindo a espera por downloads e o peso de preparar grandes discos locais
  • A origem da ideia vem da experiência com operação de armazenamento na Amazon EFS e na Netflix, e apesar da simplicidade e escalabilidade da EFS, ainda havia problemas de desempenho ao migrar de disco local para NFS
  • Os clientes montam o sistema de arquivos da Regatta via NFSv3, e as instâncias de cache da Regatta se conectam ao bucket S3 do cliente para oferecer desempenho abaixo de um milissegundo em leituras e gravações em cache
  • Já está sendo usado em notebooks Jupyter serverless, camada de cache distribuído sobre S3 e substituição de volumes de boot Ceph com thin provisioning; no futuro, a empresa também está desenvolvendo um protocolo de arquivos customizado

Oferecendo uma experiência de sistema de arquivos local sobre o S3

  • Regatta Storage é um sistema de arquivos em nuvem cobrado por uso e sincronizado automaticamente com armazenamento compatível com S3
  • O objetivo é permitir, em Spark, PyTorch e pandas, acesso direto a grandes datasets sem baixá-los antes para o disco local
  • Um vídeo com a visão geral do serviço pode ser visto no YouTube, e é possível testar gratuitamente após criar uma conta
  • A razão para não oferecer uma demonstração sem conta é que eles consideraram inadequado que usuários do Hacker News compartilhassem um único sistema de arquivos e bucket S3

Contexto de design vindo da experiência com a EFS

  • O fundador criou a Regatta com base em 8 anos de experiência no Amazon Elastic File System (EFS) e no trabalho de construir e operar armazenamento em nuvem em larga escala na Netflix e em outras empresas
  • A EFS tinha como vantagens a simplicidade e a escalabilidade de não exigir estimativa prévia de capacidade, como no S3, mas na Netflix ela não foi usada tanto quanto se esperava
    • Muitas aplicações precisavam de um sistema de arquivos POSIX, e a demanda por armazenamento podia ser incerta ou crescer repentinamente
    • Também havia muitos casos em que era necessário armazenamento que persistisse além da vida útil de instâncias ou contêineres
    • Os discos locais eram superprovisionados para acompanhar o uso potencial, gerando custo até com espaço de armazenamento ocioso
  • A EFS não servia para todas as cargas de trabalho
    • Em alguns casos surgiam problemas de desempenho ao migrar do disco local para NFS
    • Aplicações que usavam disco local como armazenamento temporário precisavam limpar manualmente os dados deixados no armazenamento persistente

Como a Regatta funciona e seu modelo de cache

  • A Regatta foi projetada como um sistema de arquivos com cobrança por uso que escala automaticamente junto com a aplicação
    • Ela sincroniza automaticamente com o S3 em formato de arquivo nativo, permitindo conexão com datasets já existentes
    • Até os dados de arquivos usados recentemente podem ser acessados diretamente no S3
    • Dados pouco acessados são removidos do cache da Regatta, fazendo com que reste apenas o custo do armazenamento S3 de backend
  • Hoje, os clientes montam o sistema de arquivos da Regatta conectando-se via NFSv3 à frota de instâncias de cache da empresa
    • As instâncias da Regatta se conectam, no backend, ao bucket S3 do cliente
    • Entregam desempenho abaixo de um milissegundo para leituras e gravações em cache
    • Por meio de um cache durável, fornecem a todos os clientes de arquivos conectados uma visão de sistema de arquivos com forte consistência
    • Operações complicadas, como renomear diretórios, são processadas de forma rápida e durável e depois propagadas de modo assíncrono para o bucket S3

Casos de uso iniciais e próximos passos

  • Os primeiros usuários estão usando a Regatta para servidores de notebooks Jupyter serverless voltados a pesquisadores de IA, uma camada de cache distribuído de baixa latência sobre S3 e como substituto de volumes de boot Ceph com thin provisioning
  • O protocolo de arquivos customizado em desenvolvimento tem como meta oferecer desempenho próximo ao local em cargas com arquivos pequenos e, em trabalhos de dados distribuídos, desempenho scale-out semelhante ao do Lustre

1 comentários

 
GN⁺ 2024-11-19
Comentários no Hacker News
  • A diferença entre o Rclone e o Regatta Storage é que, nas operações de modificação do sistema de arquivos, o Regatta usa uma camada de cache de alta velocidade para oferecer consistência forte. O Rclone não tem uma camada que garanta consistência entre clientes paralelos

    • O Regatta Storage usa uma camada de cache de alta velocidade nas operações de modificação do sistema de arquivos para oferecer consistência forte
    • O Rclone não tem uma camada que garanta consistência entre clientes paralelos
  • Parece um dos produtos mais legais que já saíram da YC, e há várias perguntas sobre como isso funciona

    • Há curiosidade sobre se ocorre degradação de desempenho ao lidar com dados na faixa de 50 GB usando um disco local de 10 GB
    • Há curiosidade sobre se é possível obter alta velocidade também em outras nuvens além da AWS
    • Há curiosidade sobre a forma de uso com montagens FUSE e NFS
    • Há curiosidade sobre se é possível executar Clickhouse ou Postgres em um volume Regatta
    • Há curiosidade sobre o que pensam a respeito de open source
    • Há curiosidade sobre se pode ser montado em vários servidores e quais são essas limitações
  • A pessoa está hospedando o DuckDB usando o GCP Filestore e pede informações sobre preço e desempenho do Regatta

    • Pede informações sobre preço e desempenho de uma instância de 10 TiB
  • Há interesse nele como disco de backup para SQLite/DuckDB/parquet, com leituras em cache no armazenamento NVMe local da instância

    • São necessárias funcionalidades de locking e memória compartilhada que não se consegue com NFS
    • Isso poderia ser implementado diretamente em espaço de usuário, mas nesse caso seria melhor usar S3
  • A pessoa acha que usar NFS como protocolo é uma boa ideia

    • Já teve experiência na IBM escrevendo um sistema de arquivos criptografado com conceito semelhante
    • É quase mágico que, ao montar o sistema de arquivos, todos os dados simplesmente “estejam lá”
  • Há preocupação com a possibilidade de a AWS copiar esse produto e oferecê-lo por um preço mais baixo

  • Houve a experiência de fazer com sucesso, em 2008, uma demonstração diante do CEO da Adobe em que uma foto tirada com um iPhone aparecia automaticamente como arquivo no Mac

    • Foi implementado um FUSE local que se comunicava com o armazenamento distribuído de objetos da Adobe
    • O trabalho de pesquisa e desenvolvimento em sistemas distribuídos começou junto com o lançamento do Dropbox
  • Há curiosidade sobre se é possível construir armazenamento SQL ACID em tempo real usando Lambda + SQLite + Regatta

  • Não está claro como conflitos de atualização de arquivos são tratados

    • Por exemplo, há curiosidade sobre como fica o arquivo final se dois usuários atualizarem o mesmo arquivo em computadores diferentes
  • Existem alternativas notáveis como s3fs, rclone e goofys