Ao implantar um cluster do ApsaraMQ for Confluent, os requisitos de throughput, a contagem de partições, as necessidades de retenção de dados e a tolerância à latência determinam os recursos necessários. Este tópico explica como estimar os recursos para cada componente do cluster e apresenta especificações recomendadas para ambientes de produção e teste.
Visão geral da arquitetura
Um cluster do ApsaraMQ for Confluent é composto por sete componentes. A tabela a seguir lista cada componente com sua contagem padrão de réplicas e função.
|
Componente |
Réplicas padrão |
Função |
|
Kafka Broker |
3 |
Processa solicitações de produção e consumo |
|
ZooKeeper |
3 |
Gerencia metadados e coordenação do cluster |
|
Connect |
2 |
Executa conectores source e sink para integração de dados |
|
SchemaRegistry |
2 |
Aplica gerenciamento de schema e compatibilidade |
|
ControlCenter |
1 |
Oferece monitoramento e gerenciamento via web |
|
KsqlDB |
2 |
Processa streams com uma interface SQL |
|
KafkaRestProxy |
2 |
Expõe uma interface HTTP/REST para produzir e consumir mensagens |
Ajuste a contagem de réplicas de cada componente conforme sua carga de trabalho.
Estimar recursos do Kafka Broker
O dimensionamento do Kafka Broker tem o maior impacto no desempenho do cluster. Defina primeiro os parâmetros da carga de trabalho e depois use as fórmulas desta seção para calcular a quantidade de brokers, as Compute Units (CUs) por broker e o tamanho do disco.
Definir parâmetros da carga de trabalho
|
Parâmetro |
Descrição |
Padrão |
|
Fator de fan-out |
Quantidade de grupos de consumidores independentes que leem os mesmos dados. Exclui tráfego de replicação entre brokers. |
-- |
|
Pico de entrada de dados |
Throughput máximo do produtor (MB/s) |
-- |
|
Entrada média de dados |
Throughput médio do produtor (MB/s) |
-- |
|
Período de retenção de dados |
Tempo de armazenamento das mensagens antes da exclusão |
7 dias |
|
Fator de replicação |
Quantidade de cópias por partição |
3 |
Calcular a quantidade de brokers
Um único Kafka Broker suporta até 100 MB/s de throughput. Planeje uma margem de 50% na largura de banda de E/S para absorver picos de tráfego.
Clusters de produção exigem pelo menos 4 brokers:
Broker count = Max(4, peak_inflow x (fan_out + 2 x replication_factor - 1) x 2 / 400)Clusters de teste exigem pelo menos 3 brokers:
Broker count = Max(3, peak_inflow x (fan_out + 2 x replication_factor - 1) x 2 / 300)Limites de partição também restringem a quantidade de brokers:
Por broker: no máximo 2.000 réplicas de partição
Cluster inteiro: no máximo 200.000 réplicas de partição
Se a contagem total de réplicas de partição for alta, dimensione a quantidade de brokers com base nos limites de partição, não apenas no throughput.
Exemplo prático
Considere uma carga de trabalho de produção com:
Pico de entrada: 200 MB/s
Fator de fan-out: 2 (dois grupos de consumidores)
Fator de replicação: 3 (padrão)
Broker count = Max(4, 200 x (2 + 2 x 3 - 1) x 2 / 400)
= Max(4, 200 x 7 x 2 / 400)
= Max(4, 7)
= 7 brokersEscolha CUs por broker
Os requisitos de CU dependem da configuração do cluster, do comportamento dos clientes, da contagem de partições e da quantidade de produtores e consumidores. Use estas diretrizes como ponto de partida:
|
Ambiente |
CUs por broker |
Limites de partição por broker (com 4 CUs) |
|
Produção |
8 ou mais |
100 réplicas líderes ou 300 réplicas de partição (incluindo líderes) |
|
Desenvolvimento e teste |
4 |
100 réplicas líderes ou 300 réplicas de partição (incluindo líderes) |
Calcular o tamanho do disco por broker
Disk per broker = Max(1 TB, average_inflow x retention_period x replication_factor / broker_count)Converta todos os valores para unidades consistentes antes de calcular. Se average_inflow estiver em MB/s, converta retention_period para segundos (1 dia = 86.400 segundos).
Exemplo prático
Com os seguintes parâmetros:
Entrada média: 50 MB/s
Período de retenção: 7 dias (604.800 segundos)
Fator de replicação: 3
Quantidade de brokers: 7
Disk per broker = Max(1 TB, 50 MB/s x 604,800 s x 3 / 7)
= Max(1 TB, ~12,960,000 MB)
= Max(1 TB, 12.4 TB)
= 12.4 TB per brokerEstimar recursos para outros componentes
Connect
|
Recurso |
Recomendação |
|
Nós |
2 ou mais para alta disponibilidade |
|
CUs por nó |
8 ou mais |
SchemaRegistry
|
Recurso |
Recomendação |
|
Nós |
2 |
|
CUs por nó |
2 |
ControlCenter
|
Recurso |
Recomendação |
|
Nós |
1 |
|
CUs |
Mais de 4 |
|
Armazenamento |
300 GB ou mais |
KsqlDB
|
Recurso |
Recomendação |
|
Nós |
2 ou mais para alta disponibilidade |
|
CUs por nó |
5 ou mais |
|
Armazenamento |
100 GB (padrão). Aumente conforme a quantidade de instruções de agregação e o volume de consultas simultâneas. |
KafkaRestProxy
|
Recurso |
Recomendação |
|
Nós |
2 ou mais para alta disponibilidade |
|
CUs por nó |
8 ou mais para cargas contínuas de produção/consumo; 4 para uso leve |
Benchmarks de desempenho
Os benchmarks a seguir foram medidos em um cluster de 4 brokers com um único tópico, 300 partições, 60 produtores e mensagens de 1 KB.
Throughput e latência por quantidade de CUs
|
Especificação do broker |
Throughput total do cluster (sem limitação) |
Throughput médio do produtor (sem limitação) |
Latência média (sem limitação) |
Throughput total (latência < 100 ms) |
|
4 CU por broker |
370 MB/s |
5,95 MB/s |
9.718 ms |
130 MB/s |
|
8 CU por broker |
400 MB/s |
7,33 MB/s |
8.351 ms |
195 MB/s |
|
12 CU por broker |
400 MB/s |
7,39 MB/s |
8.343 ms |
240 MB/s |
|
16 CU por broker |
400 MB/s |
7,47 MB/s |
8.335 ms |
290 MB/s |
|
20 CU por broker |
400 MB/s |
7,58 MB/s |
8.237 ms |
305 MB/s |
Com 4 brokers de 8 ou mais CUs cada, o cluster atinge um throughput básico de 400 MB/s. CUs adicionais melhoram principalmente o throughput sob restrição de latência, e não o throughput de pico.
O desempenho real varia conforme o tamanho da mensagem, a contagem de partições, a quantidade de consumidores e a configuração do cliente. Use estes benchmarks como referência, não como garantia.
Escalar horizontalmente com brokers adicionais
Cada broker adicional acrescenta aproximadamente 100 MB/s de throughput. Ao escalar horizontalmente, aloque pelo menos 8 CUs por broker para evitar que o poder de computação se torne um gargalo.
|
Brokers |
Throughput do cluster |
Mensagens por hora |
Partições suportadas (a 1 MB/s por partição) |
|
4 |
400 MB/s |
14,7 bilhões |
400 |
|
8 |
800 MB/s |
29,5 bilhões |
800 |
|
12 |
1.200 MB/s |
44,2 bilhões |
1.200 |
|
16 |
1.600 MB/s |
59 bilhões |
1.600 |
|
20 |
2.000 MB/s |
73,7 bilhões |
2.000 |
O throughput recomendado por partição é de 1 a 5 MB/s. Para cargas de trabalho de baixa latência, mantenha o throughput por partição na faixa inferior. À medida que a contagem de partições aumenta, o throughput do cluster diminui e a latência de cauda aumenta.
Especificações recomendadas para o cluster
As tabelas a seguir apresentam especificações iniciais para ambientes de produção e teste. Faça ajustes conforme as características da sua carga de trabalho.
Ambiente de produção
Throughput total do cluster: 400 MB/s (excluindo tráfego de replicação).
|
Componente |
CUs por nó |
Disco por nó |
Nós |
|
Kafka Broker |
12 |
2.400 GB |
4 |
|
ZooKeeper |
4 |
100 GB |
3 |
|
Connect |
12 |
-- |
2 |
|
ControlCenter |
12 |
300 GB |
1 |
|
SchemaRegistry |
2 |
-- |
2 |
|
KafkaRestProxy |
16 |
-- |
2 |
|
KsqlDB |
5 |
100 GB |
2 |
Ambiente de teste
Throughput total do cluster: 300 MB/s (excluindo tráfego de replicação).
|
Componente |
CUs por nó |
Disco por nó |
Nós |
|
Kafka Broker |
4 |
800 GB |
3 |
|
ZooKeeper |
2 |
100 GB |
3 |
|
Connect |
4 |
-- |
2 |
|
ControlCenter |
4 |
300 GB |
1 |
|
SchemaRegistry |
2 |
-- |
2 |
|
KafkaRestProxy |
4 |
-- |
2 |
|
KsqlDB |
5 |
100 GB |
2 |
Após crie um cluster, ajuste as configurações de recursos escalando componentes individuais vertical ou horizontalmente.
Faixas de recursos dos componentes
A tabela a seguir lista as faixas de configuração suportadas para cada componente.
|
Componente |
Edição |
Réplicas (padrão / mín / máx) |
CUs por nó (padrão / mín / máx) |
Disco por nó (padrão; faixa) |
|
Kafka Broker |
Professional, Enterprise |
3 / 3 / 20 |
4 / 4 / 20 |
800 GB; 800--30.000 GB |
|
ZooKeeper |
Professional, Enterprise |
3 / 3 / 3 |
2 / 2 / 20 |
100 GB; 100--30.000 GB |
|
ControlCenter |
Professional, Enterprise |
1 / 1 / 1 |
8 / 8 / 20 |
300 GB; 300--30.000 GB |
|
SchemaRegistry |
Professional, Enterprise |
2 / 2 / 3 |
1 / 1 / 20 |
Sem armazenamento |
|
Connect |
Professional, Enterprise (opcional) |
2 / 1 / 20 |
4 / 1 / 20 |
Sem armazenamento |
|
KsqlDB |
Professional, Enterprise (opcional) |
2 / 1 / 20 |
5 / 5 / 20 |
100 GB; 100--30.000 GB |
|
KafkaRestProxy |
Professional, Enterprise (opcional) |
2 / 2 / 20 |
4 / 4 / 20 |
Sem armazenamento |
Referências
Calculadora de dimensionamento para Apache Kafka e Confluent Platform -- modele sua carga de trabalho específica com a calculadora interativa da Confluent.
Requisitos de sistema da Confluent Platform -- orientações adicionais sobre hardware da Confluent.