Presentación de S2

 (s2.dev)
1 puntos por GN⁺ 2024-12-22 | 1 comentarios | Compartir por WhatsApp
  • S2 es una vista previa de un Stream Store serverless que busca manejar streams en tiempo real durables con la misma simplicidad que el almacenamiento de objetos, elevando logs y streams a elementos básicos del almacenamiento en la nube
  • Los registros se agregan al tail del stream y, aunque varios writers escriban al mismo tiempo, S2 se encarga del ordenamiento durable y admite tanto lecturas históricas como tailing en tiempo real
  • El basin de S2 actúa como un namespace de streams, similar a un bucket, y permite modelado como streams por usuario sin límites en la cantidad de streams ni en el período de retención
  • Las clases de almacenamiento comienzan con Standard y Express, con objetivos de latencia p99 de menos de 500 ms y menos de 50 ms, respectivamente, separando las opciones de latencia y costo
  • Actualmente ofrece API gRPC, SDK de Rust y CLI, y deja para las próximas etapas una API REST, compatibilidad con el protocolo Kafka, multi-region basins y latencias menores a 5 ms

El modelo de almacenamiento de streams que propone S2

  • S2 apunta a ser un Stream Store serverless para datos de streaming en la era de la nube
  • La idea central es que los logs o streams también puedan ser elementos básicos del almacenamiento en la nube, como los objetos
  • El almacenamiento de objetos se enfoca en PUT / GET / DELETE sobre objetos con nombre, y en blobs y rangos de bytes; es adecuado para datos en reposo
  • El almacenamiento de streams de S2 ofrece APPEND / READ / TRIM sobre un Stream con nombre, y toma como unidades básicas los registros y los números de secuencia
  • Las escrituras se agregan al tail del stream y, aunque varios writers escriban al mismo tiempo, S2 ordena todos los registros y garantiza su durabilidad
  • Las lecturas pueden empezar desde hace segundos hasta años atrás, y también es posible el tailing en tiempo real, algo difícil con blobs de S3
  • Un basin funciona como namespace de streams, del mismo modo que un bucket funciona como namespace de objetos
    • Se pueden usar basins y streams sin límite de cantidad
    • Tampoco hay límite en el período de retención de datos
    • También es posible modelar streams por usuario, sin tener que lidiar con límites de clústeres ni tuning de infraestructura como en Kafka
  • También admite operaciones para comprobar el tail del stream con consistencia fuerte y control de concurrencia al escribir
    • Es posible un enfoque pesimista usando fencing tokens
    • Es posible un enfoque optimista proporcionando el número de secuencia esperado
    • Este diseño apunta al offloading de durabilidad y a la separación entre cómputo y almacenamiento que usan bases de datos como MemoryDB y Neon

