Apache KafkaNatã Melo
Renato Almeida
Objetivos
● Modelo publish-subscribe● Apache Kafka● Exemplo de uso
Publish-subscribe
Motivação
● Dados de atividades e dados operacionais○ Requisito importante para aplicações Web○ Resolvido normalmente com logging○ Escalável para aplicações pequenas
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
Apache Kafka
● Desenvolvida no LinkedIn● Sistema de mensagens persistentes● Baseada no modelo Publish-Subscribe● Linguagem Scala
● Quem utiliza?
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
Arquitetura
● Topic-based● Visão geral
mensagens, brokers, tópicos, partições, produtores, consumidores
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
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
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
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
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
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
Estudo de Caso: LinkedIn
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
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
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
LinkedIn: Comparação
LinkedIn: Vazão x Latência
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
Teste de desempenho (Produtor)
Teste de desempenho (Produtor)
Teste de desempenho (Consumidor)
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)
● Produtor
Exemplo de Uso
Exemplo de Uso
● Consumidor
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
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.