Anúncio da introdução do S2

 (s2.dev)
1 pontos por GN⁺ 2024-12-22 | 1 comentários | Compartilhar no WhatsApp
  • O S2 é uma prévia de um Stream Store serverless que busca tratar fluxos em tempo real duráveis com a simplicidade do armazenamento de objetos, elevando logs e streams a elementos fundamentais do armazenamento em nuvem
  • Os registros são anexados ao tail do stream, e mesmo quando vários writers escrevem ao mesmo tempo, o S2 cuida da ordenação durável, oferecendo suporte tanto para leitura histórica quanto para tailing em tempo real
  • O basin do S2 funciona como namespace de streams, como um bucket, e permite modelagens como streams por usuário sem limite de quantidade de streams nem de período de retenção
  • As classes de armazenamento começam com Standard e Express, separando opções de latência e custo com metas de latência p99 de menos de 500 ms e menos de 50 ms, respectivamente
  • Atualmente oferece API gRPC, SDK em Rust e CLI, deixando como próximos passos API REST, compatibilidade com o protocolo Kafka, basins multi-região e latência abaixo de 5 ms

O modelo de armazenamento de streams proposto pelo S2

  • O S2 mira em ser um Stream Store serverless para dados de streaming na era da nuvem
  • A ideia central é que logs ou streams também podem se tornar elementos fundamentais do armazenamento em nuvem, como objetos
  • O armazenamento de objetos foca em PUT / GET / DELETE para objetos nomeados e em blobs e byte ranges, sendo adequado para dados em repouso
  • O armazenamento de streams do S2 oferece APPEND / READ / TRIM para Stream nomeados, usando registros e números de sequência como unidades básicas
  • As escritas são anexadas ao tail do stream, e mesmo que vários writers gravem simultaneamente, o S2 ordena todos os registros e garante durabilidade
  • As leituras podem começar de segundos atrás até anos atrás, e também permitem tailing em tempo real, algo difícil de fazer com blobs no S3
  • O basin atua como namespace de streams, assim como um bucket atua como namespace de objetos
    • basin e stream podem ser usados sem limite de quantidade
    • também não há limite para o período de retenção dos dados
    • também é possível modelar streams por usuário, sem precisar lidar com limites de cluster ou ajuste de infraestrutura como no Kafka
  • Também oferece suporte a operações de verificação do tail do stream com consistência forte e a controle de concorrência nas escritas
    • é possível usar uma abordagem pessimista com fencing token
    • é possível usar uma abordagem otimista fornecendo o número de sequência esperado
    • esse design mira no offloading durável e na separação entre computação e armazenamento usados por bancos de dados como MemoryDB e Neon

Desempenho, preços, recursos atuais e roadmap

  • O S2 fornece uma API serverless em formato de serviço multitenant, baseada na escalabilidade e na durabilidade do armazenamento de objetos
  • A durabilidade é tratada como um ponto inegociável, enquanto a escolha entre latência e custo é ajustada por storage class em cada stream
    • Standard: baseado no AWS S3 Standard e, como há produtos equivalentes em todos os provedores de nuvem pública, a empresa acredita que poderá oferecê-lo em todas as regiões de nuvem à medida que crescer
    • Express: baseado em quorum de 3 buckets do AWS S3 Express One Zone, com contraparte regional no Azure e possibilidade também no GCP
  • As metas de desempenho e os limites iniciais são os seguintes
    • Standard oferece latência p99 end-to-end de menos de 500 ms
    • Express pode entregar latência de menos de 50 ms
    • toda escrita é armazenada com segurança no S3 com durabilidade regional antes do acknowledgement
    • o throughput suportado é de centenas de MB por segundo por stream
    • a leitura de dados escritos recentemente tem baixo overhead graças ao cache em memória
    • readers atrasados são atendidos diretamente pelo armazenamento de objetos, sem cap
    • no início, as escritas serão limitadas a 125 MiBps por stream e as leituras de escritas recentes a 500 MiBps por stream
  • Durante o período de prévia, será oferecido gratuitamente, e o preço planejado foi divulgado com a meta de ficar significativamente abaixo do nível comum dos sistemas de streaming em nuvem
  • Não há custos fixos como instâncias ou unidades de cluster
  • As interfaces de desenvolvedor disponíveis hoje são as seguintes
  • O sistema é construído sobre infraestrutura de nuvem comprovada, e a base de código em Rust passa por deterministic simulation testing
    • por ainda ser um sistema jovem, podem existir problemas
    • ele está sendo amadurecido rumo à disponibilidade geral e a um SLA confiável para produção
  • O próximo roadmap está organizado em três eixos
    • Compatibilidade com o protocolo Kafka: será oferecida como uma camada open source, e alguns recursos, como compactação baseada em chave, deverão ser integrados diretamente ao S2
    • Basins multi-região: depois de expandir para mais regiões de nuvem, a empresa vê a possibilidade de basins que atravessem regiões e nuvens
    • Latências abaixo de 5 milissegundos: acredita-se que a flexibilidade estrutural das storage classes permita mais 10x de melhora em relação ao Express
  • Para quem usa principalmente as APIs “low-level” do Kafka ou do Kinesis, o S2 mira diretamente requisitos como ausência de limite no número de streams, throughput ordenado 10 a 100 vezes maior e controle de concorrência

