LinkedIn: o log e o nascimento do Kafka

01 · CONTEXTO

O problema que veio antes do Kafka

Jay Kreps conta que o LinkedIn começou a esbarrar nos limites de um banco de dados monolítico e centralizado e precisou migrar para um conjunto de sistemas distribuídos especializados. Entre eles estavam um banco de grafos distribuído, um mecanismo de busca distribuído, uma instalação de Hadoop e armazéns chave-valor de primeira e segunda geração.

O paper do Kafka descreve o outro lado do mesmo problema: os dados de log e de atividade. Sistemas antigos raspavam arquivos de log direto dos servidores de produção, e os agregadores de log mais recentes eram feitos sobretudo para carregar esses dados num data warehouse ou no Hadoop, para consumo offline. No LinkedIn, além da análise offline, era preciso atender a maioria das aplicações em tempo real com atrasos de no máximo alguns segundos.

O autor conta que se envolveu nesse problema por volta de 2008, depois de lançarem o armazém chave-valor. O projeto seguinte era montar um Hadoop funcional e mover para ele parte dos processos de recomendação, e o plano inicial era extrair os dados do data warehouse Oracle que já existia.

1. O plano inicial era extrair os dados do data warehouse Oracle que já existia.

2. O processamento do warehouse não era apropriado para o batch de produção planejado para o Hadoop.

3. O time acabou evitando o warehouse e indo direto aos bancos de origem e aos arquivos de log.

4. Por fim, criaram outro pipeline para carregar dados no armazém chave-valor que serve os resultados.

5. Sempre que havia problema em qualquer um dos pipelines, o Hadoop ficava em grande parte inútil.

02 · A IDEIA

Um log central no lugar de pipelines sob medida

Mesmo com o código feito de forma razoavelmente genérica, cada nova fonte de dados exigia configuração própria e se mostrou uma grande origem de erros e falhas. Havia dezenas de sistemas de dados, e ligar todos eles levaria a um encanamento sob medida entre cada par de sistemas.

Como muitos sistemas são ao mesmo tempo origem e destino, seriam dois pipelines de dados por sistema, um para entrada e outro para saída. Perto da conectividade total, o autor estima algo como O(N2) pipelines.

A saída que ele descreve é isolar cada consumidor da origem do dado: um novo sistema, seja fonte ou destino, deve exigir integração apenas com um pipeline único, e não com cada consumidor de dados. Foi dessa experiência que veio o foco em construir o Kafka, combinando o que tinham visto em sistemas de mensageria com o conceito de log, popular em bancos de dados e no interior de sistemas distribuídos.

O log é talvez a abstração de armazenamento mais simples possível: uma sequência de registros só de acréscimo, totalmente ordenada pelo tempo. A receita do post é pegar os dados da organização e colocá-los em um log central para assinatura em tempo real.

1. Cada fonte lógica pode ser modelada como o seu próprio log, seja uma aplicação que registra eventos ou uma tabela de banco que aceita modificações.

2. Cada sistema assinante lê do log o mais rápido que consegue, aplica cada registro novo ao próprio armazenamento e avança a sua posição no log.

3. Um sistema batch, como Hadoop ou data warehouse, pode consumir só de hora em hora ou por dia, enquanto um sistema de consulta em tempo real pode precisar do dado até o segundo.

4. Um assinante pode cair ou parar para manutenção e recuperar o atraso quando voltar, consumindo no ritmo que ele controla.

5. Nem a fonte nem o log conhecem os destinos, então sistemas consumidores podem ser adicionados e removidos sem mudar o pipeline.

O autor descreve o log como uma espécie de sistema de mensageria com garantias de durabilidade e semântica de ordenação forte.

03 · POR QUE NÃO UMA FILA COMUM

A mensageria tradicional não era o encaixe

O paper lista razões para a mensageria corporativa não ser um bom encaixe para dados de log. Esses sistemas costumam oferecer um conjunto rico de garantias de entrega, e o paper considera essas garantias, muitas vezes, um exagero para coletar dados de log. O desempenho deles também cai bastante quando as mensagens se acumulam, como acontece com consumidores offline, por exemplo aplicações de data warehouse que fazem cargas grandes periódicas em vez de consumo contínuo.