Rendimiento, precio, funciones disponibles y roadmap

  • S2 ofrece una API serverless en forma de servicio multitenant, basada en la escalabilidad y durabilidad del almacenamiento de objetos
  • La durabilidad se trata como un aspecto no negociable, y la elección entre latencia y costo se ajusta por stream mediante la clase de almacenamiento
    • Standard: se basa en AWS S3 Standard y, dado que todos los proveedores de nubes públicas tienen productos equivalentes, se considera posible ofrecerlo en todas las regiones cloud a medida que crezca
    • Express: se basa en un quorum de 3 buckets de AWS S3 Express One Zone; Azure tiene una contraparte regional y también se ve potencial en GCP
  • Los objetivos de rendimiento y los límites iniciales son los siguientes
    • Standard ofrece latencia p99 end-to-end de menos de 500 ms
    • Con Express se puede esperar una latencia de menos de 50 ms
    • Todas las escrituras se guardan de forma segura en S3 con durabilidad regional antes del acknowledgement
    • El throughput soporta un nivel de cientos de MB por segundo por stream
    • La lectura de datos escritos recientemente tiene poco overhead gracias al caché en memoria
    • Los readers rezagados se sirven directamente desde object storage y no tienen cap
    • Al inicio, las escrituras se limitan a 125 MiBps por stream, y las lecturas de escrituras recientes a 500 MiBps por stream
  • Durante la vista previa se ofrece gratis, y se publicó el precio previsto con el objetivo de ser significativamente más barato que el nivel habitual de los sistemas de streaming en la nube
  • No hay costos fijos como instancias o unidades de clúster
  • Las interfaces para desarrolladores disponibles actualmente son las siguientes
  • El sistema está sobre infraestructura cloud probada, y la base de código en Rust pasa por deterministic simulation testing
    • Todavía es un sistema joven, por lo que puede haber problemas
    • Se está madurando hacia la disponibilidad general y SLA confiables para producción
  • El siguiente roadmap se organiza en tres ejes
    • Compatibilidad con el protocolo Kafka: se ofrecerá como una capa open source, y algunas funciones como key-based compaction se integrarán directamente en S2
    • Multi-region basins: tras expandirse a más regiones cloud, se explorará la posibilidad de basins que crucen regiones y nubes
    • Latencias por debajo de 5 milisegundos: por la flexibilidad estructural de las clases de almacenamiento, se considera posible una mejora adicional de 10 veces frente a Express
  • Para quienes usan principalmente las API “low-level” de Kafka o Kinesis, S2 apunta directamente a requisitos como ausencia de límite en la cantidad de streams, throughput ordenado 10 a 100 veces mayor y control de concurrencia

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-12-22
Comentarios en Hacker News

  • No soy abogado, pero ponerle al producto S2 y decir en la presentación que es una tecnología para mejorar AWS S3 parece muy propenso a atraer reclamos de marca registrada/derechos de autor por parte de Amazon
    Al estar en la misma área, claramente también puede haber confusión entre consumidores. Seguro investigaron si la marca estaba registrada, pero igual: https://tsdr.uspto.gov/#caseNumber=98324800&caseSearchType=U...

    • Dato curioso: en español, S2 y EC2 suenan igual, ambas como “ese dos”
      Ya de por sí EC2 y S3 son confusos de distinguir al oído, y ahora se suma otro más
    • Siendo justos, si el objetivo era mejorar S3, entonces debería llamarse S4
    • Al menos el R2 de Cloudflare sí tiene una lógica detrás del nombre
      Es IBM frente a HAL, o sea, una referencia al estilo de 2001: A Space Odyssey
    • No sé si hablaron con un mal abogado de marcas o si directamente no hablaron con ninguno, pero no les habría costado tanto
      Hace poco empecé un trámite de registro de marca, y en el sitio de un registrador de dominios costaba más o menos lo mismo que comprar un dominio como s4.dev. Hacer rebranding después del lanzamiento es mucho más doloroso que cambiarlo antes
    • Amazon podría simplemente hacer lo mismo, llamarlo S3 Streams y no prestarle atención a S2
      Tal vez hasta podrían hacer una oferta de compra, pero parece muy poco probable que esto llegue a una demanda

  • La idea es realmente buena, la API es hermosa y me gustaría usarla en mi proyecto, pero no tengo ninguna confianza en que esta startup vaya a durar mucho en su forma actual
    Si tiene éxito, AWS hará una versión interna mejor y más barata; y, por otro lado, también es muy posible que no logre traction en el mercado. Habría tenido mucho más sentido como un producto final para usuarios, con dashboard incluido, tipo Papertrail, en lugar de otra API de “componente básico de nube” fuertemente atada a AWS. Si además permitieran traer tu propio backend compatible con S3, como Digital Ocean Spaces, sería un producto excelente, duradero y neutral frente a la nube

    • Desde el punto de vista del fundador, sí planean ser multicloud, y por ahora están empezando con AWS
      La arquitectura interna no está atada a AWS, sino que tiene una estructura de interfaces que puede implementarse para otros sistemas cloud
    • Sería bastante irónico si todo esto ya estuviera corriendo sobre AWS
      No se acaban las startups que empaquetan software open source como servicio, lo comercializan como más barato que el producto de AWS y, aun así, corren sobre AWS
    • A Aptible(https://aptible.com) le hacían esta misma objeción todo el tiempo, pero más de 10 años después sigue siendo una PaaS muy exitosa
    • Si trabajas en infraestructura cloud, AWS va a intentar aplastarte en precio, pero jamás va a hacerlo mejor en experiencia de desarrollador/experiencia de usuario
      Así que no creo que haya que frenarse por culpa de Beezus
    • AWS ya hizo algo parecido: https://news.ycombinator.com/item?id=42211280
      Hace 30 días anunciaron “Amazon S3 now supports the ability to append data to an object”, y Azure también tiene esa misma función desde hace mucho con append blob. Todavía es más rudimentario que S2 y no tiene el concepto de record, pero el paso que falta para que un proveedor cloud lo ofrezca de forma nativa es muy pequeño. Si además agregan el concepto de record, en la práctica ya queda bastante cerca de una cola de mensajes, y ese espacio competitivo también es grande; lo mismo pasa con las soluciones de almacenamiento de logs

  • Quiero entender esto. Si lo construyen sobre AWS y AWS cobra $0.09 por GB de salida a internet, ¿acá están cobrando $0.05 por GB por esa misma salida a internet?
    Suena como si estuvieran subsidiando el costo de salida de AWS. ¿O tienen acceso a una tarifa de salida no pública?

    • Desde el punto de vista del fundador, durante el preview no están cobrando
      Planean resolverlo cuando lleguen a una escala significativa, y claramente hay algunos supuestos metidos ahí
    • Incluso a precio de lista, después de 150TB ya baja a $0.05 por GB, y a gran escala sale todavía más barato
    • Parece que están apostando a que la mayoría de sus usuarios van a estar dentro de AWS y solo pagarán 1–2 centavos de costo de transferencia
    • Los que tienen suficiente escala no pagan precio minorista por la transferencia de datos
    • Parece que ahora lo cambiaron a $0.08 por GB
      En ese caso, a 50TB perderían como máximo $300 al mes, y a partir de ahí empezarían a ganar dinero

  • ¿Esto es básicamente WarpStream, pero ofreciendo una API de nivel más bajo en vez de ir directamente por compatibilidad con Kafka?
    A largo plazo, si llega a adoptarse, una API básica a nivel S3 para streaming sí parece realmente valiosa

    • Desde el punto de vista del fundador, es un resumen bastante acertado
      Pero el enfoque de arquitectura es distinto al de WarpStream y por eso pueden ofrecer una latencia mucho más baja. El sistema tampoco usa disco

  • Estas personas eligieron conscientemente pasar el resto de su carrera explicando “en realidad no somos S3”

    • Desde el punto de vista del fundador, se podría decir que el 50% del nombre es distinto
    • ¿Cuántos servicios de almacenamiento con letra+número hay ya? S3, B2, R2, S2...
    • O también está esto: https://github.com/google/s2geometry
    • Aun así, parece mejor que tener que explicar que no eres un grupo paramilitar que cometió crímenes de guerra indescriptibles
      Eso no da risa
    • ¿Y no podrían tener que dar esa misma explicación en un tribunal o frente a abogados? No soy abogado, pero esto parece invitar a Amazon a argumentar que intentaron aprovecharse deliberadamente de la marca “S3” y generar confusión para hacer crecer su propia marca
      En lo personal, me parece una acusación acertada, y creo que el texto original también lo deja bastante claro

  • Se ve bien, pero ¿no hay Java SDK?
    Personalmente, en las empresas donde trabajé, en el 90% de los casos dependían mucho de Spring o del cliente base para producir/consumir Kafka. Así, incluso una prueba de concepto ligera queda prácticamente bloqueada.

    • Desde la perspectiva del equipo de S2, Java/Kotlin SDK y Python SDK están en la lista a futuro.
      Por ahora hay un Rust SDK y CLI (https://s2.dev/docs/quickstart). Los servicios principales también están escritos en Rust, así que Rust se sintió como un buen punto de partida.

  • Esto me gusta. Lo siguiente que me gustaría que alguien construyera encima de esto es la parte de aplicar los “eventos” del stream a una representación consultable en un punto específico del tiempo.
    Básicamente, es la otra mitad para hacerlo parecido a Datomic. Más que una base de datos específica, quizá sería mejor un patrón o framework para crear datos concretos en memoria que se puedan consultar. Se podría aplicar sobre un Sqlite local, o basarse en MySQL binlog para aplicarlo a una instancia local consultable y rebobinarla a un momento específico, o aplicar eventos de apply/undo por aplicación sobre un estado local; hay varias formas de hacerlo.

  • Empecé Gazette hace unos 10 años [0].
    Gazette está en un punto intermedio de arquitectura entre Kafka y WarpStream/S2. Ofrece streams de log infinitos orientados a bytes con S3 como backend, pero los brokers usan discos locales temporales para la replicación inicial, la garantía de durabilidad y para reducir la latencia de append/read. Por eso, el p99 es menor a 5 ms en vez de superar los 500 ms, y además garantiza que todos los archivos lleguen a S3, junto con funciones prácticas como tamaño objetivo configurable, compresión y límites de latencia. Los clientes que leen datos históricos obtienen el contenido directamente desde S3 y luego cambian al live tailing de los append más recientes.
    Gazette empezó como una herramienta interna en mi startup anterior, y cuando fundé mi empresa actual consideramos muy brevemente ofrecerlo como raw service [1], pero luego cambiamos de dirección hacia una plataforma completa de movimiento de datos [2] que usa Gazette como detalle interno de implementación. El posicionamiento de mercado de este tipo de servicio es extremadamente estrecho. O lo haces compatible por API con lo que ya usan los clientes objetivo para que el costo de probarlo sea 0 (WarpStream hizo esto muy bien), o subes más en el stack de aplicaciones y resuelves más directamente el problema que el cliente realmente quiere solucionar.
    [0]: https://gazette.readthedocs.io/en/latest/
    [1]: https://news.ycombinator.com/item?id=21464300
    [2]: https://estuary.dev

    • Desde la perspectiva del fundador de S2, felicidades por el éxito de Estuary.
      No eres la primera persona en decir que este mercado no existe o que es muy pequeño. Pero cuando tú también buscaste validación en HN, seguramente pensabas que había algo ahí. También podríamos ofrecer mucha más compatibilidad con Kafka sobre S2, pero los componentes fundamentales importan. Yo también los quería personalmente, y como vi que se recreaban ineficientemente en todo tipo de contextos y se reutilizaban como una forma de sistema que había perdido su naturaleza original, esa convicción por sí sola bastó para convertirme en fundador. Entiendo el trasfondo del consejo, conozco las dificultades que vienen y agradezco el consejo.

  • Es un modelo de servicio muy útil, pero si todas las escrituras se persisten en S3 antes de responder con confirmación, la propuesta de valor se vuelve confusa.
    El autor puede agrupar lotes de records antes de escribirlos como blobs más grandes, y un proceso en segundo plano puede hacer compaction, pero aun así, ¿no sigue siendo un servicio de streaming basado en almacenamiento de objetos? AWS ya mostró, como hizo al pasar de RDS a Aurora, que en general tiene voluntad de implementar servicios compatibles a nivel de protocolo, y parece que podría hacer lo mismo con una reimplementación de Kafka.

    • Desde la perspectiva del equipo de S2, en esencia sí funciona así.
      Si los chunks que se escriben en el almacenamiento de objetos antes de confirmar una escritura se diseñan como multi-tenant y contienen records de distintos streams juntos, se puede escribir con frecuencia y al mismo tiempo apuntar al tamaño de blob ideal en costo/rendimiento tanto para S3 standard como para express PUT.

  • La tecnología de verdad se ve muy buena. Solo que me da pena que no sea open source.
    Quizá sea una opinión minoritaria, pero si la tecnología central se publicara con una licencia como FSL y fuera posible hacer self-hosting totalmente soportado, consideraría seriamente el servicio comercial. De otro modo, es difícil justificar la dependencia frente a algo como Kafka.

    • Desde la perspectiva del fundador, daría la bienvenida a implementaciones alternativas del S2 API.
      También estamos considerando un emulador en memoria que nosotros mismos publicaríamos como open source. La API en sí no es tan compleja. Si quieres mantener la API de Kafka y al mismo tiempo obtener funciones de S2 como su clase de almacenamiento, una enorme cantidad de topic/partition y alto rendimiento por partición, estamos planeando una capa compatible con Kafka, open source y self-hostable. También planeamos incluir funciones como cifrado del lado del cliente para dar más tranquilidad.