Iggy.rs - Construindo streaming de mensagens com Rust

Origem

• Em abril de 2023, foi tomada a decisão de aprender Rust.
• Com base na experiência em sistemas distribuídos e mensageria, decidiu-se desenvolver uma plataforma de streaming de mensagens.
• O objetivo era entender o funcionamento interno dos sistemas de mensageria e os trade-offs enfrentados pelos desenvolvedores.
• Assim nasceu o Iggy.rs, com a meta de ser uma plataforma de streaming de mensagens focada em velocidade e leveza.

Projeto

• O Iggy inicial usava o protocolo QUIC para oferecer funcionalidades básicas de troca de mensagens.
• Por meio de prototipagem contínua e melhorias, foi implementado um servidor com suporte a escrita/leitura paralela e streams independentes.
• Foram adicionados suporte aos protocolos TCP e HTTP, além de melhorias de desempenho com a otimização do mecanismo de sincronização de dados.
• Benchmarks confirmaram alta taxa de transferência e baixa latência, levando à transformação em um projeto de longo prazo.

Equipe

• O Iggy conta com uma equipe de cerca de 10 membros contribuindo em diferentes frentes.
• Há participação em vários projetos, como o servidor principal, SDK, Web UI e CLI.
• Desenvolvedores com experiências diversas participam voluntariamente, unidos pela paixão por programação.
• A participação de contribuidores externos de várias partes do mundo aumentou a confiança no projeto.

Funcionalidades

• Servidor de streaming de mensagens de alto desempenho, sustentável e baseado em log.
• Alta taxa de transferência, baixa latência e uso previsível de recursos graças ao Rust como linguagem compilada.
• Suporte a múltiplos streams, tópicos e partições, além de vários protocolos de transporte.
• API RESTful, SDKs de cliente para várias linguagens e trabalho direto com dados binários.
• Funcionalidades do servidor configuráveis, armazenamento de offsets de consumidores no servidor e suporte a vários métodos de polling de mensagens.
• Grupos de consumidores para ordenação de mensagens e escalabilidade horizontal, além de expiração e deduplicação de mensagens.
• Suporte a TLS em todos os protocolos de transporte, criptografia opcional de dados e suporte a cabeçalhos de mensagens.
• CLI integrada e aplicativo de benchmarking para gerenciamento do servidor de streaming, com distribuição em binário único.

Roadmap

• Após aparecer na página de tendências do GitHub, começaram as discussões com os usuários sobre adição de funcionalidades.
• O objetivo é melhorar desempenho e confiabilidade por meio de clustering, I/O de baixo nível e arquitetura de thread por núcleo.
• Há experimentos com o mecanismo de consenso Raft, melhorias nas operações de I/O com io_uring e planos de usar o runtime monoio.

Futuro

• O objetivo é criar uma plataforma de streaming de mensagens de propósito geral e desafiar os limites do sistema operacional e do hardware.
• Há planos de oferecer uma plataforma unificada e fácil de usar, com suporte a várias linguagens de programação, CLI e Web UI.
• O projeto pretende evoluir com base no feedback e nas ideias da comunidade.

GN⁺ Opinião

• O Iggy.rs é uma plataforma de streaming de mensagens baseada em Rust, com foco em alto desempenho e baixa latência.
• Como projeto open source, continua crescendo com a participação voluntária e as contribuições de desenvolvedores do mundo todo.
• Sua meta ambiciosa de superar os limites de desempenho de sistemas distribuídos por meio de tecnologias inovadoras como clustering, otimização de I/O de baixo nível e arquitetura de thread por núcleo é interessante e faz dele um projeto muito valioso para quem se interessa por essa área.

[GN⁺]

Opiniões no Hacker News

• Histórias como essa foram o que me trouxe para a área de software no começo
  Mesmo que existam motivos diferentes, trabalhar juntos em direção ao mesmo objetivo, e ver que a recompensa financeira não é o único propósito, parece ideal
  Espero que o projeto dê certo; acho que uma comparação com outras alternativas ajudaria a entender melhor onde este projeto se encaixa
  • Foi exatamente assim que começou, e algum dia queremos incluir também benchmarks e comparações com outras ferramentas
• A ideia é boa e o post do blog também
  O autor parece humilde, sincero e um líder de projeto construtivo
  • A equipe é realmente excelente
    Todos decidiram participar desse esforço com a ideia de também se divertir
