Sistemas Distribuídos - Publish-Subscribe - Kafka
0 gostou1,038 visualizações
O documento descreve o Apache Kafka, um sistema de mensagens distribuído e escalável. Ele discute os motivos para usar o Kafka, como funciona, sua arquitetura baseada em tópicos, e como empresas como o LinkedIn usam Kafka para lidar com grandes volumes de dados em tempo real.
Sistemas Distribuídos - Publish-Subscribe - Kafka
- 1. Apache Kafka Natã Melo Renato Almeida
- 2. Objetivos ● Modelo publish-subscribe ● Apache Kafka ● Exemplo de uso
- 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
- 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.