- O Kafka fez sucesso como log distribuído na era dos data centers, mas na nuvem pública o custo de rede entre AZs e a carga operacional de discos locais aumentam bastante
- O WarpStream é uma plataforma de streaming sem disco compatível com o protocolo Apache Kafka, que roda sobre armazenamento de objetos como S3 sem discos locais nem rebalanceamento de brokers
- Um cluster Kafka com 3 zonas de disponibilidade tem um custo de transferência entre AZs de cerca de US$ 0,053 por 1 GiB transmitido mesmo no melhor caso, mais alto que o custo de armazenar 1 GiB por um mês no S3, de US$ 0,021
- O WarpStream separa armazenamento e computação, assim como dados e metadados, com um Agent sem estado em binário Go e um repositório separado de metadados, mantendo os dados no armazenamento de objetos da conta de nuvem do usuário
- O custo pode cair de 5 a 10 vezes na maioria das cargas Kafka, mas a implementação atual exige aceitar latência de cerca de 400 ms no P99 para requisições Produce e cerca de 1 segundo no P99 de ponta a ponta entre produtor e consumidor
A estrutura básica do Kafka ficou cara na nuvem
- O Apache Kafka, aberto como open source em 2011, virou infraestrutura básica para arquiteturas de streaming
- O problema não é tanto o Kafka em si, mas o fato de seu desenho, ajustado ao data center do LinkedIn em 2011, não combinar bem com cargas modernas de nuvem
- Isso aparece principalmente em custo e carga operacional
- Economia da nuvem: o modo de replicação do Kafka pode gerar custos altos de banda entre AZs
- Carga operacional: operar um cluster Kafka próprio exige equipe dedicada e ferramentas personalizadas
- Sistemas semelhantes que armazenam dados em discos locais também podem sofrer os mesmos problemas de custo e operação
Kafka-nomics: o custo da transferência entre AZs
- Em um cluster Kafka típico com 3 zonas de disponibilidade, os dados produzidos são gravados em outra zona com probabilidade de 2/3 por causa da localização do líder da partição, e depois esse líder replica os dados para os seguidores nas outras duas zonas
- O custo quando 1 GiB é transferido entre zonas é calculado em US$ 0,022
- egress da zona de origem: US$ 0,01
- ingress na zona de destino: US$ 0,01
- Mesmo no melhor caso, o custo de transmitir 1 GiB fica em torno de
0.02 * 2/3 + 0.02 * 2 = $0.053
- Armazenar 1 GiB por um mês no S3 custa US$ 0,021, e o custo de copiar os dados do produtor ao consumidor via Kafka permitiria guardar os mesmos dados no S3 por mais de dois meses
- Em clusters Kafka de alto throughput, a tarifa de banda entre AZs domina o custo mais do que o hardware e pode representar de 70% a 90% do custo da carga
- Mesmo com throughput baixo, se a retenção for longa, a capacidade de armazenamento cresce, e a abordagem de usar SSD local com tripla replicação pode custar por GiB cerca de 10 a 20 vezes mais do que armazenamento de objetos como S3, mesmo assumindo 100% de utilização do disco
A operação do cluster nas costas dos desenvolvedores
- Desenvolvedores adotam Kafka para resolver problemas de negócio, mas antes precisam aprender Kafka e ZooKeeper ou KRaft, eleição de líder, partições, grupos de consumidores, rebalanceamento, tuning de brokers e tuning de clientes
- Tanto os brokers, que formam o plano de dados do Kafka, quanto o plano de controle baseado em consenso, como controladores e ZooKeeper, operam diretamente sobre SSDs locais
- Para executar com segurança tarefas básicas como substituir nós ou expandir o cluster em um Kafka auto-hospedado, é preciso ter equipe especializada e ferramentas customizadas
- A ferramenta embutida de reatribuição de partições do Apache Kafka não consegue gerar automaticamente um plano de redistribuição quando um broker é desativado, e o administrador precisa escrever manualmente o plano de movimentação das réplicas das partições
- Serviços gerenciados como o AWS MSK também não eliminam totalmente a carga operacional
- A documentação de rebalanceamento de cluster do MSK aponta para a documentação do Apache Kafka
- O procedimento inclui editar manualmente um JSON com quais partições devem ser movidas para quais brokers
- O Cruise Control pode reduzir essa carga, mas adiciona aprendizado de novos conceitos, implantação e monitoramento de mais um serviço, além de pontos sensíveis na operação
- O próprio Cruise Control também é uma aplicação JVM que depende de Apache Kafka e ZooKeeper
A abordagem de colocar streaming sobre armazenamento de objetos
- O Husky, criado na Datadog, era um banco de dados colunar para dados de observabilidade que rodava diretamente sobre S3 e operava em grande parte como um data lake sem estado com autoescalonamento
- Depois de construir o Husky, clusters Kafka passaram a parecer uma estrutura antiga em comparação
- A banda Kafka da Datadog era medida em dezenas de GiB/s, e o armazenamento dos brokers em NVMe na escala de PiB
- Cargas de armazenamento em grande escala têm dificuldade de competir, na nuvem, com a economia, confiabilidade, escalabilidade e elasticidade do armazenamento de objetos
- Tecnologias de big data como Snowflake e Databricks também projetam seus sistemas com armazenamento de objetos genérico no centro
- Se um sistema parecido com Kafka for construído diretamente sobre S3, duas cargas podem ser reduzidas ao mesmo tempo
- redução de custo
- redução dos problemas operacionais tradicionais do Kafka
- O desafio central é criar uma infraestrutura de streaming de baixa latência sobre um meio de armazenamento de alta latência como o S3, preservando a semântica do protocolo Kafka sem usar disco local
Arquitetura do WarpStream
- O WarpStream é uma plataforma de streaming compatível com o protocolo Apache Kafka que roda diretamente sobre armazenamentos de objetos genéricos como AWS S3, GCP GCS e Azure Blob Storage
- Não há custo de banda entre AZs, não há discos locais para administrar, e ele pode rodar dentro da VPC do usuário
- No lugar dos brokers Kafka, usa Agent
- O Agent é um binário Go sem estado
- Não usa JVM
- Fala o protocolo Kafka
- Qualquer Agent pode atuar como líder de tópico, commit de offset de grupo de consumidores e coordenador de cluster
- O WarpStream substitui a estrutura stateful do Kafka com duas separações
- separa armazenamento de computação e descarrega os dados para o S3
- separa dados de metadados e descarrega os metadados para um repositório customizado de metadados
- Ao jogar todo o armazenamento no armazenamento de objetos, não há necessidade de rebalanceamento de dados ao aumentar ou reduzir a quantidade de Agents conforme a carga varia
- Mesmo em falhas, é possível repetir a requisição imediatamente em outro Agent, acelerando a recuperação
- Isso também reduz em grande parte os hotspots em que alguns brokers Kafka ficam sobrecarregados por desequilíbrio de dados entre partições
- Os metadados de um WarpStream Virtual Cluster ficam em um banco de dados de metadados customizado
- Replicação, durabilidade e disponibilidade dos dados ficam a cargo do bucket de armazenamento de objetos, e os dados do usuário permanecem dentro da conta de nuvem dele
- O único elemento que sai da conta de nuvem são os metadados da carga, necessários para consenso, como a ordem dos lotes dentro de uma partição
- A estrutura detalhada está descrita na documentação de arquitetura do WarpStream
Exemplo de custo e trade-off de latência
- A carga de streaming contínuo do ambiente de teste produz continuamente dados a 140 MiB/s, e 3 consumidores dedicados os consomem, gerando um tráfego contínuo total de 560 MiB/s
- O custo de rede entre AZs em toda a conta de nuvem foi medido em menos de US$ 15 por dia em média
- Rodando a mesma carga em um cluster Kafka, só o custo de rede entre AZs seria de US$ 641 por dia
- A conta é
0.14GiB * $0.053/GiB * 60 * 60 * 24
- O custo de operações de API do S3 para a mesma carga fica abaixo de US$ 40 por dia
- O hardware dos Agents precisa apenas de VMs de 27 vCPUs
- O custo total de propriedade, na maioria das cargas Kafka, pode ser de 5 a 10 vezes menor com WarpStream
- A maior desvantagem é a latência
- O P99 das requisições Produce hoje é de cerca de 400 ms
- Isso porque não há resposta de confirmação até que os dados sejam armazenados de forma durável no S3 e confirmados no plano de controle da nuvem
- A latência P99 de ponta a ponta do produtor ao consumidor é de cerca de 1 segundo
- Se a carga aceitar latência P99 de cerca de 1 segundo entre produtor e consumidor, é possível reduzir o custo de streaming por GiB em 5 a 10 vezes e praticamente eliminar a carga operacional
- A interface não é um protocolo proprietário, mas Kafka, e pode rodar em ambientes que usam AWS S3, GCP GCS e Azure Blob Storage
Experiência do desenvolvedor e modo de uso
- O WarpStream ataca primeiro dois dos principais problemas do Kafka: economia na nuvem e carga operacional
- O Kafka também tem problemas de experiência de desenvolvimento, e partições são vistas como uma abstração de nível baixo demais para escrever aplicações complexas de processamento de streams
- A empresa pretende tratar no futuro maneiras de tornar aplicações de processamento de streams mais próximas do modo tradicional de escrever aplicações
- A demo pode ser executada em menos de 30 segundos
$ curl https://console.warpstream.com/install.sh | bash
$ warpstream demo
- O WarpStream é a apresentação de produto de uma empresa que vende uma alternativa baseada em armazenamento de objetos ao Apache Kafka, e os números e comparações do texto devem ser lidos nesse contexto
1 comentários
Opiniões do Hacker News
Acho que a afirmação “quase toda empresa de tecnologia usa Kafka” está errada
Não é que tenhamos apresentado evidências um ao outro, mas, das 6 empresas em que trabalhei recentemente, Kafka era usado em 0 delas; e, na empresa anterior a essas, liderei a adoção, mas depois o descartamos
O LinkedIn criou o Kafka para resolver problemas de escala gigantesca que 99% não têm e, embora engenheiros tenham fama de usar tecnologias de que não precisam, acho que a maioria está conseguindo evitar usar Kafka
Se isso é tudo de que você precisa, é fácil usá-lo como um broker de mensagens simples, sem período de retenção; se precisar fazer algo peculiar usando persistência, pode seguir por esse caminho
Se alguém tem sentimentos negativos em relação a uma ferramenta open source robusta e amplamente usada em sua forma básica, em geral imagino que seja por causa de alguns recursos ou casos de uso específicos
Na verdade, esse tipo de expressão pega mal para esse fornecedor. Dá para criticar ou competir com Kafka em termos de prós e contras técnicos, mas distorcer sua posição no mercado não é muito bom
Não duvido que existam bons casos de uso, mas, até agora, só vi entusiastas tentando encaixá-lo à força em qualquer situação, o que me deixou um gosto ruim; por isso fico do lado dos que “não gostam”
Concordo com a parte de “Accidental SRE”, mas Kafka é uma tecnologia sólida, e é por isso que há tantas ferramentas do tipo “um Kafka melhor que Kafka”, como o Redpanda
No fim, parece que saiu do ponto. Mesmo que não seja amplamente usado, isso é uma questão separada de ele ser ou não uma tecnologia polarizadora. Para quem resolve os problemas de escala daquele 1% mencionado, ele ainda pode ser algo que se ama ou odeia
É parecido com dizer que “Lamborghini divide opiniões” estaria errado porque a maioria das pessoas não tem uma Lamborghini. O autor também delimitou explicitamente o escopo ao dizer “na área de dados”
Tenho algumas perguntas
Por isso, o custo de PUT no S3 é proporcional ao número de Agents em execução e ao intervalo de flush, não ao número de topic-partitions. Ele não confirma requisições Produce antes que os dados estejam armazenados de forma durável no S3 e no plano de controle em nuvem
Acredito que não deveríamos ter que escolher entre confiabilidade e custo. O WarpStream oferece confiabilidade e disponibilidade no nível de uma implantação em 3 zonas de disponibilidade pelo custo de uma única zona de disponibilidade
A ordenação é tratada por um banco de dados de metadados customizado executado no plano de controle em nuvem
Não há nada de errado, em si, com a abordagem de ter um cluster Kafka em cada zona de disponibilidade e replicar apenas até o momento de juntar tudo depois. Mas, quando há sistemas distribuídos e zonas de disponibilidade, os engenheiros — e os requisitos de negócio — em geral acabam escolhendo uma configuração multi-AZ. O mesmo vale para regiões
Por isso, a maioria dos clusters Kafka é multi-AZ, embora em muitos casos na verdade não precisasse ser, e a conta dessa despesa acaba sendo atribuída ao Kafka
O protocolo Kafka não preserva de fato a ordem das operações dentro de uma partição Kafka. Ele preserva a ordem das operações dentro de um par produtor-partição, e mesmo isso só é possível quando configurado de determinadas maneiras
A implementação padrão preserva a ordem em que o broker recebe as mensagens do produtor, mas, do ponto de vista de um sistema externo, isso significa mais ou menos que, quando configurado corretamente, mensagens de uma determinada chave e de um determinado produtor são preservadas na ordem de recebimento
O Cloud Metadata Store basicamente faz o papel de distribuir offsets?
Sou Ryan Worl, cofundador e CTO da WarpStream. Estamos muito felizes em anunciar o preview para desenvolvedores do sistema de streaming compatível com o protocolo Kafka que construímos diretamente sobre o S3
Não há discos/nós com estado para executar, nem rebalanceamento de dados, nem ZooKeeper, e não há custo de banda entre zonas de disponibilidade, tornando-o 5 a 10 vezes mais barato
Se tiverem perguntas sobre a WarpStream, vou respondê-las junto com meu cofundador richieartoul
Um dos motivos pelos quais eu não o fiz era sentir um certo paradoxo: se escala não é importante, será que os usuários não prefeririam usar SQLite diretamente em vez de uma versão reduzida do Kafka?
Mas talvez as pessoas gostem da semântica do protocolo Kafka, ou já usem Kafka e tenham percebido que a escala que imaginaram não era aquela, então não precisam arcar com a complexidade. Boa sorte
Se derem suporte ao Cloudflare R2, acho que também seria bom para multicloud
Ela também oferece garantias de ordenação como as que o Kafka oferece no nível de partição?
Se “5 a 10 vezes mais barato” se deve em grande parte à redução de custos entre zonas de disponibilidade, o AWS MSK também não oferece isso?
Uma coisa é certa. Rodar Kafka “do jeito canônico” em VMs individuais sobre um provedor de nuvem é absurdamente caro
Lembro de ter tido uma conversa muito simples com vários clientes sobre Kafka e Hadoop: se o disco já é fornecido como um sistema totalmente redundante, por que replicar os dados de novo no nível de VM/disco?
Nesse caso era Azure Storage, que oferecia armazenamento com redundância local, redundância entre zonas de disponibilidade e redundância global, e uma boa parte disso podia ser usada para executar discos gerenciados
Por isso, serviços gerenciados de Hadoop/Kafka na nuvem bem projetados usam adaptadores de armazenamento para aproveitar a redundância embutida do provedor. É pelo mesmo motivo que alguns provedores de nuvem têm brokers de eventos compatíveis com Kafka
O restante da WarpStream parece mais um bônus, mas fico curioso sobre sua arquitetura interna e como ela evita os custos entre zonas de disponibilidade
Para constar, trabalho na Microsoft, mas antes de entrar, quase 10 anos atrás, eu construía clusters Hadoop/Spark/Kafka
Algumas implementações de Raft permitem nós que têm direito a voto, mas não podem se tornar líderes do quórum. Por exemplo, uma filial em que todo o tráfego passa por um túnel VPN assimétrico não deve ser eleita líder, mas sabe quais candidatos consegue enxergar
Assim, o custo básico de operação do cluster ficava mais perto de 2,2 vezes do que de 3 vezes o hardware, e isso fazia uma grande diferença em soluções pequenas ou sandboxes de desenvolvedor. Também é importante quando 3 shards ficam um pouco abaixo da carga necessária, mas 5 são demais, ou mesmo na diferença entre 6 e 7
O problema é que, em replicação geográfica, isso não resolve os dois problemas centrais do argumento deste texto. Em termos de economia de nuvem, a estratégia de replicação do Kafka, por design, gera custos enormes de banda entre zonas de disponibilidade; em termos de carga operacional, operar seu próprio cluster Kafka praticamente exige uma equipe dedicada e ferramentas customizadas sofisticadas
Ainda assim, precisamos recuperar esse recurso na nuvem. Especialmente quando, como sempre aconteceu no passado, o pêndulo começa a balançar de volta para mais auto-hospedagem
Soluções parecidas com EBS têm um custo associado. Elas são muito caras, especialmente quando você precisa de muitos IOPS. Mesmo que você economize nos custos de tráfego entre zonas de disponibilidade, acaba pagando uma fortuna absurda por armazenamento
Fazendo a replicação por conta própria, você pode usar armazenamento conectado muito mais barato
Para richieartoul: o post do blog está um pouco carregado no tempero
O Kafka não exige, por natureza, uma equipe dedicada de especialistas e milhões de dólares até você operar clusters muito grandes
Mas concordo totalmente que um cluster espalhado por 3 zonas de disponibilidade suga dinheiro em custos de transferência entre zonas. É assim também que a AWS vende o MSK. Eles dizem que a transferência entre zonas de disponibilidade é “gratuita”, mas na verdade ela já está embutida no preço
Parece interessante, mas depois de ler “Accidental SRE” fiquei com duas perguntas
Bare metal existe há muito tempo, e não parece que gerenciar seu próprio bare metal tenha ficado muito mais fácil. Se fosse realmente fácil, os usuários finais gerenciariam mais essas coisas diretamente
Então como vocês gerenciam esse serviço? É em provedor de nuvem ou em bare metal?
Vocês dois têm muita experiência com FoundationDB, que normalmente é gerenciado diretamente. Então escolheram FoundationDB de novo como armazenamento de metadados? Se escolheram, ou se não escolheram, gostaria de saber o motivo
Assim, todos os dados do cliente permanecem dentro da conta de nuvem e do bucket S3 do próprio cliente, e nós não podemos vê-los nem tocá-los. O cliente de fato precisa executar o WarpStream Agent por conta própria, mas ele é apenas um contêiner sem estado, fácil de gerenciar
Avaliamos o FoundationDB como armazenamento de metadados, mas no fim não o usamos. Para tornar o nível gratuito economicamente eficiente, precisávamos fazer o armazenamento de metadados ser o mais eficiente possível para esse caso de uso específico, e isso exigia algo mais customizado
Ainda assim, FoundationDB é uma tecnologia excelente. Entre os vários bancos de dados distribuídos que já usei, é o melhor
A frase “Quantas partições devo usar? Não está claro, mas, uma vez decidido, você nunca mais pode mudar, então é preciso escolher direito” está simplesmente errada. O número de partições pode ser alterado.
E também não entendo bem a afirmação repetida de que “operar Kafka exige uma equipe inteira de engenheiros”. Pela minha experiência, isso não é verdade. É verdade que o custo operacional é alto, mas, na nossa equipe, não exige muito tempo de engenharia.
Muito interessante. Eu projetei algo parecido e pretendia implementar em Zig: https://github.com/fremantle-industries/transit
Uma parte considerável da força do Kafka vem da API, e cheguei a uma conclusão parecida: no fim, a complexidade de gerenciamento de clusters será abstraída por várias implementações.
Se for possível implementar a persistência do Kafka sobre o espaço de chaves do S3, imaginei que daria para começar com uma abordagem que persiste diretamente no S3, como o WarpStream, e depois adicionar mecanismos de camadas com discos hot mais rápidos e memória para reduzir a latência de ponta a ponta.
Gosto da direção. Se quiser conversar mais a fundo, pode me chamar no Twitter: https://twitter.com/rupurt
Em um emprego anterior, criamos algo provavelmente muito parecido com este produto. Tínhamos tráfego de machine learning na casa de dezenas de TB por dia e não precisávamos de latência em tempo real, então movemos tudo para o S3 e obtivemos uma redução de custos de cerca de 90%.
Foi feito sobre a JVM e ainda usávamos um cluster Kafka de 6 brokers para manter metadados. Quando tudo ficava originalmente no Kafka, provavelmente seriam uns 300 brokers.
O modelo de computação/armazenamento do Kafka não escala bem em casos de uso extremos nos quais se pode aceitar latência, e o modelo do Apache Pulsar se encaixava melhor. Na época, porém, o Pulsar não era estável o suficiente para uso em produção.
Um dos pontos centrais da eficiência de custo era que o volume de dados era grande o bastante para não precisarmos esperar muito até atingir tamanhos de arquivo econômicos. É difícil imaginar uma pipeline com menos de 10 MB/s funcionando de forma eficiente desse jeito.
Isso era o memq do Pinterest, ou era outra coisa?
O título do texto deveria ter sido “Kafka is dead. Long live WarpStream.” A parte “long live” aponta para o sucessor.
https://en.wikipedia.org/wiki/The_king_is_dead,_long_live_th...!