Iggy.rs - Streaming de mensajes construido con Rust

Origen

• En abril de 2023, decidió aprender Rust.
• Con base en su experiencia en sistemas distribuidos y mensajería, decidió desarrollar una plataforma de streaming de mensajes.
• El objetivo era entender el funcionamiento interno de los sistemas de mensajería y los trade-offs que enfrentan los desarrolladores.
• Así nació Iggy.rs, con la meta de ser una plataforma de streaming de mensajes enfocada en la velocidad y la ligereza.

Proyecto

• Al inicio, Iggy usaba el protocolo QUIC para ofrecer funciones básicas de intercambio de mensajes.
• Mediante prototipado y mejoras continuas, se implementó un servidor con soporte para escritura/lectura en paralelo y flujos independientes.
• Se agregó soporte para los protocolos TCP y HTTP, y se mejoró el rendimiento optimizando el mecanismo de sincronización de datos.
• Las pruebas de benchmarking confirmaron un alto rendimiento y baja latencia, lo que llevó a convertirlo en un proyecto de largo plazo.

Equipo

• Iggy cuenta con un equipo de unas 10 personas que contribuyen en distintas áreas.
• Participan en diversos proyectos como el servidor central, los SDK, la web UI y la CLI.
• Desarrolladores con experiencias diversas, unidos por su pasión por la programación, participan de manera voluntaria.
• La participación de colaboradores externos de todo el mundo fortaleció la confianza en el proyecto.

Funciones

• Servidor de streaming de mensajes de alto rendimiento, sostenible y basado en logs.
• Alto throughput, baja latencia y uso predecible de recursos gracias al lenguaje compilado Rust.
• Soporte para múltiples streams, topics y particiones, además de varios protocolos de transporte.
• API RESTful, SDK de cliente en varios lenguajes y trabajo directo con datos binarios.
• Funciones del servidor configurables, almacenamiento en el servidor de offsets de consumidores y soporte para diversos métodos de polling de mensajes.
• Grupos de consumidores para orden de mensajes y escalado horizontal, además de expiración de mensajes y deduplicación.
• Soporte de TLS para todos los protocolos de transporte, cifrado opcional de datos y soporte para headers de mensajes.
• CLI integrada y app de benchmarking para administrar el servidor de streaming, con despliegue en un solo binario.

Hoja de ruta

• Tras aparecer en la página de tendencias de GitHub, comenzaron las conversaciones con usuarios sobre nuevas funciones.
• El objetivo es mejorar rendimiento y confiabilidad mediante clustering, I/O de bajo nivel y una arquitectura de un hilo por núcleo.
• Se está experimentando con el mecanismo de consenso Raft, mejoras en operaciones de I/O con io_uring y el uso del runtime monoio.

Futuro

• El objetivo es crear una plataforma de streaming de mensajes de propósito general y desafiar los límites del sistema operativo y del hardware.
• Se planea ofrecer una plataforma integrada fácil de usar, con soporte para varios lenguajes de programación, CLI y web UI.
• Se busca avanzar a partir del feedback y las ideas de la comunidad.

GN⁺ opina

• Iggy.rs es una plataforma de streaming de mensajes basada en Rust, orientada a alto rendimiento y baja latencia.
• Como proyecto de código abierto, sigue creciendo de forma constante gracias a la participación y contribución voluntaria de desarrolladores de todo el mundo.
• Su ambiciosa meta de superar los límites de rendimiento en sistemas distribuidos mediante tecnologías innovadoras como clustering, optimización de I/O de bajo nivel y una arquitectura de un hilo por núcleo resulta especialmente interesante, y lo convierte en un proyecto muy valioso para quienes se interesan en este campo.

[GN⁺]

Opiniones en Hacker News

• Historias como esta fueron las que al principio me hicieron entrar al mundo del software.
  Me parecía ideal ver a gente trabajando junta hacia un mismo objetivo, aunque tuvieran motivos distintos, y que la compensación económica no fuera el único propósito.
  Espero que al proyecto le vaya bien; creo que una comparación con otras alternativas ayudaría a entender mejor dónde se ubica.
  • Así fue exactamente como empezó, y algún día queremos incluir también benchmarks y comparaciones con otras herramientas.
• La idea es buena y el post del blog también.
  El autor se siente humilde, honesto y como un líder de proyecto constructivo.
  • El equipo es realmente excelente.
    Todos decidimos sumarnos a este esfuerzo también con la idea de divertirnos un poco.
