Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Sistemas Distribuídos - Publish-Subscribe - Kafka

675 views

Published on

Sistemas Distribuídos - Publish-Subscribe - Kafka

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Sistemas Distribuídos - Publish-Subscribe - Kafka

  1. 1. Apache Kafka Natã Melo Renato Almeida
  2. 2. Objetivos ● Modelo publish-subscribe ● Apache Kafka ● Exemplo de uso
  3. 3. Publish-subscribe
  4. 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. 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. 6. Apache Kafka ● Desenvolvida no LinkedIn ● Sistema de mensagens persistentes ● Baseada no modelo Publish-Subscribe ● Linguagem Scala ● Quem utiliza?
  7. 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. 8. Arquitetura ● Topic-based ● Visão geral mensagens, brokers, tópicos, partições, produtores, consumidores
  9. 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. 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. 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. 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. 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. 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. 15. Estudo de Caso: LinkedIn
  16. 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. 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. 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. 19. LinkedIn: Comparação
  20. 20. LinkedIn: Vazão x Latência
  21. 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. 22. Teste de desempenho (Produtor)
  23. 23. Teste de desempenho (Produtor)
  24. 24. Teste de desempenho (Consumidor)
  25. 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. 26. ● Produtor Exemplo de Uso
  27. 27. Exemplo de Uso ● Consumidor
  28. 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
  29. 29. 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.

×