• Começar com QUIC parece uma escolha muito perspicaz e inteligente
  Ele oferece multistreaming útil, semelhante ao SCTP, o que o torna um bom ponto de partida; já há muitas boas bibliotecas disponíveis, e a tendência é melhorar e ficar mais otimizado: https://github.com/xileteam/awesome-quic?tab=readme-ov-file#...
  É uma área em que apenas usar um protocolo de transporte um pouco melhor do que os existentes já traz ganhos grandes, então estou animado com os próximos 10 anos do QUIC
  • Começamos com QUIC porque queríamos experimentar algo novo
    Porém, o protocolo TCP implementado atualmente é um pouco mais rápido que o QUIC, talvez por falta de ajustes adicionais
    Além disso, no macOS o QUIC é lento em comparação com o Linux
• Parece um concorrente direto do JetStream? É impressionante esse progresso em menos de um ano
  https://docs.nats.io/nats-concepts/jetstream
  • Há muitas soluções de streaming de mensagens, como JetStream, Kafka, Redpanda, RabbitMQ Streams e Fluvio
• Não sei bem como ele se compara ao Kafka e ao Fluvio, concorrente do Kafka escrito em Rust
  Ele é mais próximo de uma fila de mensagens como o RabbitMQ?
  https://www.fluvio.io/
  • Por ser um stream de mensagens, ele é mais próximo de Kafka, Redpanda e do plugin RabbitMQ Streams
    O Fluvio é um produto real e tem uma empresa por trás, então é mais maduro, mas temos nossas próprias ideias para tornar o Iggy uma solução de streaming de mensagens competitiva
  • O Fluvio não tem como objetivo substituir tanto o Flink quanto o Kafka? Acabei de conhecer e estou tentando entender
• Alguns anos atrás, fiz algo parecido em Go com um amigo
  https://github.com/thibauts/styx
  • Parece bastante semelhante
    Fiquei curioso para saber por que vocês não continuaram trabalhando nele
• Quero experimentar algum dia. Mas acho que primeiro preciso aprender Rust
  Além disso, gostei da estética do site
  • Há vários SDKs, e o blog usa o motor Rust Zola
  • O post do blog menciona SDKs para outras linguagens de programação, então parece que dá para usar sem aprender Rust
• Ao ver este texto, acabei revisitando o ponto de partida do Fluvio
  Somos uma pequena equipe com uma longa relação, ao longo das últimas décadas, com aplicações centradas em dados em vários domínios, e estamos apostando em streaming de dados baseado em Rust e WebAssembly em vez de Java e JVM
  O texto em que o CTO resumiu a visão do Fluvio, em junho de 2021, está aqui: https://news.ycombinator.com/item?id=38880743
  Como a pergunta sobre comparação continua aparecendo, também posso compartilhar materiais que temos do lado do Fluvio. É um trabalho longo de documentação, mas posso dividir o que temos hoje. O Iggy também é um trabalho realmente muito bem-feito
• É uma ideia e um projeto muito legais
  Mas acho que preciso entender duas coisas antes de experimentar: como executar mais de uma instância de servidor e, ao executar mais de uma, como funciona a interação entre os sistemas de arquivos dos servidores
  • O post do blog diz que ele é executado como nó único. Ainda não há suporte a cluster
    Quando houver suporte a cluster, acho que poderá competir com o Kafka
• A escolha do monoio me surpreendeu
  Pelo que sei, ele exige o compilador nightly, e eu não achava isso uma boa escolha para manter um projeto
  • Ele realmente exige nightly, mas usa só cinco features, e uma delas pode ser removida adicionando um crate externo
    A maioria das outras também não é nada muito radical. Não olhei o código a fundo, mas todas fazem sentido. Por exemplo, uma delas é uma API da biblioteca padrão para criar contêineres não inicializados, permitindo eliminar cópias
    Não comparei o glommio, que funciona em stable, com o monoio, mas seria interessante
  • O Monoio parece ser o runtime de melhor desempenho e, na prática, também é fácil de usar
    Por isso escolhemos uma abordagem bleeding edge. De qualquer forma, implementar io_uring e outras otimizações ainda levará alguns meses, e é bem provável que reescrevamos algumas partes centrais e migremos para uma estrutura de uma thread por core