• Empezar con QUIC parece una decisión muy aguda e inteligente.
  Ofrece multistreaming útil, similar a SCTP, así que es un buen punto de partida; ya hay muchas bibliotecas buenas disponibles y probablemente mejoren y se optimicen aún más: https://github.com/xileteam/awesome-quic?tab=readme-ov-file#...
  Es un ámbito natural donde usar un protocolo de transporte un poco mejor que los existentes puede traer grandes beneficios, así que me entusiasma lo que QUIC pueda aportar en los próximos 10 años.
  • Empezamos con QUIC porque queríamos probar algo nuevo.
    Dicho eso, el protocolo TCP implementado actualmente es un poco más rápido que QUIC, aunque quizá sea por falta de ajustes adicionales.
    Además, QUIC en MacOS es lento en comparación con Linux.
• ¿Parece un competidor directo de JetStream? Es impresionante el avance logrado en menos de un año.
  https://docs.nats.io/nats-concepts/jetstream
  • Hay bastantes soluciones de streaming de mensajes, como JetStream, Kafka, Redpanda, RabbitMQ Streams y Fluvio.
• No tengo claro cómo se compara con Kafka y con Fluvio, un competidor de Kafka escrito en Rust.
  ¿Está más cerca de una cola de mensajes como RabbitMQ?
  https://www.fluvio.io/
  • Al ser un stream de mensajes, está más cerca de Kafka, Redpanda y el plugin RabbitMQ Streams.
    Fluvio es un producto real y tiene una empresa detrás, así que es más maduro, pero tenemos nuestras propias ideas para convertir a Iggy en una solución competitiva de streaming de mensajes.
  • ¿Fluvio no apunta a reemplazar tanto a Flink como a Kafka? Acabo de conocerlo y estoy tratando de entenderlo.
• Hace unos años hice algo parecido con un amigo en Go.
  https://github.com/thibauts/styx
  • Se ve bastante parecido.
    Me da curiosidad por qué no siguieron trabajando en él.
• Me gustaría probarlo algún día. Aunque parece que primero tendría que aprender Rust.
  Además, me gusta la estética del sitio.
  • Hay varios SDK, y el blog usa el motor Rust Zola.
  • En el post del blog se mencionan SDK para otros lenguajes de programación, así que parece que podrías usarlo sin aprender Rust.
• Este artículo me hizo volver a revisar los orígenes de Fluvio.
  Somos un equipo pequeño con una larga relación con aplicaciones centradas en datos en varios dominios durante las últimas décadas, y apostamos por el streaming de datos basado en Rust y WebAssembly en lugar de Java y la JVM.
  Aquí está el artículo de junio de 2021 en el que el CTO resumió la visión de Fluvio: https://news.ycombinator.com/item?id=38880743
  Como siguen apareciendo preguntas de comparación, también podemos compartir el material que tenemos sobre Fluvio. Es un trabajo largo de documentación, pero podemos compartir lo que tenemos por ahora. Iggy también es un trabajo realmente muy bien hecho.
• Es una idea y un proyecto realmente geniales.
  Pero antes de usarlo creo que tendría que entender dos cosas: cómo se pueden ejecutar más de una instancia de servidor y, al ejecutar más de una, cómo funciona la interacción del filesystem entre servidores.
  • En el post del blog dice que se ejecuta como nodo único. Todavía no hay soporte para clústeres.
    Cuando haya soporte para clústeres, creo que podrá competir con Kafka.
• Me sorprende que hayan elegido monoio.
  Según entiendo, requiere el compilador nightly, y no me pareció una buena elección para mantener un proyecto.
  • Sí requiere nightly, pero solo usa cinco features, y una de ellas se puede eliminar agregando un crate externo.
    La mayoría de las demás tampoco son features demasiado radicales. No revisé el código en profundidad, pero todas me parecen razonables. Por ejemplo, una es una API de la biblioteca estándar para crear contenedores no inicializados, lo que permite eliminar copias.
    No he comparado monoio con glommio, que funciona en stable, pero sería interesante.
  • Monoio parece el runtime con mejor rendimiento y en la práctica también es fácil de usar.
    Por eso elegimos un enfoque bleeding edge. De todos modos, implementar io_uring y otras optimizaciones llevará unos meses más, y es probable que reescribamos algunas partes centrales y pasemos a una estructura de un hilo por core.