Conceitos do Serviço Streaming com Apache Kafka
Para entender melhor o OCI Streaming com Apache Kafka, analise alguns termos e conceitos.
Terminologias
- Apache Kafka
- O Apache Kafka é uma plataforma de streaming de eventos de código aberto. É executado como um sistema distribuído que consiste em servidores e clientes. O OCI Streaming com Apache Kafka permite que você execute clusters Kafka totalmente gerenciados em uma tenancy com 100% de compatibilidade com o Apache Kafka.
Você usa a Console, a API ou a CLI do OCI para criar e atualizar o Cluster e o Broker.
- Cluster
- Um sistema distribuído de servidores ou brokers do Apache Kafka que armazenam e gerenciam os dados de streaming. No OCI Streaming com Apache Kafka, você pode criar dois tipos de clusters: cluster inicial ou cluster de alta disponibilidade.
- Corretor
- Um servidor Kafka que armazena dados e processa solicitações do cliente. Dependendo da carga de trabalho, você pode criar de 1 a 30 brokers em cada cluster. Cada broker em um cluster é um nó de computação usado para armazenar tópicos.
Você usa a API ou a CLI do Apache Kafka para criar e atualizar tópicos, partições, registros e operações de produtores e consumidores.
- Tópico
- Categorias definidas pelo usuário em um broker em que os dados são armazenados. Cada tópico pode ter muitas partições para distribuição de dados e processamento paralelo.
- Partições
- Os tópicos são divididos em número especificado pelo usuário de partições que armazenam registros. Os registros são ordenados dentro de cada partição e cada registro recebe uma compensação exclusiva e crescente sequencialmente.
- Registros
- Principais pares de dados de valor que são gravados e lidos em tópicos.
- Produtor
- Aplicativo que grava registros em tópicos.
- Consumidor
- Aplicativo que lê registros de tópicos.
- Cluster do Coordenador
- Uma instância do coordenador interno dentro de cada cluster que rastreia atividades em um cluster, como partições. Um cluster com 2 ou menos brokers obtém um único cluster de coordenador de nó. Clusters maiores obtêm um cluster de coordenador de 3 nós. Não é possível exibir detalhes do cluster do coordenador.
Os Limites de Serviço
| Limite | Valor |
|---|---|
| Clusters por tenancy | 5 |
| Corretores por cluster | 30 |
| Corretores por tenancy | 150 |
| Armazenamento |
Mínimo de 50 GB a Máximo de 5 TB por broker Máximo de 150 TB por cluster |
| Entrada por cluster | sem limites |
| Saída por cluster | sem limites |
| Entrada por partição | sem limites |
| Saída por partição | sem limites |
| Partições | sem limites |
| Máximo de conexões do cliente | sem limites |
| Máximo de tentativas de conexão | sem limites |
| Máximo de solicitações (por segundo) | sem limites |
| Tamanho máx. da mensagem (MB) | sem limites |
| Tamanho máximo da solicitação (MB) | sem limites |
| Máximo de bytes de extração (MB) | sem limites |
| Chaves de API | Não Aplicável |
| ACLs | sem limites |
| Configurações | 100 por tenancy |
| Atualizações de configuração | sem limites |
Limites de Recursos
| Recurso | Suporte |
|---|---|
| Exatamente uma vez semântica | Sim |
| Armazenamento compactado baseado em chave | Sim |
| Conectores personalizados | Não |
| Suporte nativo a ksqlDB | Não |
| Rede pública | Não |
| Rede privada | Sim |
| OAuth | Não |
| Logs de auditoria | Sim |
| Chaves de criptografia autogerenciadas | Não |
| Dimensionamento elástico automático | Não |
| Compartilhamento de fluxo | Não |
| Cotas de cliente | Sim |
Tipos de Cluster
No OCI Streaming com Apache Kafka, você pode criar dois tipos de clusters.
- Cluster Inicial
- Projetado para fins de teste e desenvolvimento, em que a alta disponibilidade não é um requisito crítico. Um cluster inicial oferece uma configuração flexível onde os clusters podem ter entre 1 e 30 corretores.
- Cluster de Alta Disponibilidade
- Destinado a ambientes de produção em que a alta disponibilidade é essencial. Esses clusters são configurados com um mínimo de 3 brokers distribuídos em vários domínios de disponibilidade ou falha para garantir redundância e tolerância a falhas. O cluster pode ser ampliado para um máximo de 30 corretores, fornecendo confiabilidade e resiliência para cargas de trabalho de missão crítica.
Opções Padrão do Cluster
Verifique as seguintes opções padrão para um cluster do Kafka.
- Conectividade
- Por padrão, todos os clusters Kafka são criados com conectividade privada e podem ser acessados de dentro da VCN e da sub-rede especificadas durante a criação do cluster. Se mais VCNs precisarem de acesso ao cluster do Kafka, configure o pareamento de VCN.
- Cotas de disco do broker
- Por padrão, as cotas de disco do broker são impostas para garantir a estabilidade e evitar o uso excessivo dos recursos de disco. Quando um disco de corretores atinge 97% de capacidade, a operação do produtor é limitada pela taxa, enquanto as operações do consumidor não são afetadas e continuam funcionando conforme esperado. Quando um disco de broker atinge 98% de capacidade, todas as operações do produtor são bloqueadas, enquanto as operações do consumidor podem continuar consumindo eventos e confirmando compensações sem interrupção. Você pode alterar esse comportamento padrão e definir cotas de armazenamento personalizadas em um arquivo de configuração de cluster.
- Arquivo de Configuração de Cluster
- Quando você cria um cluster do Kafka, o arquivo de configuração do cluster é criado com propriedades padrão dependendo do tipo de cluster. As configurações da propriedade são projetadas para equilibrar confiabilidade, durabilidade e facilidade de uso. Você pode usar o arquivo padrão ou criar um personalizado. Para obter uma lista de propriedades configuráveis e não configuráveis, consulte Gerenciando Configurações de Cluster.
Cluster de Alta Disponibilidade
allow.everyone.if.no.acl.found=true auto.create.topics.enable=false leader.imbalance.per.broker.percentage=1 default.replication.factor=3 offsets.topic.replication.factor=3 min.insync.replicas=2 transaction.state.log.min.isr=2 transaction.state.log.replication.factor=3Propriedade Valor Padrão Finalidade allow.everyone.if.no.acl.foundverdadeiro Se nenhuma ACL for encontrada para um recurso, todos os usuários terão acesso ao cluster. auto.create.topics.enablefalso Os tópicos não são criados automaticamente, eles devem ser criados explicitamente para melhor controle. leader.imbalance.per.broker.percentage1 Controla o limite de desequilíbrio do líder por broker para rebalanceamento. default.replication.factor3 Novos tópicos são criados com 3 réplicas para alta durabilidade. offsets.topic.replication.factor3 O tópico de compensações internas é replicado 3 vezes para resiliência. min.insync.replicas2 Pelo menos 2 réplicas devem reconhecer uma gravação para durabilidade. transaction.state.log.min.isr2 Réplicas mínimas de sincronização para o log de estado da transação. transaction.state.log.replication.factor3 Fator de replicação para o log de estado da transação. Cluster inicial
allow.everyone.if.no.acl.found=true auto.create.topics.enable=false leader.imbalance.per.broker.percentage=1 default.replication.factor=1 offsets.topic.replication.factor=1 min.insync.replicas=1 transaction.state.log.min.isr=1 transaction.state.log.replication.factor=1Propriedade Valor Padrão Finalidade allow.everyone.if.no.acl.foundverdadeiro Se nenhuma ACL for encontrada para um recurso, todos os usuários terão acesso ao cluster. auto.create.topics.enablefalso Os tópicos não são criados automaticamente, eles devem ser criados explicitamente para melhor controle. leader.imbalance.per.broker.percentage1 Controla o limite de desequilíbrio do líder por broker para rebalanceamento. default.replication.factor1 Novos tópicos são criados com 1 réplica (sem redundância). offsets.topic.replication.factor1 O tópico de compensações internas tem uma única réplica. min.insync.replicas1 Apenas 1 réplica precisa confirmar uma gravação. transaction.state.log.min.isr1 Réplicas mínimas de sincronização para o log de estado da transação. transaction.state.log.replication.factor1 Fator de replicação para o log de estado da transação.
Tamanho e Armazenamento do Cluster do Plano
Revise as diretrizes de dimensionamento de cluster para otimizar e aproveitar ao máximo um cluster do OCI Streaming com Apache Kafka.
Diretrizes Gerais
Se você precisar de mais throughput, poderá implementar as seguintes ações:
- Aumentar o número de corretores no cluster
- Aumentar o número de partições no cluster
- Aumentar OCPU por broker
Se você precisar de menor latência, poderá implementar as seguintes ações:
- Use corretores maiores com maior memória
- Use batches menores,
linger.msmenores e otimize o caminho da rede
Se a durabilidade for mais importante que a latência, considere definir o parâmetro de configuração do produtor acks definido como all.
Não planejar e configurar o cluster afeta o desempenho do cluster.
- A configuração de menos corretores resulta em baixo throughput, alta latência e sobrecarga de corretores.
- A configuração de menos partições resulta em paralelismo ruim e baixo uso do consumidor.
- A configuração de corretores com baixa potência resulta em alta latência de extração ou produção, problemas de GC e corretores instáveis.
- A configuração de muitas partições em brokers menores resulta em alto uso de memória, metadados inchados e rebalanceamento instável.
Benchmarks de Desempenho
Revise as métricas de desempenho em clusters Kafka com processadores baseados em Arm, fator de replicação definido como 3 e o parâmetro de configuração do produtor acks definido como 1.
| Configuração do Broker | Partições | Throughput Máximo do Produtor | Throughput Máximo do Consumidor | Latência |
|---|---|---|---|---|
3 corretores, cada um com a seguinte configuração:
|
1,000 | 161.21 MB por segundo | 394.38 MB por segundo | 50,70 ms |
3 corretores, cada um com a seguinte configuração:
|
2,000 | 368.76 MB por segundo | 678.39 MB por segundo | 27,79 ms |
3 corretores, cada um com a seguinte configuração:
|
2,000 | 505.13 MB por segundo | 710.82 MB por segundo | 21,11 ms |
18 corretores, cada um com a seguinte configuração:
|
2,000 | 379.39 MB por segundo | 690.27 MB por segundo | 80,18 ms |
18 corretores, cada um com a seguinte configuração:
|
4,000 | 788.73 MB por segundo | 998.11 MB por segundo | 74,53 ms |
18 corretores, cada um com a seguinte configuração:
|
4,000 | 1.08 GB por segundo | 1.15 GB por segundo | 71,29 ms |
30 corretores, cada um com a seguinte configuração:
|
4,000 | 617.60 MB por segundo | 1.02 GB por segundo | 98,27 ms |
30 corretores, cada um com a seguinte configuração:
|
6,000 | 1.65 GB por segundo | 1.34 GB por segundo | 65,81 ms |
30 corretores, cada um com a seguinte configuração:
|
6,000 | 2.41 GB por segundo | 2.09 GB por segundo | 56,82 ms |
As métricas de desempenho dependem de vários fatores e melhorias em uma configuração podem levar a compensações em outras.
Por exemplo, os números de throughput variam de acordo com fatores como tamanho da mensagem, tipo de compactação, tamanho do batch e linger.ms. Um tamanho de lote mais alto pode aumentar o throughput, mas também pode levar a uma latência mais alta.
Aumentar o número de partições geralmente melhora o throughput e melhora o desempenho do produtor. No entanto, também aumenta o uso de recursos de produtores e consumidores e introduz mais sobrecarga de metadados. Isso pode retardar a eleição de líderes e o gerenciamento de réplicas em sincronia (ISR), aumentando potencialmente a latência de solicitações de produção e extração.
Você deve ajustar os parâmetros com base nos requisitos.
- Para otimizar para menor latência, reduza
batch.sizeelinger.mse evite compactação pesada. - Para maximizar o throughput, aumente
batch.size, ative a compactação e use mais partições e brokers para escalar horizontalmente.
Sempre monitore as métricas de latência e throughput de perto e ajuste o cluster iterativamente com base nos padrões de carga de trabalho do mundo real.
Migrar
Você pode migrar dados de um cluster do Apache Kafka autogerenciado para um cluster do OCI Streaming com Apache Kafka.
A solução recomendada para esse caso de uso de migração é criar um conector MirrorMaker 2.0 em um Cluster de conexão.
Veja a seguir uma amostra da configuração
client.properties:security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
ssl.truststore.location=</path/to/truststore.jks>
ssl.truststore.password=<truststore-password>
sasl.jaas.config=org.apache.kafka.common.security.scram.ScramLoginModule required username="<username>" password="<password>";