Sistemas Distribuídos - Publish-Subscribe - Kafka

1. Apache Kafka
Natã Melo
Renato Almeida

2. Objetivos
● Modelo publish-subscribe
● Apache Kafka
● Exemplo de uso

3. Publish-subscribe

4. Motivação
● Dados de atividades e dados operacionais
○ Requisito importante para aplicações Web
○ Resolvido normalmente com logging
○ Escalável para aplicações pequenas

5. Motivação
● Problema: tempo real
○ Fluxo de dados muito alto (vazão alta)
○ Logging tradicional:
■ Latência torna inviável a utilização
■ Pode prejudicar o comportamento do sistema
● Objetivo:
○ Baixa latência para grandes volumes de dados

6. Apache Kafka
● Desenvolvida no LinkedIn
● Sistema de mensagens persistentes
● Baseada no modelo Publish-Subscribe
● Linguagem Scala
● Quem utiliza?

7. Apache Kafka
● Características
○ Distribuído
■ Consumidores e produtores espalhados pela
rede
○ Escalável
■ Vazão alta
■ Baixa latência
○ Simples
■ Característica do modelo
■ Desacoplamento

8. Arquitetura
● Topic-based
● Visão geral
mensagens, brokers, tópicos, partições, produtores, consumidores

9. Eficiência
● Don't fear the filesystem!
○ Sem cache em memória (a nível de processo)
■ Overhead mínimo com garbage collecting
■ Cache a nível de sistema de arquivos
○ Estruturas de dados eficientes para acesso
● Armazenamento simples
○ Cada partição de tópico é um "log" lógico
■ Conjuntos de arquivos de tamanho fixo
○ Espera um tempo por mais mensagens antes de
gravar no disco
■ Só ficam visíveis para consumo após gravadas

10. Eficiência
● Transferência eficiente
○ Mensagens podem ser enviadas em "lotes"
■ Leitura é "sequencial"
● Stateless
○ Estado de consumo (mensagens consumidas) é
mantido no consumidor e não nos brokers
○ Mensagens são removidas automaticamente após
certo período
■ Tipicamente, 7 dias

11. Coordenação distribuída
● Grupo de consumidores (um ou mais)
● Mensagens de uma partição são consumidas por um
único consumidor
○ Diminuir overhead de coordenação
● Consumidores coordenam entre eles próprios de forma
descentralizada
○ Consensus Zookeeper

12. Coordenação distribuída
● Uso do Zookeeper auxilia na coordenação
○ Armazenam informações em registros
■ Consumidores
■ Brokers
■ Partições
● Mudanças no conjunto de brokers ou no grupo de
consumidores são notificadas por watchers

13. Entrega e confiabilidade
● Garante "pelo menos" uma entrega
○ Entregas duplicadas devem ser tratadas na
aplicação
● Ordenação
○ Mensagens de mesma partição são entregues em
ordem
○ Não há garantia para partições diferentes
● Integridade
○ Mensagens entregues possuem CRC
○ Remove mensagens corrompidas

14. Tolerância a faltas
● O que acontece se um broker falhar?
○ Suas partições são removidas do registro
○ Mensagens não consumidas ficam indisponíveis
○ Se o sistema de armazenamento for permanentemente
danificado, suas mensagens estão perdidas
■ Não há replicação
● O que acontece se um consumidor falhar?
○ Sua entrada e suas partições de consumo são removidas
dos registros
● Após a falha, os consumidores são notificados e inicia um
balanceamento

15. Estudo de Caso: LinkedIn

16. LinkedIn: Resultados Experimentais
● Experimento comparativo
● Configurações do ambiente
○ 2 máquinas Linux, 8 cores de 2GHz, 16GB de
memória, 6 discos (RAID 10)
○ Link de 1GB
● Um produtor, um consumidor, 100 tópicos

17. LinkedIn: Resultados Experimentais
● Teste para produtor
○ 10 milhões de mensagens (200B) produzidas
● Muito menos overhead de armazenamento
○ ActiveQM - 70% mais de espaço (em 10 milhões mensagens)
● Vantagens
○ Não espera por confirmação dos brokers
■ Aumento da vazão do publisher
○ Formato de mensagem mais eficiente (batch size: 50)
● Desvantagens
○ Não existe garantia que o broker recebeu a mensagem

18. LinkedIn: Resultados Experimentais
● Teste para consumidor
○ Um consumidor para recuperar um total de 10
milhões de mensagens (200B)
● Consumiu quatro vezes mais que os demais
● Vantagens
○ Redução do overhead de transmissão
■ API Send File
○ Não há atividades de escrita no disco

19. LinkedIn: Comparação

20. LinkedIn: Vazão x Latência

21. Testes de Desempenho
● Usando simulador do Kafka
● Cenários remotos com mesmos nós
○ Broker em Virgínia/EUA
○ 2 consumidores em São Paulo/SP
○ 2 produtores em São Paulo/SP
● Variando parâmetros:
○ Tamanho do lote (produtor)
■ Em número de mensagens
○ Tamanho da mensagem (produtor)
■ Em KB
● N° de mensagens produzidas fixo
○ 20.000

22. Teste de desempenho (Produtor)

23. Teste de desempenho (Produtor)

24. Teste de desempenho (Consumidor)

25. Exemplo de Uso (Implementação)
● Consumidor / produtor simples
● Informações básicas de configuração:
○ Arquivos .properties ou diretamente no código
○ Dois modos de conexão
■ Zookeeper (recomendado)
■ Conexão direta ao(s) broker(s)

26. ● Produtor
Exemplo de Uso

27. Exemplo de Uso
● Consumidor

28. Considerações Finais
● Trabalhos futuros / em andamento
○ Replicação
○ Hierarquia de tópicos
○ Clientes em outras linguagens
● Dificuldade na configuração
○ Material da página só fornece exemplo 'local'
■ server.properties
● hostname => recomenda-se definir

30. Referências
● Kafka: a Distributed Messaging System for Log
Processing. (Jay Kreps, Neha Narkhede, Jun Rao)
● Building LinkedIn’s Real-time Activity Data Pipeline.
(LinkedIn team)
● Disponível em: http://incubator.apache.
org/kafka/projects.html. Acesso em: 9 de novembro de
2012.
● Disponível em: https://cwiki.apache.
org/confluence/display/KAFKA/Index. Acesso em: 9 de
novembro de 2012.