Leituras relacionadas

1 comentários

 
GN⁺ 2024-12-22
Opiniões do Hacker News

  • Não sou advogado, mas chamar o produto de S2 e dizer na apresentação que é uma tecnologia que melhora o AWS S3 parece ter grande chance de atrair uma reivindicação de marca registrada/direitos autorais da Amazon
    Como é o mesmo setor, também pode haver claramente confusão por parte dos consumidores. Imagino que tenham pesquisado se a marca estava registrada, claro: https://tsdr.uspto.gov/#caseNumber=98324800&caseSearchType=U...

    • Curiosidade: em espanhol, S2 e EC2 soam exatamente iguais, “ese dos”
      EC2 e S3 já são confusos de distinguir de ouvido, e agora estão adicionando mais um
    • Para ser justo, se a meta é melhorar o S3, o nome certo provavelmente seria S4
    • Pelo menos o R2 da Cloudflare tem uma justificativa para o nome
      É uma nomeação no estilo IBM vs. HAL, ou seja, 『2001: A Space Odyssey』
    • Não sei se eles consultaram um advogado de marcas ruim ou se simplesmente não consultaram ninguém, mas não teria custado tanto assim
      Comecei recentemente um processo de registro de marca, e, pelo site de uma registradora de domínios, o custo era parecido com comprar um domínio como s4.dev. Fazer rebranding depois do lançamento é muito mais doloroso do que mudar antes de lançar
    • A Amazon pode simplesmente criar a mesma coisa, chamar de S3 Streams e nem se importar com o S2
      Talvez até faça uma proposta de aquisição; a chance de isso virar processo parece muito baixa

  • A ideia é realmente ótima e a API é bonita, e eu gostaria de usá-la nos meus projetos, mas não tenho nenhuma confiança de que essa startup vá durar muito no formato atual
    Se der certo, a AWS vai criar uma versão interna melhor e mais barata; por outro lado, também é bem possível que não ganhe traction no mercado. Teria feito muito mais sentido se tivesse saído como um produto para usuário final com dashboard, tipo Papertrail, em vez de uma API de “componente básico de nuvem” intimamente acoplada à AWS. Se permitissem trazer diretamente um backend compatível com S3 como o Digital Ocean Spaces, isso viraria um excelente produto neutro em relação a nuvem e duradouro

    • Do ponto de vista do fundador, eles planejam ser multicloud e, por enquanto, estão começando pela AWS
      A arquitetura interna não é presa à AWS; é uma estrutura de interfaces que pode ser implementada para outros sistemas de nuvem
    • Seria bem irônico se tudo isso já rodasse em cima da AWS
      Não faltam startups que empacotam software open source existente como serviço, fazem marketing dizendo que é mais barato que o produto da AWS e, no fim, rodam na própria AWS
    • A mesma objeção continuou aparecendo para a Aptible(https://aptible.com), mas, mais de 10 anos depois, ela continua sendo uma PaaS muito bem-sucedida
    • Quando se trabalha com infraestrutura de nuvem, a AWS vai tentar te esmagar no preço, mas nunca vai conseguir fazer melhor em experiência do desenvolvedor/experiência do usuário
      Por isso, acho que não há motivo para parar por causa do Beezus
    • A AWS já fez algo parecido: https://news.ycombinator.com/item?id=42211280
      “Amazon S3 now supports the ability to append data to an object” foi anunciado há 30 dias, e o Azure também já tem a mesma funcionalidade há muito tempo com append blob. Ainda é mais cru que o S2 e não tem o conceito de record, mas é um passo muito pequeno para os provedores de nuvem oferecerem isso nativamente. Ao incluir o conceito de record, na prática isso fica mais próximo de uma fila de mensagens, e esse espaço competitivo também é grande, assim como o de soluções de armazenamento de logs

  • Quero entender melhor. Se isso é construído sobre a AWS, e a AWS cobra US$ 0,09 por GB de saída para a internet, aqui eles estão cobrando US$ 0,05 por GB de saída para a internet?
    Parece que estão subsidiando o custo de egress da AWS. Ou será que conseguem usar uma tarifa de saída não divulgada?

    • Do ponto de vista do fundador, eles não cobram durante o período de preview
      Quando chegarem a uma escala significativa, pretendem resolver isso, e certamente há algumas premissas embutidas aí
    • Mesmo no preço de tabela, depois de 150 TB fica US$ 0,05 por GB, e em grandes volumes é ainda mais barato que isso
    • Parece que estão apostando que a maioria dos usuários estará dentro da AWS e só pagará 1 a 2 centavos de custo de transferência
    • Lugares com escala suficiente não pagam preço de varejo por transferência de dados
    • Parece que agora mudaram para US$ 0,08 por GB
      Assim, em 50 TB, o prejuízo máximo seria de US$ 300 por mês, e a partir daí eles começam a ganhar dinheiro

  • Isso é basicamente o WarpStream, mas oferecendo uma API de nível mais baixo em vez de ir direto para compatibilidade com Kafka?
    Se for adotada no longo prazo, uma API básica no nível do S3 para streaming parece realmente valiosa

    • Do ponto de vista do fundador, esse é um resumo em certa medida correto
      Mas a abordagem arquitetural é diferente da WarpStream e, por isso, consegue oferecer latência muito menor. O sistema também não tem disco

  • Essas pessoas escolheram conscientemente passar o resto da carreira explicando que “na verdade, nós não somos o S3”

    • Do ponto de vista do fundador, dá para dizer que 50% do nome é diferente
    • Quantos desses serviços de armazenamento com letra+número já existem agora? S3, B2, R2, S2...
    • Ou também tem este: https://github.com/google/s2geometry
    • Ainda assim, parece melhor do que ter que explicar que não é uma organização paramilitar que cometeu crimes de guerra indescritíveis
      Isso não é motivo de riso
    • Será que eles não podem acabar tendo que explicar isso também em tribunal ou diante de advogados? Não sou advogado, mas isso parece um convite para a Amazon argumentar que eles tentaram se aproveitar deliberadamente da marca “S3” e gerar confusão para desenvolver a própria marca
      Pessoalmente, acho que esse argumento é correto, e o próprio texto deixa isso bem transparente

  • Parece bom, mas não tem Java SDK?
    Pessoalmente, nas empresas em que trabalhei, em 90% dos casos a produção/consumo no Kafka dependia profundamente do Spring ou do cliente básico. Isso praticamente impede até uma prova de conceito leve

    • Da perspectiva da equipe do S2, Java/Kotlin SDK e Python SDK estão no roadmap
      No momento há o Rust SDK e a CLI (https://s2.dev/docs/quickstart). O serviço principal também é escrito em Rust, então Rust pareceu um bom ponto de partida

  • Gosto disso. A próxima coisa que eu gostaria que alguém construísse em cima disso é a parte de aplicar “eventos” de stream como representações consultáveis em um ponto específico no tempo
    Basicamente, é a outra metade para criar algo parecido com o Datomic. Em vez de um banco de dados específico, talvez seja melhor ter um padrão ou framework para criar dados consultáveis concretos em memória. Há várias formas possíveis: aplicar a um SQLite local, aplicar a uma instância local consultável baseada no binlog do MySQL e permitir voltar a um ponto específico no tempo, ou aplicar eventos de apply/undo específicos da aplicação ao estado local

  • Comecei o Gazette há cerca de 10 anos [0]
    O Gazette fica em um ponto intermediário de arquitetura entre Kafka e WarpStream/S2. Ele fornece streams infinitos de log orientados a bytes com S3 como backend, mas os brokers usam discos locais de rascunho para garantir replicação/durabilidade inicial e reduzir a latência de append/read. Assim, o p99 fica abaixo de 5 ms, em vez de acima de 500 ms, e ele garante que todos os arquivos cheguem ao S3, com conveniências como limites configuráveis de tamanho alvo/compactação/latência. Clientes que leem dados históricos buscam o conteúdo diretamente do S3 e depois passam para live tailing dos appends muito recentes
    O Gazette começou como uma ferramenta interna na minha startup anterior e, quando criei a empresa atual, considerei por um período muito breve oferecê-lo como um serviço bruto [1], mas mudei a direção para uma plataforma completa de movimentação de dados [2] que usa o Gazette como detalhe interno de implementação. O posicionamento de mercado de um serviço como esse é extremamente estreito. Ou você o torna compatível em API com o que os clientes-alvo já usam, reduzindo o custo de experimentação a zero (o WarpStream fez isso bem), ou sobe mais na stack da aplicação e resolve mais diretamente o problema que o cliente realmente está tentando resolver
    [0]: https://gazette.readthedocs.io/en/latest/
    [1]: https://news.ycombinator.com/item?id=21464300
    [2]: https://estuary.dev

    • Da perspectiva do fundador do S2, parabéns pelo sucesso da Estuary
      Você não é a primeira pessoa a dizer que esse mercado não existe ou é muito pequeno. Mas, quando você buscou validação no HN, também deve ter achado que havia algo ali. Poderíamos oferecer muito mais coisas sobre o S2, como compatibilidade com Kafka, mas o componente básico central é importante. Eu também queria isso pessoalmente e vi esse tipo de sistema ser recriado em todo tipo de contexto e reutilizado de forma ineficiente, em formas que perderam sua natureza original; essa convicção por si só já foi suficiente para me tornar fundador. Entendo o contexto do conselho e sei das dificuldades pela frente, e agradeço o conselho

  • É um modelo de serviço muito útil, mas, se todas as escritas forem persistidas no S3 antes do acknowledgment, a proposta de valor fica confusa
    O autor pode agrupar batches de records antes de escrevê-los como blobs maiores, e um processo em background pode fazer compaction, mas ainda assim não é um serviço de streaming baseado em object storage? A AWS mostrou, como na passagem do RDS para o Aurora, que em geral está disposta a implementar serviços compatíveis em protocolo, e parece que poderia fazer o mesmo com uma reimplementação do Kafka

    • Da perspectiva da equipe do S2, essencialmente é assim mesmo
      Se os chunks gravados no object storage antes de confirmar a escrita forem projetados para multi-tenant e incluírem records de streams diferentes juntos, dá para escrever com frequência e ainda mirar tamanhos de blob ideais em preço/performance para PUTs do S3 Standard e do Express, respectivamente

  • A tecnologia parece realmente muito legal. Só é uma pena que não seja source-available
    Talvez seja uma opinião minoritária, mas eu consideraria seriamente o serviço comercial se a tecnologia central fosse publicada sob uma licença como a FSL e houvesse self-hosting totalmente suportado. Caso contrário, é difícil justificar o lock-in em comparação com algo como Kafka

    • Da perspectiva do fundador, implementações alternativas da S2 API são bem-vindas
      Também estamos considerando um emulador em memória que vamos abrir como open source. A API em si não é tão complexa. Se você quiser manter a API do Kafka e obter recursos como as classes de armazenamento do S2, um número muito grande de topics/partitions e alta taxa de transferência por partition, estamos planejando uma camada compatível com Kafka, open source e self-hostable. Também pretendemos incluir recursos como criptografia do lado do cliente para dar mais tranquilidade