Os autores também preferem o modelo pull ao push, em que o broker repassa dados ao consumidor: no pull, cada consumidor busca as mensagens na taxa máxima que aguenta e evita ser inundado por mensagens empurradas mais rápido do que consegue tratar.

No Kafka, a informação de quanto cada consumidor já leu não fica no broker, e sim no próprio consumidor. O consumidor também pode voltar deliberadamente a um offset antigo e reconsumir dados, o que viola o contrato comum de uma fila, mas se mostrou essencial para muitos consumidores. Por exemplo, se há um erro na lógica da aplicação consumidora, ela pode reprocessar certas mensagens depois de corrigi-lo, algo particularmente importante para as cargas de ETL no data warehouse ou no Hadoop.

04 · EVENTOS E ESCALA

Do uso nos eventos ao volume

O post mostra o efeito no código. A página de vagas passa a só mostrar a vaga e registrar que ela foi exibida, com atributos da vaga, de quem viu e outros fatos úteis. Os demais sistemas interessados, como recomendação, segurança, analytics de quem anuncia e data warehouse, apenas assinam o feed e fazem o seu processamento.

No LinkedIn, o Kafka é usado como o log de eventos central e multiassinante, com várias centenas de tipos de evento definidos. Segundo o post, rodavam na época mais de 60 bilhões de escritas únicas de mensagens por dia, e várias centenas de bilhões se contadas as escritas do espelhamento entre datacenters.

Para escalar na horizontal, o log é dividido em partições. Cada partição é um log totalmente ordenado, sem ordem global entre partições, e quem escreve controla a partição de cada mensagem, com a maioria dos usuários particionando por alguma chave, como o id do usuário. O particionamento permite acrescentar ao log sem coordenação entre os shards e faz a vazão crescer linearmente com o tamanho do cluster.

Cada partição é replicada em um número configurável de réplicas, cada uma com uma cópia idêntica do log da partição. Uma delas atua como líder e, se o líder falha, outra réplica assume. A garantia é que cada partição preserva a ordem e que os appends de um único remetente a uma partição são entregues na ordem enviada; a falta de ordem global é uma limitação, mas o autor diz que não a achou grave.

O log também agrupa leituras e escritas pequenas em operações maiores. O agrupamento em lotes ocorre do cliente ao servidor, nas escritas em disco, na replicação entre servidores, na transferência aos consumidores e na confirmação de dados. Um formato binário simples é mantido entre o log em memória, o log em disco e a transferência pela rede, o que permite otimizações como a transferência sem cópia. O efeito acumulado é que normalmente dá para escrever e ler na taxa que o disco ou a rede suportam, mesmo com conjuntos de dados muito maiores que a memória.

05 · IMPLANTAÇÃO

Como o paper descreve a implantação

O paper descreve um cluster Kafka co-localizado com cada datacenter onde rodam os serviços voltados ao usuário.

1. Os serviços de frontend publicam os dados de log em lotes nos brokers Kafka locais, e um balanceador de hardware distribui os pedidos de publicação entre os brokers.

2. Os consumidores online do Kafka rodam em serviços dentro do mesmo datacenter.

3. Um cluster Kafka em um datacenter separado, para análise offline, roda consumidores embutidos que puxam os dados dos Kafka dos datacenters ao vivo.

4. Jobs de carga puxam os dados desse cluster réplica para o Hadoop e para o data warehouse, e a carga do Hadoop usa um formato de entrada especial que deixa jobs MapReduce lerem direto do Kafka.

5. Sem muito ajuste, a latência ponta a ponta do pipeline completo era de cerca de 10 segundos em média, suficiente para os requisitos deles.

O paper registra que o Kafka acumulava centenas de gigabytes de dados e perto de um bilhão de mensagens por dia. Há ainda um sistema de auditoria para verificar que não há perda de dados ao longo de todo o pipeline, e um esquema que permite impor um contrato de compatibilidade entre produtores e consumidores.

06 · DO PAPER AO POST

O que mudou entre as duas fontes

O paper registra a data de 12 de junho de 2011, e o post de Jay Kreps é de 16 de dezembro de 2013. A tabela compara o que cada fonte diz sobre o mesmo sistema.