O uso generalizado das tecnologias Apache-stack é uma tendência óbvia. E Kafka está na vanguarda da popularidade: hoje, as pessoas que conhecem esse mediador de mensagens talvez excedam o número daqueles que estão acostumados a ver a palavra Franz ao lado da palavra Kafka.
Nós mesmos estamos usando ativamente essa tecnologia em nossos projetos. Mas é sempre interessante, mas como isso funciona para os outros? E é duplamente interessante se este não é apenas um exemplo da prática de alguém, mas um teste focado na tecnologia. Portanto, traduzimos um artigo recente que fala sobre como o Dropbox procurou empiricamente os limites de oportunidades e limites de resistência em Kafka. E encontrou o que ele queria.
Explorando os limites de largura de banda de Kafka no DropboxO Apache Kafka é uma solução popular para streaming distribuído e processamento sequencial de grandes quantidades de dados. É amplamente utilizado na indústria de alta tecnologia, e o Dropbox não é exceção. Kafka desempenha um papel importante na estrutura de dados de muitos de nossos sistemas distribuídos críticos - análise de dados, aprendizado de máquina, monitoramento, recuperação e processamento de fluxo (Cape) (e estes são apenas alguns).
No Dropbox, os clusters Kafka são gerenciados pela equipe Jetstream, cuja principal responsabilidade é fornecer serviços de alta qualidade relacionados ao Kafka. Compreender o limite de largura de banda Kafka na infraestrutura do Dropbox é fundamental para tomar as decisões corretas sobre como alocar recursos em diferentes casos de uso, e esse era um dos objetivos prioritários da equipe. Recentemente, criamos uma plataforma de teste automatizada para conseguir isso. E nesta publicação, gostaríamos de compartilhar nosso método e os resultados.
Plataforma de teste
A figura acima mostra os parâmetros da nossa plataforma de teste para este estudo. Usamos o Spark para hospedar clientes Kafka, o que nos permite produzir e consumir tráfego em um volume arbitrário. Criamos três clusters Kafka de tamanhos diferentes, para que o ajuste do tamanho do cluster fosse literalmente reduzido para redirecionar o tráfego para outro ponto. Kafka criou um tópico para a produção e consumo de tráfego de teste. Para simplificar, distribuímos o tráfego por todos os corretores de maneira uniforme. Para isso, criamos um tópico de teste com o número de seções dez vezes o número de corretores. Cada corretor lidera exatamente 10 seções. Como a gravação em uma seção é seqüencial, poucas partições alocadas a um broker podem levar à gravação competitiva, o que limita a largura de banda. Nossas experiências mostraram que 10 é um bom número para eliminar as dificuldades de gargalo associadas à gravação competitiva.
Devido à natureza distribuída de nossa infraestrutura, nossos clientes estão localizados em várias regiões dos Estados Unidos. Considerando que nosso tráfego de teste está significativamente abaixo do limite dos canais de tronco do Dropbox, podemos assumir com confiança que esse limite de tráfego inter-regional também é aplicável ao tráfego local.
O que afeta a carga?Existem muitos fatores que podem afetar a carga do cluster Kafka: o número de produtores, o número de grupos de consumidores, o deslocamento inicial de consumidores, o número de mensagens por segundo, o tamanho de cada mensagem, o número de tópicos e seções envolvidos. E estes são apenas alguns deles. O grau de liberdade na definição dos parâmetros é alto. Portanto, precisamos encontrar os fatores dominantes para reduzir a complexidade dos testes para um nível aceitável.
Examinamos várias combinações de parâmetros que achamos adequados. Chegamos a uma conclusão surpreendente de que os fatores dominantes que devem ser levados em consideração são os principais componentes da carga: o número de mensagens produzidas por segundo (s / s) e o número de bytes por mensagem (b / s).
Modelo de tráfegoAdotamos uma abordagem formal para entender as limitações do Kafka. Há um espaço de tráfego relacionado para um cluster Kafka específico. Cada ponto desse espaço multidimensional corresponde a um estado único de tráfego aplicável ao Kafka e apresentado como um vetor de parâmetros: <s / s, b / s, # produtores, # grupos de consumidores, # tópicos, ...>. Todos os estados de tráfego que não resultam em congestionamento KafKa formam um subespaço fechado cuja superfície limitará o cluster Kafka.
Para o nosso primeiro teste, escolhemos s / se eb / s como parâmetros principais e reduzimos o espaço de tráfego para um plano bidimensional. Os limites do tráfego permitido formam áreas de rastreamento claras. A detecção do limite de Kafka no nosso caso é equivalente a determinar os valores de contorno dessa área.
Automação de TestePara definir os limites com precisão suficiente, foi necessário realizar centenas de testes com vários parâmetros - o que seria extremamente irracional para se fazer manualmente. Portanto, desenvolvemos um algoritmo que permite executar todos os experimentos sem intervenção humana.
Taxa de congestionamentoÉ muito importante encontrar um conjunto de indicadores que permita avaliar programaticamente o status do Kafka. Examinamos uma ampla gama de indicadores possíveis e resolvemos a pequena amostra a seguir:
- um fluxo de E / S simples é inferior a 20%: isso significa que o pool de fluxos de trabalho usado pelo Kafka para processar solicitações de clientes está muito ocupado e não pode lidar com as tarefas recebidas.
- mudança no conjunto de réplicas sincronizadas (ISR) em mais de 50%: isso significa que ao usar o tráfego por 50% do tempo observado, pelo menos um intermediário não tem tempo para duplicar os dados recebidos de seu líder.
Os mesmos indicadores são usados no Jetstream para monitorar o status do Kafka e servir como os primeiros sinais de alarme de sobrecarga do cluster.
Encontre bordasPara determinar um valor de limite, fixamos b / se mudamos s / s para sobrecarregar Kafka. É possível determinar o valor do limite s / s quando conhecemos o valor s / s seguro e está próximo, mas já está causando sobrecarga. Desses dois, o valor s / s seguro é considerado o valor limite. Como mostrado abaixo, a linha de valores de contorno é formada de acordo com os resultados de testes semelhantes com diferentes indicadores b / s:
Vale ressaltar que, em vez de regular diretamente s / s, experimentamos um número diferente de fabricantes com a mesma velocidade de produção, indicada por np. O fato é que o processamento em lote de mensagens complica o controle sobre a velocidade de produção de um único fabricante. Uma mudança no número de fabricantes, por outro lado, permite alterar linearmente o tráfego. De acordo com nossa pesquisa inicial, um simples aumento no número de fabricantes não criará uma diferença perceptível na carga do Kafka.
Para começar, encontramos um valor de limite separado usando uma pesquisa binária. A pesquisa começa com um intervalo muito grande np [0, max], em que max é o valor que necessariamente levará à sobrecarga. Em cada iteração, um valor médio é selecionado para criar tráfego. Se Kafka estiver sobrecarregado com esse valor, esse valor médio se tornará o novo limite superior; caso contrário, ele se tornará um novo limite inferior. O processo de pesquisa para quando o intervalo é reduzido o suficiente. Em seguida, consideramos os indicadores s / s, que estão relacionados ao limite inferior estabelecido dos valores dos limites.
Resultado
Como você pode ver no diagrama acima, definimos os valores de limite para Kafka de tamanhos diferentes. Com base nos resultados, chegamos à conclusão de que a taxa de transferência máxima possível da infraestrutura do Dropbox é de 60 Mb / s por broker.
Deve-se enfatizar que esse é um limite conservador, pois o conteúdo de nossas mensagens de teste foi o mais aleatório possível, a fim de reduzir o efeito da compactação interna de mensagens no Kafka. Quando o tráfego atinge seu limite, a unidade e a rede são totalmente utilizadas. Nos scripts de trabalho, as mensagens Kafka geralmente correspondem a um determinado padrão, pois geralmente são formadas por algoritmos semelhantes. Isso fornece oportunidades significativas para otimizar a compactação de mensagens. Testamos um cenário extremo, quando as mensagens consistem em um único caractere e registramos uma taxa de transferência muito maior, pois o disco e a rede não são mais um gargalo.
Além disso, esses indicadores de taxa de transferência estão corretos se houver pelo menos 5 grupos de consumidores assinando o tópico testado. Em outras palavras, a largura de banda de gravação indicada é alcançada quando a largura de banda de leitura é 5 vezes maior. Quando o número de grupos de consumidores excede 5, a largura de banda de gravação começa a diminuir à medida que a rede se torna um gargalo. Como a taxa de tráfego de leitura e gravação é muito menor que 5 nos casos em que os clusters de produção do Dropbox são usados, a largura de banda obtida se estende a todos os clusters de produção.
Esse resultado ajudará você a planejar melhor os recursos para o futuro Kafka. Por exemplo, se queremos permitir que até 20% de todos os intermediários trabalhem offline, a largura de banda máxima segura de um intermediário deve ser 60 MB / s * 0,8 ~ = 50 Mb / s. A partir de agora, esse número pode ser usado para determinar o tamanho do cluster, dependendo da taxa de transferência planejada de casos de uso futuros.
Ferramentas para trabalhos futurosA plataforma e o testador automatizado serão ferramentas valiosas para a equipe da Jetstream em seus futuros trabalhos. Quando passamos para um novo hardware, alteramos a configuração da rede ou atualizamos a versão do Kafka, podemos simplesmente executar novamente esses testes e obter novos dados sobre os limites permitidos da nova configuração. Podemos aplicar a mesma metodologia para estudar outros fatores que podem afetar o desempenho de Kafka de várias maneiras. Por fim, a plataforma pode atuar como uma plataforma de teste da Jetstream para simular novas opções de tráfego ou reproduzir problemas em um ambiente isolado.
ResumirNeste artigo, introduzimos nossa abordagem sistemática para entender as limitações do Kafka. É importante observar que alcançamos esses resultados com base na infraestrutura do Dropbox, portanto nossos números podem não ser aplicáveis a outras instalações Kafka devido à diferença nas condições de hardware, software e rede. Esperamos que a metodologia apresentada aqui possa ajudar os leitores a entender seus próprios sistemas.