Sistemas Distribuídos - Publish-Subscribe - Kafka

561 visualizações

Publicada em

Sistemas Distribuídos - Publish-Subscribe - Kafka

Publicada em: Tecnologia
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

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.

×